#3158 PR merged: docs: document booting of ReaR rescue initramfs on z/VM

Labels: enhancement, documentation, fixed / solved / done

lzaoral opened issue at 2024-02-19 13:30:

Pull Request Details:

All steps described in the new documentation were tried on a Fedora Rawhide s390x VM running under the z/VM hypervisor.

  • Description of the changes in this pull request:

Document booting of ReaR rescue initramfs on s390/s390x.

jsmeix commented at 2024-02-19 14:53:

@lzaoral
Wow!
Looks "rather interesting" to me as a total ZIPL noob ;-)
Now I have a starting point :-)
Thank you for it!

lzaoral commented at 2024-02-19 15:13:

Glad to hear that! 😄 BTW, if you accidentally overwrite the zipl configuration of your host (e.g. when using the same device for storing the kernel and initrd) when experimenting, you can just call zipl without any argument to restore it to the default values (at least on Fedora/RHEL).

jsmeix commented at 2024-02-21 12:40:

@lzaoral
I would like to suggest to add a bit more context description
to make the "Booting ReaR rescue initramfs on s390/s390x"
section somewhat self-contained (to a reasonable extent)
so that when someone reads only this section
it is comprehensible on its own.

Perhaps as a total ZIPL noob I am not an intended reader
of this section so my following suggestions could go too far.
Nevertheless I just make them and you can then decide
if and what context description you may add
as you think what could be best for our users.

(1) "Bare metal" recovery (i.e. recovery on a "bare VM"):
As far as I see it seems the described method using zipl
makes the ReaR recovery system boot on the same system
where the zipl command is run.
Accordingly it seems the zipl method has the same drawback
as the kexec method, that a running Linux system is
already needed where the ReaR recovery system should boot
(to run kexec or zipl) so neither the kexec method
nor the zipl method support recovery on a "bare VM"
(i.e. on a VM where not yet a Linux system must be running).
Is this the case or do I misunderstand something?
If my understanding is right, it should be clearly described
that a running Linux system is already needed
where the ReaR recovery system should be booted.
If I misunderstand things, it should be clearly described
where "rear mkbackup" was run
versus where "rear recover" should be run
and how to make the ReaR recovery system boot
where "rear recover" should be run.

(2) REAR_OUTPUT usage:
It confuses me that REAR_OUTPUT is used
both for zipl "output" via --target and
for zipl "input" via --image and --ramdisk.
I read
https://manpages.debian.org/jessie/s390-tools/zipl.8
and I am wondering if it is really required that one same
REAR_OUTPUT directory must be used for the zipl options

--target=REAR_OUTPUT
--image=REAR_OUTPUT/...
--ramdisk=REAR_OUTPUT/...

or if all could be different directories like

--target=BOOTMAP_INSTALL_DIRECTORY
--image=/SOME/PATH/TO/KERNEL
--ramdisk=/ANOTHER/PATH/TO/INITRD

If all could be different directories it should be clearly
described what the reason is why it is usually OK
to use one same directory for all three options.
I think the same directory for KERNEL and INITRD is natural
but perhaps a differnt --target directory could be required,
see the next item (3):

(3) Bootloader install device:
It was inexplicable to me why

The bootloader ... was installed on the dasda device

regardless that no bootloader install device was specified.
I think
https://manpages.debian.org/jessie/s390-tools/zipl.8
explains it:

-t <TARGET DIRECTORY> or --target=<TARGET DIRECTORY>
  Use the specified <TARGET DIRECTORY>.
  zipl uses this directory to store the bootmap,
  i.e. a file containing boot data.
  The actual boot loader is installed onto the device
  containing the target directory.
  Supported devices are DASD and SCSI disks.

So it should be made more clear that via --target
the bootloader install device is implicitly specified
to avoid possibly "surprising" results when a user
specifies some --target=... that happens
to be on whatever unexpected device
where then a bootloader gets installed.
In particular when REAR_OUTPUT is used for --target
(i.e. the ReaR recovery system kernel and initrd
may be stored anywhere where its underlying device
is not meant to be booted from).

(4) Only for DASD disks:
According to
https://manpages.debian.org/jessie/s390-tools/zipl.8
the zipl --target method is only supported for
DASD and SCSI disks.
If this is right, it may be clearly described.
Probably - as far as I remember the code -
currently only DASD disks are supported by ReaR
so currently the zipl --target method is supported on
all IBM Z disks that are currently supported by ReaR.
The crucial word is "currently" - i.e. if ReaR gets
enhanced to also support other IBM Z disks, the
described zipl --target method may no longer work
so to be future-proof this restriction of the
zipl --target method should be mentioned
because in practice nobody updates documentation ;-)

jsmeix commented at 2024-02-26 07:39:

To avoid misunderstanding:

