ram0 vga=normal rw' as for other boot media¶

Labels: enhancement, bug, fixed / solved / done

ivarmu opened issue at 2022-04-13 13:25:¶

Relax-and-Recover (ReaR) Pull Request Template¶

Please fill in the following items before submitting a new pull request:

Pull Request Details:¶

Type: Bug Fix
Impact: High
Reference to related issue (URL): No issue opened right now
How was this pull request tested?: Local VM
Brief description of the changes in this pull request:
On RHEL8.5, if you simply add the line GRUB_RESCUE=y at /etc/rear/site.conf and run rear -v mkbackup, you'll see the new entry at the Grub2 menu, but that new boot option will end up with a Panic like the following one:

The original Grub2 entry looks like the following:

menuentry 'Relax-and-Recover' --class os {
          search --no-floppy --fs-uuid --set=root 1c0c73ea-169c-4ed5-a6d0-d0e6501fc0b6
          echo 'Loading kernel /boot/rear-kernel ...'
          linux /rear-kernel selinux=0 unattended console=ttyS0,9600 console=tty0
          echo 'Loading initrd /boot/rear-initrd.cgz (may take a while) ...'
          initrd /rear-initrd.cgz
}

Looking at the kernel parameters used at every other boot media generated by ReaR, the root parameter generated by the /usr/share/rear/output/default/940_grub2_rescue.sh file is using a wrong value, as the correct value should be root=/dev/ram0.

That PR is generating the grub entry with this parameter, in addition to the search --no-floppy --fs-uuid --set=root ... line. Maybe that line should disappear, but I can't test other O.S.

pcahyna commented at 2022-04-13 14:43:¶

@antonvoznia you have used GRUB_RESCUE recently, have you encountered this problem?

pcahyna commented at 2022-04-14 13:15:¶

Thanks for the report and patch, interestingly, I think I have used GRUB_RESCUE in the past and I don't recall having to do that, so I wonder what exactly the problem is.

jsmeix commented at 2022-04-20 07:38:¶

I am not a GRUB expert so I may confuse things
but I think there are two different "root" thingies here:

The "root" for GRUB (i.e. where GRUB finds its files).
This is specified via search --no-floppy --fs-uuid --set=root ...

The "root" for the kernel (i.e. where Linux finds its files).
This can be specified via a Linux kernel comand line parameter.

jsmeix commented at 2022-04-20 07:53:¶

@pcahyna
I had used and tested GRUB_RESCUE some longer time ago
in particular during https://github.com/rear/rear/pull/942
and it had worked for me at that time (on SLES12)
for certain values of "worked", see the details in that pull request ;-)

pcahyna commented at 2022-04-20 09:23:¶

well I saw @antonvoznia using GRUB_RESCUE recently and it worked, so apparently sometimes it works, sometimes it does not. I will try to reproduce it, but if not successful, I would just merge the PR and not dedicate too much attention to the issue.

ivarmu commented at 2022-04-20 10:00:¶

well I saw @antonvoznia using GRUB_RESCUE recently and it worked, so apparently sometimes it works, sometimes it does not. I will try to reproduce it, but if not successful, I would just merge the PR ond not dedicate too much attention to the issue.

For your reference, I'm using the following config:

OUTPUT=ISO
OUTPUT_URL=file:///secundario/imagenes

BACKUP=NETFS
BACKUP_URL=file:///secundario/imagenes
NETFS_KEEP_OLD_BACKUP_COPY=2

EXCLUDE_VG=("secundario")
EXCLUDE_MOUNTPOINTS=("/secundario/logs" "/secundario/imagenes")

GRUB_RESCUE=y

ISO_DEFAULT="automatic"

KERNEL_CMDLINE="${KERNEL_CMDLINE:-} unattended root=/dev/ram0"

REQUIRED_PROGS+=("/root/rear-configs/montar_disco_secundario.sh")

PRE_RECOVERY_SCRIPT="/bin/montar_disco_secundario.sh"

USER_INPUT_TIMEOUT=5

