** Description changed: + ### SRU TMPL DRAFT ### + + [Impact] + + One can't deploy using root XFS partition using 18.04 on UEFI platform. + + [Test case] + + * Deploy a Bionic machine with a storage layout as follows: + + vda-part1 536.9 MB fat32 /boot/efi + vgroot-lvroot 31.7 GB xfs / ## Only xfs is important here. + + The Bionic/18.04LTS deployments will fail to boot and will be redirected to grub prompt: + grub> + + [Where could problem occurs] + + I checked the delta between the 2 grub (Bionic and Focal) versions after + the add of 'xfs' module to see if any fixes/CVE/... that we should pick + up, and I found nothing. + + Ryan, cyphermox and I were concerned that it is adding to the set of + modules included in the secureboot-signed binary. I confirmed with + vorlon and everything seemed okay on his end. + + [Other information] + + * Debian: + debian/changelog: + * Add xfs module to signed UEFI images (closes: #911147, LP: #1652822). + + * Salsa commit: + https://salsa.debian.org/grub-team/grub/-/commit/01f1eee93acd4113475b403f80661cf651fbcc00 + + * The workaround is to create a /boot partition, with ext4, so you have: + + # Example + vda-part1 ext4 /boot + vda-part2 fat32 /boot/efi + vgroot-lvroot xfs / + + + [Original Description] + If I do a fresh install on an efi system and use xfs for the root and boot filesystems, the install will succeed and then on reboot grub will drop to a grub shell and fail to boot. If I try to do an ls on any of the xfs filesystems, grub reports unsupported filesystem. Doing an insmod on xfs.mod doesn't work on the xfs filesystem since it can't be read /boot/efi is a fat32 esp partition and can be read by grub. I can make the system boot by putting a copy of /boot/grub/x86_64-efi/xfs.mod in /boot/efi/EFI/ubuntu/xfs.mod and then putting the following line in /boot/efi/EFI/ubuntu/grub.cfg insmod (hd0,gpt1)/EFI/ubuntu/xfs.mod I'm guessing this would work if boot was ext2. My current HDD setup is: fdisk -l /dev/sda Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5F358931-DDAE-4F78-8647-B54434A5A3DC Device Start End Sectors Size Type /dev/sda1 2048 2000895 1998848 976M EFI System /dev/sda2 2000896 4001791 2000896 977M Linux filesystem /dev/sda3 4001792 804902911 800901120 381.9G Linux LVM - My current fstab is: /dev/mapper/vgroot-lvroot / xfs defaults 0 0 # /boot was on /dev/sda2 during installation UUID=006c4d31-8c29-4e25-b8c2-5f70f5f19afd /boot xfs defaults 0 0 # /boot/efi was on /dev/sda1 during installation UUID=DFD4-FB95 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgroot-lvhome /home xfs defaults 0 0 /dev/mapper/vgroot-lvswap none swap sw 0 0 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: grub-efi-amd64 2.02~beta2-36ubuntu3.2 ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35 Uname: Linux 4.4.0-57-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.4 Architecture: amd64 CurrentDesktop: MATE Date: Tue Dec 27 12:42:40 2016 InstallationDate: Installed on 2016-12-27 (0 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: grub2 UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed: ### SRU TMPL DRAFT ### [Impact] One can't deploy using root XFS partition using 18.04 on UEFI platform. [Test case] * Deploy a Bionic machine with a storage layout as follows: vda-part1 536.9 MB fat32 /boot/efi vgroot-lvroot 31.7 GB xfs / ## Only xfs is important here. The Bionic/18.04LTS deployments will fail to boot and will be redirected to grub prompt: grub> [Where could problem occurs] I checked the delta between the 2 grub (Bionic and Focal) versions after - the add of 'xfs' module to see if any fixes/CVE/... that we should pick - up, and I found nothing. + the add of 'xfs' module to see if thre is any fixes/CVE/... that we + should pick up, and I found nothing. Ryan, cyphermox and I were concerned that it is adding to the set of modules included in the secureboot-signed binary. I confirmed with vorlon and everything seemed okay on his end. [Other information] * Debian: debian/changelog: * Add xfs module to signed UEFI images (closes: #911147, LP: #1652822). * Salsa commit: https://salsa.debian.org/grub-team/grub/-/commit/01f1eee93acd4113475b403f80661cf651fbcc00 * The workaround is to create a /boot partition, with ext4, so you have: # Example vda-part1 ext4 /boot vda-part2 fat32 /boot/efi vgroot-lvroot xfs / - [Original Description] If I do a fresh install on an efi system and use xfs for the root and boot filesystems, the install will succeed and then on reboot grub will drop to a grub shell and fail to boot. If I try to do an ls on any of the xfs filesystems, grub reports unsupported filesystem. Doing an insmod on xfs.mod doesn't work on the xfs filesystem since it can't be read /boot/efi is a fat32 esp partition and can be read by grub. I can make the system boot by putting a copy of /boot/grub/x86_64-efi/xfs.mod in /boot/efi/EFI/ubuntu/xfs.mod and then putting the following line in /boot/efi/EFI/ubuntu/grub.cfg insmod (hd0,gpt1)/EFI/ubuntu/xfs.mod I'm guessing this would work if boot was ext2. My current HDD setup is: fdisk -l /dev/sda Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5F358931-DDAE-4F78-8647-B54434A5A3DC Device Start End Sectors Size Type /dev/sda1 2048 2000895 1998848 976M EFI System /dev/sda2 2000896 4001791 2000896 977M Linux filesystem /dev/sda3 4001792 804902911 800901120 381.9G Linux LVM My current fstab is: /dev/mapper/vgroot-lvroot / xfs defaults 0 0 # /boot was on /dev/sda2 during installation UUID=006c4d31-8c29-4e25-b8c2-5f70f5f19afd /boot xfs defaults 0 0 # /boot/efi was on /dev/sda1 during installation UUID=DFD4-FB95 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgroot-lvhome /home xfs defaults 0 0 /dev/mapper/vgroot-lvswap none swap sw 0 0 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: grub-efi-amd64 2.02~beta2-36ubuntu3.2 ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35 Uname: Linux 4.4.0-57-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.4 Architecture: amd64 CurrentDesktop: MATE Date: Tue Dec 27 12:42:40 2016 InstallationDate: Installed on 2016-12-27 (0 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: grub2 UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: ### SRU TMPL DRAFT ### [Impact] One can't deploy using root XFS partition using 18.04 on UEFI platform. [Test case] * Deploy a Bionic machine with a storage layout as follows: vda-part1 536.9 MB fat32 /boot/efi vgroot-lvroot 31.7 GB xfs / ## Only xfs is important here. The Bionic/18.04LTS deployments will fail to boot and will be redirected to grub prompt: grub> [Where could problem occurs] I checked the delta between the 2 grub (Bionic and Focal) versions after the add of 'xfs' module to see if thre is any fixes/CVE/... that we should pick up, and I found nothing. Ryan, cyphermox and I were concerned that it is adding to the set of modules included in the secureboot-signed binary. I confirmed with vorlon and everything seemed okay on his end. [Other information] * Debian: debian/changelog: - * Add xfs module to signed UEFI images (closes: #911147, LP: #1652822). + - Add xfs module to signed UEFI images (closes: #911147, LP: #1652822). * Salsa commit: https://salsa.debian.org/grub-team/grub/-/commit/01f1eee93acd4113475b403f80661cf651fbcc00 * The workaround is to create a /boot partition, with ext4, so you have: # Example vda-part1 ext4 /boot vda-part2 fat32 /boot/efi vgroot-lvroot xfs / [Original Description] If I do a fresh install on an efi system and use xfs for the root and boot filesystems, the install will succeed and then on reboot grub will drop to a grub shell and fail to boot. If I try to do an ls on any of the xfs filesystems, grub reports unsupported filesystem. Doing an insmod on xfs.mod doesn't work on the xfs filesystem since it can't be read /boot/efi is a fat32 esp partition and can be read by grub. I can make the system boot by putting a copy of /boot/grub/x86_64-efi/xfs.mod in /boot/efi/EFI/ubuntu/xfs.mod and then putting the following line in /boot/efi/EFI/ubuntu/grub.cfg insmod (hd0,gpt1)/EFI/ubuntu/xfs.mod I'm guessing this would work if boot was ext2. My current HDD setup is: fdisk -l /dev/sda Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5F358931-DDAE-4F78-8647-B54434A5A3DC Device Start End Sectors Size Type /dev/sda1 2048 2000895 1998848 976M EFI System /dev/sda2 2000896 4001791 2000896 977M Linux filesystem /dev/sda3 4001792 804902911 800901120 381.9G Linux LVM My current fstab is: /dev/mapper/vgroot-lvroot / xfs defaults 0 0 # /boot was on /dev/sda2 during installation UUID=006c4d31-8c29-4e25-b8c2-5f70f5f19afd /boot xfs defaults 0 0 # /boot/efi was on /dev/sda1 during installation UUID=DFD4-FB95 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgroot-lvhome /home xfs defaults 0 0 /dev/mapper/vgroot-lvswap none swap sw 0 0 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: grub-efi-amd64 2.02~beta2-36ubuntu3.2 ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35 Uname: Linux 4.4.0-57-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.4 Architecture: amd64 CurrentDesktop: MATE Date: Tue Dec 27 12:42:40 2016 InstallationDate: Installed on 2016-12-27 (0 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: grub2 UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: ### SRU TMPL DRAFT ### [Impact] One can't deploy using root XFS partition using 18.04 on UEFI platform. [Test case] * Deploy a Bionic machine with a storage layout as follows: vda-part1 536.9 MB fat32 /boot/efi vgroot-lvroot 31.7 GB xfs / ## Only xfs is important here. The Bionic/18.04LTS deployments will fail to boot and will be redirected to grub prompt: grub> [Where could problem occurs] I checked the delta between the 2 grub (Bionic and Focal) versions after the add of 'xfs' module to see if thre is any fixes/CVE/... that we should pick up, and I found nothing. Ryan, cyphermox and I were concerned that it is adding to the set of modules included in the secureboot-signed binary. I confirmed with vorlon and everything seemed okay on his end. [Other information] * Debian: + + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911147 + debian/changelog: - - Add xfs module to signed UEFI images (closes: #911147, LP: #1652822). + - Add xfs module to signed UEFI images (closes: #911147, LP: #1652822). * Salsa commit: https://salsa.debian.org/grub-team/grub/-/commit/01f1eee93acd4113475b403f80661cf651fbcc00 * The workaround is to create a /boot partition, with ext4, so you have: # Example vda-part1 ext4 /boot vda-part2 fat32 /boot/efi vgroot-lvroot xfs / [Original Description] If I do a fresh install on an efi system and use xfs for the root and boot filesystems, the install will succeed and then on reboot grub will drop to a grub shell and fail to boot. If I try to do an ls on any of the xfs filesystems, grub reports unsupported filesystem. Doing an insmod on xfs.mod doesn't work on the xfs filesystem since it can't be read /boot/efi is a fat32 esp partition and can be read by grub. I can make the system boot by putting a copy of /boot/grub/x86_64-efi/xfs.mod in /boot/efi/EFI/ubuntu/xfs.mod and then putting the following line in /boot/efi/EFI/ubuntu/grub.cfg insmod (hd0,gpt1)/EFI/ubuntu/xfs.mod I'm guessing this would work if boot was ext2. My current HDD setup is: fdisk -l /dev/sda Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5F358931-DDAE-4F78-8647-B54434A5A3DC Device Start End Sectors Size Type /dev/sda1 2048 2000895 1998848 976M EFI System /dev/sda2 2000896 4001791 2000896 977M Linux filesystem /dev/sda3 4001792 804902911 800901120 381.9G Linux LVM My current fstab is: /dev/mapper/vgroot-lvroot / xfs defaults 0 0 # /boot was on /dev/sda2 during installation UUID=006c4d31-8c29-4e25-b8c2-5f70f5f19afd /boot xfs defaults 0 0 # /boot/efi was on /dev/sda1 during installation UUID=DFD4-FB95 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgroot-lvhome /home xfs defaults 0 0 /dev/mapper/vgroot-lvswap none swap sw 0 0 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: grub-efi-amd64 2.02~beta2-36ubuntu3.2 ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35 Uname: Linux 4.4.0-57-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.4 Architecture: amd64 CurrentDesktop: MATE Date: Tue Dec 27 12:42:40 2016 InstallationDate: Installed on 2016-12-27 (0 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: grub2 UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652822 Title: grub efi doesn't install fs module needed to access root To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1652822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs