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:
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 --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-87c99343a7 6a' { platform_ search_ hint = xy ]; then bios=hd2, msdos1 --hint- efi=hd2, msdos1 --hint- baremetal= ahci2,msdos1 b7f2589e- 08b4-4997- 945f-87c99343a7 6a 08b4-4997- 945f-87c99343a7 6a vmlinuz- 3.13.0- 45-generic root=UUID= b7f2589e- 08b4-4997- 945f-87c99343a7 6a ro rootflags=subvol=@ crashkernel= 384M-:128M 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_
search --no-floppy --fs-uuid --set=root --hint-
else
search --no-floppy --fs-uuid --set=root b7f2589e-
fi
linux /@/boot/
initrd /@/boot/
}
The get_grub_kernel() function from /etc/init. d/kexec- load parses such an entry in /boot/grub/ grub.cfg, and then passes grub_entry( ) function. As a result, we get a final command looking like:
"linux" and "initrd" lines to process_
/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-87c99343a7 6a 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". d/kexec- load, IMHO.
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.