kernel-packages team mailing list archive

["mr.Kernel" <1416861@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: kexec-tools (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  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 --initrd
- argument for kexec. For example, the GRUB entry looks as follows
- (default setup with btrfs for / and /home):
+ 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
+         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 
+ 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.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1416861

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

Status in kexec-tools package in Ubuntu:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1416861/+subscriptions