Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #272303 > unrolled thread

Default partition mounts [ "Installation Guide" lacks index ]

Back to article view | Back to linux.debian.user

Contents

  Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-19 13:20 +0200
    Re: Default partition mounts [ "Installation Guide" lacks index ] David <bouncingcats@gmail.com> - 2024-08-19 14:10 +0200
      Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-19 15:50 +0200
        Re: Default partition mounts [ "Installation Guide" lacks index ] Joe <joe@jretrading.com> - 2024-08-19 18:00 +0200
          Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-19 20:20 +0200
    Re: Default partition mounts [ "Installation Guide" lacks index ] Andy Smith <andy@strugglers.net> - 2024-08-19 22:00 +0200
      Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-20 10:50 +0200
        Re: Default partition mounts [ "Installation Guide" lacks index ] "Andrew M.A. Cater" <amacater@einval.com> - 2024-08-20 11:40 +0200
          Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-20 12:50 +0200
            Trixie and i386 - was [Re: Default partition mounts [ "Installation  Guide" lacks index ]] Richard Owlett <rowlett@access.net> - 2024-08-20 14:40 +0200
              Re: Trixie and i386 - was [Re: Default partition mounts [  "Installation Guide" lacks index ]] Charles Curley <charlescurley@charlescurley.com> - 2024-08-20 15:50 +0200
              Future of i386 as installer "Andrew M.A. Cater" <amacater@einval.com> - 2024-08-20 15:50 +0200
        The lack of a future for 32-bit x86 installs (Was Re: Default  partition mounts [ "Installation Guide" lacks index ]) Andy Smith <andy@strugglers.net> - 2024-08-20 17:20 +0200
          Re: The lack of a future for 32-bit x86 installs (Was Re: Default  partition mounts [ "Installation Guide" lacks index ]) Roberto C. Sánchez <roberto@debian.org> - 2024-08-20 18:10 +0200
    Re: Default partition mounts [ "Installation Guide" lacks index ] Tom Dial <tddial@comcast.net> - 2024-08-20 00:50 +0200
      Re: Default partition mounts [ "Installation Guide" lacks index ] David Wright <deblis@lionunicorn.co.uk> - 2024-08-20 05:20 +0200
        Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-20 10:10 +0200
    Re: Default partition mounts [ "Installation Guide" lacks index ] David Christensen <dpchrist@holgerdanske.com> - 2024-08-20 06:30 +0200
      Re: Default partition mounts [ "Installation Guide" lacks index ] Richard Owlett <rowlett@access.net> - 2024-08-20 10:20 +0200
      UEFI multiboot (was: Re: Default partition mounts [ "Installation  Guide" lacks index ]) Max Nikulin <manikulin@gmail.com> - 2024-08-20 17:20 +0200
        Re: UEFI multiboot (was: Re: Default partition mounts [  "Installation Guide" lacks index ]) Erwan David <erwan@rail.eu.org> - 2024-08-20 17:30 +0200
        Re: UEFI multiboot (was: Re: Default partition mounts [  "Installation Guide" lacks index ]) Nicolas George <george@nsup.org> - 2024-08-20 18:00 +0200
          Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation  Guide" lacks index ]) Jeffrey Walton <noloader@gmail.com> - 2024-08-20 18:30 +0200
            Re: UEFI multiboot gene heskett <gheskett@shentel.net> - 2024-08-20 22:20 +0200
          Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-21 06:00 +0200
            Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-21 06:30 +0200
              Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-21 18:20 +0200
                Re: UEFI multiboot Nicolas George <george@nsup.org> - 2024-08-21 19:40 +0200
                Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-22 00:30 +0200
                  Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-22 05:20 +0200
                    Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-22 11:50 +0200
                      Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-22 18:00 +0200
                        Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-22 22:50 +0200
                      [SUMMARY] Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-23 05:10 +0200
                        Re: [SUMMARY] UEFI multiboot Felix Miata <mrmazda@earthlink.net> - 2024-08-23 06:50 +0200
                          Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-30 18:10 +0200
                            Re: UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-08-30 18:50 +0200
                              Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-08-31 04:20 +0200
                            [SUMMARY] Re: UEFI multiboot Max Nikulin <manikulin@gmail.com> - 2024-09-14 06:10 +0200
                              Re: [SUMMARY] UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-09-14 06:40 +0200
                                Re: [SUMMARY] UEFI multiboot songbird <songbird@anthive.com> - 2024-09-14 19:40 +0200
                                  Re: [SUMMARY] UEFI multiboot Felix Miata <mrmazda@stanis.net> - 2024-09-14 21:20 +0200
                                    Re: [SUMMARY] UEFI multiboot "Thomas Schmitt" <scdbackup@gmx.net> - 2024-09-14 21:40 +0200
                                  Re: [SUMMARY] UEFI multiboot Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-09-16 12:20 +0200
                                    Re: [SUMMARY] UEFI multiboot songbird <songbird@anthive.com> - 2024-09-17 01:50 +0200
                    Re: UEFI multiboot Joe <joe@jretrading.com> - 2024-08-22 12:00 +0200
            Re: UEFI multiboot Nicolas George <george@nsup.org> - 2024-08-21 08:50 +0200
              Re: UEFI multiboot Joe <joe@jretrading.com> - 2024-08-21 09:20 +0200

