GRUB_DISABLE_INITRD should imply GRUB_FORCE_PARTUUID

Bug #1669160 reported by Steve Langasek on 2017-03-01
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
High
Mathieu Trudel-Lapierre

Bug Description

Currently, if you want to boot a Linux system without an initrd, you have to both set GRUB_DISABLE_INITRD=true, and set GRUB_FORCE_PARTUUID to the value of the partition uuid of the root filesystem.

disabling initrd boot only works if your root filesystem is specified in a syntax
If GRUB knows the root device, it should be able to probe the partition uuid of it without having to ask.

If the root disk is specified in a format that is known to not be resolvable by the kernel (LABEL= or UUID=), and grub is not able to resolve this to a partition uuid at update-grub time, then GRUB_DISABLE_INITRD=true should be a no-op. We should not construct a grub.cfg that we know will not boot.

However if grub is able to resolve it, then GRUB_DISABLE_INITRD=true should automatically probe the PARTUUID and use it rather than requiring it to be hard-coded.

Steve Langasek (vorlon) on 2017-03-01
Changed in grub2 (Ubuntu):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
milestone: none → ubuntu-17.03
Steve Langasek (vorlon) on 2017-03-01
Changed in grub2 (Ubuntu):
assignee: Canonical Foundations Team (canonical-foundations) → Mathieu Trudel-Lapierre (cyphermox)

Moving to ubuntu-17.05 so it remains on my todo list, I'll get to it immediately after the zesty release.

Changed in grub2 (Ubuntu):
milestone: ubuntu-17.03 → ubuntu-17.05
status: New → Triaged
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers