grub-installer ignores "bootdev" setting in preseed file

[Riccardo Murri]

I am installing an Ubuntu system with two disks attached; I want the
OS to be installed on the second disk /dev/sdb; the first disk
/dev/sda is currently completely empty (not even partitioned). The
install process works fine, but then GRUB ignores the line:

        d-i grub-installer/bootdev string /dev/sdb

and complains that it cannot write to /dev/sda (because it does not
even have a partition table).

Same happens if I use GRUB's own notation "(hd1)" instead of /dev/sdb
in the preseed file.

If I omit the "grub-installer/bootdev" line in the preseed, then D-I
stops to ask me if I want to install GRUB on sda or sdb.

The issue can be replicated with virtual machines: add two disks (one
of the empty / zeroed out), and instruct the preseed to install on the
second one.

I think this is the same as Debian bug #666974, but I'm filing it
separately as I'm not sure what/how much is changed in Ubuntu's
version of D-I. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666974

Preseed options used for partitioning / target selection:

    ### Partitioning
    d-i partman-auto/method string lvm
    d-i partman-auto/choose_recipe select atomic

    # do not ask for confirmation, ever
    d-i partman-basicfilesystem/no_swap boolean false
    d-i partman-lvm/confirm boolean true
    d-i partman-lvm/confirm_nooverwrite boolean true
    d-i partman-lvm/device_remove_lvm boolean true
    d-i partman-md/confirm boolean true
    d-i partman-md/device_remove_md boolean true
    d-i partman-partitioning/confirm_write_new_label boolean true
    d-i partman/choose_partition select finish
    d-i partman/confirm boolean true
    d-i partman/confirm_nooverwrite boolean true
    d-i partman/exception_handler select Retry

GRUB-related preseed options:

    ### Boot loader installation
    d-i grub-installer/only_debian boolean true
    d-i grub-installer/with_other_os boolean true
    d-i grub-installer/bootdev string /dev/sdb

[Launchpad Janitor (janitor)]

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

[Asher Newcomer (ashern)]

Is there any workaround for this, or is it impossible to perform an automated install to anything other than a primary hd?

[Jeff (jeff-lasslett)]

I've made a bootable USB drive that I am using to start off net installations of a customised ubuntu distro. The trouble is that the USB drive ends up as /dev/sda. Late in the install process the debian installer attempts to install grub to the MBR of /dev/sda despite the whole install going to /dev/sdb.

This will force me to not preseed the grub portion of the install. This is a problem because I am an oem and I need unattended net installs (even if I do need a USB drive to kick the process off due to the bios not having PXE capability).

[Yung Shen (kaxing)]

having similar issue when systems with sdcard inserted,
installer will automatically install grub on mmcblk0 even with:

d-i grub-installer/bootdev hd(0, 0)

[Stuart Longland (redhatter)]

I've got the following in my preseed file:

d-i partman-auto/disk string /dev/sdc
d-i grub-installer/only_debian boolean false
d-i grub-installer/bootdev string /dev/sdc

We've got two machines intended as Ceph OSD nodes, they've got two 3TB HDDs on the two high-speed SATA ports and a 60GB SSD on a second. Since the SSD is mostly for the OS with the HDDs providing the bulk of the I/O, this is meant the HDDs wound up as sda and sdb with the SSD being called sdc. The BIOS is set to boot sdc first, and the other two disks will be initially unpartitioned so it's important that the boot-loader winds up on sdc.

The above seems to do the trick. I rather suspect the docs are a little ambiguous, particularly with regards to the syntax used to specify bootdev which looks like a relic of GRUB-legacy days.

[Darkmike (mikefaille)]

It affect me too on Ubuntu 12.04.3

[Launchpad Janitor (janitor)]

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

[Dave Chiluk (chiluk)]

The above two debdiffs modify the precedence of the grub-installer/bootdev option to take precedence over grub-installer/with_other_os and grub-installer/only_debian, so that if it is set it will not get over-written by the other options.

@cjwatson, @xnox
Please review and let me know what I should've done differently.

[Dimitri John Ledkov (xnox)]

On 7 February 2014 17:07, Dave Chiluk <email address hidden> wrote:
> The above two debdiffs modify the precedence of the grub-
> installer/bootdev option to take precedence over grub-
> installer/with_other_os and grub-installer/only_debian, so that if it is
> set it will not get over-written by the other options.
>
> @cjwatson, @xnox
> Please review and let me know what I should've done differently.
>