Page 1 of 3  [1] 2 3  Next page →

#272303 — Default partition mounts [ "Installation Guide" lacks index ]

I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
I multi boot [Grub will have at least three options]:
   1. minimalist installation - primarily command line usage
   2. 64 bit Debian with maximum features
   3. 32 bit Debian - couple of applications require a 32 bit OS
   4. other installs with strong project dependencies

Today's question
At boot time, what determines which physical partition gets mounted as a 
specific directory ( /, /home, swap, and so forth )?

Please reference documentation as reading it will remind me of how and 
why I chose specific options.

TIA

P.S. - re-reading https://www.debian.org/releases/stable/amd64/ ;}!

[toc] | [next] | [standalone]

#272304

On Mon, 19 Aug 2024 at 11:19, Richard Owlett <rowlett@access.net> wrote:

> At boot time, what determines which physical partition gets mounted as a
> specific directory ( /, /home, swap, and so forth )?
>
> Please reference documentation as reading it will remind me of how and
> why I chose specific options.

man 5 fstab

https://debian-handbook.info/browse/stable/sect.config-misc.html#sect.fstab-mount-points

[toc] | [prev] | [next] | [standalone]

#272309

THANK YOU

On 08/19/2024 07:02 AM, David wrote:
> On Mon, 19 Aug 2024 at 11:19, Richard Owlett <rowlett@access.net> wrote:
> 
>> At boot time, what determines which physical partition gets mounted as a
>> specific directory ( /, /home, swap, and so forth )?
>>
>> Please reference documentation as reading it will remind me of how and
>> why I chose specific options.
> 
> man 5 fstab

"fstab" was one of the keywords I'd forgotten.

> 
> https://debian-handbook.info/browse/stable/sect.config-misc.html#sect.fstab-mount-points

Browsing that link suggests it will prompt me to ask needed questions.
It's not the document I was visualizing. I was expecting something that 
I would have been reading when new to Linux.
[I remember 026, KSR35 and vacuum tube CPUs ;]

Thanks again.

[toc] | [prev] | [next] | [standalone]

#272314

On Mon, 19 Aug 2024 08:44:39 -0500
Richard Owlett <rowlett@access.net> wrote:

> THANK YOU
> 
> On 08/19/2024 07:02 AM, David wrote:
> > On Mon, 19 Aug 2024 at 11:19, Richard Owlett <rowlett@access.net>
> > wrote: 
> >> At boot time, what determines which physical partition gets
> >> mounted as a specific directory ( /, /home, swap, and so forth )?
> >>
> >> Please reference documentation as reading it will remind me of how
> >> and why I chose specific options.  
> > 
> > man 5 fstab  
> 
> "fstab" was one of the keywords I'd forgotten.
> 
> > 
> > https://debian-handbook.info/browse/stable/sect.config-misc.html#sect.fstab-mount-points  
> 
> Browsing that link suggests it will prompt me to ask needed questions.
> It's not the document I was visualizing. I was expecting something
> that I would have been reading when new to Linux.

Then what you want is not documentation but tutorials. You want
documentation when you know something you need to do but not the exact
details of how. Many man pages are rather short on examples, which
tutorials will provide.

Try Google with:
linux directory mounting on boot tutorial

This will turn up a lot of similar but not identical sites, varying
from a bald list of instructions to do a particular thing, to an
explanation of fundamentals. Some won't mean much to you, ignore them
and move on.

The first step is probably to look at /etc/fstab on a working system
and see what you can understand of it, and what you don't understand.
That's certainly where partitions are named, along with filesystem
directories and the mapping between them. The documentation is where
you find what the mounting parameters mean and do. Apart from fstab
itself, you'll need the man pages for the mount commands for whatever
filesystem types are named in fstab e.g. mount.cifs, as many parameters
are specific to the filesystem type.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#272318

On 08/19/2024 10:57 AM, Joe wrote:
> On Mon, 19 Aug 2024 08:44:39 -0500
> Richard Owlett <rowlett@access.net> wrote:
> 
>> THANK YOU
>>
>> On 08/19/2024 07:02 AM, David wrote:
>>> On Mon, 19 Aug 2024 at 11:19, Richard Owlett <rowlett@access.net>
>>> wrote:
>>>> At boot time, what determines which physical partition gets
>>>> mounted as a specific directory ( /, /home, swap, and so forth )?
>>>>
>>>> Please reference documentation as reading it will remind me of how
>>>> and why I chose specific options.
>>>
>>> man 5 fstab
>>
>> "fstab" was one of the keywords I'd forgotten.
>>
>>>
>>> https://debian-handbook.info/browse/stable/sect.config-misc.html#sect.fstab-mount-points
>>
>> Browsing that link suggests it will prompt me to ask needed questions.
>> It's not the document I was visualizing. I was expecting something
>> that I would have been reading when new to Linux.
> 
> Then what you want is not documentation but tutorials. You want
> documentation when you know something you need to do but not the exact
> details of how. Many man pages are rather short on examples, which
> tutorials will provide.
> 
> Try Google with:
> linux directory mounting on boot tutorial
> 
> This will turn up a lot of similar but not identical sites, varying
> from a bald list of instructions to do a particular thing, to an
> explanation of fundamentals. Some won't mean much to you, ignore them
> and move on.
> 
> The first step is probably to look at /etc/fstab on a working system
> and see what you can understand of it, and what you don't understand.
> That's certainly where partitions are named, along with filesystem
> directories and the mapping between them. The documentation is where
> you find what the mounting parameters mean and do. Apart from fstab
> itself, you'll need the man pages for the mount commands for whatever
> filesystem types are named in fstab e.g. mount.cifs, as many parameters
> are specific to the filesystem type.
> 

