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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp