Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Two questions about EFIstub booting
Two questions about EFIstub booting
1) I followed https://wiki.debian.org/EFIStub but while the kernel is loaded I get an error message about it not being able to locate the initramd even though it is placed in the same directory as the vmlinuz on the esp. Also, the entry is pointing to the correct location (verified with -v). EDIT: ok got it running by using UCS so that I can boot into busybox, but it still complains that root is not ready when booting. The UUID is correct, so I guess it might be that the rootfs is too slow.
2) on an Intel machine would one need to pass the location of the microcode to the machine also? Is this done, as I think it was suggested in the arch wiki, by inserting two distinct initram image addresses with efibootmgr?
2) on an Intel machine would one need to pass the location of the microcode to the machine also? Is this done, as I think it was suggested in the arch wiki, by inserting two distinct initram image addresses with efibootmgr?
Last edited by pylkko on 2017-03-03 12:51, edited 1 time in total.
Re: Two questions about EFIstub booting
After some tweaking around with different options and partitions and file system types, I think what is happening is that the device is some how not ready early enough. This is odd because dmesg in busybox after a failed boot shows sda as recognized. Yet, "cannot mount /dev/sda3 no such device"...
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 133 times
Re: Two questions about EFIstub booting
Hey pylkko, can we please see the exact efibootmgr(8) command that you used to generate the NVRAM entry?
The full content of your motherboard's NVRAM entries may also be useful:
Personally, I remove that package from my Debian systems (to keep `vrms` happy and my sources clean) and instead unpack the custom initramfs image supplied by Arch in their intel-ucode package and add that to the EFI system partition and bootloader configuration, as per the ArchWiki.
The full content of your motherboard's NVRAM entries may also be useful:
Code: Select all
# efibootmgr -v
For Debian the Intel microcode is handled by the separate intel-microcode package and I think this uses /etc/kernel/preinstall.d/intel-micocode to add the firmware but I'm not sure exactly.on an Intel machine would one need to pass the location of the microcode to the machine also?
Personally, I remove that package from my Debian systems (to keep `vrms` happy and my sources clean) and instead unpack the custom initramfs image supplied by Arch in their intel-ucode package and add that to the EFI system partition and bootloader configuration, as per the ArchWiki.
deadbang
Re: Two questions about EFIstub booting
Yes. I used this commandwhere I exported the UUID, and I have looked it up in blkid and it matches.
And efibootmgr -v reportsSo, in other words I copied the initrd and the kernel (from the symlinks) to the EFI partition from the root.
this is a purely experimental setup, I have another partition on that machine that has a grub booted btrfs Debian, but this is an old sid install that is actually a stretch now, since I "downgraded" it after I did not have time to update it all the time and it got out of date. I wasn't sure if efibootmgr would be able to handle a btrfs root, so I decided to experiment with this other. When boot fails on this entry i can do /bin/reboot in busybox and go back to EFI and then press esc and boot the entry that works.
This is per the Debian Wiki. However, I am left wondering why it uses the device UUID and not the PARTUUID?
actually, yes maybe I should give the -p flag in the command since
Also, tried to not use UUID and just manually give /dev/sda3 but this causes the kernel to panic.
Code: Select all
efibootmgr -c -g -L "Sid (EFI stub)" -l '\EFI\sid\vmlinuz' -u "root=UUID=$UUID ro quiet rootfstype=ext4 add_efi_memmap initrd=\\EFI\\sid\\initrd.img"
Code: Select all
export UUID=$(blkid -s UUID -o value /dev/sda3)
Code: Select all
Boot0003* Sid (EFI stub) HD(1,GPT,5653128f-deb1-4770-a8ca-c06068f2331a,0x800,0x82000)/File(\EFI\SID\VMLINUZ)r.o.o.t.=.U.U.I.D.=.2.0.a.d.1.f.1.9.-.9.8.f.e.-.4.7.f.b.-.a.4.2.0.-.d.a.7.4.2.d.f.8.e.1.5.4. .r.o. .q.u.i.e.t. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4.s. .a.d.d._.e.f.i._.m.e.m.m.a.p. .i.n.i.t.r.d.=.\.E.F.I.\.s.i.d.\.i.n.i.t.r.d...i.m.g.
this is a purely experimental setup, I have another partition on that machine that has a grub booted btrfs Debian, but this is an old sid install that is actually a stretch now, since I "downgraded" it after I did not have time to update it all the time and it got out of date. I wasn't sure if efibootmgr would be able to handle a btrfs root, so I decided to experiment with this other. When boot fails on this entry i can do /bin/reboot in busybox and go back to EFI and then press esc and boot the entry that works.
This is per the Debian Wiki. However, I am left wondering why it uses the device UUID and not the PARTUUID?
actually, yes maybe I should give the -p flag in the command since
EDIT2: no, that is definetly not it, since that is for pointing to the efiman page of efibootmgr wrote:-p | --part PART
Partition number containing the bootloader (defaults to 1)
Also, tried to not use UUID and just manually give /dev/sda3 but this causes the kernel to panic.
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 133 times
Re: Two questions about EFIstub booting
Is that a typo?pylkko wrote:And efibootmgr -v reportsCode: Select all
.r.o.o.t.f.s.t.y.p.e.=.e.x.t.4.s.
I don't think there should be an "s" at the end of "ext4"; also, I have never specified my filesystem when EFISTUB booting so I don't think you need that parameter at all.
deadbang
Re: Two questions about EFIstub booting
Head_on_a_Stick wrote:Is that a typo?pylkko wrote:And efibootmgr -v reportsCode: Select all
.r.o.o.t.f.s.t.y.p.e.=.e.x.t.4.s.
I don't think there should be an "s" at the end of "ext4"; also, I have never specified my filesystem when EFISTUB booting so I don't think you need that parameter at all.
Good catch, apparently so! But it is, unfortunately, probably not the root of the issue as I have tried many many entries.
Re: Two questions about EFIstub booting
No. It was the issue. Or at least some part of it. Now it boots into emergency mode. And says "failed to load kernel modules". and it also complains that it cannot mount /boot/EFI. But I don't even need it to mount that...
I piped journalctl -xb into a file and will start analyzing that now. But I am really thinking is this worth the pain, grub works so well and causes essentially no "overhead".
I piped journalctl -xb into a file and will start analyzing that now. But I am really thinking is this worth the pain, grub works so well and causes essentially no "overhead".
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 133 times
Re: Two questions about EFIstub booting
Are you sure that the kernel image on the ESP is the current, running kernel for your sid system?pylkko wrote:it boots into emergency mode. And says "failed to load kernel modules". and it also complains that it cannot mount /boot/EFI.
Check that the root-level symlinks are correct:
Code: Select all
ls -l /
deadbang
Re: Two questions about EFIstub booting
I noticed that apt is complaining that the kernel symlink is broken. I'll have to redo it all
Re: Two questions about EFIstub booting
Reading the journalctl output and seeing that it could not find /etc/* I redid the install. That is hand copied (no symlink) the initrd and vmliuz to the ESP. Made sure that the same kernel version is installed on the root, redid the efibootmgr entry with either rootfs=ext4 or not and it does not seem to be able to get beyond busybox/intiramfs complaining that /dev cannot be mounted on /root/dev because it cannot be found. According to dmesg, it does, however, apparently find the disk and the correct partition and even filesystem type.
Re: Two questions about EFIstub booting
So, I had a chance to look at this again, and unfortunately the problem is probably not something that normal users are going to be able to resolve.
It says
"Blocked a compatibility format interrupt request"
DMAR
It also says Fault index 50a0 fault reason 37
and then it fails at creating /dev
It says
"Blocked a compatibility format interrupt request"
DMAR
It also says Fault index 50a0 fault reason 37
and then it fails at creating /dev
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 133 times
Re: Two questions about EFIstub booting
I am finding it difficult to follow exactly what you have been trying, the exact commands and output would help me greatly.
I have just tried this command in my stretch-based system:
My box is now booted from that NVRAM entry:
I use this script at /etc/kernel/postinstall.d/zz-update-esp to keep the kernel & initrd updated:
https://gist.github.com/Head-on-a-Stick ... 8e55ce5352
With this partition structure:
https://gist.github.com/Head-on-a-Stick ... 9c681d54fa
Is your configuration method comparable to my working set up?
I have just tried this command in my stretch-based system:
Code: Select all
# efibootmgr -d /dev/sda -p 1 -c -L "pylkko" -l /Helium/vmlinuz -o "root=UUID=347fcad5-6e39-4c73-ab69-710b4077051f rw rootflags=subvol=Helium quiet zswap.enabled=1 snd_hda_intel.index=1 apparmor=1 security=apparmor panic=0 scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y initrd=/intel-ucode.img initrd=/Helium/initrd.img"
Code: Select all
root@Helium:~ # efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002
Boot0001* pylkko HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\Helium\vmlinuz)r.o.o.t.=.U.U.I.D.=.3.4.7.f.c.a.d.5.-.6.e.3.9.-.4.c.7.3.-.a.b.6.9.-.7.1.0.b.4.0.7.7.0.5.1.f. .r.w. .r.o.o.t.f.l.a.g.s.=.s.u.b.v.o.l.=.H.e.l.i.u.m. .q.u.i.e.t. .z.s.w.a.p...e.n.a.b.l.e.d.=.1. .s.n.d._.h.d.a._.i.n.t.e.l...i.n.d.e.x.=.1. .a.p.p.a.r.m.o.r.=.1. .s.e.c.u.r.i.t.y.=.a.p.p.a.r.m.o.r. .p.a.n.i.c.=.0. .s.c.s.i._.m.o.d...u.s.e._.b.l.k._.m.q.=.y. .d.m._.m.o.d...u.s.e._.b.l.k._.m.q.=.y. .i.n.i.t.r.d.=./.i.n.t.e.l.-.u.c.o.d.e...i.m.g. .i.n.i.t.r.d.=./.H.e.l.i.u.m./.i.n.i.t.r.d...i.m.g.
Boot0002* UEFI OS HD(1,GPT,876168c2-2afb-4f50-ba94-cc7732d47b98,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)
https://gist.github.com/Head-on-a-Stick ... 8e55ce5352
With this partition structure:
https://gist.github.com/Head-on-a-Stick ... 9c681d54fa
Is your configuration method comparable to my working set up?
deadbang
Re: Two questions about EFIstub booting
I used the commands that are given in the Debian wiki. I now realize that there the kernel commandline is somewhat simplistic in that example and I just copied the one from the grub entry and it worked, although without the microcode there are small things (appears to be power savings issues for example). Preliminary results seem to indicate that boot time did not decrease, but actually increased...