grub-installer fails if root is on 27th disk

Bug #776633 reported by Roland Dreier on 2011-05-03
This bug affects 5 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)

Bug Description

Binary package hint: debian-installer

I tried installing ubuntu-server 11.04 on a real system with 28 disks, where the disk I wanted to use as the root partition happened to be enumerated as /dev/sdaa (notice the two "a"s -- /dev/sda through /dev/sdaz are used, and then /dev/sdaa is the next disk). The installer made it most of the way through, but the grub-installer step failed.

I tried this in a virtual environment (for easier reproduction), and did:

    for i in $(seq -f'%02.0f' 28); do qemu-img create -f qcow2 d$i 4g; done

to make 28 virtual drives (the qcow2 format means this uses minimal disk space), and then:

    kvm -net nic,model=virtio -net user -m 1024 -vga vmware -usbdevice tablet -smp 2 -vnc :1 \
    -drive file=/home/roland/ubuntu-11.04-server-amd64.iso,media=cdrom,if=ide,boot=on \
    -drive file=d01,if=virtio,format=qcow2 \
    -drive file=d02,if=virtio,format=qcow2 \
    -drive file=d03,if=virtio,format=qcow2 \
    -drive file=d04,if=virtio,format=qcow2 \
    -drive file=d05,if=virtio,format=qcow2 \
    -drive file=d06,if=virtio,format=qcow2 \
    -drive file=d07,if=virtio,format=qcow2 \
    -drive file=d08,if=virtio,format=qcow2 \
    -drive file=d09,if=virtio,format=qcow2 \
    -drive file=d10,if=virtio,format=qcow2 \
    -drive file=d11,if=virtio,format=qcow2 \
    -drive file=d12,if=virtio,format=qcow2 \
    -drive file=d13,if=virtio,format=qcow2 \
    -drive file=d14,if=virtio,format=qcow2 \
    -drive file=d15,if=virtio,format=qcow2 \
    -drive file=d16,if=virtio,format=qcow2 \
    -drive file=d17,if=virtio,format=qcow2 \
    -drive file=d18,if=virtio,format=qcow2 \
    -drive file=d19,if=virtio,format=qcow2 \
    -drive file=d20,if=virtio,format=qcow2 \
    -drive file=d21,if=virtio,format=qcow2 \
    -drive file=d22,if=virtio,format=qcow2 \
    -drive file=d23,if=virtio,format=qcow2 \
    -drive file=d24,if=virtio,format=qcow2 \
    -drive file=d25,if=virtio,format=qcow2 \
    -drive file=d26,if=virtio,format=qcow2 \
    -drive file=d27,if=virtio,format=qcow2 \
    -drive file=d28,if=virtio,format=qcow2

(the first two lines can be tweaked for your ISO location and UI preferences). In this VM, I chose to use whole disk on /dev/vdaa in the partitioner, and I got the same error with grub-installer failing.

I'm currently poking around the grub-installer script to see what exactly is failing. In /var/log/syslog (in the installer), I just see:

    WARNING **: Configuring 'grub-installer' failed with error code 1

but no diagnostics from grub-installer that I can find.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: debian-installer (not installed)
Uname: Linux 2.6.39-999-generic x86_64
Architecture: amd64
Date: Tue May 3 11:26:53 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101206)
MachineType: LENOVO 2901CTO
 total used free shared buffers cached
 Mem: 7987000 7830544 156456 0 290636 5617776
 -/+ buffers/cache: 1922132 6064868
 Swap: 1738748 620 1738128
 PATH=(custom, user)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.39-999-generic root=UUID=ab1e5491-e40c-4113-bf20-22ecb604999a ro drm.debug=0xe
SourcePackage: debian-installer
UpgradeStatus: Upgraded to natty on 2011-03-24 (39 days ago) 10/27/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6UET61WW (1.41 ) 2901CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6UET61WW(1.41):bd10/27/2010:svnLENOVO:pn2901CTO:pvrThinkPadT410s:rvnLENOVO:rn2901CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: 2901CTO
dmi.product.version: ThinkPad T410s
dmi.sys.vendor: LENOVO

Roland Dreier (roland.dreier) wrote :
Roland Dreier (roland.dreier) wrote :

Looks like the bug is in this snippet of grub-installer:

# This code to set disc_offered was taken from lilo-installer
rootfs_nodevfs=$(mapdevfs $rootfs)
bootfs_nodevfs=$(mapdevfs $bootfs)
prefix=$(device_to_disk "$bootfs")

case $prefix in
        disc_offered_devfs=$(echo "$bootfs_nodevfs" | sed "s:\(.*\)/.*:\1/disc:")

Since my root filesystem is on /dev/vdaa1, $prefix ends up as /dev/vdaa which doesn't match the second-to-last pattern (the intention is to catch it with /dev/[hsv]d[a-z] but that only matches /dev/vda through /dev/vdz. Tweaking that pattern is a little scary since it seems pretty magical...

Roland Dreier (roland.dreier) wrote :

Here's a patch that I tested out that handles two- and three-letter drive names for /dev/sd... and /dev/vd...

I checked the kernel sources and /dev/hdX will never use multiple letters, and /dev/sdX and /dev/vdX will only use one, two or three letters. In my virtual test system as described above, I can successfully install grub on /dev/vdaa with a patched grub-installer.

tags: added: patch
Colin Watson (cjwatson) on 2011-05-31
affects: debian-installer (Ubuntu) → grub-installer (Ubuntu)
Changed in grub-installer (Ubuntu):
status: New → Confirmed

I think grub-pc is also affected by similar device name length issues. I have a Sun Fire X4500 where the firmware is so strange only two of the 48 disk drives are exposed to the BIOS as boot disks. Ubuntu sees them as /dev/sdy and /dev/sdag

I was able to shoe-horn an installation of 10.04.3 on by using the server installation CD option "continue without without bootloader" (or something to that effect) then booting from the CD in recovery mode and from a shell prompt running "dpkg-reconfigure grub-pc" which presented me with only /dev/sda through /dev/sdz as installation targets for grub2. The system has md RAID1 /dev/sdy1 and /dev/sdag1 but the bootstrap is only on /dev/sdy at this point and not on /dev/sdag.

Eventually I hope to get around to find the code that limits grub-pc to only /dev/sd[a-z]

lmhd (maylein) wrote :
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers