You are not logged in.
Pages: 1
I have a dell inspiron 5567 running ubuntu originally. I'm trying to boot using the efistub method, as described on the wiki. When I boot the arch linux entry, I get a kernel panic with
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)My efi partition is mounted at /boot, contents of /boot and efibooymgr output is
root@newdell:/boot/efi# ls
EFI en-us initramfs-linux-fallback.img initramfs-linux.img intel-ucode.img myarch.nsh shellx64_v2.efi vmlinuz-linux
root@newdell:/boot/efi# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0009,0001,000A,0008,0000
Boot0000* ubuntu HD(1,GPT,da3d0f82-f0f6-4f49-808d-73b6dd7565c4,0x800,0xfa000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* arch HD(1,GPT,da3d0f82-f0f6-4f49-808d-73b6dd7565c4,0x800,0xfa000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.a.4. .r.w. .i.n.i.t.r.d.=.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
Boot0003* USB Storage Device BBS(USB,USB Storage Device,0x0)..BO
Boot0004* CD/DVD/CD-RW Drive BBS(CDROM,P1: PLDS DVD+/-RW DU-8A5LH ,0x0)..BO
Boot0005* Onboard NIC BBS(Network,Realtek PXE B03 D00,0x0)..BO
Boot0006* UEFI: SanDisk X400 2.5 7MM 256GB, Partition 1 HD(1,GPT,da3d0f82-f0f6-4f49-808d-73b6dd7565c4,0x800,0xfa000)/File(EFI\boot\bootx64.efi)..BO
Boot0008* shell2 PciRoot(0x0)/Pci(0x17,0x0)/Sata(0,65535,0)/HD(1,GPT,da3d0f82-f0f6-4f49-808d-73b6dd7565c4,0x800,0xfa000)/File(\shellx64_v2.efi)
Boot0009* \arch HD(1,GPT,da3d0f82-f0f6-4f49-808d-73b6dd7565c4,0x800,0xfa000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.a.4. .r.w. .i.n.i.t.r.d.=.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
Boot000A* /arch HD(1,GPT,da3d0f82-f0f6-4f49-808d-73b6dd7565c4,0x800,0xfa000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.a.4. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.(the directory is /boot/efi and not /boot, because I'm writing from the ubuntu install, witch mounts the esp there)
I experimented with / \ in the initrd neither worked, and installed efi shell from the aur. I also wrote myarch.nsh
\vmlinuz-linux root=/dev/sda4 rw initrd=intel-ucode.img initrd=initramfs-linux.imgwhich boots arch without isues.
I found this topic, which is very similar. It seems the dell uefi has problems with passing parameters. The ubuntu installation it originaly came with uses shim, whitout any parameters.
Can there be some switch in the system settings to enable passing parameters? (I looked but cant find anything) Did anyone have similar problems?
Offline
I usually boot using EFISTUB capability of the Arch kernel. I notice something odd shown by your efibootmgr verbose status. I think all the periods that appear to be delimiters are the problem. What is the command you are using to create the boot entry in UEFI. Here is mine.
#efibootmgr -d /dev/sda -p 1 -c -L "ArchLinux" -l \vmlinuz-linux -u "root=/dev/sda3 rw initrd=/initramfs-linux.img"Is it possible that you don't have quotes around your kernel parameters?
Simple and Open
Offline
Well forget my previous post. At the moment I didn't have this lappy I'm using booting via EFISTUB. I added a boot option for that using the command I included above. It works fine, no kernel panic, but does show the periods like yours does above via the efibootmgr -v. I would still like to see your efibootmgr command used to create you entries if possible. I'll look into this further.
Simple and Open
Offline
The place back slashes may be needed are on the paths that exist on the ESP, since it is FAT32 and that is all that UEFI can see. I think efibootmgr had an update that made it not matter which slash was used though.
I am now noticing your note about the mount point. Did you move the kernel to /boot? Using a /boot mount point puts the kernel on the ESP where UEFI can launch it. Using a /boot/efi mount point puts the kernel on the root partition where UEFI can't launch it. Unless you copy the kernel to the /boot/efi location. When using /boot/efi as the mount point for the ESP, the /boot directory is on the root partition. The kernel gets installed and upgraded to /boot.
When efibootmgr -v shows me the loader on my boot entry it has no leading slash as yours does even though you can see there is a slash in that parameter of the command I used to create the entry.
Simple and Open
Offline
The code output I copied was from ubuntu (where the eps is mounted at /boot/efei), arch mounts the esp to /boot, so I dont have to copy the kernel (the myarch.nsh script works, so the paths are good).
When arch is launched with EFISTUB vmlinuz-linux get executed, so the path for it must be right.
I read that the slash shouldn't matter too, just wanted to be sure that that's not the problem.
The efibootmgr command was pretty much the same, only with root=/dev/sda4.
I'm now booting arch with systemd-boot, it works perfectly, but I still would like to get to the bottom of the efistub issue.
Offline
Since you're using bootctl now, please post the results of this command. It may help by showing more about the boot entries.
# bootctl statusLast edited by Blasphemist (2017-07-17 22:21:34)
Simple and Open
Offline
The bootctl status outout is
Using EFI System Partition at /boot.
System:
Firmware: UEFI 2.40 (American Megatrends 5.11)
Secure Boot: disabled
Setup Mode: user
Loader:
Product: systemd-boot 233
Partition: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-/EFI/systemd/systemd-bootx64.efi
Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-/EFI/systemd/systemd-bootx64.efi (systemd-boot 233)
File: `-/EFI/BOOT/BOOTX64.EFI (systemd-boot 233)
Boot Loader Entries in EFI Variables:
Title: Linux Boot Manager
ID: 0x0002
Status: active, boot-order
Partition: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-/EFI/systemd/systemd-bootx64.efi
Title: ubuntu
ID: 0x0000
Status: active, boot-order
Partition: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-/EFI/ubuntu/shimx64.efi
Title: shell2
ID: 0x0008
Status: active, boot-order
Partition: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-/shellx64_v2.efi
Title: arch
ID: 0x0001
Status: active
Partition: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-/vmlinuz-linux
Title: UEFI: SanDisk X400 2.5 7MM 256GB, Partition 1
ID: 0x0006
Status: active
Partition: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-EFI/boot/bootx64.efi
Title: \arch
ID: 0x0009
Status: active
Partition: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-/vmlinuz-linux
Title: /arch
ID: 0x000A
Status: active
Partition: /dev/disk/by-partuuid/da3d0f82-f0f6-4f49-808d-73b6dd7565c4
File: `-/vmlinuz-linuxI have no experience with bootctl, should it output the parameters for the *arch entries?
Last edited by matyilona200 (2017-07-18 09:32:32)
Offline
I took some time to do some testing of efibootmgr options today to try and get more to the bottom of this. I was able to cause the kernel panic. Same message as you have. The way I can cause it is to remove the -u option before the kernel parameters. This option changes the kernel parameters from ASCII to UCS-2 as I understand it.
I kept trying a new efibootmgr command, testing boot, looking at the verbose (-v) output of efibootmgr and using anything else I thought relevant for that change, deleting the entry from UEFI with efibootmgr, making another change to my efibootmgr command to create an entry and testing all over. If booting did the kernel panic, I just booted using my UEFI built in boot manager and choosing my bootctl boot option to do another test.
Here is the efibootmgr command I last used.
# efibootmgr -c -d /dev/sda -p 1 -L "ArchLinux" -l \vmlinuz-linux -u "root=PARTUUID=77c504b8-28ac-4fae-aab9-551d9dc9588f rw initrd=\initramfs-linux.img"Just for the sake of completeness for readers of this I'll comment on this command. The -c option tells efibootmgr to create a new entry, if you use -b it will edit an existing entry. The -d option specifies the drive containing the $ESP and the -p option is the partition number of the $ESP, 1 in my case. The -L option shows me naming my entry ArchLinux. The -l option specifies the path and file name of the kernel that I want to launch. This would be the path and filename of a boot loader or boot manager if that was desired but I'm just launching the EFISTUB arch kernel directly.
My mount point for the $ESP is /boot and that puts my kernel files on the $ESP. At the root of that partition is the best way I know to say it. So the paths to my kernel files reflect that. I found that it didn't matter if I used back slashes on the paths to my kernel files, or front slashes. UEFI is locating and launching the kernel on a FAT32 $ESP so you'd think I might have to use back slashes but it doesn't seem to matter. I started off with the root= part of my kernel parameters shown as /dev/sda1 but then switched to using PARTUUID but as far as I can tell that didn't change anything.
I used bootctl status to get a different look at the results of all this as I tested. I used this command to show my PARTUUID. Remember that PARTUUID is different than UUID that you can see using lsblk.
# ls -l /dev/disk/by-partuuid/After you've booted you can use this to see the kernel parameters that the kernel used at boot. I was using this to compare kernel parameters used from my manually created boot option to one created during the installation of bootctl.
$ cat /proc/cmdlineIn the end I'm not telling you much you didn't know. I think your problem is in passing kernel parameters, but I don't see the cause. If it was me I'd delete all of the EFISTUB entries you've created and create a new one. If it doesn't work, delete it and try changing one thing. I for one am curious what the issue will be. I think that there have been issues with certain vendor flavors of UEFI that make passing kernel parameters problematic but I don't know the details. Maybe you'll find yours will work if you use PARTUUID. I hope so.
Simple and Open
Offline
Pages: 1