Make Hibernation Great Again!

 I have now put the fixes from the last two blogposts into a github repository: https://github.com/seife/make-hibernate-great-again so that you can just clone it, examine what it does and then run

sudo make install

followed by

sudo dracut -f

This should do the following:

• let resume actually work (by enabling the dracut resume module)
• make hibernate more verbose (switch to an empty text console and increase the kernel's log level before hibernation, restore after resume)
• make resume more verbose

Have fun!

I have also packaged it in obs://home:seife:testing, but I do not really advise to use this repo on anything but my own machines ;-) 

 

 

"hibernation fix" part 2: verbose resume

Now that I fixed hibernation to resume at all, I found another thing I had added to my old install long ago.

The "problem" is, that resume from hibernation is very quiet. So all you see is the GRUB messages "loading kernel", "loading initrd", then nothing, just the disk light may be blinking for quite some time, and if resume is successful, you'll see the unlock prompt of your screenlock.

That's a bit too little "user interface" for my taste.

The reason it is like this is, that the kernel's progress messages (in 10% steps) are printed with level "pr_info":

    if (!(nr_pages % m))

        pr_info("Image loading progress: %3d%%\n",

                                     nr_pages / m * 10);

But the default "quiet" boot suppresses KERN_INFO messages, which is good because without that, you cannot find the prompt for unlocking your crypted filesystems amongst all those KERN_INFO messages during boot... so how to fix it?

We can just adapt the systemd-hibernate-resume.service to increase the kernel log level just before starting to resume, via a dropin file in /etc/systemd/system/systemd-hibernate-resume.service.d/10-resume-verbose.conf:

[Service]

ExecStartPre=/bin/sh -c "echo 7 > /proc/sys/kernel/printk"

ExecStartPost=/bin/sh -c "echo 1 > /proc/sys/kernel/printk"

Also, add the file to your dracut config, so that it is actually included in the initrd:

install_items+=" /etc/systemd/system/systemd-hibernate-resume@.service.d/10-resume-verbose.conf "

now rebuild your initrd with "dracut -f" and enjoy :-)

Oh, and of course this only helps if you do not use things like plymouth which actually hide everything interesting during boot. Update 2022-02-12: it also works with plymouth, because image loading kicks in before plymouth can hide the interesting bits.

dracut: fix hibernate after fresh install

Just for fun, I finally installed a fresh Tumbleweed on one of my machines to actually find out if I'm missing out on new features that are masked by just always updating the old installation.

One feature that I had missed was, that hibernation was no longer working. Or, to be more exact, hibernation was working, but resume was not. Investigating the issue, I found that dracut's "resume" module was not included in the initramfs, which in turn lead to initramfs not even trying to resume.

The dracut mechanism has some logic to actually find out if suspend and resume is configured, and when it decides it is not, it will just skip adding the "useless" resume module.

Unfortunately, the check is faulty IMHO. It checks, if the resume device is configured in the kernel, and if it is, it adds the module to dracut. The problem is, that this kernel config is written by the resume code in the initrd... so during installation this is not the case, and as a result the module is not added to initrd, which leads to the config not being set on next reboot... 

The trivial fix is to call dracut once with the option to include the resume module:

dracut -a resume -f

After a reboot, the kernel config will be set and in the future the resume module will always be included in the initrd.

For an even saver setup, adding

add_dracutmodules+=" resume "

to /etc/dracut.conf.d/99-local.conf might be even better.

Of course I wanted to report a bug about the issue, then found out that there are plenty already:

• openSUSE: https://bugzilla.opensuse.org/1192506
• upstream dracut: https://github.com/dracutdevs/dracut/issues/924
• Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1795422
• RedHat actually fixed it for RHEL9 by just removing the crazy "only include it if it has been included before"-logic: https://github.com/redhat-plumbers/dracut-rhel9/pull/12

openSUSE Tumbleweed on the Banana Pi BPI-M2 ZERO

This is the first post of a small series about openSUSE on the Banana Pi BPI-M2 ZERO.

Preface

I recently got myself a Banana Pi M2 Zero board while ordering other stuff at an electronics distributor. The M2 zero is the same form factor and feature set as the Raspberry Pi Zero W (the GPIO pin headers are said to be compatible, it has WiFi and Bluetooth built in and an USB OTG port). The CPU is an Allwinner H2+, a quad-core ARM processor running a 1GHz clock speed, RAM size is 512MB. Processing power is probably comparable to a Raspberry Pi 2 board.

I bought the M2 Zero to use it with an RTLSDR stick to receive the signal of my outside RF temperature sensor. This worked with the Raspberry Pi Zero W, but was a bit too much for the slower CPU which has other more important things to do anyway (playing internet radio ;-), so the M2 Zero was a cheap, more powerful alternative. The box will be running headless and thus I do not care about support for graphics and multimedia anyway.

In the end, I switched the RF receiver to a RaspyRFM board whih is using less energy and simpler to use than an RTLSDR stick just to receive some sensors and now the M2 Zero board is free for tinkering...

openSUSE on the M2 Zero

There was already an image available for the Banana Pi M2 Plus (called "sinovoipbpim2plus"), which is the "bigger brother" of the M2 zero, but that image did not boot. Experimenting with the u-boot image from armbian lead to success in "openSUSE Tumbleweed boots with armbian u-boot". Thanks to the friendly openSUSE ARM community, a matching u-boot version for the M2 Zero was built quickly and I could submit the updated image in OBS to get an image ready for the board (called "sinovoipbpim2zero").

Some small things are still to be sorted out, this is why I would suggest you use the image from the home:seife:bananapi repository for now. Since the board has only WiFi networking (more on that in a later post...), you'll need a serial console wired up for initial setup and I strongly suggest to use at least the "openSUSE-Tumbleweed-ARM-X11-..." image and not the JeOS image, since JeOS does not contain NetworkManager and using WiFi with wicked (actually using anything with wicked) is not fun.

So put the image on the SD card, connect the serial console, boot the box up. Log in as root. WiFi connection is easily established then:

nmcli dev wifi connect YOUR_SSID password YOUR_PASSWORD

That's it, have fun! ;-)

Addon note: When I started to write this post, my home:seife:bananapi repo was necessary for actually getting WiFi to work (contained a fixed kernel-firmware package). This has all been submitted to upstream or openSUSE:Factory:ARM now. All that's "special" in my repo now is a slightly extended package selection in the image (the "dtc" package is included) and a fixed config.sh script that makes NetworkManager actually work correctly, including name resolution, see boo#1180234 for details), so the image from openSUSE:Factory:ARM should be "good enough" for most uses already and in the near future I'll probably retire the home:seife:bananapi project or use it just for development stuff).