Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
On 07.01.24 20:33, songbird wrote: i see you've solved your issue, but i just wanted to point out that it works and is ok for people who want to try it out. Says who?
Re: systemd-boot not asking password, not resuming from hibernate
On 07.01.24 18:07, David Wright wrote: On Sat 06 Jan 2024 at 20:04:57 (+0100), Richard Rosner wrote: I just tried out systemd-boot. What I noticed, it doesn't ask for my decryption password to decrypt both my LUKS2 encrypted root and swap partition. This kinda defeats the purpose of encrypted drives. How do I have systemd-boot forget and never again remember my credentials? I'm assuming that when you boot, you do get /one/ prompt for your passphrase, and not zero. If it doesn't ask /again/ after that, then I'd guess that it's storing something somewhere. Nope, there's absolutely none. It just boots straight into the system, just as I said. Hence, I literally named this topic "systemd-boot *not asking* password". If it wouldn't ask again, that would just be the as expected behavior you'll also get from Grub. It makes no sense to ask for every encrypted partition when the passphrase is the same. In the little I've read about this, I've come across a scheme where Grub writes an initrd file in memory and appends it to your main initrd(s) so that the kernel can read it later. I kinda doubt that, like a lot. Maybe update-initramfs does pull in information from the Grub config, but otherwise there's no indication to that. It does pass parameters you put into the /etc/default/grub to the Kernel though. For the installation, I just installed systemd-boot. Afterward I had to uncomment the timeout option in /boot/efi/loader/loader.conf so I would get the selection screen, but I didn't make any other modifications. So what exactly is missing? Adding to that, resume from hibernate doesn't seem to work. Resume is included in the options line in the /boot/efi/loader/entries files, it's also enabled in initramfs-tools, yet after powering on after hibernating, I'm not greeted with where I left off. I don't use hibernation. I close down desktops because I can remotely boot them, and I leave laptops running as they consume trivial power. Good for you, not my use case. PS: by any chance does anybody know if systemd-boot supports Argon2 KDF for LUKS2? I only know that Grub2 doesn't (yet), but it's difficult to find the specific documentation on systemd-boot. You probably need to follow appropriate lists if you want to stay up to date. That's just how not to do things. Software should be well documented, otherwise it should be replaced by something that is. Systemd replaced SysV Init as a service starter because it was much easier to handle and not just a pile of historical garbage nobody understands anymore. The same should be kept for other systemd services.
Re: Possibly broken Grub or initrd after updates on Testing
On 04.01.24 19:49, Richard Rosner wrote:
On 04.01.24 19:02, David Wright wrote:
Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?
Cheers,
David.
Let's hope the mailing list let's this go through.
It did, but since it seems to have been malformed yet again, let's try
again.
Keep in mind, this is based on the assumption that your whole /
partition is LUKS encrypted (in my case now LUKS2). "root partition
UUID1" is the UUID that's shown in Disks or on the Grub screen for the
decryption password prompt. Now, I can't say for sure what
"root-partition-UUID2" is, but that's what seems to be symlinked to
/dev/dm-0 and with blkid, one of the entries will look like this:
/dev/mapper/luks-: UUID=""
BLOCK_SIZE="4096" TYPE="ext4"
So maybe it's just some kind of virtual UUID for the decrypted root
partition.
Adding to that, "root partition UUID1.1" is basically the same as
UUID1.1, just without dashes. So it's the same format as Grub shows for
the ususal bootup password prompt. Let's hope this time this is the
right one.
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
insmod png
if background_image
/usr/share/desktop-base/emerald-theme/grub/grub-4x3.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class
gnu --class os $menuentry_id_option 'gnulinux-simple-UUID2>' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'
else
search --no-floppy --fs-uuid --set=root
fi
echo 'Loading Linux 6.5.0-5-amd64 ...'
linux /boot/vmlinuz-6.5.0-5-amd64 root=UUID=UUID2> ro quiet root=/dev/mapper/luks- splash
resume=/dev/mapper/luks-
echo 'Loading initial ramdisk ...'
Re: Possibly broken Grub or initrd after updates on Testing
On 07.01.24 18:07, David Wright wrote: I compared your new grub.cfg with mine (suitably decimated and edited) and the significant differences are very few; extra modules are loaded: cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256. Myset root='hd0,gpt5' is replaced by set root='cryptouuid/' and my --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-bar emetal=ahci0,gpt5 is replaced by hint='cryptouuid/' Unlike the first version of grub.cfg that you pasted earlier: cryptomount -u set root='cryptouuid/ there's no cryptomount in your new one. I'm guessing that means that the LUKS2 partition has been decrypted by Grub before grub.cfg is commanded. Do you now get just the one prompt for the passphrase when you boot? (I'm not very familiar with how far encrypted /boot has progressed.) There was always only one prompt for the passphrase when boot was working on its own. Only if you had to manually decrypt all partitions, you'd need to enter it for every encrypted partition there is — probably because you don't necessarily need to have the same password for everything. There might be an option to have it reuse the key, but I have yet to find that. Also, that the cryptomount lines are missing must be why Grub was still a bit unreliable. I'll write my current grub.cfg in a separate message, as they are back now after some experiments with rEFInd, systemd-boot and trying to get resume from hibernation to work reliably. The other difference in the earlier, pasted grub.cfg is that its linux line was extremely long, and looked as though a large amount of text had been added from GRUB_CMDLINE_LINUX_DEFAULT and/or GRUB_CMDLINE_LINUX, perhaps set in /etc/default/grub? I commented previously on the multiple root= parameters, and have also noticed that the recovery mode lines had "single" duplicated. I presume all that configuration stuff has gone away now. Well, that bunch of text is necessary, since grub has to communicate the location of the root and the swap partitions to the kernel, so of course they are automatically included in the default/grub. The last one there is just a little fix for better handling very old Synaptic touchpads in Wayland. In my current grub.cfg the multiple root= entries in one line seem to be gone, but there are still multiple single in the recovery parts. I somehow doubt whether all this will be any help, as you're working well beyond my experience, and somewhere near the cutting edge of Grub. Just shows how hopelessly outdated Grub is and that it sorely needs a replacement — and a better experience in replacing it. Grub 2.12 was just released in December. On the other hand, LUKS was originally released in 2004, LUKS2 followed in 2018 and became the default with cryptsetup 2.1.0 in early 2019 — though Debian seems to ignore that, since the installer still by default creates LUKS1 volumes. Also, by default, LUKS2 uses Argon2 key derivation function — unsupported even by Grub 2.12. All this in a time when smartphones have been encrypted for years by default, so have MacBooks and even Windows is slowing making it a default. Not to mention the fact that Linux distributions are offering encryption in their installers for many years now, with a few even making it a default, like Pop.
systemd-boot not asking password, not resuming from hibernate
I just tried out systemd-boot. What I noticed, it doesn't ask for my decryption password to decrypt both my LUKS2 encrypted root and swap partition. This kinda defeats the purpose of encrypted drives. How do I have systemd-boot forget and never again remember my credentials? For the installation, I just installed systemd-boot. Afterward I had to uncomment the timeout option in /boot/efi/loader/loader.conf so I would get the selection screen, but I didn't make any other modifications. So what exactly is missing? Adding to that, resume from hibernate doesn't seem to work. Resume is included in the options line in the /boot/efi/loader/entries files, it's also enabled in initramfs-tools, yet after powering on after hibernating, I'm not greeted with where I left off. PS: by any chance does anybody know if systemd-boot supports Argon2 KDF for LUKS2? I only know that Grub2 doesn't (yet), but it's difficult to find the specific documentation on systemd-boot.
Re: Possibly broken Grub or initrd after updates on Testing
On 04.01.24 19:02, David Wright wrote:
Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?
Cheers,
David.
Let's hope the mailing list let's this go through.
Keep in mind, this is based on the assumption that your whole /
partition is LUKS encrypted (in my case now LUKS2).
"root-partition-UUID" is the UUID that's shown in Disks or on the Grub
screen for the decryption password prompt. Now, I can't say for sure
what "root-partition-UUID2" is, but that's what seems to be symlinked to
/dev/dm-0 and with blkid, one of the entries will look like this:
/dev/mapper/luks-: UUID=""
BLOCK_SIZE="4096" TYPE="ext4"
So maybe it's just some kind of virtual UUID for the decrypted root
partition.
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if loadfont unicode ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='cryptouuid/'
else
search --no-floppy --fs-uuid --set=root
fi
insmod png
if background_image /boot/grub/.background_cache.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class
gnu --class os $menuentry_id_option
'gnulinux-simple-' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='cryptouuid/'
else
search --no-floppy --fs-uuid --set=root
fi
echo 'Loading Linux 6.5.0-5-amd64 ...'
linux /boot/vmlinuz-6.5.0-5-amd64
root=UUID= ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-6.5.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-' {
menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64' --class
debian --class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-6.5.0-5-amd64-advanced-' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='cryptouuid/'
else
search --no-floppy --fs-uuid --set=root
fi
echo 'Loading Linux 6.5.0-5-amd64 ...'
linux /boot/vmlinuz-6.5.0-5-amd64
root=UUID= ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-6.5.0-5-amd64
}
menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64 (recovery
mode)' --class debian --class gnu-linux
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
Well, that was a bust. I accidentally didn't just format the EFI
partition, but deleted it. So I re-created it with the help of disks and
gparted (to leave the first 3 MB empty, I remeber that being a fix added
kinda recently to combat bad BIOS/EFI implementations, since Windows is
doing the same and nobody could come up with anything better.
Anyways, after installing rEFInd with no grub present, it would boot
into rEFInd, but that's it. No boot options, nothing under F2. Also, I
couldn't find anything helpful on the Arch Wiki page for this. In
theory, it should be as simple as refind-install. So the only reason I
could guess to be the reason would be that rEFInd might not be capable
of handling LUKS, which would be quite disappointing. Maybe I'll take a
look at systemd-boot in the next days, as I don't need any customization
anyways, and maybe it can handle encryption (or better decryption)
better than Grub — especially with LUKS2 grub seems a bit unreasonably slow.
On 04.01.24 11:56, Richard Rosner wrote:
Good to know that it should be possible. But as mentioned, these
symbols only offer me to boot from grub or fwupd. F2 also doesn't show
that much more, it merely gives me the option to boot into the BIOS
settings. Maybe I'll have to completely purge all Grub packages, wipe
the existing EFI partition and then try to install rEFInd. I'll have
to check.
On Thu, Jan 4, 2024, 09:29 Joel Roth wrote:
On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote:
> So, since for whatever reason Grub seems to be broken beyond
repair, I today
> tried to just replace it with rEFInd. Installation succeeded
without any
> trouble. But when I start my system, rEFInd just asks me if I
want to boot
> with fwupd or with the still very broken Grub. Am I missing
something? Is
> rEFInd really just something to select between different OSs
(and not just
> different distributions like Grub can very well do) and then
gives the rest
> over to their bootloaders or am I missing something so rEFInd
will take over
> all of Grubs jobs?
I boot my debian-based system with rEFInd. Grub is not
present. A couple big icons show on the boot screen. The
small print at the bottom mentions hit F2 for more options.
On my system, F2 offers a selection among all kernels
present.
rEFInd installs into EFI/refind/ in the EFI partition.
I originally encountered it looking for something to
boot debian on a Intel Mac. It's been trouble-free.
> On 01.01.24 21:45, Richard Rosner wrote:
> >
> >
> > On 01.01.24 21:20, Richard Rosner wrote:
> > >
> > > On 01.01.24 20:30, David Wright wrote:
> > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> > > > > On 01.01.24 18:13, David Wright wrote:
> > > > > I can boot by hand, but since this is all archived
anyways and it's
> > > > > uneccessarily difficult to find some sort of guide how
to even do
> > > > > this, it might as well be a documentation for users
having such
> > > > > troubles in the future.
> > > > >
> > > > > Also, besides the way that I have no clue how it would
have to look
> > > > > like to set up a paragraph in the grub.cfg, I simply
don't see
> > > > > anything wrong with it anyways. So I can't even look at
the grub
> > > > > settings files grub.cfg is being generated from to check
where the
> > > > > error lies.
> > > > You append the commands that you used to boot manually
with into
> > > > /etc/grub.d/40_custom, observing the comments there, and
also into
> > > > grub.cfg itself at the appropriate place (near the
bottom). The
> > > > former is so that Grub includes it in any new grub.cfg
that you
> > > > create.
> > > Good to know.
> > Edit:, never mind. Tried that, it still booted straight to the
UEFI BIOS
> > menu after entering my password. At this point, I'm seriously
> > considering slapping rEFInd on it and pray that it picks up on
> > everything automatically and fix the situation. But so should
Grub have,
> > besides the fact that I can't even be entirely sure Grub is to
blame and
> > not something else.
--
Joel Roth
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
You should really re-read the FAQ that was sent in just two days ago... On January 4, 2024 11:58:28 AM GMT+01:00, Jeffrey Walton wrote: >On Thu, Jan 4, 2024 at 2:45 AM Richard Rosner wrote: >> >> Wow, what a bunch of unhelpful comments. >> >> First, if it wasn't for Eddie recommending boot-repair, "broken beyond >> repair" in fact was the very fitting term. > >Here was Eddie's comment" I have had very good results using >"Boot-Repair" software to recover Grub difficulties." > >"Broken beyond repair" seems to be context dependent. And it seems to >depend on the user. > >> Second, have you maybe considered that I've already read the home page of >> rEFInd and came to the same conclusion? Besides the fact that the page is >> virtually unreadable - both from a visual and a content point of view - I >> have yet to find anything indicating what it is actually capable of and what >> not. Because as far as I can tell, it should be able to do what I want it to >> do. > >No. You did not state it. And you did not cite something you did not >understand. I think you are full of shit. > >> So please, if you don't have anything to add other than snarky remarks, just >> don't answer. > >You mean like: "So, since for whatever reason Grub seems to be broken >beyond repair"? > >Jeff >
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
Good to know that it should be possible. But as mentioned, these symbols only offer me to boot from grub or fwupd. F2 also doesn't show that much more, it merely gives me the option to boot into the BIOS settings. Maybe I'll have to completely purge all Grub packages, wipe the existing EFI partition and then try to install rEFInd. I'll have to check. On Thu, Jan 4, 2024, 09:29 Joel Roth wrote: > On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote: > > So, since for whatever reason Grub seems to be broken beyond repair, I > today > > tried to just replace it with rEFInd. Installation succeeded without any > > trouble. But when I start my system, rEFInd just asks me if I want to > boot > > with fwupd or with the still very broken Grub. Am I missing something? Is > > rEFInd really just something to select between different OSs (and not > just > > different distributions like Grub can very well do) and then gives the > rest > > over to their bootloaders or am I missing something so rEFInd will take > over > > all of Grubs jobs? > > I boot my debian-based system with rEFInd. Grub is not > present. A couple big icons show on the boot screen. The > small print at the bottom mentions hit F2 for more options. > On my system, F2 offers a selection among all kernels > present. > > rEFInd installs into EFI/refind/ in the EFI partition. > I originally encountered it looking for something to > boot debian on a Intel Mac. It's been trouble-free. > > > > > > On 01.01.24 21:45, Richard Rosner wrote: > > > > > > > > > On 01.01.24 21:20, Richard Rosner wrote: > > > > > > > > On 01.01.24 20:30, David Wright wrote: > > > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: > > > > > > On 01.01.24 18:13, David Wright wrote: > > > > > > I can boot by hand, but since this is all archived anyways and > it's > > > > > > uneccessarily difficult to find some sort of guide how to even do > > > > > > this, it might as well be a documentation for users having such > > > > > > troubles in the future. > > > > > > > > > > > > Also, besides the way that I have no clue how it would have to > look > > > > > > like to set up a paragraph in the grub.cfg, I simply don't see > > > > > > anything wrong with it anyways. So I can't even look at the grub > > > > > > settings files grub.cfg is being generated from to check where > the > > > > > > error lies. > > > > > You append the commands that you used to boot manually with into > > > > > /etc/grub.d/40_custom, observing the comments there, and also into > > > > > grub.cfg itself at the appropriate place (near the bottom). The > > > > > former is so that Grub includes it in any new grub.cfg that you > > > > > create. > > > > Good to know. > > > Edit:, never mind. Tried that, it still booted straight to the UEFI > BIOS > > > menu after entering my password. At this point, I'm seriously > > > considering slapping rEFInd on it and pray that it picks up on > > > everything automatically and fix the situation. But so should Grub > have, > > > besides the fact that I can't even be entirely sure Grub is to blame > and > > > not something else. > > -- > Joel Roth > >
Re: Possibly broken Grub or initrd after updates on Testing
I have kept the referral to the old problem in the topic for a reason. Been there, done that. I'm not entirely sure how, but boot-repair was the only thing that was able to fix Grub. Before that I've reinstalled it countless times, thanks. But since this is very much not an answer to the question at hand, but to the original question - and as such an entirely different topic - I'm rewriting this to the old topic too. On Thu, Jan 4, 2024, 02:12 Jeffrey Walton wrote: > On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner > wrote: > > > > So, since for whatever reason Grub seems to be broken beyond repair, > > I seriously doubt this is the case. I'm guessing the problem lies > elsewhere. > > > I today tried to just replace it with rEFInd. Installation succeeded > without any trouble. But when I start my system, rEFInd just asks me if I > want to boot with fwupd or with the still very broken Grub. Am I missing > something? Is rEFInd really just something to select between different OSs > (and not just different distributions like Grub can very well do) and then > gives the rest over to their bootloaders or am I missing something so > rEFInd will take over all of Grubs jobs? > > The rEFInd website is at <https://www.rodsbooks.com/refind/>. I'm > guessing you have not taken time to read about it based on your > questions. > > Jeff > >
Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
Wow, what a bunch of unhelpful comments. First, if it wasn't for Eddie recommending boot-repair, "broken beyond repair" in fact was the very fitting term. Second, have you maybe considered that I've already read the home page of rEFInd and came to the same conclusion? Besides the fact that the page is virtually unreadable - both from a visual and a content point of view - I have yet to find anything indicating what it is actually capable of and what not. Because as far as I can tell, it should be able to do what I want it to do. So please, if you don't have anything to add other than snarky remarks, just don't answer. On Thu, Jan 4, 2024, 02:12 Jeffrey Walton wrote: > On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner > wrote: > > > > So, since for whatever reason Grub seems to be broken beyond repair, > > I seriously doubt this is the case. I'm guessing the problem lies > elsewhere. > > > I today tried to just replace it with rEFInd. Installation succeeded > without any trouble. But when I start my system, rEFInd just asks me if I > want to boot with fwupd or with the still very broken Grub. Am I missing > something? Is rEFInd really just something to select between different OSs > (and not just different distributions like Grub can very well do) and then > gives the rest over to their bootloaders or am I missing something so > rEFInd will take over all of Grubs jobs? > > The rEFInd website is at <https://www.rodsbooks.com/refind/>. I'm > guessing you have not taken time to read about it based on your > questions. > > Jeff > >
Re: Possibly broken Grub or initrd after updates on Testing
Thanks, this actually did the job. I don't know what it was, but my guess is it was the step "purge Grub before reinstalling it". PS: rewrote to the old subject, as this is clearly an answer to the original problem, as it doesn't have anything to do with replacing Grub all together. On 03.01.24 21:04, Eddie wrote: I have had very good results using "Boot-Repair" software to recover Grub difficulties. Eddie On 1/3/24 14:23, Richard Rosner wrote: So, since for whatever reason Grub seems to be broken beyond repair, I today tried to just replace it with rEFInd. Installation succeeded without any trouble. But when I start my system, rEFInd just asks me if I want to boot with fwupd or with the still very broken Grub. Am I missing something? Is rEFInd really just something to select between different OSs (and not just different distributions like Grub can very well do) and then gives the rest over to their bootloaders or am I missing something so rEFInd will take over all of Grubs jobs?
Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]
So, since for whatever reason Grub seems to be broken beyond repair, I today tried to just replace it with rEFInd. Installation succeeded without any trouble. But when I start my system, rEFInd just asks me if I want to boot with fwupd or with the still very broken Grub. Am I missing something? Is rEFInd really just something to select between different OSs (and not just different distributions like Grub can very well do) and then gives the rest over to their bootloaders or am I missing something so rEFInd will take over all of Grubs jobs? On 01.01.24 21:45, Richard Rosner wrote: On 01.01.24 21:20, Richard Rosner wrote: On 01.01.24 20:30, David Wright wrote: On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: On 01.01.24 18:13, David Wright wrote: I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like to set up a paragraph in the grub.cfg, I simply don't see anything wrong with it anyways. So I can't even look at the grub settings files grub.cfg is being generated from to check where the error lies. You append the commands that you used to boot manually with into /etc/grub.d/40_custom, observing the comments there, and also into grub.cfg itself at the appropriate place (near the bottom). The former is so that Grub includes it in any new grub.cfg that you create. Good to know. Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS menu after entering my password. At this point, I'm seriously considering slapping rEFInd on it and pray that it picks up on everything automatically and fix the situation. But so should Grub have, besides the fact that I can't even be entirely sure Grub is to blame and not something else.
Re: Possibly broken Grub or initrd after updates on Testing
On 01.01.24 21:20, Richard Rosner wrote: On 01.01.24 20:30, David Wright wrote: On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: On 01.01.24 18:13, David Wright wrote: I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like to set up a paragraph in the grub.cfg, I simply don't see anything wrong with it anyways. So I can't even look at the grub settings files grub.cfg is being generated from to check where the error lies. You append the commands that you used to boot manually with into /etc/grub.d/40_custom, observing the comments there, and also into grub.cfg itself at the appropriate place (near the bottom). The former is so that Grub includes it in any new grub.cfg that you create. Good to know. Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS menu after entering my password. At this point, I'm seriously considering slapping rEFInd on it and pray that it picks up on everything automatically and fix the situation. But so should Grub have, besides the fact that I can't even be entirely sure Grub is to blame and not something else.
Re: Possibly broken Grub or initrd after updates on Testing
On 01.01.24 20:30, David Wright wrote: On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote: On 01.01.24 18:13, David Wright wrote: I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like to set up a paragraph in the grub.cfg, I simply don't see anything wrong with it anyways. So I can't even look at the grub settings files grub.cfg is being generated from to check where the error lies. You append the commands that you used to boot manually with into /etc/grub.d/40_custom, observing the comments there, and also into grub.cfg itself at the appropriate place (near the bottom). The former is so that Grub includes it in any new grub.cfg that you create. Good to know. This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4 The UUID of the first partition containing the EFI stuff is 3647-0C47, the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1 with ext4 as it seems - why does Debian still not default to creating LUKS2 by default anyways after 5 years?) and the swap partition has b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1). Because it could lock people out of their preexisting LUKS partitions. I meant when you use the automated installer and wipe the whole disk anyways. There wouldn't be any preexisting LUKS partitions left that could be broken. Or can there not be LUKS1 and LUKS2 at the same time in the event that e.g. the device with the system on is LUKS2 and another device just containing data was LUKS1? For me it looks like the grub.cfg has everything it needs to work. Why do your linux lines have two root= strings? No idea. I never really touched anything related to grub, besides the earlier mentioned tries to get some logs. Also, since it looks like there is no grub rescue mode installed (at least it's not being entered when it should) I did remove the comment in front of GRUB_DISABLE_RECOVER and set it to "false", just in case that for some reason it would default to true, thus not installing grub rescue. There's only one root in the /etc/default/grub.
Re: Possibly broken Grub or initrd after updates on Testing
I can boot by hand, but since this is all archived anyways and it's uneccessarily difficult to find some sort of guide how to even do this, it might as well be a documentation for users having such troubles in the future. Also, besides the way that I have no clue how it would have to look like to set up a paragraph in the grub.cfg, I simply don't see anything wrong with it anyways. So I can't even look at the grub settings files grub.cfg is being generated from to check where the error lies. This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4 The UUID of the first partition containing the EFI stuff is 3647-0C47, the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1 with ext4 as it seems - why does Debian still not default to creating LUKS2 by default anyways after 5 years?) and the swap partition has b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1). For me it looks like the grub.cfg has everything it needs to work. On 01.01.24 18:13, David Wright wrote: On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote: On January 1, 2024 5:43:12 PM GMT+01:00, David Wright wrote: Like this? └─sda6 8:60 406.2G 0 part └─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G 0 crypt /home That's groups of 8 4 4 4 12. Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid aren't available there? I thought you could boot by hand. Then all the UUIDs are available to you in lsblk, the /dev/disk/ symlinks, etc. I would then transcribe them into a 40_custom paragraph in grub.cfg so you can boot easily. Then I would work on getting Grub to write its grub.cfg correctly. In the meantime, 40_custom would stay put. Cheers, David.
Re: Possibly broken Grub or initrd after updates on Testing
Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid aren't available there? On January 1, 2024 5:43:12 PM GMT+01:00, David Wright wrote: >Like this? > > └─sda6 8:60 406.2G 0 part >└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G 0 crypt > /home > >That's groups of 8 4 4 4 12. > >Cheers, >David. >
Re: Possibly broken Grub or initrd after updates on Testing
So, I found a way to manually mount luks partition in Grub and boot from it. What I did to get there: set root=(hd0,gpt2) cryptomount -a This gave me the unencrypted version of the root partition as (crypto1) set root=(crypto1) linux /vmlinuz root=/dev/mapper/luks-UUID initrd /initrd.img boot The problem only is to get the UUID format right. When you're asked to enter the decryption key in a normal boot, it's shown, but without any dashes. But the format must be the same eg Disks shows it. But sure if a Grub tool can show that, but worst case you'll be booted into a initrd BusyBox terminal where you can just look inside /dev/mapper and see the true path that needs to be entered. Question is, how do I repair the boot process so I don't have to boot by hand every time? On January 1, 2024 12:52:40 PM GMT+01:00, Richard Rosner wrote: >I do not see an answer to my questions.
Re: Possibly broken Grub or initrd after updates on Testing
I do not see an answer to my questions. > On Jan 1, 2024, at 11:52, Michael Kjörling <2695bd53d...@ewoof.net> wrote: > > On 1 Jan 2024 11:46 +0100, from rich...@rosner-online.de (Richard Rosner): >> I'm not sure what you meant with "rescue mode", but I've reinstalled >> grub anyways. The log of it doesn't look good though. Quite a bunch >> of errors. The result also is the same. > > Please review the posts in the thread starting on Dec 21 2023 14:25:26 > UTC, > https://lists.debian.org/msgid-search/254ebb90-9a49-4b5a-b1d6-e41b51d8a...@columbus.rr.com > > -- > Michael Kjörling https://michael.kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” >
Re: Possibly broken Grub or initrd after updates on Testing
I'm not sure what you meant with "rescue mode", but I've reinstalled grub anyways. The log of it doesn't look good though. Quite a bunch of errors. The result also is the same. https://pastes.io/nvmlsxghlm > On Jan 1, 2024, at 11:03, Michael Kjörling <2695bd53d...@ewoof.net> wrote: > > On 1 Jan 2024 09:16 +0100, from rich...@rosner-online.de (Richard Rosner): >> could you please check if you received either of my two tries to get >> this answer through the mailing list? > > I did not. Maybe they are held for moderation due to size? > > Next time, you can check for yourself at either > https://lists.debian.org/debian-user/recent or at > https://lists.debian.org/debian-user/ under the "archives" heading. > There's also a search there. If a message is not in the archive after > one or two archive refreshes, it probably didn't make it through the > list for whatever reason there may be. > > -- > Michael Kjörling https://michael.kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” >
Re: Possibly broken Grub or initrd after updates on Testing
As far as I can tell, /boot and /boot/grub are the same filesystem. After all, I didn't really do anything custom. Just your default LUKS installation with the boot efi stuff on sda1/sdb1/whatever, LUKS on 2 and LUKS encrypted swap on 3. I did make a video. Nothing that's not showing up always. For a fraction of a second it shows something about slot 0 open, that's it. > On Dec 29, 2023, at 20:37, Richard Rosner wrote: > > As far as I can tell, /boot and /boot/grub are the same filesystem. After > all, I didn't really do anything custom. Just your default LUKS installation > with the boot efi stuff on sda1/sdb1/whatever, LUKS on 2 and LUKS encrypted > swap on 3. > > I did make a video. Nothing that's not showing up always. For a fraction of a > second it shows something about slot 0 open, that's it. > >> On Dec 29, 2023, at 20:13, Michael Kjörling <2695bd53d...@ewoof.net> wrote: >> >> On 29 Dec 2023 18:56 +0100, from rich...@rosner-online.de (Richard Rosner): >>> Hey, I have quite the strange issue. After updating a bunch of >>> packages today [1], mostly related to systemd, gstreamer and udev, >>> and restarting my device, it no longer boots. I have an encrypted >>> system. So I do get asked for my decryption password as usual, but a >>> few seconds later, instead of continuing to the Grub boot menu, my >>> device simply reboots to the BIOS menu. >> >> Sounds to me very much like GRUB is having trouble finding or reading >> critical files under /boot/grub, and gives up for that reason. But it >> _should_ stop, not reboot, if that's the case. >> >>> From what you describe, it sounds like you use a LUKS-encrypted /boot. >> Is that correct? Also, please confirm that the contents of /boot/grub >> are located on the same file system as the contents of /boot (that is, >> that /boot/grub is not on its own file system). >> >> You probably already know this, but the GRUB LUKS passphrase prompt is >> very early stage. >> >> Have you tried making a video recording of the screen from when you >> press Enter at the passphrase prompt, to when it reboots, and then go >> through that carefully (frame by frame)? Maybe GRUB _does_ print >> something indicating what the actual problem is, but it reboots so >> quickly after that that you don't have time to see it. A video might >> capture that fraction-of-a-second display (even if only partially) and >> help point you in the right direction. >> >> -- >> Michael Kjörling https://michael.kjorling.se >> “Remember when, on the Internet, nobody cared that you were a dog?” >>
Possibly broken Grub or initrd after updates on Testing
Hey, I have quite the strange issue. After updating a bunch of packages today [1], mostly related to systemd, gstreamer and udev, and restarting my device, it no longer boots. I have an encrypted system. So I do get asked for my decryption password as usual, but a few seconds later, instead of continuing to the Grub boot menu, my device simply reboots to the BIOS menu. It's not the first time I ran into such an issue. I did once after manually updating initrd because Grub wouldn't offer to boot the 6.5.0-4 kernel because of malformed grub.cfg. The solution was kinda simple. Boot into a life system, mount the encrypted system according to [2], find out the guide was either outdated or not suitable for updating initrd, find a fix, recreate initrd again and done. Sadly, this time that solution won't help. Also I can't find any way to get a log of which troubles Grub runs into that it can't continue the boot process. I tried getting Grub to write logs to the system by modifying GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub by removing quite and splash and adding loglevel=7 (and update-grub), but nothing is written, probably because for some reason Grub can't really decrypt the system. So, how do I even find out what's wrong? I'm not familiar with the Grub cmd, I have no idea how to get it to tell me what's wrong to even start finding a solution. Anybody knows more? [1]: Start-Date: 2023-12-28 19:40:04 Upgrade: udev:amd64 (254.5-1, 255.2-2), acl:amd64 (2.3.1-3+b1, 2.3.1-4), wpasupplicant:amd64 (2:2.10-20, 2:2.10-21), libacl1:amd64 (2.1.1-3-61, 2.3.1-4), libarmadillo12:amd64 (1:12.6.4+dfsg-1, 1:12.6.7±dfsg-1), libpam-systemd:amd64 (254.5-1, 255.2-2), libp11-kit0:amd64 (0.25.3-2, 0.25.3-4), libp11-kit0:i386 (0.25.3-2.6.25.3-4), libsonic0:amd64 (0.2.0-12, 0.2.0-13), libinput10:amd64 (1.23.0-2, 1.23.0-2.1), libsystemd0:amd64 (254.5-1, 255.2-2), libsystend0:i386 (254.5-1. 255.2-2), pandoc-data:amd64 (3.0.1-3, 3.0.1-4), libudev-dev:amd64 (254.5-1, 255.2-2), systemd:amd64 (254.5-1, 255.2-2), libudev1:amd64 (254.5-1, 255.2-2), libudev1:i386 (254.5-1, 255-2-2), p11-kit-modules:amd64 (0.25.3-2, 0.25.3-4), python3-wxgtk4.0:amd64 (4.2.1+dfsg-2, 4.2.1-dfsg-3), gstreamer1.0-gtk3:amd64 (1.22.7-1, 1.22.8-3), gstreamer1.0-plugins-good:amd64 (1.22,7-1, 1-22-83-3), gstreamer1.0-plugins-good:i386 (1.22.7-1, 1.22.8-3), libcap-ng0:amd64 (0.8.3-3, 0.8.4-1), mdamd:amd64 (4.2+20231026-1, 4.2+20231121-1), libinput-tools:amd64 (1.23.0-2, 1.23.0-2.1), libsystemd-shared:amd64 (254.5-1, 255.2-2), libattr1:amd64 (1:2.5.1-4+b1, 1:2.5.1-5), cpio:amd64 (2.13+dfsg-7.1, 2.14+dfsg-1), gstreamer1.0-pulseaudio:amd64 (1:22.7-1, 1.22.8-3), libsystemd-dev:amd64 (254.5-1, 255.2-2), p11-kit:amd64 (0.25.3-2, 0.25.3-4), libinput-bin:amd64 (1.23.0-2, 1.23.0-2.1) End-Date: 2023-12-28 19:45:40 [2]: https://wiki.debian.org/GrubEFIReinstall
