boot that's the question¶

Labels: enhancement, fixed / solved / done

gozora opened issue at 2016-07-30 13:53:¶

Hello @jsmeix
As discussed in couple of threads here related to GRUB_RESCUE functionality, I maybe found way how to check correct prefix (/boot or /) for rear-initrd and rear-kernel.
It looks to be rather simple. If you have /boot as separate mountpoint, initrd and kernel uses / as prefix.
If you don't have /boot separated (part of root (/)) initrd and kernel will be prefixed with /boot. which is only logical if you think of it :-)

Could you please test if this new modification is working for you, and maybe check for some regression here and there ;-) ?
I didn't create pull request for it yet as there are still couple of things I need to think about.
You can find draft here.

P.S. I've found out that GRUB_RESCUE does not work correctly on my EFI Debian 8.4, as it looks like Debian uses /boot/grub/grub.cfg as config file.
So assumption in 94_grub2_rescue.sh (line 47):

if is_true $USING_UEFI_BOOTLOADER ; then
    # set to 1 means using UEFI
    grub_conf="$( dirname $UEFI_BOOTLOADER )/grub.cfg"
    ...

will not be that fortunate ..

jsmeix commented at 2016-08-01 10:04:¶

Only a minor issue at first glance:

You had my

echo "          echo 'Loading kernel $boot_kernel_file ...'"
...
echo "          echo 'Loading initrd $boot_initrd_file (may take a while) ...'"

changed to

echo "          echo 'Loading kernel $grub_rear_menu_entry_linux_value ...'"
...
echo "          echo 'Loading initrd $grub_rear_menu_entry_initrd_value (may take a while) ...'"

I had intentionally not used the GRUB2 menue entry value
for the message but the actual file name so that the message
shows what actual file name GRUB 2 loads and not the
meaningless GRUB2 internal menue entry value.

In other words:
When GRUB 2 loads /boot/rear-kernel but the
GRUB2 internal menue entry value is only /rear-kernel
I want the message that is shown to the user to be

Loading kernel /boot/rear-kernel ...

because that is the actual files that is loaded
and not

Loading kernel /rear-kernel ...

because actually there is no such file on the disk.

gozora commented at 2016-08-01 10:26:¶

@jsmeix heh, this was the exact reason why I've changed it. I thought it would be better to see what is grub actually loading instead of content of /boot after system is up ...
When you are in grub shell it is kind of different world.
But no problem to to return it back to original.

jsmeix commented at 2016-08-01 11:12:¶

Ah!

It seems - only a blind assumption for now - things
start to make sense for me:

When /boot/ is on its own partition
i.e. a filesystem on /dev/sdaN
that will be under LInux mounted as /boot/
then GRUB uses the filesystem on /dev/sdaN directly
and in that filesystem there is no such thing as /boot/
so that for GRUB the files are in '/' on that filesystem.

Now the question is what we like to tell the user
with that GRUB message:
The name of the file from GRUB's point of view
(i.e. so that it is meaningful in the GRUB shell)
or the name of the file from Linux' point of view
(i.e. so that it is meaningful when Linux was booted).

I think I have to meditate on it...
;-)

jsmeix commented at 2016-08-01 11:32:¶

Regarding the find_kernel_initrd_prefix() function:

I think when a function is only used in one single script
I would prefer to keep such local things local.

Why not have directly in 94_grub2_rescue.sh

local grub_boot_dir=$boot_dir
if mountpoint $boot_dir ; then
    # When /boot is on its own partition
    # i.e. a filesystem on /dev/sdaN
    # that will be under Linux mounted as /boot
    # then GRUB uses the filesystem on /dev/sdaN directly
    # and in that filesystem there is no such thing as /boot
    # so that for GRUB the files are in the root of that filesystem:
    grub_boot_dir=""
fi
grub_rear_menu_entry_linux_value=$grub_boot_dir/$kernel_name
grub_rear_menu_entry_initrd_value=$grub_boot_dir/$initrd_name

FWIW:
I think my variable names grub_rear_menu_entry_linux_value
and grub_rear_menu_entry_initrd_value got too long (as a result
of my ignorance of filenames from GRUB's point of view).
Now - provided my above understanding is right - one could use
proper names for them like grub_kernel_file and grub_initrd_file

gozora commented at 2016-08-01 11:41:¶

Now the question is what we like to tell the user
with that GRUB message:
The name of the file from GRUB's point of view
(i.e. so that it is meaningful in the GRUB shell)
or the name of the file from Linux' point of view
(i.e. so that it is meaningful when Linux was booted).

I think I have to meditate on it...
;-)

Yes, or flip coin :-)

I think when a function is only used in one single script
I would prefer to keep such local things local.

Why not have directly in 94_grub2_rescue.sh

Ok, will make it local ...

Did you had time to do some testing? I'm just curious whether it works for you as well ...

jsmeix commented at 2016-08-01 11:49:¶

I did not yet test it
and today I have to leave early.
I think your changes are a good improvement
so that you should do a pull request.
I think I can test it tomorrow.

By the way:
I noticed your '@#$%#$^$$%' - if I understand it correctly
you also do not like Linux distribution specific deviations
too much - and yes they are a maintenance nightmare!

gozora commented at 2016-08-01 12:05:¶

Ok, I'll prepare it then ...

By the way:
I noticed your '@#$%#$^$$%' - if I understand it correctly
you also do not like Linux distribution specific deviations
too much - and yes they are a maintenance nightmare!

Yes, that "special" condition was there to make this work on Debian as well. It will not be part of pull request (yet).

I'm working currently on some way how to identify UEFI/legacy boot + boot loaders version + boot loader config files reliably, so we don't have to guess any more.
Aim is to get rid of code like this in the future:

if [[ $OS_VENDOR = "Debian" ]]; then
         LogPrint "Debian special test case ..."
         grub_conf=$( readlink -f $boot_dir/grub/grub.cfg)
fi

gozora commented at 2016-08-01 19:01:¶

#948 was created. For me it worked fine, but as always testing is more than welcome...
UEFI based systems (like my SLES12 SP1) do still need manual intervention in grub shell to boot from this entry, mostly due secure boot :-(. I'll try to address this later.

jsmeix commented at 2016-08-02 12:16:¶

With https://github.com/rear/rear/pull/948 merged
I consider this issue to be fixed.

UEFI issues should be handled in a separate issue.

@gozora
as always many thanks for your valuable contribution!
You helped me to understand a crucial part of GRUB
see https://github.com/rear/rear/issues/946#issuecomment-236553278

gozora commented at 2016-08-02 12:30:¶

No problem.

[Export of Github issue for rear/rear.]

#946 Issue closed: /boot or not /boot that's the question¶