If I remove the root=/dev/ram0 from the KERNEL_CMDLINE, the system is unable to boot with the new Grub2 entry. Remember I'm using RHEL8.5.

jsmeix commented at 2022-04-20 10:18:¶

Because we have root=/dev/ram0 at many other places
I assume it is OK to also have it in general for GRUB_RESCUE
(I cannot imagine why root=/dev/ram0 should not work)
so I approve this pull request.

jsmeix commented at 2022-04-20 10:23:¶

By the way

# find usr/share/rear -type f | xargs grep '/dev/ram0'

shows that we have at several places

... root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE ...

so I wonder if we should use that also for GRUB_RESCUE
(i.e. with additional vga=normal rw)?

jsmeix commented at 2022-04-21 07:22:¶

@ivarmu
could you try out if it still works (or even works better) for you
with additional kernel command line options vga=normal rw
i.e. the line in usr/share/rear/output/default/940_grub2_rescue.sh like

        echo "          linux $grub_boot_dir/$boot_kernel_name root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE"

@rear/contributors
do you think additional kernel command line options vga=normal rw
make sense also for GRUB_RESCUE?

I think with additional kernel command line options vga=normal rw
booting the ReaR recovery system via GRUB_RESCUE should
behave more in sync (in particular what video mode is used and
that the kernel's root device is enforced mounted read-write)
with booting the ReaR recovery system from external medium
(e.g. from an ISO image on CDROM or from a USB drive).

ivarmu commented at 2022-04-21 10:19:¶

@jsmeix adding these settings is working without any issue for me.

ivarmu commented at 2022-04-21 15:16:¶

shit! I've vanished my PR :-(

hpannenb commented at 2022-04-21 15:23:¶

@rear/contributors do you think additional kernel command line options vga=normal rw make sense also for GRUB_RESCUE?

@jsmeix You might want to take a look at this. I guess the answer to adding/using vga=normal is: ... it depends. Though not knowing all the "grubby" circumstances it might also be a: ... it does not hurt ... according to that.

Edit: updated link to GRUB2.x manual and kernel (boot) doc.

jsmeix commented at 2022-04-22 06:12:¶

I already had looked too often at the GRUB documentation
and at the kernel command line parameters documentation
but the more one looks at them the more one gets confused
what "the right way" actually is in practice "out there in real world"
so the only thing we can do in practice is to implement what results
least issue reports from our users "out there in real world".

Therefore my argument is:
We use root=/dev/ram0 vga=normal rw
at several places except for GRUB_RESCUE
and we got no issue reports from our users (as far as I know)
except this one for GRUB_RESCUE
so we should also use that for GRUB_RESCUE
in particular because it works for @ivarmu according to
https://github.com/rear/rear/pull/2791#issuecomment-1105019251

When issues appear with GRUB 'linux' command options
we could "provide final power to the user" by introducing
a new config variable for GRUB 'linux' command options
so users could specify special things if really needed.
But currently it seems using root=/dev/ram0 vga=normal rw
"just works out there in real world" so we can keep things simple
and use that (hardcoded) everywhere.

https://www.gnu.org/software/grub/manual/grub/grub.html#linux
reads (excerpts)

On x86 systems, the kernel will be booted using the 32-bit boot protocol.
Note that this means that the ‘vga=’ boot option will not work;
...
GRUB can automatically detect some uses of ‘vga=’ and
translate them to appropriate settings of ‘gfxpayload’

I guess "will not work" does not mean that booting fails
but only means that the 'vga' boot option has no effect
so it boots as if there was no 'vga' boot option.
Perhaps for 'vga=normal' GRUB can automatically
translate it to appropriate settings of 'gfxpayload'
so in particular 'vga=normal' may even work.
So I think 'vga=normal' does not hurt or it even works.

jsmeix commented at 2022-04-22 06:14:¶

@pcahyna
if you agree please merge it.

pcahyna commented at 2022-04-22 11:59:¶

I agree with adding rw as it is related to root=. Isn't it better to add vga separately though - it seems unrelated and I am a bit afraid of breaking something else?

pcahyna commented at 2022-04-22 12:01:¶