| 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. |
|
