grub2 2.04-1ubuntu12.2 breaks boot on some machines

[Joseph Yasi]

2.04-1ubuntu12.2 broke boot on my machine. It doesn't work with kernels that don't have CONFIG_EFI_STUB=y configured. This really needs to fall back to the old mode if EFI handover is not supported by the kernel.

Also, after using a kernel with CONFIG_EFI_STUB=y it still failed to boot one of my machines with root specified by UUID. I was able to workaround it by manually specifying the boot device with /dev/nvme0n1p2 at the grub menu, and then specifying GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: xorg 1:7.7+19ubuntu12
Uname: Linux 5.5.10-customskl x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp
ApportVersion: 2.20.11-0ubuntu8.6
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
CurrentDesktop: KDE
Date: Fri Mar 20 21:19:01 2020
DistUpgraded: 2019-10-26 18:15:16,011 DEBUG running apport_crash()
DistroCodename: eoan
DistroVariant: ubuntu
DkmsStatus:
 zfs, 0.8.3, 5.5.10-customskl, x86_64: installed
 zfs, 0.8.3, 5.5.9-customskl, x86_64: installed
GraphicsCard:
 Intel Corporation UHD Graphics 630 (Desktop) [8086:3e92] (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. UHD Graphics 630 (Desktop) [1043:872f]
InstallationDate: Installed on 2012-12-04 (2664 days ago)
InstallationMedia: Kubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.1)
MachineType: System manufacturer System Product Name
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.5.10-customskl root=/dev/nvme0n1p2 ro rootflags=subvol=@ drm_kms_helper.edid_firmware=DP-1:edid/monoprice_28_4k.edid
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to eoan on 2019-10-26 (146 days ago)
dmi.bios.date: 10/07/2019
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2203
dmi.board.asset.tag: Default string
dmi.board.name: ROG MAXIMUS X HERO (WI-FI AC)
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2203:bd10/07/2019:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGMAXIMUSXHERO(WI-FIAC):rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.sku: SKU
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.100-4~yasi1~19.10
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.2-1ubuntu1~yasi1~19.10
version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.2-1ubuntu1~yasi1~19.10
version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20191209.2226.f66d3954-0ubuntu0+yasi1~19.10
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

[Joseph Yasi (joe-yasi)]

I filed this against grub2 originally. Somehow ubuntu-bug changed that to xorg. I added grub2 back. It's not letting me remove xorg.

[Joseph Yasi (joe-yasi)]

Now it did. The page does not work well on mobile.

[Joseph Yasi (joe-yasi)]

I get "error: kernel doesn't support EFI handover" when trying to boot a kernel without EFISTUB. The patches for EFISTUB boot added with 2.04-1ubuntu12.2 mention fallback for kernels that don't have EFISTUB. That didn't work for my kernels. Was it tested?

[Joseph Yasi (joe-yasi)]

After enabling CONFIG_EFI_STUB=y both of my machines will not boot from filesystem UUID. The rootfs on both machines is a btrfs subvolume on an nvme partition. On boot, the kernel panics that it can't find the rootfs:
kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)

If I either specify by device path (/dev/nvme0n1p2 and /dev/nvme0n1p3 for the two machines) or by PARTUUID, it can find it and boot. I haven't investigated why the kernel can't find the filesystems by fs UUID, but they are not available after the EFI handover.

To workaround it, I have set these options in /etc/default/grub:
GRUB_DISABLE_LINUX_UUID=true
GRUB_DISABLE_LINUX_PARTUUID=false

This forces grub to pass the PARTUUID instead of the fs UUID.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.