Activity log for bug #1416861

Date Who What changed Old value New value Message
2015-02-01 16:10:21 Andrew Ignatov bug added bug
2015-02-01 16:11:02 Andrew Ignatov 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 --initrd argument 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. 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.