It looks ok to me, but i'd like to run it through both bios & uefi
across most of our test-cases to see if there are any regressions.
Gladly this should only affect automatic preseeds. Some help with
testing this patch via kickstart would be appreciated as I haven't
used kickstart yet (maybe a good time to learn that).

--
Regards,

Dimitri.

[Dave Chiluk (chiluk)]

Sure take your time. There's no rush on this one. I honestly don't know of anyone who is using kickstart though.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "lp1012629.precise.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

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

[Dave Chiluk (chiluk)]

@xnox @cjwatson

I'd really like to get this into trusty, which has feature freeze in a few days.

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub-installer - 1.78ubuntu15

---------------
grub-installer (1.78ubuntu15) trusty; urgency=medium

  * Cherrypick 1.92 changes:
    * Adapt patch from Guilhem Moulin to always honor
    grub-installer/bootdev, when it was preseeded, instead of insisting on
    automatic detection which may lead to unpredictable results (e.g. use
    a different device, or fail unattended installation). Closes:
    #666974. LP: #1012629.
 -- Dimitri John Ledkov <email address hidden> Tue, 25 Feb 2014 16:43:41 +0000

[Sandeep Raman (sandeep-raman)]

I'm using preseed to install 12.04.4 and seeing the error mentioned in the bug. How can I implement the patch/fix in 12.04.4 iso to unblock myself?

[Colin Watson (cjwatson)]

When backporting this, please take care to include my fix for bug 1292628, which was a regression caused by fixing this bug.

[David Partain (david-partain)]

Hi,

This is still not working for me.

I downloaded the latest trusty mini.iso (from 3 April) and have tried to install on a laptop using a USB stick. It ends with:

Running 'grub-install --force "/dev/sda"' failed.

So, I verified that I'm grabbing what I should...

Apr 3 15:13:02 anna[6110]: 2014-04-03 15:13:02 URL:http://mymirror/ubuntu/pool/main/g/grub-installer/grub-installer_1.78ubuntu19_amd64.udeb [198620/198620] -> "/var/cache/anna/grub-installer_1.78ubuntu19_amd64.udeb" [1]

which is the latest. I verified that I'm preseeding correctly:

Apr 3 15:12:47 debconf: --> GET partman/early_command
Apr 3 15:12:47 debconf: <-- 0 USBDEV=$(list-devices usb-partition | sed "s/\(.*\)./\1/"); BOOTDEV=$(list-devices disk | grep -v $USBDEV | head -1); debconf-set partman-auto/disk $BOOTDEV; debconf-set grub-installer/bootdev $BOOTDEV;
Apr 3 15:12:47 preseed: running preseed command partman/early_command: USBDEV=$(list-devices usb-partition | sed "s/\(.*\)./\1/"); BOOTDEV=$(list-devices disk | grep -v $USBDEV | head -1); debconf-set partman-auto/disk $BOOTDEV; debconf-set grub-installer/bootdev $BOOTDEV;
Apr 3 15:12:48 debconf: --> SET partman-auto/disk /dev/sdb
Apr 3 15:12:48 debconf: <-- 0 value set
Apr 3 15:12:48 debconf: --> SET grub-installer/bootdev /dev/sdb
Apr 3 15:12:48 debconf: <-- 0 value set

and here's what actually happens when it gets to the grub bit...

Apr 3 15:26:20 debconf: --> SETTITLE debian-installer/grub-installer/title
Apr 3 15:26:20 debconf: <-- 0 OK
Apr 3 15:26:20 debconf: --> GET grub-installer/bootdev
Apr 3 15:26:20 debconf: <-- 0 /dev/sdb
Apr 3 15:26:20 debconf: --> GET cdrom-detect/hybrid
Apr 3 15:26:20 debconf: <-- 10 cdrom-detect/hybrid doesn't exist
Apr 3 15:26:21 debconf: --> PROGRESS STEP 1
Apr 3 15:26:21 debconf: <-- 0 OK
Apr 3 15:26:21 debconf: --> PROGRESS INFO grub-installer/progress/step_bootdev
Apr 3 15:26:21 debconf: <-- 0 OK
Apr 3 15:26:21 debconf: --> FGET grub-installer/bootdev seen
Apr 3 15:26:21 debconf: <-- 0 false

That "false" worries me. Is that right?

Then it continues and blows up.

