Default partition mounts [ "Installation Guide" lacks index ]

[Richard Owlett]

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/ ;}!

[David]

Post by Richard Owlett
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

[Richard Owlett]

THANK YOU

Post by David

Post by Richard Owlett
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.

Post by David
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.

[Joe]

On Mon, 19 Aug 2024 08:44:39 -0500

Post by Richard Owlett
THANK YOU

Post by David

Post by Richard Owlett
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.

Post by David
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.

[Richard Owlett]

Post by Joe
On Mon, 19 Aug 2024 08:44:39 -0500

Post by Richard Owlett
THANK YOU

Post by David

Post by Richard Owlett
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.

Post by David
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.
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*.]

[Andy Smith]

Hi,

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

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
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.

Post by Richard Owlett
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.

Post by Richard Owlett
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.

[Richard Owlett]

Post by Andy Smith
Hi,
I'm afraid I have not got the kind of answer you request for your
actual question but…

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
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.

Post by Andy Smith

Post by Richard Owlett
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".

Post by Andy Smith
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.

Post by Andy Smith

Post by Richard Owlett
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.
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.

[Andrew M.A. Cater]

Post by Richard Owlett

Post by Andy Smith
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.

Post by Richard Owlett

Post by Andy Smith

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
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 :)

Post by Richard Owlett

Post by Andy Smith

Post by Richard Owlett
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?

Post by Richard Owlett

Post by Andy Smith
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>

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

Post by Andy Smith
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
(***@debian.org)

[Richard Owlett]

Post by Andrew M.A. Cater

Post by Richard Owlett

Post by Andy Smith
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.

Post by Andrew M.A. Cater
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 ;]

Post by Andrew M.A. Cater

Post by Richard Owlett

Post by Andy Smith

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
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 ;]

Post by Andrew M.A. Cater
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*

Post by Andrew M.A. Cater

Post by Richard Owlett

Post by Andy Smith

Post by Richard Owlett
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.

Post by Andrew M.A. Cater

Post by Richard Owlett

Post by Andy Smith
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>

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

Post by Andy Smith
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
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

[Richard Owlett]

Post by Richard Owlett

[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.
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)

Post by Richard Owlett
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]

[Charles Curley]

On Tue, 20 Aug 2024 07:34:33 -0500

Post by Richard Owlett
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.

[Andrew M.A. Cater]

Post by Richard Owlett

Post by Richard Owlett

[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)."

Post by Richard Owlett

Post by Richard Owlett
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)

Post by Richard Owlett
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

Post by Richard Owlett
[snip]

[Andy Smith]

Hello,

Post by Richard Owlett

[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.

[Roberto C. Sánchez]

Post by Andy Smith
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

[Tom Dial]

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
  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

Post by Richard Owlett
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/ ;}!

[David Wright]

Post by Tom Dial

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
  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.

[Richard Owlett]

Post by David Wright

Post by Tom Dial

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
  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,
devpts /dev/pts devpts defaults 0 0
tmpfs /run tmpfs nosuid,size=10%,mode=755 0

0

Post by David Wright
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 :}

[David Christensen]

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
  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

[Richard Owlett]

Post by David Christensen

Post by Richard Owlett
I'm over 80 and doing first "from scratch" install since Squeeze ;}
Hardware is Lenovo R61 ThinkPad (64 bit).
   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>

Post by David Christensen
 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
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.

[Max Nikulin]

Post by David Christensen
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.

[Erwan David]

Post by David Christensen
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.

Here is the tree on my laptop, I think the "ubuntu part" comes from a
former Mint installation (Debian is tthe only OS on the computer)

.
└── EFI
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fbx64.efi
│   └── mmx64.efi
├── debian
│   ├── BOOTX64.CSV
│   ├── fbx64.efi
│   ├── fw
│   │   └── fwupd-cdcae5ae-413a-4198-b866-8028e994dd53.cap
│   ├── fwupdx64.efi
│   ├── grub.cfg
│   ├── grubx64.efi
│   ├── mmx64.efi
│   └── shimx64.efi
├── Dell
│   └── Bios
│   └── Recovery
│   ├── BIOS_CUR.RCV
│   └── BIOS_PRE.rcv
└── ubuntu
├── BOOTX64.CSV
├── fw
├── fwupdx64.efi
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi

[Nicolas George]

Single EFI System Partition may contain loaders from different vendors, but
not 2 Debian systems installed on different partitions.

This is not true. The only problem you will have with this setup is that
you will need to install and/or configure the bootloader manually.

EFI files are signed
for Secure Boot, so vendor paths can not be easily adjusted.

Secure boot is a joke when it comes to security, its only “merit” is to
prevent lusers from installing software with disabled DRM.

I have no idea
how much trouble may cause multiple ESP on the same drive.

Once the bootloader is installed, the partition is referred by UUID, it
does not matter if it is the ESP or not.

[Jeffrey Walton]

Post by Nicolas George
[...]

EFI files are signed
for Secure Boot, so vendor paths can not be easily adjusted.

Secure boot is a joke when it comes to security, its only “merit” is to
prevent lusers from installing software with disabled DRM.

Speaking of Secure Boot, this just made my radar:
<https://www.schneier.com/blog/archives/2024/07/compromising-the-secure-boot-process.html>.

Jeff

[gene heskett]

Post by Jeffrey Walton

Post by Nicolas George
[...]

EFI files are signed
for Secure Boot, so vendor paths can not be easily adjusted.

Secure boot is a joke when it comes to security, its only “merit” is to
prevent lusers from installing software with disabled DRM.

<https://www.schneier.com/blog/archives/2024/07/compromising-the-secure-boot-process.html>.
Jeff

And proves the point, that all this bs is for naught if enough salary is
paid to the right people.

Cheers, Gene Heskett, CET.

[Max Nikulin]

Post by Nicolas George

Single EFI System Partition may contain loaders from different vendors, but
not 2 Debian systems installed on different partitions.

This is not true. The only problem you will have with this setup is that
you will need to install and/or configure the bootloader manually.

Do you mean 3rd party bootloader (e.g. grub)? I was responding to "AIUI
UEFI/GPT were designed to support multi-boot". Custom configuration of
grub (earlier lilo) was possible before UEFI and GPT.

Erwan posted directory tree for debian+ubuntu ESP, but it is a case of
different vendors. Richard wants 2 variants of Debian (however UEFI may
be irrelevant to that machine). I was experimenting trying to get 2
entries from the same vendor in the UEFI (firmware) boot menu and found
it tricky and inconvenient.

Post by Nicolas George
<https://www.schneier.com/blog/archives/2024/07/compromising-the-secure-boot-process.html>.

When I noticed that news, I was curious if there is an alternative
command to "efi-readvar -v PK" since I do not have the tool installed. It is

efi-readvar -v PK

I found it in
<https://github.com/fwupd/fwupd/issues/2695>
"Add test for detecting the "AMI Test PK" in the HSI"
opened 2020-12-18T19:23:10Z

The issue that is rather similar at first glance was filed 3.5 years
before the latest discovery.

[Felix Miata]

Post by Max Nikulin
I was experimenting trying to get 2
entries from the same vendor in the UEFI (firmware) boot menu and found
it tricky and inconvenient.

How so? I found it quite simple to edit /etc/default/grub and replace the default
value of GRUB_DISTRIBUTOR= to some unique string, e.g. "trixie" or "debian12",
then update Grub before doing second installation. What else did you find necessary?

[Max Nikulin]

Post by Felix Miata

Post by Max Nikulin
I was experimenting trying to get 2
entries from the same vendor in the UEFI (firmware) boot menu and found
it tricky and inconvenient.

How so? I found it quite simple to edit /etc/default/grub and replace the default
value of GRUB_DISTRIBUTOR= to some unique string, e.g. "trixie" or "debian12",
then update Grub before doing second installation. What else did you find necessary?

Have I missed something or GRUB_DISTRIBUTOR affects *grub* menu, but not
*UEFI* boot menu?

printf "GRUB_DISTRIBUTOR=%s\n" mydeb \

Post by Felix Miata
/etc/default/grub.d/distributor.cfg

update-grub
grep --count mydeb /boot/grub/grub.cfg
8

So the added option has been applied. However I have not noticed any
effect related to UEFI configuration

efibootmgr -v | grep --count mydeb

0

iconv -f UCS-2 /boot/efi/EFI/debian/BOOTX64.CSV
shimx64.efi,debian,,This is the boot entry for debian

/boot/efi/EFI/debian remained as it was earlier.

My expectations for "UEFI/GPT were designed to support multi-boot" in
the context of discussion of 2 Debian installations are the following:

- It is possible to create either EFI/mydeb or EFI/debian/mydeb on the
ESP partition so that grubx64.efi from this directory may load grub.cfg
from the *same* directory (path relative to the .efi binary). Currently
.cfg path is a compile-time setting (EFI/debian/grubx64.cfg) for the
sake of secure boot.
- boot menu entry with customized name is created (efibootmgr)
- name in BOOTX64.CSV is changed accordingly. This file is used by
fallback fbx64.efi to create EFI boot variable when it is missed during
boot. Currently it is not a configuration file and copied from
/usr/lib/shim/BOOTX64.CSV (shim-unsigned).

I have not tried to dispute that it is possible to configure grub for 2
Debian systems. I do not mind that UEFI allows to put boot files for
different architectures and (besides removable media EFI/BOOT path) from
different vendors. I still suspect it is a UEFI+SecureBoot design
shortcoming that it is not possible to install the same loader (the same
vendor) on the same ESP twice with different configurations.

[Nicolas George]

Post by Max Nikulin
Have I missed something or GRUB_DISTRIBUTOR affects *grub* menu, but not
*UEFI* boot menu?

Indeed, it is not just as simple as that.

Post by Max Nikulin
I still suspect it is a UEFI+SecureBoot design
shortcoming that it is not possible to install the same loader (the same
vendor) on the same ESP twice with different configurations.

--bootloader-id=ID
the ID of bootloader. This option is only available on EFI and
Macs.

I it as simple as this.

[Felix Miata]

Post by Max Nikulin

Post by Felix Miata

Post by Max Nikulin
I was experimenting trying to get 2
entries from the same vendor in the UEFI (firmware) boot menu and found
it tricky and inconvenient.

How so? I found it quite simple to edit /etc/default/grub and replace the default
value of GRUB_DISTRIBUTOR= to some unique string, e.g. "trixie" or "debian12",
then update Grub before doing second installation. What else did you find necessary?