IMHO "tutorial" is a sub-set of "documentation".
And the "magic string" is "/etc/fstab" ;}
[I had modified the one on this machine. Whenever I modify a default 
file, I *include comments* about *why*.]

[toc] | [prev] | [next] | [standalone]

#272320

Hi,

I'm afraid I have not got the kind of answer you request for your
actual question but…

On Mon, Aug 19, 2024 at 06:19:26AM -0500, Richard Owlett wrote:
> I'm over 80 and doing first "from scratch" install since Squeeze ;}
> Hardware is Lenovo R61 ThinkPad (64 bit).
> I multi boot [Grub will have at least three options]:
>   1. minimalist installation - primarily command line usage
>   2. 64 bit Debian with maximum features
>   3. 32 bit Debian - couple of applications require a 32 bit OS

All 32-bit x86 software runs on a 64-bit kernel no problem¹ on
Debian, so it's unlikely you actually need to dedicate a whole
install to a 32-bit kernel, which also as previously mentioned has a
single digit of years of remaining lifetime in Debian.

>   4. other installs with strong project dependencies

Dependencies can indeed get out of hand sometimes.

I don't know how much you are up for a learning experience but
virtual machines or containers can often be a good way to
compartmentalise projects and their dependencies without needing to
do whole separate installs.

So you see, I think your use case can be handled with only one
Debian install, using containers or VMs for the projects with a lot
of dependencies. But I appreciate it's a lot to get stuck into.

> Today's question
> At boot time, what determines which physical partition gets mounted as a
> specific directory ( /, /home, swap, and so forth )?

You asked for pointers to complete documentation on this and I can't
do that which is why I said this wasn't going to be an answer to
your actual question.

A summary however is that:

The grub entry provides an initramfs and a device for use as root.

The initramfs provides a temporary root filesystem containing all of
the tools necessary to mount the actual root device as root.

It then mounts root (which must also contain /etc). If root did not
also contain /usr then that is also mounted at this point.

The real init from the root filesystem (systemd) then takes
over, looks at /etc/fstab and mounts everything² in there at the
places it says.

So, there are multiple things going on here as regards what gets
mounted where. The bootloader entry decides which device / will be
on (you can test this by changing / in the fstab — whatever is in
the bootloader entry will prevail). The initramfs can mount things
outside of the direction of fstab but tyoically doesn't. Then the
init system from the real root filesystem reads /etc/fstab.

Finally there can be systemd .mount units outside of fstab, but
again that is not typical and you'd know if you added those.

Thanks,
Andy

¹ By which I mean if it runs on a 32-bit kernel it will work on a
  64-bit kernel as well unless they went out of their way to ensure
  it won't work.

² Some things in /etc/fstab can be set to "noauto" to prevent them
  being automatically mounted at boot time.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#272340

On 08/19/2024 02:51 PM, Andy Smith wrote:
> Hi,
> 
> I'm afraid I have not got the kind of answer you request for your
> actual question but…
> 
> On Mon, Aug 19, 2024 at 06:19:26AM -0500, Richard Owlett wrote:
>> I'm over 80 and doing first "from scratch" install since Squeeze ;}
>> Hardware is Lenovo R61 ThinkPad (64 bit).
>> I multi boot [Grub will have at least three options]:
>>    1. minimalist installation - primarily command line usage
>>    2. 64 bit Debian with maximum features
>>    3. 32 bit Debian - couple of applications require a 32 bit OS
> 
> All 32-bit x86 software runs on a 64-bit kernel no problem¹ on
> Debian, so it's unlikely you actually need to dedicate a whole
> install to a 32-bit kernel, which also as previously mentioned has a
> single digit of years of remaining lifetime in Debian.

I don't see anything on https://wiki.debian.org/LTS that implies shorter 
lifetime for i386 than anything else.

> 
>>    4. other installs with strong project dependencies
> 
> Dependencies can indeed get out of hand sometimes.

I wasn't speaking of "software dependencies". For different projects I 
want different "working environments".

> 
> I don't know how much you are up for a learning experience but
> virtual machines or containers can often be a good way to
> compartmentalise projects and their dependencies without needing to
> do whole separate installs.
> 
> So you see, I think your use case can be handled with only one
> Debian install, using containers or VMs for the projects with a lot
> of dependencies. But I appreciate it's a lot to get stuck into.

I looked into VMs long ago. For my style - no advantages worth the effort.