Apr 3 15:26:21 debconf: --> INPUT high grub-installer/only_debian
Apr 3 15:26:21 debconf: <-- 30 question skipped
Apr 3 15:26:21 debconf: --> GO
Apr 3 15:26:21 debconf: <-- 0 ok
Apr 3 15:26:21 debconf: --> GET grub-installer/only_debian
Apr 3 15:26:21 debconf: <-- 0 true
Apr 3 15:26:21 debconf: --> PROGRESS STEP 1
Apr 3 15:26:21 debconf: <-- 0 OK
Apr 3 15:26:21 debconf: --> SUBST grub-installer/progress/step_install_loader BOOTDEV /dev/sda
Apr 3 15:26:21 debconf: Adding [BOOTDEV] -> [/dev/sda]
Apr 3 15:26:21 debconf: <-- 0
Apr 3 15:26:21 debconf: --> PROGRESS INFO grub-installer/progress/step_install_loader
Apr 3 15:26:21 debconf: <-- 0 OK
Apr 3 15:26:21 grub-installer: info: Installing grub on '/dev/sda'
Apr 3 15:26:21 grub-installer: info: grub-install does not support --no-floppy
Apr 3 15:26:21 grub-installer: info: Running chroot /target grub-install --force "/dev/sda"
Apr 3 15:26:21 grub-installer: Installing for i386-pc platform.
Apr 3 15:26:22 grub-installer: grub-install: warning: your embedding area is unusually small. core.img won't fit in it..
Apr 3 15:26:22 grub...

[David Partain (david-partain)]

Hi,

I will also note that if you download the latest trusty min.iso, put it on a usb stick, boot from that and install, you'll get exactly the same error.

Cheers,

David

[Chris J Arges (arges)]

So two things, please (1) verify that the trusty version does indeed fix this issue _and_ (2) if this is backported to any other version we'll need to ensure Colin's fix for the regression this patch introduced is also incorporated and tested. Please update, verify and then subscribe sponsors again.

[David Partain (david-partain)]

Hi,

As far as I know, this is NOT fixed for trusty. For grins, I downloaded the latest mini.iso yesterday (from http://archive.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/current/images/netboot/ and dated 05-Apr-2014 11:23), used unetbootin to put it on a USB stick, and tried to install. The installation went fine, but grub-install as per above. I had chosen sdb (the internal hard drive) for installation, but grub-install still used sda.

Cheers,

David

[Dave Chiluk (chiluk)]

@david-partain, this has been fixed in trusty, what you are experiencing is a new bug altogether.

I was able to verify that forcing the bootdev in the preseed file does indeed force grub to install onto /dev/sdb when using the non-netboot install.

However, when using the same preseed file with the netboot install I experienced the issue david-partain is complaining about. The grub-installer stage creates a red screen with the error message

"Unable to install Grub in /dev/sdb Executing 'grub-install /dev/sdb' failed.

This is a fatal error
"

Looking at virtual terminal 4 there is an error message
"grub-install: error: unable to identify a filesystem in hostdisk//dev/sdb; safety check can't be performed."

I'm not yet certain why the server iso works, and the netboot iso fails.

@david-partain, can you check the virtual terminal to see if you are getting the same error?

[Dave Chiluk (chiluk)]

@david-partain I was able to work around the error that I was experiencing by ensuring that there was a valid partition table on /dev/sdb.

That makes sense as well. There's really no way to install bootloader to the mbr of /dev/sdb if the mbr doesn't exist because there is no partition table.

[David Partain (david-partain)]

Hi Dave,

I've been working with Canonical on this issue since I posted all of my information.

I have the following as part of my preseed:

d-i partman/early_command string \
USBDEV=$(list-devices usb-partition | sed "s/\(.*\)./\1/");\
BOOTDEV=$(list-devices disk | grep -v "$USBDEV" | head -1);\
debconf-set partman-auto/disk $BOOTDEV;\
debconf-set grub-installer/bootdev $BOOTDEV;

During installation, this becomes:

Jun 19 12:31:20 debconf: --> SET partman-auto/disk /dev/sdb
Jun 19 12:31:20 debconf: <-- 0 value set
Jun 19 12:31:20 debconf: --> SET grub-installer/bootdev /dev/sdb

(which is right) but still I get this:

Jun 19 12:45:03 debconf: --> SETTITLE debian-installer/grub-installer/title
Jun 19 12:45:03 debconf: <-- 0 OK
Jun 19 12:45:03 debconf: --> GET grub-installer/bootdev
Jun 19 12:45:03 debconf: <-- 0 /dev/sdb
Jun 19 12:45:03 debconf: --> GET cdrom-detect/hybrid
Jun 19 12:45:03 debconf: <-- 10 cdrom-detect/hybrid doesn't exist
Jun 19 12:45:03 debconf: --> PROGRESS STEP 1
Jun 19 12:45:03 debconf: <-- 0 OK
Jun 19 12:45:03 debconf: --> PROGRESS INFO grub-installer/progress/step_bootdev
Jun 19 12:45:03 debconf: <-- 0 OK
Jun 19 12:45:03 debconf: --> FGET grub-installer/bootdev seen
Jun 19 12:45:03 debconf: <-- 0 false
Jun 19 12:45:03 debconf: --> INPUT high grub-installer/only_debian
Jun 19 12:45:03 debconf: <-- 30 question skipped
Jun 19 12:45:03 debconf: --> GO
Jun 19 12:45:03 debconf: <-- 0 ok
Jun 19 12:45:03 debconf: --> GET grub-installer/only_debian
Jun 19 12:45:03 debconf: <-- 0 true
Jun 19 12:45:03 debconf: --> PROGRESS STEP 1
Jun 19 12:45:03 debconf: <-- 0 OK
Jun 19 12:45:03 debconf: --> SUBST grub-installer/progress/step_install_loader BOOTDEV /dev/sda
Jun 19 12:45:03 debconf: Adding [BOOTDEV] -> [/dev/sda]

which is wrong. I asked for sdb :-)