Have I missed something or GRUB_DISTRIBUTOR affects *grub* menu, but not
*UEFI* boot menu?

Your language as I quoted above I interpreted to mean:

1-you wish 2 entries from same vendor in BBS menu
2-you are not directly or ATM concerned with any Grub menu

Here's how multiboot configuration goes on just one of mine:
# inxi -S
System:
Host: ab85m Kernel: 6.9.7-1-default arch: x86_64 bits: 64
Console: pty pts/0 Distro: openSUSE Tumbleweed 20240820
# mount | grep -i vfat
/dev/sda1 on /boot/efi type vfat (rw,relatime...
# dmidecode | grep -i efi
UEFI is supported
# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0003,0002
Boot0000* opensusetw HD(1,GPT,<...>,0x800,0xa0000)/File(\EFI\opensusetw\grubx64.efi)
Boot0002* UEFI OS HD(1,GPT,<...>,0x800,0xa0000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0003* CD/DVD Drive BBS(CDROM,,0x0)0000474f00004e4f7f000000010000004f00440052...
Boot0004* Hard Drive BBS(HD,,0x0)0000474f00004e4f81000000010000004f00540045004...
# grep UTOR /etc/default/grub
GRUB_DISTRIBUTOR="opensusetw"
# tree /boot/efi/
/boot/efi/
├── EFI
│   ├── BOOT
│   │   ├── BOOTX64.EFI
│   │   └── mt74x64.efi
│   └── opensusetw
│   └── grubx64.efi
├── MemTest86.log
├── MemTest86-Report-20200216-223015.html
├── mt74x64.efi
└── mt83x64.efi

4 directories, 7 files
# lsblk -f | grep deb
├─sda7 ext4 1.0 tg1p07stw c9b0...701a 1G 82% /disks/stw
├─sda9 ext4 1.0 tg1p09deb12 87b9...8adc 606.5M 88% /disks/deb12
├─sda13 ext4 1.0 tg1p13deb13 a5d4...ceb0 2.9G 58% /disks/deb13
├─sda17 ext4 1.0 tg1p17deb11 5be1...5084 675.4M 87% /disks/deb11
# ls -gG /boot/grub2/custom.cfg
-rwxr-xr-x 1 6796 Aug 5 00:03 /boot/grub2/custom.cfg
#
<system restart>
# inxi -S
System:
Host: ab85m Kernel: 6.9.12-amd64 arch: x86_64 bits: 64
Desktop: TDE (Trinity) v: R14.1.3~[DEVELOPMENT] Distro: Debian GNU/Linux
trixie/sid
# mount | grep -i vfat
# dmidecode | grep -i efi
UEFI is supported
# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0003,0002
Boot0000* opensusetw HD(1,GPT,<...>,0x800,0xa0000)/File(\EFI\opensusetw\grubx64.efi)
Boot0002* UEFI OS HD(1,GPT,<...>,0x800,0xa0000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0003* CD/DVD Drive BBS(CDROM,,0x0)0000474f00004e4f7f000000010000004f00440052...
Boot0004* Hard Drive BBS(HD,,0x0)0000474f00004e4f81000000010000004f00540045004...
# grep UTOR /etc/default/grub
grep: /etc/default/grub: No such file or directory
# tree /boot/efi
-bash: tree: command not found
# tree /boot/efi
/boot/efi

0 directories, 0 files
# lsblk -f | egrep 'stw|deb'
├─sda7 ext4 1.0 tg1p07stw c9b0...701a 1G 82% /disks/stw
├─sda9 ext4 1.0 tg1p09deb12 87b9...8adc 606.5M 88% /disks/deb12
├─sda13 ext4 1.0 tg1p13deb13 a5d4...ceb0 3.6G 49% /
├─sda17 ext4 1.0 tg1p17deb11 5be1...5084 675.4M 87% /disks/deb11
# ls -gG /boot/grub/custom.cfg
ls: cannot access '/boot/grub/custom.cfg': No such file or directory
# ls -gG /disks/stw/boot/grub2/custom.cfg
-rwxr-xr-x 1 6796 Aug 5 00:03 /disks/stw/boot/grub2/custom.cfg
# which update-grub
# dpkg-query -l | grep grub
# parted -l | grep -i ESP
1 1049kB 337MB 336MB fat32 TG1P01 EFI System (ESP) T253X 2295 boot, esp
#
My BBS menu contains 4 entries corresponding to output from efibootmgr,
with the highlight on the one beginning "opensusetw", as configured via
GRUB_DISTRIBUTOR=.

My custom.cfg is 100% managed by me. Its included stanzas are automatically
included along with the entries contained in grub.cfg. By reason of my
having copied /etc/grub.d/41_custom to /etc/grub.d/07_custom, and emptying
/etc/grub.d/41_custom, stanzas from custom.cfg precede those from grub.cfg
when Grub's boot menu is onscreen. Management of custom.cfg is trivial, as
editing is required only when adding another installation, or some other
non-trival changes among installed systems are employed. Stanzas in
custom.cfg all employ symlinks to kernel and initrds.

This is KISS applied to multibooting with UEFI. As with legacy/MBR booting,
only one installed bootloader is required to support as many installed
GNU/Linux installations as desired. I trust it adequately explains why
above only one directory in /EFI/ on ESP exists. It is orthogonal to use
of GRUB_DISTRIBUTOR= to assign a unique directory name within /EFI/ on ESP.

Post by Max Nikulin
printf "GRUB_DISTRIBUTOR=%s\n" mydeb \

Post by Felix Miata
/etc/default/grub.d/distributor.cfg

update-grub
grep --count mydeb /boot/grub/grub.cfg
8

Do we know that the update-grub command normally writes to /boot/efi/EFI/,
and NVRAM (optional?)?

Post by Max Nikulin
So the added option has been applied. However I have not noticed any
effect related to UEFI configuration
efibootmgr -v | grep --count mydeb
0
iconv -f UCS-2 /boot/efi/EFI/debian/BOOTX64.CSV
shimx64.efi,debian,,This is the boot entry for debian
/boot/efi/EFI/debian remained as it was earlier.
My expectations for "UEFI/GPT were designed to support multi-boot" in
- It is possible to create either EFI/mydeb or EFI/debian/mydeb on the
ESP partition so that grubx64.efi from this directory may load grub.cfg
from the *same* directory (path relative to the .efi binary). Currently
.cfg path is a compile-time setting (EFI/debian/grubx64.cfg) for the
sake of secure boot.
- boot menu entry with customized name is created (efibootmgr)
- name in BOOTX64.CSV is changed accordingly. This file is used by
fallback fbx64.efi to create EFI boot variable when it is missed during
boot. Currently it is not a configuration file and copied from
/usr/lib/shim/BOOTX64.CSV (shim-unsigned).
I have not tried to dispute that it is possible to configure grub for 2
Debian systems. I do not mind that UEFI allows to put boot files for
different architectures and (besides removable media EFI/BOOT path) from
different vendors. I still suspect it is a UEFI+SecureBoot design
shortcoming that it is not possible to install the same loader (the same
vendor) on the same ESP twice with different configurations.

[Max Nikulin]

Post by Felix Miata
My BBS menu contains 4 entries corresponding to output from efibootmgr,
with the highlight on the one beginning "opensusetw", as configured via
GRUB_DISTRIBUTOR=.

Or it just coincides with the configured value. My expectation is that
EFI/opensusetw/grub.cfg is still hardcoded in your grubx64.efi. I tried
earlier "install-grub --bootloader-id", but there was a pitfall in the
case of enabled SecureBoot: grubx64.efi and grub.cfg were taken from
different ESP directories that is not apparent in some cases.

Post by Felix Miata
My custom.cfg is 100% managed by me.

[...]

Post by Felix Miata
This is KISS applied to multibooting with UEFI.

Sorry, but this time I would prefer to leave aside grub configuration
unrelated to UEFI. I have never had intention to dispute that it is
possible to configure multiboot using grub. Multiboot using UEFI
facilities directly is a bit different beast.

Post by Felix Miata

Post by Max Nikulin
printf "GRUB_DISTRIBUTOR=%s\n" mydeb \

Post by Felix Miata
/etc/default/grub.d/distributor.cfg

update-grub
grep --count mydeb /boot/grub/grub.cfg
8

Do we know that the update-grub command normally writes to /boot/efi/EFI/,
and NVRAM (optional?)?

Actually I tried dpkg-reconfigure for grub and shim packages and your
message made me thinking that you may correct me and may provide proper
commands to configure *UEFI* boot menu.

From my old notes:
<https://bugs.launchpad.net/bugs/1450783>

[Felix Miata]

Post by Max Nikulin

Post by Felix Miata
My BBS menu contains 4 entries corresponding to output from efibootmgr,
with the highlight on the one beginning "opensusetw", as configured via
GRUB_DISTRIBUTOR=.

Or it just coincides with the configured value.

/etc/default/grub's GRUB_DISTRIBUTOR=, if not null, /is/ where the configuration
is established. In openSUSE, that default is null, and thus falls back to
something somewhere I suppose in /usr/ establishing opensuse as its default. In
Debian it is by default whatever `lsb_release -i -s 2> /dev/null || echo Debian`
works out to be, usually "debian" AFAICT, unless it's been changed since last I
had such file from a Debian installation. With only one bootloader per PC, lots of
/etc/default/ directories have no grub file in them.

Post by Max Nikulin
My expectation is that
EFI/opensusetw/grub.cfg is still hardcoded in your grubx64.efi.

Given /boot/grub2/grub.cfg was last written 13 minutes after
EFI/opensusetw/grubx64.efi, I do not believe it is in there in this or on any
other of my installations:

# ls -gG /boot/efi/EFI/opensusetw/grub.cfg
ls: cannot access '/boot/efi/EFI/opensusetw/grub.cfg': No such file or directory
# ls -gG /boot/efi/EFI/opensusetw/
total 148
-rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi
# ls -gG /boot/efi/EFI/*
/boot/efi/EFI/BOOT:
total 1172
-rwxr-xr-x 1 143360 Aug 23 2022 BOOTX64.EFI
-r-xr-xr-x 1 1053552 Jul 26 2017 mt74x64.efi

/boot/efi/EFI/opensusetw:
total 148
-rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi
# lsblk -f | egrep -i 'tw|deb|esp'
├─sda1 vfat FAT32 TG1P01ESP ...9-E... 315M 1% /boot/efi
├─sda7 ext4 1.0 tg1p07stw c9b0...701a 1.1G 81% /
├─sda9 ext4 1.0 tg1p09deb12 87b9...8adc 1.5G 76% /disks/deb12
├─sda13 ext4 1.0 tg1p13deb13 a5d4...ceb0 3.6G 49% /disks/deb13
├─sda17 ext4 1.0 tg1p17deb11 5be1...5084 765.9M 86% /disks/deb11
# ls -gG /boot/grub2/grub.cfg
-rw------- 1 28238 Aug 21 16:21 /boot/grub2/grub.cfg
#

Post by Max Nikulin

Post by Felix Miata
Do we know that the update-grub command normally writes to /boot/efi/EFI/,
and NVRAM (optional?)?

Actually I tried dpkg-reconfigure for grub and shim packages and your
message made me thinking that you may correct me and may provide proper
commands to configure *UEFI* boot menu.
<https://bugs.launchpad.net/bugs/1450783>

efibootmgr -c -L "opensusetw" -d /dev/sda1 -l '\EFI\opensusetw\grubx64.efi'
here has created a new entry in NVRAM when old was obsolete or deleted. It doesn't
create the opensusetw directory on the ESP. That is written by any process that
reads GRUB_DISTRIBUTOR= to determine where to do its writing on the ESP.

[Max Nikulin]

# ls -gG/boot/efi/EFI/opensusetw/
total 148
-rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi

Am I right that you either do not use Secure Boot or generated a local
key instead of/in addition to Microsoft and SUSE ones?

In the case of default or almost default install with a Debian key
(mokutil --list-enrolled)

ls -gG /boot/efi/EFI/debian/
total 5960
-rwx------ 1 108 Oct 9 2023 BOOTX64.CSV
-rwx------ 1 87328 Oct 9 2023 fbx64.efi
-rwx------ 1 112 Oct 9 2023 grub.cfg
-rwx------ 1 4199872 Oct 9 2023 grubx64.efi
-rwx------ 1 849616 Oct 9 2023 mmx64.efi
-rwx------ 1 948768 Oct 9 2023 shimx64.efi

Shim and grub are shipped signed, so install-grub can not embed location
of /boot/grub2/grub.cfg (search.fs_uuid) into grubx64.efi. So grub.cfg
specifying a partition with /boot is written to EFI/debian/grub.cfg:

search.fs_uuid 12345678-90ab-4cde-f012-34567890abcd root
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

I have found an upstream bug:

<https://savannah.gnu.org/bugs/index.php?57381>
bug #57381: EFI image with wrong prefix when bootload-id is specified

that confirms that "debian" is fixed in the EFI/debian/grub.cfg path
when grubx64.efi is taken from grub-efi-amd64-signed. I have no idea if
EFI binaries can determine their own location to implement relative path
for the configuration file. Depending on that hardcoded .cfg path is
either grub or UEFI limitation.

[Felix Miata]

Post by Max Nikulin

# ls -gG/boot/efi/EFI/opensusetw/
total 148
-rwxr-xr-x 1 151552 Aug 21 16:08 grubx64.efi

Am I right that you either do not use Secure Boot or generated a local
key instead of/in addition to Microsoft and SUSE ones?

I'm just finishing up with a distribution upgrade on one of my PCs. I cloned
/dev/sda16 to /dev/sda64, updated configuration on /dev/sda64, verified it works
normally, then did the upgrade on the original. My many computers each have lots
of GNU/Linux installations. This particular one includes OS/2. KISS with so many
installations demands I not tangle everything up with secure boot. It's
complicated enough without.

[Max Nikulin]

Post by Felix Miata
That is written by any process that
reads GRUB_DISTRIBUTOR= to determine where to do its writing on the ESP.

To avoid confusion of those who may notice this thread in search engine
results:

In Debian GRUB_DISTRIBUTOR value is *not* passed to "grub-install
--bootloader-id" by postinst package scripts:
<https://sources.debian.org/src/grub2/2.12-5/debian/postinst.in/?hl=723#L723>
<https://sources.debian.org/src/shim-signed/1.44/debian/shim-signed.postinst/?hl=64#L64>

Notice

Post by Felix Miata
case $bootloader_id in
kubuntu) bootloader_id=ubuntu ;;
esac

that was added to prevent a secure boot issue.

Behavior of SUSE may be different.

I believe, a robust way would be to add grub-install option that reports
path withing EFI partition configured at compile time, so heuristics
based on GRUB_DISTRIBUTOR from /etc/default/grub would not confuse users.

*Signed* grub*.efi reads its config from EFI/debian/grub.cfg (that loads
/boot/grub/grub.cfg) that is fixed when the binary is signed.

[Felix Miata]

Post by Max Nikulin

Post by Felix Miata
That is written by any process that
reads GRUB_DISTRIBUTOR= to determine where to do its writing on the ESP.

To avoid confusion of those who may notice this thread in search engine
In Debian GRUB_DISTRIBUTOR value is *not* passed to "grub-install
<https://sources.debian.org/src/grub2/2.12-5/debian/postinst.in/?hl=723#L723>
<https://sources.debian.org/src/shim-signed/1.44/debian/shim-signed.postinst/?hl=64#L64>
Notice

Post by Felix Miata
case $bootloader_id in
kubuntu) bootloader_id=ubuntu ;;
esac

that was added to prevent a secure boot issue.
Behavior of SUSE may be different.
I believe, a robust way would be to add grub-install option that reports
path withing EFI partition configured at compile time, so heuristics
based on GRUB_DISTRIBUTOR from /etc/default/grub would not confuse users.

I don't know what vexing secure boot might introduce, but without it,
GRUB_DISTRIBUTOR= was used by grub-install in Trixie here to produce
results I expected:

# inxi -S
System:
Host: msi85 Kernel: 6.9.12-amd64 arch: x86_64 bits: 64
Console: pty pts/0 Distro: Debian GNU/Linux trixie/sid
# grep TOR /etc/default/grub
GRUB_DISTRIBUTOR="debian13"
# efibootmgr | egrep 'suse|debian|rder'
BootOrder: 0000,0004,0005,0003,0001,0002
Boot0000* opensusetw HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\OPENSUSETW\GRUBX64.EFI)
Boot0004* opensuse HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
# tree /boot/efi/EFI
/boot/efi/EFI
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fbx64.efi
│   ├── MemTest86.log
│   └── mt74x64.efi
├── opensuse
│   └── grubx64.efi
└── opensusetw
└── grubx64.efi