> 
>> Today's question
>> At boot time, what determines which physical partition gets mounted as a
>> specific directory ( /, /home, swap, and so forth )?
> 
> You asked for pointers to complete documentation on this and I can't
> do that which is why I said this wasn't going to be an answer to
> your actual question.
> 
> A summary however is that:
> 
> The grub entry provides an initramfs and a device for use as root.
> 
> The initramfs provides a temporary root filesystem containing all of
> the tools necessary to mount the actual root device as root.
> 
> It then mounts root (which must also contain /etc). If root did not
> also contain /usr then that is also mounted at this point.
> 
> The real init from the root filesystem (systemd) then takes
> over, looks at /etc/fstab and mounts everything² in there at the
> places it says.
> 
> So, there are multiple things going on here as regards what gets
> mounted where. The bootloader entry decides which device / will be
> on (you can test this by changing / in the fstab — whatever is in
> the bootloader entry will prevail). The initramfs can mount things
> outside of the direction of fstab but tyoically doesn't. Then the
> init system from the real root filesystem reads /etc/fstab.
> 
> Finally there can be systemd .mount units outside of fstab, but
> again that is not typical and you'd know if you added those.
> 
> Thanks,
> Andy
> 
> ¹ By which I mean if it runs on a 32-bit kernel it will work on a
>    64-bit kernel as well unless they went out of their way to ensure
>    it won't work.
> 
> ² Some things in /etc/fstab can be set to "noauto" to prevent them
>    being automatically mounted at boot time.
> 

[toc] | [prev] | [next] | [standalone]

#272341

On Tue, Aug 20, 2024 at 03:44:03AM -0500, Richard Owlett wrote:
> On 08/19/2024 02:51 PM, Andy Smith wrote:
> > Hi,
> > 
> > I'm afraid I have not got the kind of answer you request for your
> > actual question but…
> > 

Hi Richard,

A first question: is this your main computer?

The R61 is from 2007 or so - so more than 15 years old.
It has a 160GB spinning disk, if I'm reading the specs correctly, and 1GB of
memory.

> > On Mon, Aug 19, 2024 at 06:19:26AM -0500, Richard Owlett wrote:
> > > I'm over 80 and doing first "from scratch" install since Squeeze ;}
> > > Hardware is Lenovo R61 ThinkPad (64 bit).
> > > I multi boot [Grub will have at least three options]:
> > >    1. minimalist installation - primarily command line usage
> > >    2. 64 bit Debian with maximum features
> > >    3. 32 bit Debian - couple of applications require a 32 bit OS
> > 
> > All 32-bit x86 software runs on a 64-bit kernel no problem¹ on
> > Debian, so it's unlikely you actually need to dedicate a whole
> > install to a 32-bit kernel, which also as previously mentioned has a
> > single digit of years of remaining lifetime in Debian.
> 
> I don't see anything on https://wiki.debian.org/LTS that implies shorter
> lifetime for i386 than anything else.
> 
There will be non i386 installer medium for Trixie when released though
i386 will be retained as a release architecture. There are already
packages which cannot be built within i386 limitations so the architecture
is mostly built using amd64. Some packages for i386 will not now build
even on amd64 because of compiler changes. i386 is dead but won't lie down :)

> > 
> > >    4. other installs with strong project dependencies
> > 
> > Dependencies can indeed get out of hand sometimes.
> 
> I wasn't speaking of "software dependencies". For different projects I want
> different "working environments".
> 

A single install with all directories in one partition using LVM would be
most straightforward. In 160GB and booting using MBR/legacy, you may
run out of disk physical partitions anyway.

Install with GUI for general use. Switch to a full screen VT for
command line use, maybe?

> > 
> > I don't know how much you are up for a learning experience but
> > virtual machines or containers can often be a good way to
> > compartmentalise projects and their dependencies without needing to
> > do whole separate installs.
> > 

Absolutely agreed: the problem is the 1GB memory

<snip>

> 
> I looked into VMs long ago. For my style - no advantages worth the effort.
> 
> > Finally there can be systemd .mount units outside of fstab, but
> > again that is not typical and you'd know if you added those.
> > 
> > Thanks,
> > Andy
> > 
>

Richard,

You are going to be *significantly* limited by hardware here with the
size and memory requirements of modern Debian. Make life simpler:
install a desktop environment with lower memory requirements like XFCE
and try and minimise diverse requirements.

*DO* read the release notes. If you want to make significant customisations,
I'd suggest a text only install, maybe using the expert install option.

All the very best, as ever,

Andy
(amacater@debian.org) 
> 

[toc] | [prev] | [next] | [standalone]

#272342

On 08/20/2024 04:30 AM, Andrew M.A. Cater wrote:
> On Tue, Aug 20, 2024 at 03:44:03AM -0500, Richard Owlett wrote:
>> On 08/19/2024 02:51 PM, Andy Smith wrote:
>>> Hi,
>>>
>>> I'm afraid I have not got the kind of answer you request for your
>>> actual question but…
>>>
> 
> Hi Richard,
> 
> A first question: is this your main computer?

No.		But it is one of my *NEWER* machineS.
My i386 based desktop preceded Debian Stretch by several years ;}
Its primary attraction is that it is a conveniently available and 
suitably capable machine.

> 
> The R61 is from 2007 or so - so more than 15 years old.
> It has a 160GB spinning disk, if I'm reading the specs correctly, and 1GB of
> memory.

