/etc/init.d/kexec-load does not expect /boot being inside a btrfs subvolume /@/

Bug #1416861 reported by Andrew Ignatov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kexec-tools (Ubuntu)
New
Undecided
Unassigned

Bug Description

Greetings,

I've discovered, that in case the root partition resides on a btrfs subvolume (default Ubuntu name "@"), and /boot catalog is inside this subvolume, /etc/init.d/kexec-load does not correctly form the arguments for kexec. For example, the GRUB entry looks as follows (default setup with btrfs for / and /home):

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-b7f2589e-08b4-4997-945f-87c99343a76a' {
        recordfail
        load_video
        gfxmode $linux_gfx_mode
        insmod gzio
        insmod part_msdos
        insmod btrfs
        set root='hd2,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 b7f2589e-08b4-4997-945f-87c99343a76a
        else
          search --no-floppy --fs-uuid --set=root b7f2589e-08b4-4997-945f-87c99343a76a
        fi
        linux /@/boot/vmlinuz-3.13.0-45-generic root=UUID=b7f2589e-08b4-4997-945f-87c99343a76a ro rootflags=subvol=@ crashkernel=384M-:128M
        initrd /@/boot/initrd.img-3.13.0-45-generic
}

The get_grub_kernel() function from /etc/init.d/kexec-load parses such an entry in /boot/grub/grub.cfg, and then passes
"linux" and "initrd" lines to process_grub_entry() function. As a result, we get a final command looking like:

/sbin/kexec -l /@/boot/vmlinuz-3.13.0-45-generic --initrd=/@/boot/initrd.img-3.13.0-45-generic --append=root=UUID=b7f2589e-08b4-4997-945f-87c99343a76a ro rootflags=subvol=@ crashkernel=384M-:128M

But in the currently loaded system the "@" btrfs subvolume is mounted as /, so the paths that are correct for GRUB (when the subvolume is not yet mounted), are not valid, so kexec fails with "No such file or directory".
As a workaround, I've done a dirty hack by creating a symlink "@" on the root partition, which points to / itself, but a more intelligent check should be implemented in /etc/init.d/kexec-load, IMHO.

description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.