4 directories, 6 files
# grub-install --target=x86_64-efi --efi-directory=/boot/efi
Installing for x86_64-efi platform.
Installation finished. No error reported.
# efibootmgr | egrep 'suse|debian|rder'
BootOrder: 0006,0000,0004,0005,0003,0001,0002
Boot0000* opensusetw HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\OPENSUSETW\GRUBX64.EFI)
Boot0004* opensuse HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0006* debian13 HD(1,GPT,64c8...8745,0x800,0xa0000)/File(\EFI\debian13\grubx64.efi)
# tree /boot/efi/EFI
/boot/efi/EFI
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fbx64.efi
│   ├── MemTest86.log
│   └── mt74x64.efi
├── debian13
│   └── grubx64.efi
├── opensuse
│   └── grubx64.efi
└── opensusetw
└── grubx64.efi

5 directories, 7 files
#
Note I didn't use option --bootloader-id, so grub-install had no place on my
Trixie's / filesystem to find string "debian13" other than GRUB_DISTRIBUTOR=
in /etc/default/grub.

[Max Nikulin]

Post by Felix Miata
I don't know what vexing secure boot might introduce, but without it,
GRUB_DISTRIBUTOR= was used by grub-install in Trixie here to produce

[...]

Post by Felix Miata
# grep TOR /etc/default/grub
GRUB_DISTRIBUTOR="debian13"

