Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #264892 > unrolled thread
| Started by | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| First post | 2023-12-18 21:40 +0100 |
| Last post | 2023-12-22 15:20 +0100 |
| Articles | 20 on this page of 23 — 7 participants |
Back to article view | Back to linux.debian.user
GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-18 21:40 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Richmond <dnomhcir@gmx.com> - 2023-12-18 22:00 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Felix Miata <mrmazda@earthlink.net> - 2023-12-18 23:20 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-20 01:30 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Felix Miata <mrmazda@earthlink.net> - 2023-12-20 03:50 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... David Wright <deblis@lionunicorn.co.uk> - 2023-12-20 07:10 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Felix Miata <mrmazda@earthlink.net> - 2023-12-20 08:00 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-21 22:40 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-21 23:00 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 02:30 +0100
Re: GRUB -- Debian overrides? (but on original thread topic, not so much) Felix Miata <mrmazda@earthlink.net> - 2023-12-22 04:30 +0100
Re: GRUB -- Debian overrides? (but on original thread topic, not so much) David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 06:40 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-22 12:30 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... David Wright <deblis@lionunicorn.co.uk> - 2023-12-27 06:00 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... "Roy J. Tellason, Sr." <roy@rtellason.com> - 2023-12-20 17:10 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-21 22:40 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Felix Miata <mrmazda@earthlink.net> - 2023-12-22 01:40 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Greg Wooledge <greg@wooledge.org> - 2023-12-22 01:50 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-21 23:50 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-22 08:50 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-22 12:00 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Mark Fletcher <mark27q1@gmail.com> - 2023-12-22 12:50 +0100
Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... Felix Miata <mrmazda@earthlink.net> - 2023-12-22 15:20 +0100
Page 1 of 2 [1] 2 Next page →
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2023-12-18 21:40 +0100 |
| Subject | GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HMsz7-euji-1@gated-at.bofh.it> |
Hello I need help with a problem configuring grub. My main OS on the system concerned is bookworm (was probably originally installed as bullseye, might even have been earlier, and then has been upgraded over the years, now at bookworm). That system is the system that has installed grub and grub's configuration gets updated whenever a kernel update happens in the Debian stable ecosystem. I have now set up an LFS (Linux from Scratch) installation on the same box, on a brand new SSD installed into the machine for the purpose. So I want to be able to dual-boot. I have been able to get a grub.cfg including the LFS system but the root of the LFS system is being specified by device name and that is a problem. There are also a couple of existing, older SSDs in the machine, one of which contains an older installation of Debian which I don't use any more but haven't quite brought myself to delete (although will eventually), and one is mounted as /opt in my main system. Because I want to dual-boot with the LFS system I turned on the os-prober in /etc/default/grub. Running update-grub then duly finds the LFS system and sets up configuration in grub for it (it also finds the old Debian system, which I'd prefer to keep out of grub but that's not a big deal for now). Both old and current Debian installations use LVM and initrd. The LFS instance uses neither. I just don't seem to be able to persuade update-grub to put root=UUID=<blah> or root=PARTUUID=<blah> into the linux command line for the LFS system. Because update-grub is going to be run every time there is a kernel update in Debian, I need it to work and just overriding it by hand isn't a solution. Instead it is using root=/dev/sdX2. The problem is over the last few boots I have seen the SSD containing the LFS system come up as /dev/sda, /dev/sdb and on this boot now, /dev/sdc. According to the grub-mkconfig documentation[1], if I make sure GRUB_DISABLE_LINUX_UUID and GRUB_DISABLE_LINUX_PARTUUID are both set to false, in the absence of an initrd it should use "root=PARTUUID=<>" in the linux command line, but when I run update-grub that is not happening, and the device identifier is being used instead. Can anyone explain why, and how I can fix this in a way that will still work the next time the bookworm kernel gets an update? Thanks Mark [1] https://www.gnu.org/software/grub/manual/grub/html_node/Root-Identifcation-Heuristics.html#Root-Identifcation-Heuristics
[toc] | [next] | [standalone]
| From | Richmond <dnomhcir@gmx.com> |
|---|---|
| Date | 2023-12-18 22:00 +0100 |
| Message-ID | <HMsSt-eupX-9@gated-at.bofh.it> |
| In reply to | #264892 |
It's not ideal, but what I did when I had two disks and two operating systems was I installed two grubs, one for each OS, one on each MBR. I then used the BIOS menu to choose which disk to boot. This means each OS updates its own grub instance.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2023-12-18 23:20 +0100 |
| Subject | Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HMu7T-evjs-1@gated-at.bofh.it> |
| In reply to | #264892 |
Mark Fletcher composed on 2023-12-18 20:36 (UTC): > Can anyone explain why, and how I can fix this in a way that will > still work the next time the bookworm kernel gets an update? I can't answer why Grub scripts to what the do, because I don't really use them, and don't need to understand much about them. Grub config files in /boot/grub/ are akin to scripts, but they are really simple, mainly just command scripts. The usual one is grub.cfg, the one os-prober feeds from other Linux installations. A less common one is custom.cfg. To use it requires the admin build it. When it exists, grub-mkconfig incorporates its use by/in grub.cfg. It actually gets called by default from /etc/grub.d/41_custom, which adds the stanzas from it to the Grub boot menu - after those that it has generated itself. I copy it to /etc/grub.d/07_custom, and empty 41_custom. That causes my custom stanzas to appear first in Grub's boot menu. /etc/grub.d/40_custom acts, and a copy of it as 06_custom would act, in similar fashion, except that the admin's custom stanzas are put into it by the admin instead of into a custom.cfg file. Thus, you, as admin, construct working stanzas however you like, with or without UUIDS, with or without device names, with or without volume LABELS, however you like boot to go, and they don't get changed, except by the admin - you. This is easy, because you as admin can use the kernel (and initrd) symlinks Debian puts in /, or anywhere you'd like symlinks to them to go, for distros that don't automatically create them for you. There's no need for maintenance when new kernels are installed in the case of Debian and other distros that automatically generate new symlinks. For those that don't, creating them is trivial. <https://forums.opensuse.org/t/how-to-have-a-custom-uefi-grub-menu-for-a-multiboot-system/133541/2> is a thread that goes through my UEFI system setups. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2023-12-20 01:30 +0100 |
| Message-ID | <HMSDf-eKfb-3@gated-at.bofh.it> |
| In reply to | #264894 |
On Mon, 18 Dec 2023 at 22:15, Felix Miata <mrmazda@earthlink.net> wrote: > > Thus, you, as admin, construct working stanzas however you like, with or without > UUIDS, with or without device names, with or without volume LABELS, however you > like boot to go, and they don't get changed, except by the admin - you. This is > easy, because you as admin can use the kernel (and initrd) symlinks Debian puts in > /, or anywhere you'd like symlinks to them to go, for distros that don't > automatically create them for you. There's no need for maintenance when new > kernels are installed in the case of Debian and other distros that automatically > generate new symlinks. For those that don't, creating them is trivial. > > <https://forums.opensuse.org/t/how-to-have-a-custom-uefi-grub-menu-for-a-multiboot-system/133541/2> > is a thread that goes through my UEFI system setups. > -- Thanks very much for your help, I reckon I can make that work. Is that the "official" answer? I am curious to know from Debian GRUBbers (as it were) if the behaviour I am describing in this thread is expected... Thanks Mark
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2023-12-20 03:50 +0100 |
| Subject | Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HMUOJ-eLqm-1@gated-at.bofh.it> |
| In reply to | #264937 |
Mark Fletcher composed on 2023-12-20 00:28 (UTC): > I am curious to know from Debian > GRUBbers (as it were) if the behaviour I am describing in this thread > is expected... I suspect few if any regulars here spend much time with Slackware. I think a more conventional approach would be to reconfigure Slackware to boot by UUID, with the result that Debian's os-prober should pick it up in the more reliable fashion. I don't have a bootloader installed on my only Slackware, and have no more familiarity with ELILO than that it seems to be the Slack user favorite bootloader. Whether or how well it or its Grub might pick up Debian, or any proclivity it may have to usurp boot control from Debian or include stanza(s) for Debian, I have no basis for guessing. If you can keep your Slack kernel (& initrd if using one) generically symlinked without much trouble, a stanza you put in /etc/grub.d/41_custom should be able to boot Slack from Debian's Grub using your custom stanza containing root=LABEL= or root=UUID= without trouble. Same would go for using 07_custom, or custom.cfg with 06_custom, to move your custom stanza to the Debian Grub menu's top. Multiboot is as much art as science. Like anything in Gnu/Linux, there are multiple ways to decouple felines from their skins. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-20 07:10 +0100 |
| Subject | Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HMXWh-eNBt-3@gated-at.bofh.it> |
| In reply to | #264940 |
On Tue 19 Dec 2023 at 21:40:19 (-0500), Felix Miata wrote:
> Mark Fletcher composed on 2023-12-20 00:28 (UTC):
>
> > I am curious to know from Debian
> > GRUBbers (as it were) if the behaviour I am describing in this thread
> > is expected...
>
> I suspect few if any regulars here spend much time with Slackware. I think a more
> conventional approach would be to reconfigure Slackware to boot by UUID, with the
> result that Debian's os-prober should pick it up in the more reliable fashion. I
> don't have a bootloader installed on my only Slackware, and have no more
> familiarity with ELILO than that it seems to be the Slack user favorite
> bootloader. Whether or how well it or its Grub might pick up Debian, or any
> proclivity it may have to usurp boot control from Debian or include stanza(s) for
> Debian, I have no basis for guessing.
I can't see anywhere where the OP claims to have set up LFS for
booting itself, as opposed to being booted from a Debian Grub.
It only says "I have been able to get a grub.cfg including the
LFS system …", which seems to imply LFS has only been set up
as a "foreign" system by a Debian system.
When os-prober runs on my system, a lot of stuff gets logged in
messages, syslog and user.log. The lines that contain the string
"result:" (without the quotes) are interesting. It's evident from
those that have six fields following result: have had their root=
field copied from the foreign system's grub.cfg. (In my case,
"foreign" means a Debian system of the previous release.)
When os-prober writes several clauses into my new grub.cfg's
"### BEGIN /etc/grub.d/30_os-prober ###" section, the references
to the partition are constructed using UUIDs (not PARTUUIDs, because
there's an initrd). However, the kernel command line reads
"root=LABEL=toto04", so that string wasn't constructed by os-prober,
but copied from the foreign grub.cfg¹.
That suggests to me the probability that whereas +Grub constructs+
the root= strings for the "### BEGIN /etc/grub.d/10_linux ###"
section, +os-prober copies+ the root= strings into the
"### BEGIN /etc/grub.d/30_os-prober ###" section instead.
> If you can keep your Slack kernel (& initrd if using one) generically symlinked
> without much trouble, a stanza you put in /etc/grub.d/41_custom should be able to
> boot Slack from Debian's Grub using your custom stanza containing root=LABEL= or
> root=UUID= without trouble. Same would go for using 07_custom, or custom.cfg with
> 06_custom, to move your custom stanza to the Debian Grub menu's top.
In case it's not clear, "generically symlinked" means that
/vmlinuz is a symlink pointing to the most recent linux-image.
(Similarly for initrd.) I added the following to
/etc/grub.d/07_custom:
menuentry 'My bullseye' $menuentry_id_option 'custom' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --set=root --label noah03
echo 'Load /vmlinuz …'
linux /vmlinuz root=LABEL=noah03 ro systemd.show_status=true quiet
echo 'Load initial ramdisk /initrd.img …'
initrd /initrd.img
}
¹ After installing a system, upgrading the kernel, or upgrading
Grub, I run a script that converts /all/ the UUIDs in grub.cfg
into LABELs, in this little dance:
cp grub.cfg → grub.cfg-uuids
cp grub.cfg-edited → grub.cfg-old
< grub.cfg filter-script > grub.cfg-edited
cp grub.cfg-edited → grub.cfg
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2023-12-20 08:00 +0100 |
| Subject | Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HMYIF-eNR5-1@gated-at.bofh.it> |
| In reply to | #264949 |
David Wright composed on 2023-12-20 00:00 (UTC-0600):
> In case it's not clear, "generically symlinked" means that
> /vmlinuz is a symlink pointing to the most recent linux-image.
> (Similarly for initrd.) I added the following to
> /etc/grub.d/07_custom:
> menuentry 'My bullseye' $menuentry_id_option 'custom' {
> load_video
> set gfxpayload=keep
> insmod gzio
> insmod part_gpt
> insmod ext2
> search --no-floppy --set=root --label noah03
> echo 'Load /vmlinuz …'
> linux /vmlinuz root=LABEL=noah03 ro systemd.show_status=true quiet
> echo 'Load initial ramdisk /initrd.img …'
> initrd /initrd.img
> }
A bit less is needed here in custom.cfg:
menuentry "Debian 13 Trixie defkernel 3 on P10" {
load_video
set gfxpayload=keep
search --no-floppy --set=root --hint-baremetal=ahci0,gpt10 --label zd8p10deb13
linux /vmlinuz root=LABEL=zd8p10deb13 noresume consoleblank=0 preempt=full mitigations=off
initrd /initrd.img
}
menuentry "Slackware 15.0 GUI on P25"{
load_video
set gfxpayload=keep
search --no-floppy --set=root --hint-efi=hd0,gpt25 --label zd8p25slack
linux /boot/vmlinuz rw root=LABEL=zd8p25slack noresume consoleblank=0 mitigations=off
initrd /boot/initrd.gz
}
# lsblk -f | egrep 'fat|slack|deb13'
├─sda1 vfat FAT32 ZD8P01ESP 20A0-2A08
├─sda10 ext4 1.0 zd8p10deb13 e37c3e3c...
├─sda25 ext4 1.0 zd8p25slack 6664eb9b...
# grep RETT /etc/os-release
PRETTY_NAME="openSUSE Tumbleweed"
# rpmqa grub2-2.1
grub2-2.12~rc1-12.1.x86_64
#
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2023-12-21 22:40 +0100 |
| Message-ID | <HNyVP-favU-7@gated-at.bofh.it> |
| In reply to | #264949 |
On Wed, 20 Dec 2023 at 06:01, David Wright <deblis@lionunicorn.co.uk> wrote: > > > I can't see anywhere where the OP claims to have set up LFS for > booting itself, as opposed to being booted from a Debian Grub. > It only says "I have been able to get a grub.cfg including the > LFS system …", which seems to imply LFS has only been set up > as a "foreign" system by a Debian system. Yes, that's exactly it. My very first attempt involved using Debian's /boot partition as the /boot partition for LFS as well, so installing LFS's kernel (6.4.12 IIRC) alongside Debian's, but I quickly learned the folly of that when I saw the mess update-grub made of that... So I rebuilt my LFS (was happy to do so, this is a learning exercise) with its own /boot partition, which gets me closer to the solution I want which is one Grub, Debian's grub, with Debian as the first and default boot choice, but LFS available as an alternative. And the only remaining problem is the Debian GRUB's insistence on using /dev/sdX2 (for the root partition is the second partition on the disk) in the "linux" command line parameter. > > When os-prober runs on my system, a lot of stuff gets logged in > messages, syslog and user.log. The lines that contain the string > "result:" (without the quotes) are interesting. It's evident from > those that have six fields following result: have had their root= > field copied from the foreign system's grub.cfg. (In my case, > "foreign" means a Debian system of the previous release.) > > When os-prober writes several clauses into my new grub.cfg's > "### BEGIN /etc/grub.d/30_os-prober ###" section, the references > to the partition are constructed using UUIDs (not PARTUUIDs, because > there's an initrd). However, the kernel command line reads > "root=LABEL=toto04", so that string wasn't constructed by os-prober, > but copied from the foreign grub.cfg¹. > > That suggests to me the probability that whereas +Grub constructs+ > the root= strings for the "### BEGIN /etc/grub.d/10_linux ###" > section, +os-prober copies+ the root= strings into the > "### BEGIN /etc/grub.d/30_os-prober ###" section instead. > Interesting -- but there is no grub.cfg on the LFS system because grub has never been installed there. There is a /boot partition but no /boot/grub/grub.cfg <suddenly doubts self, and goes to check -- indeed, there isn't>. So, nothing to copy from in this case. Mark
[toc] | [prev] | [next] | [standalone]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2023-12-21 23:00 +0100 |
| Message-ID | <HNzfb-faCI-11@gated-at.bofh.it> |
| In reply to | #265115 |
On Thu, 21 Dec 2023 at 21:38, Mark Fletcher <mark27q1@gmail.com> wrote:
>
>
> So I rebuilt my LFS (was happy to do so, this is a learning exercise)
> with its own /boot partition, which gets me closer to the solution I
> want which is one Grub, Debian's grub, with Debian as the first and
> default boot choice, but LFS available as an alternative. And the only
> remaining problem is the Debian GRUB's insistence on using /dev/sdX2
> (for the root partition is the second partition on the disk) in the
> "linux" command line parameter.
>
Apologies -- I probably made it less clear rather than more with the
above -- I mean that Debian GRUB is insisting on using /dev/sdX2 _for
the LFS menu entry_. For its own menu entry it works fine, because my
bookworm installation is using LVM.
There is and ever has been only one GRUB on this system -- Debian's.
That's why I am asking about this on a Debian list. My goal here is to
configure Debian's GRUB to boot LFS as a secondary option alongside
the primary option of Debian, and have that survive kernel updates for
Debian, and I am there, except for persuading it not to specify
"root=/dev/sdX2" for the root filesystem in the LFS linux command
line, and instead persuading ti to specify "root=PARTUUID=<part UUID>"
which grub-mkconfig's documentation says is what it will do when there
is no initrd and the GRUB_DISABLE_LINUX_{PART,}UUID variables are set
to false.
Mark
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-22 02:30 +0100 |
| Subject | Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HNCwp-fcNZ-5@gated-at.bofh.it> |
| In reply to | #265115 |
On Thu 21 Dec 2023 at 21:38:46 (+0000), Mark Fletcher wrote:
> On Wed, 20 Dec 2023 at 06:01, David Wright <deblis@lionunicorn.co.uk> wrote:
> >
> > I can't see anywhere where the OP claims to have set up LFS for
> > booting itself, as opposed to being booted from a Debian Grub.
> > It only says "I have been able to get a grub.cfg including the
> > LFS system …", which seems to imply LFS has only been set up
> > as a "foreign" system by a Debian system.
>
> Yes, that's exactly it. My very first attempt involved using Debian's
> /boot partition as the /boot partition for LFS as well, so installing
> LFS's kernel (6.4.12 IIRC) alongside Debian's, but I quickly learned
> the folly of that when I saw the mess update-grub made of that...
What sort of mess? I would have thought Grub would ignore excess
kernels dropped into /boot. I have a laptop here that has two
bookworm netinst ISOs (release candidates) and a kernel and initrd
(hd-media) for booting the ISOs, and they've been ignored through
at least two kernel upgrades:
4096 Oct 9 22:49 /grub
83 Aug 16 15:52 System.map-5.10.0-25-686
83 Sep 28 23:25 System.map-5.10.0-26-686
245147 Aug 16 15:52 config-5.10.0-25-686
245200 Sep 28 23:25 config-5.10.0-26-686
703594k Apr 24 2023 debian-bookworm-DI-rc1-i386-netinst.iso
704643k Apr 28 2023 debian-bookworm-DI-rc2-i386-netinst.iso
19920k Apr 27 2023 initrd.gz
33580k Oct 7 12:36 initrd.img-5.10.0-25-686
33588k Nov 27 18:46 initrd.img-5.10.0-26-686
5548224 Apr 8 2023 vmlinuz
4988160 Aug 16 15:52 vmlinuz-5.10.0-25-686
4990880 Sep 28 23:25 vmlinuz-5.10.0-26-686
I've already posted my (slightly overlong) /etc/grub.d/07_custom;
I can boot the installer with:
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "Install Debian via HTTP" {
search --no-floppy --label --set=root noah03
linux /boot/vmlinuz priority=low
initrd /boot/initrd.gz
}
#
### END /etc/grub.d/40_custom ###
> So I rebuilt my LFS (was happy to do so, this is a learning exercise)
> with its own /boot partition, which gets me closer to the solution I
> want which is one Grub, Debian's grub, with Debian as the first and
> default boot choice, but LFS available as an alternative. And the only
> remaining problem is the Debian GRUB's insistence on using /dev/sdX2
> (for the root partition is the second partition on the disk) in the
> "linux" command line parameter.
I've never run LFS; what does the menuentry in grub.cfg look like?
> > When os-prober runs on my system, a lot of stuff gets logged in
> > messages, syslog and user.log. The lines that contain the string
> > "result:" (without the quotes) are interesting. It's evident from
> > those that have six fields following result: have had their root=
> > field copied from the foreign system's grub.cfg. (In my case,
> > "foreign" means a Debian system of the previous release.)
> >
> > When os-prober writes several clauses into my new grub.cfg's
> > "### BEGIN /etc/grub.d/30_os-prober ###" section, the references
> > to the partition are constructed using UUIDs (not PARTUUIDs, because
> > there's an initrd). However, the kernel command line reads
> > "root=LABEL=toto04", so that string wasn't constructed by os-prober,
> > but copied from the foreign grub.cfg.
> >
> > That suggests to me the probability that whereas +Grub constructs+
> > the root= strings for the "### BEGIN /etc/grub.d/10_linux ###"
> > section, +os-prober copies+ the root= strings into the
> > "### BEGIN /etc/grub.d/30_os-prober ###" section instead.
So what does this command show, if anything:
$ zgrep result: /var/log/messages*
/var/log/messages:Dec 21 18:10:52 acer 90linux-distro: result: /dev/sda4:Debian GNU/Linux 12 (bookworm):Debian:linux
/var/log/messages:Dec 21 18:10:57 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux:/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro quiet
/var/log/messages:Dec 21 18:10:57 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-13-686:/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro quiet
/var/log/messages:Dec 21 18:10:57 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-13-686 (recovery mode):/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro single
/var/log/messages:Dec 21 18:10:57 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-10-686:/boot/vmlinuz-6.1.0-10-686:/boot/initrd.img-6.1.0-10-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro quiet
/var/log/messages:Dec 21 18:10:58 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-10-686 (recovery mode):/boot/vmlinuz-6.1.0-10-686:/boot/initrd.img-6.1.0-10-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro single
(you can use messages*, syslog* or user.log*)
> Interesting -- but there is no grub.cfg on the LFS system because grub
> has never been installed there. There is a /boot partition but no
> /boot/grub/grub.cfg <suddenly doubts self, and goes to check --
> indeed, there isn't>.
> So, nothing to copy from in this case.
That's why I was interested in the zgrep output: I've never had
a system with "foreign" systems that lack grub.cfg (except for
Windows, which is handled differently). I've always set up Grub
on any system I've installed.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2023-12-22 04:30 +0100 |
| Subject | Re: GRUB -- Debian overrides? (but on original thread topic, not so much) |
| Message-ID | <HNEox-fdXd-1@gated-at.bofh.it> |
| In reply to | #265132 |
David Wright composed on 2023-12-21 19:20 (UTC-0600):
> On Thu 21 Dec 2023 at 21:38:46 (+0000), Mark Fletcher wrote:
>> My very first attempt involved using Debian's
>> /boot partition as the /boot partition for LFS as well, so installing
>> LFS's kernel (6.4.12 IIRC) alongside Debian's, but I quickly learned
>> the folly of that when I saw the mess update-grub made of that...
> What sort of mess? I would have thought Grub would ignore excess
> kernels dropped into /boot.
It doesn't exactly ignore. This is from a rather old Dell MBR booting
with Grub Legacy installed (but rarely actually used to boot Bullseye):
# inxi -CSz
System:
Kernel: 5.10.0-23-amd64 arch: x86_64 bits: 64 Desktop: Trinity v: R14.1.1
Distro: Debian GNU/Linux 11 (bullseye)
CPU:
Info: dual core model: Intel Core2 Duo E4400 bits: 64 type: MCP cache:
L2: 2 MiB
Speed (MHz): avg: 2000 min/max: N/A cores: 1: 2000 2: 2000
# apt-get full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
linux-image-5.10.0-11-amd64 linux-image-5.10.0-13-amd64 linux-image-5.10.0-14-amd64 linux-image-5.10.0-18-amd64
linux-image-5.10.0-9-amd64 usb.ids
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
linux-image-5.10.0-26-amd64
The following packages will be upgraded:
linux-image-amd64
1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/55.6 MB of archives.
After this operation, 318 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
Selecting previously unselected package linux-image-5.10.0-26-amd64.
(Reading database ... 97500 files and directories currently installed.)
Preparing to unpack .../linux-image-5.10.0-26-amd64_5.10.197-1_amd64.deb ...
Unpacking linux-image-5.10.0-26-amd64 (5.10.197-1) ...
Preparing to unpack .../linux-image-amd64_5.10.197-1_amd64.deb ...
Unpacking linux-image-amd64 (5.10.197-1) over (5.10.179-1) ...
Setting up linux-image-5.10.0-26-amd64 (5.10.197-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-23-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-23-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.10.0-26-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.10.0-26-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-26-amd64
/etc/kernel/postinst.d/zz-update-grub:
Searching for GRUB installation directory ... found: /boot/grub
WARNING: tempfile is deprecated; consider using mktemp instead.
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
WARNING: tempfile is deprecated; consider using mktemp instead.
Searching for splash image ... none found, skipping ...
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv2' has bad syntax: version number does not start with digit
dpkg: warning: version 'prv' has bad syntax: version number does not start with digit
dpkg: warning: version 'cur' has bad syntax: version number does not start with digit
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz-prv2
Found kernel: /boot/vmlinuz-prv
Found kernel: /boot/vmlinuz-cur
Found kernel: /boot/vmlinuz-5.10.0-26-amd64
Found kernel: /boot/vmlinuz-5.10.0-23-amd64
Found kernel: /boot/vmlinuz-5.10.0-20-amd64
Found kernel: /boot/vmlinuz-5.10.0-18-amd64
Found kernel: /boot/vmlinuz-5.10.0-14-amd64
Found kernel: /boot/vmlinuz-5.10.0-13-amd64
Found kernel: /boot/vmlinuz-5.10.0-11-amd64
Found kernel: /boot/vmlinuz-5.10.0-9-amd64
Updating /boot/grub/menu.lst ... done
Setting up linux-image-amd64 (5.10.197-1) ...
# ln -s vmlinuz-5.10.0-26-amd64 vmlinuz-cur && ln -s initrd.img-5.10.0-26-amd64 initrd-cur
# ls -Gg vml*
lrwxrwxrwx 1 23 Jun 14 2023 vmlinuz -> vmlinuz-5.10.0-23-amd64
-rw-r--r-- 1 6837952 Feb 28 2022 vmlinuz-5.10.0-11-amd64
-rw-r--r-- 1 6840768 Mar 17 2022 vmlinuz-5.10.0-13-amd64
-rw-r--r-- 1 6843648 Apr 29 2022 vmlinuz-5.10.0-14-amd64
-rw-r--r-- 1 6962016 Sep 2 2022 vmlinuz-5.10.0-18-amd64
-rw-r--r-- 1 7008928 Dec 13 2022 vmlinuz-5.10.0-20-amd64
-rw-r--r-- 1 7036256 May 12 2023 vmlinuz-5.10.0-23-amd64
-rw-r--r-- 1 7044672 Sep 29 00:25 vmlinuz-5.10.0-26-amd64
lrwxrwxrwx 1 22 Oct 31 2021 vmlinuz51009 -> vmlinuz-5.10.0-9-amd64
-rw-r--r-- 1 6833568 Sep 30 2021 vmlinuz-5.10.0-9-amd64
lrwxrwxrwx 1 23 Feb 5 2022 vmlinuz51011 -> vmlinuz-5.10.0-11-amd64
lrwxrwxrwx 1 23 Apr 16 2022 vmlinuz51013 -> vmlinuz-5.10.0-13-amd64
lrwxrwxrwx 1 23 Jun 5 2022 vmlinuz51014 -> vmlinuz-5.10.0-14-amd64
lrwxrwxrwx 1 23 Sep 21 2022 vmlinuz51018 -> vmlinuz-5.10.0-18-amd64
lrwxrwxrwx 1 23 Dec 21 22:09 vmlinuz-cur -> vmlinuz-5.10.0-26-amd64
lrwxrwxrwx 1 23 Jun 14 2023 vmlinuz-prv -> vmlinuz-5.10.0-23-amd64
lrwxrwxrwx 1 23 Dec 30 2022 vmlinuz-prv2 -> vmlinuz-5.10.0-20-amd64
#
Newer PCs with grub-efi exhibit similar behavior, but all here that actually
have grub-efi installed already have current kernel.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-22 06:40 +0100 |
| Subject | Re: GRUB -- Debian overrides? (but on original thread topic, not so much) |
| Message-ID | <HNGql-ffb0-3@gated-at.bofh.it> |
| In reply to | #265137 |
On Thu 21 Dec 2023 at 22:19:47 (-0500), Felix Miata wrote: > David Wright composed on 2023-12-21 19:20 (UTC-0600): > > On Thu 21 Dec 2023 at 21:38:46 (+0000), Mark Fletcher wrote: > > >> My very first attempt involved using Debian's > >> /boot partition as the /boot partition for LFS as well, so installing > >> LFS's kernel (6.4.12 IIRC) alongside Debian's, but I quickly learned > >> the folly of that when I saw the mess update-grub made of that... > > > What sort of mess? I would have thought Grub would ignore excess > > kernels dropped into /boot. > > It doesn't exactly ignore. This is from a rather old Dell MBR booting > with Grub Legacy installed (but rarely actually used to boot Bullseye): [ … ] > Found kernel: /boot/vmlinuz > Found kernel: /boot/vmlinuz-prv2 > Found kernel: /boot/vmlinuz-prv > Found kernel: /boot/vmlinuz-cur > Found kernel: /boot/vmlinuz-5.10.0-26-amd64 > Found kernel: /boot/vmlinuz-5.10.0-23-amd64 > Found kernel: /boot/vmlinuz-5.10.0-20-amd64 > Found kernel: /boot/vmlinuz-5.10.0-18-amd64 > Found kernel: /boot/vmlinuz-5.10.0-14-amd64 > Found kernel: /boot/vmlinuz-5.10.0-13-amd64 > Found kernel: /boot/vmlinuz-5.10.0-11-amd64 > Found kernel: /boot/vmlinuz-5.10.0-9-amd64 > Updating /boot/grub/menu.lst ... done [ … ] > Newer PCs with grub-efi exhibit similar behavior, but all here that actually > have grub-efi installed already have current kernel. Mine is a bullseye BIOS-booting laptop with the previously listed /boot directory. I copied a couple of kernels and initrds from the bookworm RCs in partition noah04, and then ran grub-mkconfig. Stderr shows: Generating grub configuration file ... Found linux image: /boot/vmlinuz-6.1.0-13-686 Found initrd image: /boot/initrd.img-6.1.0-13-686 Found linux image: /boot/vmlinuz-6.1.0-10-686 Found initrd image: /boot/initrd.img-6.1.0-10-686 Found linux image: /boot/vmlinuz-5.10.0-26-686 Found initrd image: /boot/initrd.img-5.10.0-26-686 Found linux image: /boot/vmlinuz-5.10.0-25-686 Found initrd image: /boot/initrd.img-5.10.0-25-686 Warning: os-prober will be executed to detect other bootable partitions. Its output will be used to detect bootable binaries on them and create new boot entries. Found Debian GNU/Linux 12 (bookworm) on /dev/sda4 done All the Debian kernels installed from linux-image-….deb packages are found by Grub, and appear in the usual array of prefix10 menuentries. Also, both the bookworm kernels are found by os-prober, as shown by the previously posted zgrep result: listing, and appear in the usual array of prefix30 menuentries. But something about the hd-media installer kernel/initrd seems to prevent Grub from finding them and constructing a menuentry. We know that the LFS kernel is detected by Debian's os-prober, but only that Grub makes a "mess" when given the opportunity of finding the LFS kernel in the same /boot as the Debian ones. What exactly is this mess? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2023-12-22 12:30 +0100 |
| Message-ID | <HNLT4-fiFo-51@gated-at.bofh.it> |
| In reply to | #265132 |
On Fri, 22 Dec 2023 at 01:21, David Wright <deblis@lionunicorn.co.uk> wrote:
>
> What sort of mess? I would have thought Grub would ignore excess
> kernels dropped into /boot. I have a laptop here that has two
> bookworm netinst ISOs (release candidates) and a kernel and initrd
> (hd-media) for booting the ISOs, and they've been ignored through
> at least two kernel upgrades:
>
> 4096 Oct 9 22:49 /grub
> 83 Aug 16 15:52 System.map-5.10.0-25-686
> 83 Sep 28 23:25 System.map-5.10.0-26-686
> 245147 Aug 16 15:52 config-5.10.0-25-686
> 245200 Sep 28 23:25 config-5.10.0-26-686
> 703594k Apr 24 2023 debian-bookworm-DI-rc1-i386-netinst.iso
> 704643k Apr 28 2023 debian-bookworm-DI-rc2-i386-netinst.iso
> 19920k Apr 27 2023 initrd.gz
> 33580k Oct 7 12:36 initrd.img-5.10.0-25-686
> 33588k Nov 27 18:46 initrd.img-5.10.0-26-686
> 5548224 Apr 8 2023 vmlinuz
> 4988160 Aug 16 15:52 vmlinuz-5.10.0-25-686
> 4990880 Sep 28 23:25 vmlinuz-5.10.0-26-686
It saw a Debian kernel (6.1.something) on <debian boot partition>/ and
a LFS kernel (6.4.12 IIRC) on <the same Debian boot partition>/. It
also saw candidate root filesystems on <debian lvm root> and <LFS root
partition>. And it proceeded to cartesian join them, so I got LFS
kernel with debian root filesystem, Debian kernel with Debian root
filesystem, LFS kernel with LFS root filesystem (specified by
/dev/sdc2 which the very next time it booted that disk was /dev/sda2)
and Debian kernel with LFS root filesystem (again specified by device
name). Obviously, only 2 of those are things I'd ever want to boot.
And, once I saw what it had done, I kinda slapped my forehead and
thought well yeah, how was it supposed to know not to do that...
>
> I've never run LFS; what does the menuentry in grub.cfg look like?
>
menuentry 'Linux From Scratch (12.0-systemd) (on /dev/sdc2)' --class linuxfromsc
ratch --class gnu-linux --class gnu {
insmod part_gpt
insmod ext2
set root='hd2,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-ef
i=hd2,gpt1 --hint-baremetal=ahci2,gpt1 <fs UUID elided>
else
search --no-floppy --fs-uuid --set=root <fs UUID elided>
957b66
fi
linux /vmlinuz-6.4.12-lfs-12.0-systemd root=PARTUUID=<partUUID elided>
}
That is AFTER my edits to replace root=/dev/sdc2 in the linux command
line with the PARTUUID. The FS UUIDs I elided above were put there by
GRUB. Again, Debian GRUB created this when I ran it with os_prober
turned ON. I grabbed this and copied it to custom.cfg, made the edit
to add the PARTUUID, then ran update-grub again with os_prober turned
off.
Ah hold on. Maybe os_prober is what is generating this menuentry
stanza in the first place, and grub is just using it. If that's the
case, I was asking the wrong question in the first place. Maybe the
question isn't why isn't grub using PARTUUID= in this situation, which
the manual says it will, but rather why isn't os_prober doing so?
>
> So what does this command show, if anything:
>
> $ zgrep result: /var/log/messages*
> /var/log/messages:Dec 21 18:10:52 acer 90linux-distro: result: /dev/sda4:Debian GNU/Linux 12 (bookworm):Debian:linux
> /var/log/messages:Dec 21 18:10:57 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux:/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro quiet
> /var/log/messages:Dec 21 18:10:57 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-13-686:/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro quiet
> /var/log/messages:Dec 21 18:10:57 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-13-686 (recovery mode):/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro single
> /var/log/messages:Dec 21 18:10:57 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-10-686:/boot/vmlinuz-6.1.0-10-686:/boot/initrd.img-6.1.0-10-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro quiet
> /var/log/messages:Dec 21 18:10:58 acer 40grub2: result: /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-10-686 (recovery mode):/boot/vmlinuz-6.1.0-10-686:/boot/initrd.img-6.1.0-10-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8 ro single
>
> (you can use messages*, syslog* or user.log*)
Interestingly, the most recent output in /var/log/messages* was from
November, ie before i started playing with this. So here is what is in
/var/log/syslog*, confining attention to the most recent date:
/var/log/user.log:2023-12-18T18:37:47.192311+00:00 phantom 40lsb:
result: /dev/sdc2:Linux From Scratch
(12.0-systemd):LinuxFromScratch:linux
/var/log/user.log:2023-12-18T18:37:49.378939+00:00 phantom
90linux-distro: result: /dev/mapper/kazuki--vg-root:Debian GNU/Linux
10 (buster):Debian:linux
/var/log/user.log:2023-12-18T18:37:49.893237+00:00 phantom 90fallback:
result: /dev/sdc2:/dev/sdc1::/boot/vmlinuz-6.4.12-lfs-12.0-systemd::root=/dev/sdc2
/var/log/user.log:2023-12-18T18:37:51.945521+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian
GNU/Linux:/boot/vmlinuz-4.19.0-12-amd64:/boot/initrd.img-4.19.0-12-amd64:root=/dev/mapper/kazuki--vg-root
ro quiet
/var/log/user.log:2023-12-18T18:37:52.037769+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian GNU/Linux, with
Linux 4.19.0-12-amd64:/boot/vmlinuz-4.19.0-12-amd64:/boot/initrd.img-4.19.0-12-amd64:root=/dev/mapper/kazuki--vg-root
ro quiet
/var/log/user.log:2023-12-18T18:37:52.125886+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian GNU/Linux, with
Linux 4.19.0-12-amd64 (recovery
mode):/boot/vmlinuz-4.19.0-12-amd64:/boot/initrd.img-4.19.0-12-amd64:root=/dev/mapper/kazuki--vg-root
ro single
/var/log/user.log:2023-12-18T18:37:52.217524+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian GNU/Linux, with
Linux 4.19.0-11-amd64:/boot/vmlinuz-4.19.0-11-amd64:/boot/initrd.img-4.19.0-11-amd64:root=/dev/mapper/kazuki--vg-root
ro quiet
/var/log/user.log:2023-12-18T18:37:52.304735+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian GNU/Linux, with
Linux 4.19.0-11-amd64 (recovery
mode):/boot/vmlinuz-4.19.0-11-amd64:/boot/initrd.img-4.19.0-11-amd64:root=/dev/mapper/kazuki--vg-root
ro single
(The references to "kazuki" are an old buster installation on an old
SSD that is connected to this box but that I am not using these days,
but can't quite bring myself to delete.... I don't particularly want
it in GRUB but don't mind if it gets there)
I don't know how it figured out /dev/sdc2 -- on the one hand it is
clever to have done so with no grub.cfg to tell it, on the other I
wish it were clever enough to use PARTUUID= instead, as the
grub-mkconfig manual implies it is.
That all said, the updated idea of trying 40_custom instead of
41_custom and thus avoiding the question of the config_directory
variable is what I will try next.
Mark
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-27 06:00 +0100 |
| Subject | Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HPubn-gos9-5@gated-at.bofh.it> |
| In reply to | #265144 |
On Fri 22 Dec 2023 at 11:24:22 (+0000), Mark Fletcher wrote:
> On Fri, 22 Dec 2023 at 01:21, David Wright <deblis@lionunicorn.co.uk> wrote:
> >
> > What sort of mess? I would have thought Grub would ignore excess
> > kernels dropped into /boot.
> [ … ]
> It saw a Debian kernel (6.1.something) on <debian boot partition>/ and
> a LFS kernel (6.4.12 IIRC) on <the same Debian boot partition>/. It
> also saw candidate root filesystems on <debian lvm root> and <LFS root
> partition>. And it proceeded to cartesian join them, so I got LFS
> kernel with debian root filesystem, Debian kernel with Debian root
> filesystem, LFS kernel with LFS root filesystem (specified by
> /dev/sdc2 which the very next time it booted that disk was /dev/sda2)
> and Debian kernel with LFS root filesystem (again specified by device
> name). Obviously, only 2 of those are things I'd ever want to boot.
> And, once I saw what it had done, I kinda slapped my forehead and
> thought well yeah, how was it supposed to know not to do that...
That seems to answer my question—it's something about installation
kernels that makes Grub ignore them, rather than Debian/non-Debian.
> > I've never run LFS; what does the menuentry in grub.cfg look like?
> [ … ]
> That is AFTER my edits to replace root=/dev/sdc2 in the linux command
> line with the PARTUUID. The FS UUIDs I elided above were put there by
> GRUB. Again, Debian GRUB created this when I ran it with os_prober
> turned ON. I grabbed this and copied it to custom.cfg, made the edit
> to add the PARTUUID, then ran update-grub again with os_prober turned
> off.
>
> Ah hold on. Maybe os_prober is what is generating this menuentry
> stanza in the first place, and grub is just using it. If that's the
> case, I was asking the wrong question in the first place. Maybe the
> question isn't why isn't grub using PARTUUID= in this situation, which
> the manual says it will, but rather why isn't os_prober doing so?
AIUI os-prober doesn't write "fancy" kernel commands lines itself:
it copies them. The scripts that write prefix30 menuentries are happy
to juggle partitions and contents because they are written with Grub's
capabilities in mind, but they can't know how those kernels will
interpret their commandline parameters beyond the most basic.
[ … ]
> I don't know how it figured out /dev/sdc2 -- on the one hand it is
> clever to have done so with no grub.cfg to tell it,
It searched partitions for bootables, and found one in /dev/sdc2
(which, as you pointed out, is not a stable name), so it wrote
linux /vmlinuz-6.4.12-lfs-12.0-systemd root=/dev/sdc2
named after where it found the kernel. "root=/dev/sdc2" can be
understood by any linux kernel.
> on the other I
> wish it were clever enough to use PARTUUID= instead, as the
> grub-mkconfig manual implies it is.
Only /etc/grub.d/{10_linux,20_linux_xen} can generate PARTUUIDs;
/etc/grub.d/30_os-prober doesn't even contain the string "PARTUUID".
And I noticed:
https://www.linuxfromscratch.org/lfs/view/9.0/chapter08/grub.html
says:
"Caution
"There is a command, grub-mkconfig, that can write a configuration
file automatically. It uses a set of scripts in /etc/grub.d/ and
will destroy any customizations that you make. These scripts are
designed primarily for non-source distributions and are not
recommended for LFS. If you install a commercial Linux distribution,
there is a good chance that this program will be run. Be sure to
back up your grub.cfg file."
So it seems to be assumed that LFS sysadmins should craft their own.
> That all said, the updated idea of trying 40_custom instead of
> 41_custom and thus avoiding the question of the config_directory
> variable is what I will try next.
Yes, I posted a 40_custom entry, and have never seen any advantage
in trying the 41_custom method myself.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | "Roy J. Tellason, Sr." <roy@rtellason.com> |
|---|---|
| Date | 2023-12-20 17:10 +0100 |
| Message-ID | <HN7iW-eTC2-9@gated-at.bofh.it> |
| In reply to | #264940 |
On Tuesday 19 December 2023 09:40:19 pm Felix Miata wrote: > I suspect few if any regulars here spend much time with Slackware. I, for one, have been running Slackware since 1999. It's what's running in this virtualbox where I do my email, and it's also what's running on my file server... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
[toc] | [prev] | [next] | [standalone]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2023-12-21 22:40 +0100 |
| Message-ID | <HNyVP-favU-9@gated-at.bofh.it> |
| In reply to | #264940 |
On Wed, 20 Dec 2023 at 02:40, Felix Miata <mrmazda@earthlink.net> wrote: > > Mark Fletcher composed on 2023-12-20 00:28 (UTC): > > > I am curious to know from Debian > > GRUBbers (as it were) if the behaviour I am describing in this thread > > is expected... > > I suspect few if any regulars here spend much time with Slackware. I am genuinely confused about how Slackware came into the picture here... my foreign OS is LFS, nothing to do with slackware as far as I know... I appreciate your initial help which I still think is my best hope of a solution -- about to implement in a few minutes so will know for sure shortly -- but have not responded to the rest of this message as I think it is based on a misunderstanding. Thanks Mark
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2023-12-22 01:40 +0100 |
| Subject | Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HNBK1-fci9-3@gated-at.bofh.it> |
| In reply to | #265116 |
Mark Fletcher composed on 2023-12-21 21:30 (UTC): > Felix Miata wrote: >> I suspect few if any regulars here spend much time with Slackware. > I am genuinely confused about how Slackware came into the picture > here... my foreign OS is LFS, nothing to do with slackware as far as I > know... Pure unadulterated word dyslexia here. My brain routinely fails to register any difference between LFS and Slackware, both of which in my mind rely more heavily on the brains of its admins than those of Debian's or its derivatives'. LFS I've never attempted to use. Slackware I have. Sorry for causing confusion here. > I appreciate your initial help which I still think is my best hope of > a solution Boot setup are rather simple here. I don't "edit" content of any files in /etc/grub.d/ in the usual sense of the word. What I do is copy 40_custom to 06_custom, and copy 41_custom to 07_custom on my Tumbleweed installation. Then I remove the content from 40_custom and 41_custom to make them inert rather than having the package system recreate them and bloat grub.cfg as a result. I manually maintain one file: /boot/grub2/custom.cfg on my Tumbleweed / filesystem. That would correspond to a Debian LVM user, such as you, maintaining /grub/custom.cfg on his /boot filesystem. Admins are 100% responsible for the content of (*/gru*/)custom.cfg. Because of my particular handling of /etc/grub.d/, the stanzas in custom.cfg head the selection list presented by Grub on boot. Those generated by Grub's scripts are rarely utilized here. Any selected stanza from custom.cfg that fails to boot something can only be due to my own fault. Tumbleweed is the only distro installed here where the ESP is routinely mounted to /boot/efi/. Only one bootloader is needed per typical Gnu/Linux-only multiboot PC. >From one PC here currently booted: # grep vmlinuz /boot/grub2/custom.cfg | wc -l 21 # grep root= /boot/grub2/custom.cfg | wc -l 21 # grep root=LABEL /boot/grub2/custom.cfg | wc -l 21 # There need be no difference from my configuration an any Debian user's, other than the name of the directory containing custom.cfg. For those who don't know the why of /boot/grub2/ instead of /boot/grub/ (on openSUSE at least), grub2 is used instead of grub in /boot/ as a historical continuation of the multiple releases period when both Grub Legacy and Grub2 could be simultaneously installed on the same installation without need for any filename customization in Grub as installed. IIRC, one could be setup on MBR, the other on a partition, possibly more for developer convenience than any expectation users would want both at once. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-22 01:50 +0100 |
| Subject | Re: GRUB -- Debian overrides? Or maybe I just don't understand it well... |
| Message-ID | <HNBTH-fcm0-1@gated-at.bofh.it> |
| In reply to | #265129 |
On Thu, Dec 21, 2023 at 07:33:13PM -0500, Felix Miata wrote: > >From one PC here currently booted: > # grep vmlinuz /boot/grub2/custom.cfg | wc -l > 21 > # grep root= /boot/grub2/custom.cfg | wc -l > 21 > # grep root=LABEL /boot/grub2/custom.cfg | wc -l > 21 Just for the record, grep -c (count matching lines) exists.
[toc] | [prev] | [next] | [standalone]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2023-12-21 23:50 +0100 |
| Message-ID | <HNA1z-fb8F-1@gated-at.bofh.it> |
| In reply to | #264894 |
On Mon, 18 Dec 2023 at 22:15, Felix Miata <mrmazda@earthlink.net> wrote:
>
> I can't answer why Grub scripts to what the do, because I don't really use them,
> and don't need to understand much about them. Grub config files in /boot/grub/ are
> akin to scripts, but they are really simple, mainly just command scripts. The
> usual one is grub.cfg, the one os-prober feeds from other Linux installations. A
> less common one is custom.cfg. To use it requires the admin build it. When it
> exists, grub-mkconfig incorporates its use by/in grub.cfg. It actually gets called
> by default from /etc/grub.d/41_custom, which adds the stanzas from it to the Grub
> boot menu - after those that it has generated itself. I copy it to
> /etc/grub.d/07_custom, and empty 41_custom. That causes my custom stanzas to
> appear first in Grub's boot menu. /etc/grub.d/40_custom acts, and a copy of it as
> 06_custom would act, in similar fashion, except that the admin's custom stanzas
> are put into it by the admin instead of into a custom.cfg file.
>
> Thus, you, as admin, construct working stanzas however you like, with or without
> UUIDS, with or without device names, with or without volume LABELS, however you
> like boot to go, and they don't get changed, except by the admin - you. This is
> easy, because you as admin can use the kernel (and initrd) symlinks Debian puts in
> /, or anywhere you'd like symlinks to them to go, for distros that don't
> automatically create them for you. There's no need for maintenance when new
> kernels are installed in the case of Debian and other distros that automatically
> generate new symlinks. For those that don't, creating them is trivial.
>
I have just tried this, I see 41_custom in /etc/grub.d and I see that
the text from that file ends up in my grub.cfg when I run update-grub.
So I have disabled os-prober, since I won't need it if I can get this
working, and created a cusom.cfg file with approximately what
os-prober generated as manuentry stanza lines for my LFS instance
(with references to os-prober removed and the root=/dev/sdc2 changed
to root=PARTUUID=<part UUID>)
And... on reboot, the menu entry for LFS is not included.
Now looking closer at 41_custom, it says this:
#!/bin/sh
cat <<EOF
if [ -f \${config_directory}/custom.cfg ]; then
source \${config_directory}/custom.cfg
elif [ -z "\${config_directory}" -a -f \$prefix/custom.cfg ]; then
source \$prefix/custom.cfg
fi
EOF
I read that as saying if custom.cfg exists *in whatever directory is
pointed at by the variable config_directory*, then read that file. If
the directory pointed at by config_directory doesn't exist and there
is a custom.cfg in whatever directory is pointed at by the variable
prefix, use that.
The question is, what values are config_directory and prefix set to?
"prefix" is referenced in other scripts in /etc/grub.d and set to /usr
-- which is no use here as /usr is on the partition we are trying to
find so grub won't be able to see that at boot time. The only script
in that directory that references config_directory is 41_custom and it
doesn't set it. Looking at my /boot/grub/grub.cfg it doesn't contain
any references to config_directory except those that were copied from
41_custom. Am I supposed to change 41_custom or something? And if I
am, I guess I would want it to say /grub/custom.cfg since this path is
presumably relative to the root of the /boot partition, that at the
time this is being consulted that is the only partition mounted?
I feel like I am getting close but am not quite there.
Mark
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> |
|---|---|
| Date | 2023-12-22 08:50 +0100 |
| Message-ID | <HNIs9-fgjk-1@gated-at.bofh.it> |
| In reply to | #265125 |
Mark Fletcher <mark27q1@gmail.com> writes > The question is, what values are config_directory and prefix set to? Grub sets config_directory to point to the directory where it's reading it's config from. In other words, /boot. But why not just use 40_custom? It copies whatever is in the file (after the header) to your grub.cfg. Don't need to figure out what file goes in what directory. It also keeps configuration in /etc instead of moving it to /boot.
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.debian.user
csiph-web