In my above
https://github.com/rear/rear/pull/3158#issuecomment-1956565746
I wrote about "bare metal recovery",
I even wrote "true bare metal recovery".

This was very misleading because on IBM Z systems
"true bare metal recovery" is not wanted.
On IBM Z there is always some virtualization in between.
What I actually meant was that the ReaR recovery system
can be booted on a "bare VM" i.e. on a VM where not yet
another Linux operating system must be running.

I changed my misleading wording in my above
https://github.com/rear/rear/pull/3158#issuecomment-1956565746
from "bare metal" to "bare VM".

lzaoral commented at 2024-02-26 13:56:

Thank you a lot for the thorough review, @jsmeix!

I've specified that the new section is only for virtual machines running under z/VM. While it should be possible to also use ReaR on IBM Z LPARs, I have never tried that personally (maybe @pcahyna has some experience?).

(1) The zipl method can be used independently of the running OS which is an information I forgot include by using z/VM Control Program directly. Actually, it should be quite straightforward to use zipl to implement OUTPUT=USB just like you would use GRUB2 or EXTLINUX to prepare a bootable device on x86_64.

(2) Correct, the value of the --target= option can be arbitrary as long as that directory is on the same device. (Actually, I was able to create the bootmap file (even without --force) on a completely different device but unsurprisingly, the machine then failed to boot.)

(3) Hopefully done.

(4) RHEL only supports IBM Z machines with DASD or SCSI disks so I have zero experience with other disk types. However, zipl(8) on Fedora Rawhide also mentions NVMe as a supported --target=. Also, it seems that --tape= is the right option for tape devices. So the only option that cannot be covered by zipl is the z/VM reader (a virtual punch card reader) which cannot be used with plain kernel and initramfs anyway (I have never tried booting RHEL installer from this device but, apparently, you also need some additional files to do so.).

I've updated the zipl section to include this information as well.

jsmeix commented at 2024-02-26 14:55:

@lzaoral
thank you so much for your so much improved documentation!

In particular thank you for spelling out
certain IBM Z specific terms like

z/VM Control Program (CP)

which helps to avoid confusion with things
like the traditional Unix cp program ;-)

I think I got now (for the very first time - hooray!)
some basic understanding how all that IBM Z booting stuff
belongs together (in particular zipl and chreipl versus CP).

jsmeix commented at 2024-02-26 15:12:

@lzaoral
some years ago (at the time when I did my first tests
with ReaR on IBM Z) we had an internal issue at SUSE
whether or not to officially support ReaR on IBM Z.
At that time only virtual machines running under z/VM
with only DASD disks were considered.
ReaR on IBM Z LPARs was explicitly not considered.
So at least for now we do not need to worry about
support for ReaR on IBM Z LPARs or non-DASD disks.
Nevertheless it is very good to make clear that
support for ReaR on IBM Z is currently limited to
virtual machines running under z/VM with DASD disks
and perhaps also under z/VM with SCSI disks.

jsmeix commented at 2024-02-26 15:23:

Now this

The machine will not boot if `BOOTMAP_INSTALL_DIRECTORY`
and `REAR_DIRECTORY` are on different devices!

makes things clear and it explains why in practice
it is probably simplest and best to use one same
directory for bootmap, kernel, and initrd.

jsmeix commented at 2024-02-26 15:28:

@pcahyna
because in
https://github.com/rear/rear/pull/3158#issuecomment-1964207577
@lzaoral "advertised" you as a possible "IBM Z expert" ;-)
I would appreciate it if you could have a look here
(as time permits).

@rear/contributors
I would like to merge it on Friday afternoon
unless there are objections.

pcahyna commented at 2024-03-01 16:31:

@jsmeix sorry for being late, looking now ...

pcahyna commented at 2024-03-01 16:31:

can you please delay merging a bit?

jsmeix commented at 2024-03-01 16:59:

@pcahyna
don't worry and no need to be sorry!
Of course I delay merging when you need time for review.
No rush, take your time, and
have a relaxed and recovering weekend!

jsmeix commented at 2024-03-04 09:26:

@pcahyna
thank you for your review!
As always your precise view reveals problematic things.

jsmeix commented at 2024-03-06 12:51:

As far as I see now all looks well
so I would like to merge it tomorrow afternoon
unless objections appear.

@pcahyna
please approve this pull request when it is OK for you.

lzaoral commented at 2024-03-07 15:04:

I've rebased the branch against master and squashed all fixups.

jsmeix commented at 2024-03-08 06:30:

@rear/contributors
I would like to merge it today afternoon
unless there are objections.

jsmeix commented at 2024-03-08 16:03:

@lzaoral
thank you for all your work to get that done properly and
for your patience to answer all my understanding questions!

@pcahyna
thank you for your careful review!

[Export of Github issue for rear/rear.]