[...]

Post by Felix Miata
├── debian13
│   └── grubx64.efi
├── opensuse

How does grubx64.efi find where grub.cfg is located? Is it compatible
with Secure Boot? It is the reason why your experiment is not convincing.

I have tried some variants of full shim+grub signed configurations on
the laptop with buggy firmware where I experienced troubles several
years ago. The results have surprised me and they are the same as for
qemu with OVMF instance.

grubx64.efi (v2.06) from Debian bookworm has no problem with reading
grub.cfg placed in the same directory and directory name does not matter.

grubx64.efi (v2.06) from Ubuntu 20.04 focal reads config file strictly
from EFI/ubuntu/grub.cfg.

I have not figured out what specific patch causes the difference. A lot
of lines are changed. I do not think it is a security measure. Perhaps
something is broken in attempts to improve booting from network.

There was a similar issue with Debian
https://bugs.debian.org/932966
and devuan still used EFI/debian when bootloader id "devuan" is used,
patches have not dropped (but perhaps just to avoid issues with existing
installations).

A couple of problems that I have noticed in bookworm:

1. When /usr/lib/shim/BOOTX64.CSV is installed, bootloader id in it is
not adjusted. As a result if additional removable path EFI/BOOT is used
then there is a chance that fbx64.efi will create "debian" boot entry,
not the name specified in GRUB_DISTRIBUTOR