I routinely use a Dell Latitude E6410. [circa 2010 IIRC ;]

> 
>>> On Mon, Aug 19, 2024 at 06:19:26AM -0500, Richard Owlett wrote:
>>>> I'm over 80 and doing first "from scratch" install since Squeeze ;}
>>>> Hardware is Lenovo R61 ThinkPad (64 bit).
>>>> I multi boot [Grub will have at least three options]:
>>>>     1. minimalist installation - primarily command line usage
>>>>     2. 64 bit Debian with maximum features
>>>>     3. 32 bit Debian - couple of applications require a 32 bit OS
>>>
>>> All 32-bit x86 software runs on a 64-bit kernel no problem¹ on
>>> Debian, so it's unlikely you actually need to dedicate a whole
>>> install to a 32-bit kernel, which also as previously mentioned has a
>>> single digit of years of remaining lifetime in Debian.
>>
>> I don't see anything on https://wiki.debian.org/LTS that implies shorter
>> lifetime for i386 than anything else.
>>
> There will be non i386 installer medium for Trixie when released though
> i386 will be retained as a release architecture.

Can you point me to the details. I have two i386 I wish to use as long 
as possible.
[I suspect I could satisfy much of my usage with my Kaypro 10 if dial-up 
service still existed ;]

> There are already
> packages which cannot be built within i386 limitations so the architecture
> is mostly built using amd64. Some packages for i386 will not now build
> even on amd64 because of compiler changes. i386 is dead but won't lie down :)

You mean there are others like me out there? *ROFL*

> 
>>>
>>>>     4. other installs with strong project dependencies
>>>
>>> Dependencies can indeed get out of hand sometimes.
>>
>> I wasn't speaking of "software dependencies". For different projects I want
>> different "working environments".
>>
> 
> A single install with all directories in one partition using LVM would be
> most straightforward. In 160GB and booting using MBR/legacy, you may
> run out of disk physical partitions anyway.
> 
> Install with GUI for general use. Switch to a full screen VT for
> command line use, maybe?

I'm a GUI person. Though I date from 026/KSR35 era I do like some modern 
conveniences.

> 
>>>
>>> I don't know how much you are up for a learning experience but
>>> virtual machines or containers can often be a good way to
>>> compartmentalise projects and their dependencies without needing to
>>> do whole separate installs.
>>>
> 
> Absolutely agreed: the problem is the 1GB memory
> 
> <snip>
> 
>>
>> I looked into VMs long ago. For my style - no advantages worth the effort.
>>
>>> Finally there can be systemd .mount units outside of fstab, but
>>> again that is not typical and you'd know if you added those.
>>>
>>> Thanks,
>>> Andy
>>>
>>
> 
> Richard,
> 
> You are going to be *significantly* limited by hardware here with the
> size and memory requirements of modern Debian. Make life simpler:
> install a desktop environment with lower memory requirements like XFCE
> and try and minimise diverse requirements.
> 
> *DO* read the release notes. If you want to make significant customisations,
> I'd suggest a text only install, maybe using the expert install option.
> 
> All the very best, as ever,
> 
> Andy
> (amacater@debian.org)
>>
> 
> 

[toc] | [prev] | [next] | [standalone]

#272345 — Trixie and i386 - was [Re: Default partition mounts [ "Installation Guide" lacks index ]]

On 08/20/2024 05:45 AM, Richard Owlett wrote:
> On 08/20/2024 04:30 AM, Andrew M.A. Cater wrote:
>>[snip]
>> There will be non i386 installer medium for Trixie when released though
>> i386 will be retained as a release architecture.
> 
> Can you point me to the details. I have two i386 I wish to use as long 
> as possible.

I don't know if this is what Andrew was referring to, but I just found:
> Debian 13 will continue to support 32 bit x86 processors, however
> the lower limit is now i686.
https://en.wikipedia.org/wiki/Debian_version_history
which refers to
"Debian Trixie release notes"
https://www.debian.org/releases/trixie/release-notes/issues.en.html#i386-is-i686
which states (in part)
> 5.1.13. Baseline for 32-bit PC is now i686¶
> 
> Debian's support for 32-bit PC (known as the Debian architecture i386)
> now no longer covers any i586 processor. The new minimum requirement
> is i686. This means that the i386 architecture now requires the "long NOP" (NOPL)
> instruction, while bullseye still supported some i586 processors without
> that instruction (e.g. the "AMD Geode").

[snip]

[toc] | [prev] | [next] | [standalone]

#272347 — Re: Trixie and i386 - was [Re: Default partition mounts [ "Installation Guide" lacks index ]]

On Tue, 20 Aug 2024 07:34:33 -0500
Richard Owlett <rowlett@access.net> wrote:

> > 5.1.13. Baseline for 32-bit PC is now i686¶
> > 
> > Debian's support for 32-bit PC (known as the Debian architecture
> > i386) now no longer covers any i586 processor. The new minimum
> > requirement is i686. This means that the i386 architecture now
> > requires the "long NOP" (NOPL) instruction, while bullseye still
> > supported some i586 processors without that instruction (e.g. the
> > "AMD Geode").  

Even this isn't entirely correct. I have four nice Geode based
machines, one of which is still in daily service. Applications may not
run on them. I was not able to get an appletalk server working well on
one because of instruction set issues. I did not pursue the issue. I
moved the appletalk server to a more modern (and faster and more
capacious) machine.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#272348 — Future of i386 as installer

On Tue, Aug 20, 2024 at 07:34:33AM -0500, Richard Owlett wrote:
> On 08/20/2024 05:45 AM, Richard Owlett wrote:
> > On 08/20/2024 04:30 AM, Andrew M.A. Cater wrote:
> > > [snip]
> > > There will be non i386 installer medium for Trixie when released though
> > > i386 will be retained as a release architecture.
> > 
> > Can you point me to the details. I have two i386 I wish to use as long
> > as possible.
> 

Thanks to my colleagues with a good memory: it was announced after the
Cambridge mini-DebConf by the release team:

https://lists.debian.org/debian-devel-announce/2023/12/msg00003.html

"A future for the i386 architecture
==================================

Insofar as they still do, we anticipate that the kernel, d-i and images teams
will cease to support i386 in the near future. Following that, there are two
routes into running i386:

1. as a multi-arch option on an otherwise amd64 system
2. as an i386 chroot on another architecture system

We're not planning to make i386 a partial architecture in the way [1] Ubuntu
has, arch:any will still contain i386 so everything builds by
default. Maintainers who wish to drop i386 support can do so *after*
coordination with the reverse (build) dependencies of their package, as with
dropping support for any other architecture. We also like to note that we have
no opposition to changes to the baseline when these changes land (it's a port
matter)."

> I don't know if this is what Andrew was referring to, but I just found:
> > Debian 13 will continue to support 32 bit x86 processors, however
> > the lower limit is now i686.
> https://en.wikipedia.org/wiki/Debian_version_history
> which refers to
> "Debian Trixie release notes"
> https://www.debian.org/releases/trixie/release-notes/issues.en.html#i386-is-i686
> which states (in part)
> > 5.1.13. Baseline for 32-bit PC is now i686¶
> > 
> > Debian's support for 32-bit PC (known as the Debian architecture i386)
> > now no longer covers any i586 processor. The new minimum requirement
> > is i686. This means that the i386 architecture now requires the "long NOP" (NOPL)
> > instruction, while bullseye still supported some i586 processors without
> > that instruction (e.g. the "AMD Geode").
> 

As above: there won't be an installer.

Hope this helps, as ever,

Andrew Cater
(amacater@debian.org)
> [snip]
> 
> 

[toc] | [prev] | [next] | [standalone]

#272350 — The lack of a future for 32-bit x86 installs (Was Re: Default partition mounts [ "Installation Guide" lacks index ])

Hello,

On Tue, Aug 20, 2024 at 03:44:03AM -0500, Richard Owlett wrote:
> On 08/19/2024 02:51 PM, Andy Smith wrote:
> > [32-bit x86] as previously mentioned has a single digit of years
> > of remaining lifetime in Debian.
> 
> I don't see anything on https://wiki.debian.org/LTS that implies shorter
> lifetime for i386 than anything else.

The LTS page covers lifetimes for things currently released in
Debian whereas I am talking about the expected release architectures
for future Debian releases and their support lifetimes.

The plans for the next release of Debian ("trixie") some time in
2025 do not include installer support for 32-bit x86 or a 32-bit x86
kernel, so the lifetime for a 32-bit kernel in Debian is now
bookworm plus the 5 years of its LTS. The expected long term route
to run 32-bit x86 software on Debian is on a 64-bit kernel.

As a result anything you install as 32-bit x86 now has no upgrade
path and quite limited support future. A 64-bit install has a more
promising future as the running of 32-bit packages is still planned
to be supported for quite a while to come.

Then there is the fact that the LTS team can and does mark packages
as unsupportable for the lifetime of LTS when they need to, so just
because LTS team exists doesn't mean they can get around to
supporting 32-bit x86 installer/kernel. I would not be at all
surprised if they gave up on it before the end of bookworm LTS.

Note also that the email that Andrew Cater linked to was very
careful in its wording. When it said, "Insofar as they still do, we
anticipate that the kernel, d-i and images teams will cease to
support i386 in the near future" — this is your clue that very few
people are actually supporting this *right now*. Indeed, one¹ reason
why 32-bit x86 support is being dropped (everywhere) isn't because
no one wants it or no one uses it, but because (close to) no one in
the upstream Linux kernel and toolchain community is *supporting*
it, which leads to it being unsupportable in Debian. Already, and
for a number of years before now.

Debian Release Managers decide what meets the grade for a release
architecture:

    https://release.debian.org/testing/arch_qualify.html

32-bit x86 is a really bad idea for new installs on hardware that
can do amd64, and has been for a long time.

Thanks,
Andy

¹ The other big one for Debian is the inability to build some big
  32-bit x86 packages on native 32-bit x86 build hosts due to the
  limited address space. Building them on amd64 would work but I
  don't think it's seen as a priority.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#272356 — Re: The lack of a future for 32-bit x86 installs (Was Re: Default partition mounts [ "Installation Guide" lacks index ])

On Tue, Aug 20, 2024 at 03:17:02PM +0000, Andy Smith wrote:
> 
> Then there is the fact that the LTS team can and does mark packages
> as unsupportable for the lifetime of LTS when they need to, so just
> because LTS team exists doesn't mean they can get around to
> supporting 32-bit x86 installer/kernel. I would not be at all
> surprised if they gave up on it before the end of bookworm LTS.
> 
Some other things to consider.

Once the LTS team takes over maintenance of a given release, the kernel
updates switch to a backport of the kernel from release+1. For instance,
with buster (which shipped with linux-4.19) since it switched to being
under the responsibility of the LTS team has received backports of
linux-5.10 (from bullseye). So, if you're thinking about the lifetime of
bullseye (which will extend another 2-ish years from now under LTS),
then it will receive backports of the bookworm kernel. If that kernel
version discontinues 32-bit support (to where it cannot be feasibly
maintained in bookworm), then it will likewise cease to have 32-bit
support in bullseye.

As far as installers, the LTS team does not produce installers. The
installer team's commitment is only for 3 years following release, so
whatever installers are available are the only ones which will be
available. But, as has been stated elsewhere in this discussion, new
installs of 32-bit x86 are not a good idea. Relatedly, if you find
yourself creating a fresh install of a 3, 4, or 5 years old Debian
release, you should really question whether that is a good idea. And
then realize that if you decide to install anyways that support will
become progressively more challenging.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#272322

On 8/19/24 05:19, Richard Owlett wrote:
> I'm over 80 and doing first "from scratch" install since Squeeze ;}
> Hardware is Lenovo R61 ThinkPad (64 bit).
> I multi boot [Grub will have at least three options]:
>    1. minimalist installation - primarily command line usage
>    2. 64 bit Debian with maximum features
>    3. 32 bit Debian - couple of applications require a 32 bit OS
>    4. other installs with strong project dependencies
> 
> Today's question
> At boot time, what determines which physical partition gets mounted as a specific directory ( /, /home, swap, and so forth )?

In most cases, mount actions are as described in /etc/fstab of the image being booted. See the manpage for fstab. The significant exception I am aware of would be a case in which there are ZFS file systems, for which mount points are specified within the file system.

Note that fstab (5) is not a complete specification; in particular, the list of mount options is not complete. Additional information can be had from the mount (5) manpage, which has a more complete list of general mount options and references to applicable manpages for filesystem specific options.

If you use an installer, /etc/fstab normally will be set up correctly for the instance during installation, and may be modified by editing /etc/fstab (for instance, to enable data exchange by cross mounting one or more partitions used primarily by a different image).

Regards,
Tom Dial

> 
> Please reference documentation as reading it will remind me of how and why I chose specific options.
> 
> TIA
> 
> P.S. - re-reading https://www.debian.org/releases/stable/amd64/ ;}!

[toc] | [prev] | [next] | [standalone]

#272333

On Mon 19 Aug 2024 at 16:23:31 (-0600), Tom Dial wrote:
> On 8/19/24 05:19, Richard Owlett wrote:
> > I'm over 80 and doing first "from scratch" install since Squeeze ;}
> > Hardware is Lenovo R61 ThinkPad (64 bit).
> > I multi boot [Grub will have at least three options]:
> >    1. minimalist installation - primarily command line usage
> >    2. 64 bit Debian with maximum features
> >    3. 32 bit Debian - couple of applications require a 32 bit OS
> >    4. other installs with strong project dependencies
> > 
> > Today's question
> > At boot time, what determines which physical partition gets mounted as a specific directory ( /, /home, swap, and so forth )?
> 
> In most cases, mount actions are as described in /etc/fstab of the image being booted.

AFAICT the /etc/fstab in the boot images of all my Debian systems
is empty. It's only when the root filesystem gets mounted that a
non-empty /etc/fstab becomes available.

OTOH a netinst installer's image does have a populated /etc/fstab,
but only with:

  devpts     /dev/pts     devpts  defaults    0   0
  tmpfs      /run         tmpfs   nosuid,size=10%,mode=755    0   0
  proc       /proc        proc    defaults    0   0
  sysfs      /sys         sysfs   noauto      0   0

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#272338

On 08/19/2024 10:17 PM, David Wright wrote:
> On Mon 19 Aug 2024 at 16:23:31 (-0600), Tom Dial wrote:
>> On 8/19/24 05:19, Richard Owlett wrote:
>>> I'm over 80 and doing first "from scratch" install since Squeeze ;}
>>> Hardware is Lenovo R61 ThinkPad (64 bit).
>>> I multi boot [Grub will have at least three options]:
>>>     1. minimalist installation - primarily command line usage
>>>     2. 64 bit Debian with maximum features
>>>     3. 32 bit Debian - couple of applications require a 32 bit OS
>>>     4. other installs with strong project dependencies
>>>
>>> Today's question
>>> At boot time, what determines which physical partition gets mounted as a specific directory ( /, /home, swap, and so forth )?
>>
>> In most cases, mount actions are as described in /etc/fstab of the image being booted.
> 
> AFAICT the /etc/fstab in the boot images of all my Debian systems
> is empty. It's only when the root filesystem gets mounted that a
> non-empty /etc/fstab becomes available.
> 
> OTOH a netinst installer's image does have a populated /etc/fstab,
> but only with:
> 
>    devpts     /dev/pts     devpts  defaults    0   0
>    tmpfs      /run         tmpfs   nosuid,size=10%,mode=755    0   
0
>    proc       /proc        proc    defaults    0   0
>    sysfs      /sys         sysfs   noauto      0   0
> 
> Cheers,
> David.
> 
> 