The only workaround so far seems to be to have:

d-i grub-installer/only_debian boolean false

which then pops up a question if I really want it on sdb, which I can confirm. This, however, sorta defeats the purpose of a fully-automated installation with users who don't know what sdb is :-)

How can I ensure that there's a valid partition table on /dev/sdb in a fully-automated install? I'm doing this for partitioning:

d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-auto/method string crypto
d-i partman-auto-lvm/new_vg_name string somename
d-i partman-auto-lvm/guided_size string max
d-i partman-lvm/confirm boolean true
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
d-i partman-auto/expert_recipe string \
(recipe deleted)
d-i partman/default_filesystem string ext4

Can I add something to ensure that the partition table is there?

Thanks.

David

[Gilles DOFFE (gdoffe)]

Same problem here. Using custom preseed file to automatically burn grub on fakeraid volume /dev/md126 (instead of /dev/md126p1 due to an other bug #1370368).

So adding :
d-i grub-installer/bootdev string /dev/md126

to my preseed file does nothing.

I'm trying to preseed Ubuntu 14.04.1 desktop with ubiquity

[Sai Kiran (saikiran-gummaraj)]

I still find issues installing grub via 'd-i grub/installer' if there are more than one disk. Or it could be the other issue Dave Chiluk referred to in the post #23.

Tried this on Precise (12.04.4, 12.04.5) and Trusty with errors.

d-i debconf/priority string critical
d-i partman/early_command string debconf-set partman-auto/disk "/dev/sdb"
# My partition recipe
d-i grub-installer/only_debian boolean false
d-i grub-installer/with_other_os boolean false
d-i grub-installer/bootdev "/dev/sdb"

I see the update grub run but ubuntu never boots after the install.

I could only workaround these issues via a late_command to run the grub-install from the target itself via chroot.

[Jav (the-jav)]

I'm also experiencing the bug (same results as in post #25).
I'm installing Ubuntu server 14.04.2 from an USB drive on a 2HDD machine (in RAID1 with HP smart array controller)

[Christofer Bernander (christoferb)]

I'm also experiencing issues with grub-installer ignoring/overriding the bootdev setting on Ubuntu Server 14.04.2 w/ Software RAID (at least when set using the debconf-set command).

I had to resort to using the same type of workaround as mentioned in post #27, so I thought I'd share some details of it here for reference:

...

# Identify disks larger than 1 TiB
d-i partman/early_command string \
DISKLIST=$(for f in $(list-devices disk); \
do fdisk -l $f 2>/dev/null | sed -nr 's|^Disk (/[^:]+):.* [0-9]{13,} bytes$|\1|p'; done | sort); \
echo "${DISKLIST}" > /tmp/disklist

...

# Manual GRUB installation
d-i grub-installer/skip boolean true
d-i lilo-installer/skip boolean true
d-i preseed/late_command string \
in-target apt-get -y install grub-pc; \
for line in $(cat /tmp/disklist); do in-target grub-install --force "${line}"; done; \
in-target update-grub

...

This works for me on two separate systems where one has the (system) disks on sda+sdb and the other on sdb+sdc.

Here is an expanded version of the first part which includes the partition recipe:

# Identify disks larger than 1 TiB
d-i partman/early_command string \
DISKLIST=$(for f in $(list-devices disk); \
do fdisk -l $f 2>/dev/null | sed -nr 's|^Disk (/[^:]+):.* [0-9]{13,} bytes$|\1|p'; done | sort); \
echo "${DISKLIST}" > /tmp/disklist; \
DISKA=$(echo "${DISKLIST}" | head -n 1); \
DISKB=$(echo "${DISKLIST}" | head -n 2 | tail -n 1); \
debconf-set partman-auto/disk "${DISKA} ${DISKB}"; \
debconf-set partman-auto-raid/recipe "1 2 0 ext2 /boot ${DISKA}2#${DISKB}2 . 1 2 0 ext4 / ${DISKA}3#${DISKB}3 ."

The rest of the partitioning is just a standard 'd-i partman-auto/expert_recipe string multiraid' config that does not need to reference the disk variables.

[Elias Abacioglu (raboo)]

It says fix released for trusty.. I'm installing trusty and experiencing same problem.
Getting a dialog that wants me to confirm the disk I've selected. Attaching a screenshot.
So apparently it's not fixed for trusty.

Here is my preseed partitioning snippet:

d-i debconf/priority string critical
# install on smallest disk.
d-i partman/early_command string \
  DISK=$(parted_devices | sort -k2n | head -1 | cut -f1);\
  debconf-set partman-auto/disk "$DISK";\
  debconf-set grub-installer/bootdev "$DISK";

#d-i partman-auto/disk string "$(parted_devices | sort -k2n |awk NR==1'{print $1}')"
d-i partman-auto/method string regular
d-i partman-auto/purge_lvm_from_device boolean true
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true

d-i partman-basicfilesystems/choose_label string gpt
d-i partman-basicfilesystems/default_label string gpt
d-i partman-partitioning/choose_label string gpt
d-i partman-partitioning/default_label string gpt
d-i partman/choose_label string gpt
d-i partman/default_label string gpt

d-i partman-auto/expert_recipe string \
  boot-root :: \
    1 1 1 free $gptonly{ } $primary{ } \
      $bios_boot{ } method{ biosgrub } . \
    4048 1000 4048 linux-swap \
      method{ swap } format{ } \
    . \
    30000 500 -1 ext4 \
      $gptonly{ } $primary{ } \
      method{ format } format{ } \
      use_filesystem{ } filesystem{ ext4 } \
      mountpoint{ / } \
    .

partman-basicfilesystems partman-basicfilesystems/no_mount_point boolean false
d-i partman/confirm_write_new_label boolean true
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

[Dave Chiluk (chiluk)]

So I've been doing a lot of work in this area recently. After looking closely through partman-partitioning, and create_new_label forces a gpt partition table if the volume is above 2TB. This makes sense, since disks >2TB tend to have issue with msdos partition tables. Unfortunately my slightly older, bios-booting/legacy-booting system just does not want to boot off of gpt disks. As a result it will not boot after install, even though grub-installer successfully installs.

So for me the solution is to either use smaller disks or boot using efi.

Hopefully this doesn't muddy the waters any more than it already is. Additionally if people are still having issues it would be beneficial to start over in a new case and start the problem definition from scratch.

[Your Mom (h-blut)]

Same issue for Xenial.

To me this doesn't look like a partman issue, since the grub-installer is practically ignoring the bootdev set in the preseed file, ("debconf: --> SUBST grub-installer/progress/step_install_loader BOOTDEV /dev/sda"), and since I am also forgoing the partman partitioning (also a work-around)

[Hans van den Bogert (hbogert)]

I'm still hitting this. Though this could be partly blamed on the fact that i'm setting `grub-installer/bootdev ...` dynamically at `partman/early_command`.
Fix for me was to add the following to the early_command as well:

    . /usr/share/debconf/confmodule;\
    db_fset grub-installer/bootdev seen true

[Cameron Nicholson (cameron-nicholson)]

This is still broken for me in Trusty 14.04.5

Interestingly it only appears broken on servers with a storage controller AND disks on the motherboard scsi host (sata or sas). That may or may not be pertinent/related, but I've so far been unable to get it to break in the same way on hosts with a bunch of disks only on the on-board controller.

hbogert's fix (https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1012629/comments/33) has worked when introduced in our disk recipe script.

Something is still broken.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release