2. It is not apparent that after modifying GRUB_DISTRIBUTOR it is
necessary to create the directory with matched name in /boot/efi/EFI.
Otherwise "dpkg-reconfigure grub-efi-amd64" does not run grub-install. I
would prefer to have an explicit setting instead of relying on presence
of a directory.

The main point is that I did not expect that Debian and Ubuntu may
diverge in so subtle way. I believed fixed .cfg path is a UEFI
limitation or at best an inherent grub limitation.

[Felix Miata]

Post by Max Nikulin
How does grubx64.efi find where grub.cfg is located?

I don't know what doc might report this, but in a file viewer I see a string like
(,gpt7)/boot/grub) embedded in a vast sea of nulls 98% of the way into the file.

[Max Nikulin]

Post by Felix Miata

Post by Max Nikulin
How does grubx64.efi find where grub.cfg is located?

I don't know what doc might report this, but in a file viewer I see a string like
(,gpt7)/boot/grub) embedded in a vast sea of nulls 98% of the way into the file.

Does UEFI secure boot allows modification of some part of a signed .efi
binary without invalidating its signature?

/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed is copied verbatim to
EFI/*/grubx64.efi. I still believe there is a reason why
"(,gpt7)/boot/grub" is written to EFI/*/grub.cfg when secure boot is used.

[Max Nikulin]

Avoid setting non-standard GRUB_DISTRIBUTOR in /etc/default/grub if you
use Debian 12 bookworm with enabled Secure Boot and signed grub image
from Debian. Alternatively install grub-2.12 from backports.

Post by Max Nikulin

Post by Felix Miata
I don't know what vexing secure boot might introduce, but without it,
GRUB_DISTRIBUTOR= was used by grub-install in Trixie here to produce

There is significant difference in patches for grub-2.12 in trixie and
for 2.06 in bookworm. In the case of Secure Boot, grub-install copies
signed grubx64.efi instead of generation of an image specific to the
machine.

Post by Max Nikulin
I have tried some variants of full shim+grub signed configurations on

[...]

Post by Max Nikulin
grubx64.efi (v2.06) from Debian bookworm has no problem with reading
grub.cfg placed in the same directory and directory name does not matter.
grubx64.efi (v2.06) from Ubuntu 20.04 focal reads config file strictly
from EFI/ubuntu/grub.cfg.

If there is EFI/debian/grub.cfg then it has higher priority than the
file from the directory from where grubx64.efi is loaded. Loading config
file from a custom directory looks like an unintentional behavior.

Post by Max Nikulin
I have not figured out what specific patch causes the difference. A lot
of lines are changed. I do not think it is a security measure.

The difference of grub-2.06 behavior between Ubuntu and Debian are
caused by build script, not by patches. It is a result of an attempt to
fix issues with Unicode characters. Relevant changes:

grub2 (2.06-14) experimental; urgency=medium

* Bundle unicode.pf2 in a squashfs memdisk attached to the signed EFI binary

-- Julian Andres Klode <***@debian.org> Mon, 19 Jun 2023 17:26:49 +0200

grub2 (2.06-6) unstable; urgency=medium

* Include fonts in the memdisk build for EFI images.
Closes: #1024395, #1025352, #1024447

-- Steve McIntyre <***@debian.org> Sun, 04 Dec 2022 20:42:23 +0000

Bookworm currently have 2.06-13 and in 2.06-14 config should be loaded
strictly from EFI/debian/grub.cfg.

The script written for booting from CD or a similar media
<https://sources.debian.org/src/grub2/2.06-13%2Bdeb12u1/debian/build-efi-images/#L64>
accidentally got bundled into regular images
<https://sources.debian.org/src/grub2/2.06-13%2Bdeb12u1/debian/build-efi-images/#L240>
Since 2.06-14 a dedicated squashfs image has been provided for fonts, so
the config search script is not a part of prebuilt images.

Post by Max Nikulin
Perhaps something is broken in attempts to improve booting from network.

I wrote "broken" describing Ubuntu-20.4 behavior where custom
GRUB_DISTRIBUTOR may cause failure to boot. I consider 2.06 broken in
Debian now. However patches making it possible in 2.12 are really
related to network
<https://lists.nongnu.org/archive/html/grub-devel/2023-01/msg00012.html>
A one setting fw_path and
<https://sources.debian.org/patches/grub2/2.12-5/network/try-prefixes-for-tftp-config-file.patch/>

They have not been included into the upstream repository. Debian
changelog entry is

* Port UEFI based network stack to 2.12 (LP: #2039081)

Post by Max Nikulin
1. When /usr/lib/shim/BOOTX64.CSV is installed, bootloader id in it is
not adjusted. As a result if additional removable path EFI/BOOT is used
then there is a chance that fbx64.efi will create "debian" boot entry,
not the name specified in GRUB_DISTRIBUTOR
2. It is not apparent that after modifying GRUB_DISTRIBUTOR it is
necessary to create the directory with matched name in /boot/efi/EFI.
Otherwise "dpkg-reconfigure grub-efi-amd64" does not run grub-install. I
would prefer to have an explicit setting instead of relying on presence
of a directory.

3. EFI/debian/grub.cfg has highest priority, so if bookworm is installed
in parallel with another Debian then neither must have
GRUB_DISTRIBUTOR=debian. Moreover grub.cfg likely may be found on some
other disk (e.g. a USB pendrive) having .disk/info. The version from
backports should help.

Post by Max Nikulin
I believed fixed .cfg path is a UEFI
limitation or at best an inherent grub limitation.

I have realized that shim can not work if it can not load grub from the
same directory. Perhaps it really happens in some cases.

<https://www.gnu.org/software/grub/manual/grub/html_node/cmdpath.html>
in Special environment variables

Post by Max Nikulin
15.1.4 cmdpath
The location from which core.img was loaded as an absolute directory
name (see File name syntax). This is set by GRUB at startup based on
information returned by platform firmware. Not every platform provides
this information and some may return only device without path name.

For EFI platform the required function is implemented (for many other
platforms it is not), however there are enough code paths when it may
return without providing a usable value.

At first glance shim really loads files using relative paths while grub
tries to obtain absolute path. Perhaps some EFI-specific trick may be
added to grub code to make it more reliable.

Curiously a patch intended to improve config loading breaks cmdpath.
Instead it sets the fw_path variable.

So multiple loaders from the same vendor is tricky in the case of UEFI
SecureBoot. Behavior of grub may vary across Linux distributions.

[Felix Miata]

Post by Max Nikulin
So multiple loaders from the same vendor is tricky in the case of UEFI
SecureBoot. Behavior of grub may vary across Linux distributions.

Thus, consider to KISS. Pick one installation's bootloader to depend on. Install
no others.

[songbird]

Post by Felix Miata

Post by Max Nikulin
So multiple loaders from the same vendor is tricky in the case of UEFI
SecureBoot. Behavior of grub may vary across Linux distributions.

Thus, consider to KISS. Pick one installation's bootloader to depend on. Install
no others.

hmm, well i actually use Refind for my normal booting up
and install GRUB as a backup. so far i've never needed the
backup but i do test it out from time to time.


songbird

[Felix Miata]

Post by songbird

Post by Felix Miata

Post by Max Nikulin
So multiple loaders from the same vendor is tricky in the case of UEFI
SecureBoot. Behavior of grub may vary across Linux distributions.

Thus, consider to KISS. Pick one installation's bootloader to depend on. Install
no others.

hmm, well i actually use Refind for my normal booting up
and install GRUB as a backup. so far i've never needed the
backup but i do test it out from time to time.

Which distros ship rEFInd? It's not among packages monitored by distrowatch.

[Thomas Schmitt]

Hi,

Post by Felix Miata
Which distros ship rEFInd? It's not among packages monitored by distrowatch.

It seems that Debian does since a while:
https://tracker.debian.org/pkg/refind

The tracker page points by its "homepage" link to
https://www.rodsbooks.com/refind/
which shows the name "rEFInd".


Have a nice day :)

Thomas

[Anssi Saari]

Post by songbird
hmm, well i actually use Refind for my normal booting up
and install GRUB as a backup. so far i've never needed the
backup but i do test it out from time to time.

Um, so how do you choose which boot manager you want to run? UEFI boot
menu?

[songbird]

Post by Anssi Saari

Post by songbird
hmm, well i actually use Refind for my normal booting up
and install GRUB as a backup. so far i've never needed the
backup but i do test it out from time to time.

Um, so how do you choose which boot manager you want to run? UEFI boot
menu?

efibootmgr lets you pick.


songbird

[Joe]

On Thu, 22 Aug 2024 10:17:58 +0700

Post by Max Nikulin
Actually I tried dpkg-reconfigure for grub and shim packages and your
message made me thinking that you may correct me and may provide
proper commands to configure *UEFI* boot menu.

efibootmgr

As I mentioned previously, not all UEFI implementations behave properly.

Your firmware probably has a hotkey to run the UEFI boot selector after
power on, but it may not have any editing facilities.

From Windows it's much harder, and requires rebooting into Safe Mode.
In Linux, efibootmgr can be run from chroot from e.g. a Debian
installation medium in rescue mode.

[Nicolas George]

Post by Max Nikulin
Do you mean 3rd party bootloader (e.g. grub)?

There is nothing “3rd party” about GRUB.

Post by Max Nikulin
I was responding to "AIUI
UEFI/GPT were designed to support multi-boot".

Yes, and so was I. If you want half a dozen different GRUBs configured
for half a dozen installed distros, it is possible. Completely useless

Post by Max Nikulin
Custom configuration of grub
(earlier lilo) was possible before UEFI and GPT.

… and more convenient. But it is possible.

Post by Max Nikulin
Erwan posted directory tree for debian+ubuntu ESP, but it is a case of
different vendors. Richard wants 2 variants of Debian (however UEFI may be
irrelevant to that machine).

As I said, perfectly possible.

Post by Max Nikulin
I was experimenting trying to get 2 entries
from the same vendor in the UEFI (firmware) boot menu and found it tricky
and inconvenient.

“Tricky and inconvenient” ≠ “impossible”

[Joe]

On Wed, 21 Aug 2024 08:45:05 +0200

Post by Nicolas George

Post by Max Nikulin
Do you mean 3rd party bootloader (e.g. grub)?

There is nothing “3rd party” about GRUB.

Post by Max Nikulin
I was responding to
"AIUI
UEFI/GPT were designed to support multi-boot".

Yes, and so was I. If you want half a dozen different GRUBs configured
for half a dozen installed distros, it is possible. Completely useless

Post by Max Nikulin
Custom
configuration of grub
(earlier lilo) was possible before UEFI and GPT.

… and more convenient. But it is possible.

Post by Max Nikulin
Erwan posted directory tree for debian+ubuntu ESP, but it is a case
of different vendors. Richard wants 2 variants of Debian (however
UEFI may be irrelevant to that machine).

As I said, perfectly possible.

Post by Max Nikulin
I was experimenting trying to get 2
entries
from the same vendor in the UEFI (firmware) boot menu and found it
tricky and inconvenient.

“Tricky and inconvenient” ≠ “impossible”

No all UEFI firmware is equal. I have an Acer netbook which does not
honour DefaultBoot. When cold booted, it always boots to the Windows
drive and resets that as the default boot. Fortunately, it can be
overridden by a USB stick. It does honour NextBoot, so I have a script
which sets NextBoot to grub on each Linux boot, and I carry a Debian
rescue USB for the odd occasion when I have to use Windows.