As I said in a previous reply, the existence of "/etc/fstab" was the 
key. I read the *comments* I had put in mine had triggered memories of 
what I had done and why :}

[toc] | [prev] | [next] | [standalone]

#272335

On 8/19/24 04:19, Richard Owlett wrote:
> I'm over 80 and doing first "from scratch" install since Squeeze ;}
> Hardware is Lenovo R61 ThinkPad (64 bit).
> I multi boot [Grub will have at least three options]:
>    1. minimalist installation - primarily command line usage
>    2. 64 bit Debian with maximum features
>    3. 32 bit Debian - couple of applications require a 32 bit OS
>    4. other installs with strong project dependencies
> 
> Today's question
> At boot time, what determines which physical partition gets mounted as a 
> specific directory ( /, /home, swap, and so forth )?
> 
> Please reference documentation as reading it will remind me of how and 
> why I chose specific options.
> 
> TIA
> 
> P.S. - re-reading https://www.debian.org/releases/stable/amd64/ ;}!


I tried multi-boot back in the day (e.g. BIOS/MBR) -- it was not for me. 
  My solution was to buy multiple disks and put one OS on each.  You 
could do this -- the disk drive in the Lenovo R61 ThinkPad is externally 
accessible:

https://www.ifixit.com/Guide/Lenovo+ThinkPad+R61i+Hard+Drive+Replacement/118125


AIUI UEFI/GPT were designed to support multi-boot, but one-disk-per-OS 
is KISS -- each installer can have its way with the entire disk, and the 
installed OS just works (if it supports your hardware).


That said, the fundamental problem with either approach is that no 
matter which OS you are running, you want something in another OS that 
is not running.  Back in the day, I bought additional computers.  Today, 
there are several high quality hypervisors to choose from.


A key consideration is where to put your data, so that it is accessible 
from whichever OS you happen to be running.  Solutions include a file 
server, a NAS, and another drive with a lowest-common-denominator file 
system (e.g. FAT32, ExFAT, or NTFS).


David

[toc] | [prev] | [next] | [standalone]

#272339

On 08/19/2024 11:27 PM, David Christensen wrote:
> On 8/19/24 04:19, Richard Owlett wrote:
>> I'm over 80 and doing first "from scratch" install since Squeeze ;}
>> Hardware is Lenovo R61 ThinkPad (64 bit).
>> I multi boot [Grub will have at least three options]:
>>    1. minimalist installation - primarily command line usage
>>    2. 64 bit Debian with maximum features
>>    3. 32 bit Debian - couple of applications require a 32 bit OS
>>    4. other installs with strong project dependencies
>>
>> Today's question
>> At boot time, what determines which physical partition gets mounted as 
>> a specific directory ( /, /home, swap, and so forth )?
>>
>> Please reference documentation as reading it will remind me of how and 
>> why I chose specific options.
>>
>> TIA
>>
>> P.S. - re-reading https://www.debian.org/releases/stable/amd64/ ;}!
> 
> 
> I tried multi-boot back in the day (e.g. BIOS/MBR) -- it was not for me. 

To each his own <GRIN>

>   My solution was to buy multiple disks and put one OS on each.  You 
> could do this -- the disk drive in the Lenovo R61 ThinkPad is externally 
> accessible:
> 
> https://www.ifixit.com/Guide/Lenovo+ThinkPad+R61i+Hard+Drive+Replacement/118125  >
> 
> 
> AIUI UEFI/GPT were designed to support multi-boot, but one-disk-per-OS 
> is KISS -- each installer can have its way with the entire disk, and the 
> installed OS just works (if it supports your hardware).
> 
> 
> That said, the fundamental problem with either approach is that no 
> matter which OS you are running, you want something in another OS that 
> is not running.  Back in the day, I bought additional computers.  Today, 
> there are several high quality hypervisors to choose from.
> 
> 
> A key consideration is where to put your data, so that it is accessible 
> from whichever OS you happen to be running.  Solutions include a file 
> server, a NAS, and another drive with a lowest-common-denominator file 
> system (e.g. FAT32, ExFAT, or NTFS).

I have a solution I like and fits my style/habits.
Thanks.

[toc] | [prev] | [next] | [standalone]

#272349 — UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

On 20/08/2024 11:27, David Christensen wrote:
> AIUI UEFI/GPT were designed to support multi-boot

Single EFI System Partition may contain loaders from different vendors, 
but not 2 Debian systems installed on different partitions. EFI files 
are signed for Secure Boot, so vendor paths can not be easily adjusted. 
I have no idea how much trouble may cause multiple ESP on the same 
drive. I tried ESP on different drives and it works (HP firmware on a 
decade-old laptop is quite buggy in respect to boot configuration). 
Actually GRUB menu to load system from alternative partition is more 
convenient than firmware boot menu in my case.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web