grub-installer fails on disks > 26th (restrictive shell pattern)

[Mauricio Faria de Oliveira]

Problem:
-------

grub-installer fails on disks greater than the 26th disk.

Upfront, I acknowledge this is an unlikely scenario, but that problem was caught by test teams,
and it might be worth fixing (proposal included below) for some application/cases/environments.

Cause:
-----

Shell pattern matching rule (/usr/bin/grub-installer, line 327).

   case $prefix in
       [...]
      /dev/[hsv]d[a-z0-9]|[...]) <<---
       [...]
       *)
       [...]

That pattern disallows disks named after /dev/sdaa, for example.
Names with 2 letters are assigned to the 27th disk forwards (i.e., sda-sdz for the first 26).

With the current code, disks > 26 will match the '*' (asterisk) rule, and hit the grub-installer error.

Solution Proposal:
-----------------

sed '327 s,|,*|,' -i /usr/bin/grub-installer

i.e.,

   case $prefix in
       [...]
  - /dev/[hsv]d[a-z0-9]|[...])
  + /dev/[hsv]d[a-z0-9]*|[...])
       [...]
       *)
       [...]

This would allow the old pattern to exist (* matches /zero/ or more characters),
while allowing more characters after an initial alphanumeric character.

Caveat: ok, the new characters can now be anything (asterisk), not only alphanumeric
chars, but I think it's unlikely to see anything named after "/dev/[hsv]d[a-z0-9](more chars)"
where '(more chars)' isn't also '[a-z0-9]', specially on the (mostly controlled) installer scenario.

Problem Test-case:
-----------------

Install with 27 disks, choosing the 27th disk (sdaa, or vdaa.. anything w/ 2 alphas before a partition number)

Step 0) create 27 disk images

$ for i in {1..27}; do qemu-img create -f qcow2 disk-$i.qcow2 1g; done
Formatting 'disk-1.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off
[...]
Formatting 'disk-27.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off
$

Step 1) install ubuntu server on it

Using ppc64el as an example, but should occur on other archs too:

(use 'eval' for the correct expansion of '-drive\ file=disk-{1..27}.qcow2')

$ eval qemu-system-ppc64 -enable-kvm -M pseries -cpu POWER7 -smp 1,cores=1,threads=1 -m 1G -vga none -nographic -boot once=d -device spapr-vscsi -drive media=cdrom,file=ubuntu-14.04-server-ppc64el.iso -drive\ file=disk-{1..27}.qcow2

Step 2) proceed until grub install stage; it will fail.

Solution Test-case:
------------------

Same steps as 'problem test-case', but on the 'Partition disks' stage (or anything
after /usr/bin/grub-installer is present), drop to a shell and modify the script:

 [...]
 Partition disks
 Go Back
 Execute a shell
 Continue

 ~ # sed '327 s,|,*|,' -i /usr/bin/grub-installer
 ~ # exit

 (back to the installer, resume normal installation by pressing enter.. selection should be at Partition Disks)

The grub-installer should pass correctly.

Note: after the installation finishes, grub2 will not boot the correct drive since it only attemps
from disks 'disk (0) to disk7' (which is another story/bug). So, if you want to see the system
booting, change the qemu command line from 'disk-{1..27}' to 'disk-{20-27}' (i.e., disk7 is the
installed disk).

You should see:

 Trying to load: from: disk ...
 E3404: Not a bootable device!
 Trying to load: from: disk1 ...
 E3404: Not a bootable device!
 Trying to load: from: disk2 ...
 E3404: Not a bootable device!
 Trying to load: from: disk3 ...
 E3404: Not a bootable device!
 Trying to load: from: disk4 ...
 E3404: Not a bootable device!
 Trying to load: from: disk5 ...
 E3404: Not a bootable device!
 Trying to load: from: disk6 ...
 E3404: Not a bootable device!
 Trying to load: from: disk7 ... Successfully loaded
 [ ... booting ... ]

Thanks.

[Launchpad Janitor (janitor)]

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

[Mauricio Faria de Oliveira (mfo)]

Attaching patch w/ 'solution proposal' (mentioned in description).

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "grub-installer-26plus-disks.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Phillip Susi (psusi)]

It looks like that will also prevent installing grub to any partition numbered over 9, which is a more common scenario.

[Mauricio Faria de Oliveira (mfo)]

Hi Phillip,

Hm, that I'm not sure of..
IIRC that part of the code expects only the disk block device without the partition number, but I haven't gone through it in detail.
(I guess the [0-9] range is there for disks named after sd1 or something like that, which I haven't seen yet, but recall something similar on a log file from the past)

But if it indeed does, then, fair enough: that's a better argument (less unlikely scenario :-) for fixing this.

Thanks

[Christian Rund (christian-rund)]

See comment #13 in bug 1317914 (https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1317914) for a detailed description of my observations.
One of these is that I had been able to install GRUB to a disk no. 26 (/dev/vdz).

Using the instructions to patch the grub-installer script I also was able to install GRUB to /dev/vdaa. Subsequent booting is a different story related to SLOF aliases.

[Mauricio Faria de Oliveira (mfo)]

Yes; updating the bug title to disambiguate. Thanks.

[Mauricio Faria de Oliveira (mfo)]

(according to this snippet in description)

> Problem:
> -------
>
> grub-installer fails on disks greater than the 26th disk.

[Paul Boven (p-boven)]

Ran into this when installing Ubuntu 14.04 on a SuperMicro 847 (36 disks + 2 SataDOMS for the OS), so just commenting to say this is not a merely hypothetical situation. The SataDoms end up at /dev/sdak and /de/sdal.

Applying the 'sed' workaround from the description worked.

[Mauricio Faria de Oliveira (mfo)]

Thanks for veryfing and confirming this :)