[DOCUMENTATION] Unable to install ZBM and Alpine on new disk following the official guide

[clarenceab]

Hello, following the advice given on IRC I'm opening this issue about installing Alpine along with ZBM using the official guide.

I've tried from version 3.16.2 to the latest, 3.18.2 with no success.
This is a one encypted disk only setup, on metal (x86_64 if it matters).

Going step by step with the guide, the part when it always fail is, after installing the distro and chrooting into the new system, the enabling startup services. Everytime I want to setup udev as the device manager, it complains about not having the mdev service added to the sysinit runlevel. But when I do it, it disable the hwdrivers one, previosly added.

In one of my attempts, I was able to only active mdev service, and complete the steps of the guide, but when i tried to export the zpool, I couldnt do it because it was busy the command complained.

https://gitlab.alpinelinux.org/alpine/aports/-/issues/14046
It may be relevant? Ive read the ZBM guide was created before that commit made it to the Alpine 3.16.2 release IIRC.

Thanks in advance.

[clarenceab]

Presumably this is THE thing that (may) solve this
https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/158
About quieting the rc-update: service mdev is not in the runlevel sysinit alert.

[ahesford]

If you follow our guide and ignore the mdev message, does the installation work? Your linked "solution" is just "ignore the message [that we don't tell you to act on anyway]".

[clarenceab]

If you follow our guide and ignore the mdev message, does the installation work? Your linked "solution" is just "ignore the message [that we don't tell you to act on anyway]".

No, because then setting up (e)udev as the dev manager doesn’t work. Thought maybe that PR permits the script to actually work, but I’m not sure.

I’d also see the existence of the zfs-udev package on Alpine that the guide doesn’t tell to install.

But again, just thinking about possible reasons.

[ahesford]

I just stripped the udev stuff from the Alpine guide. Making non-default device management work isn't really within the scope of our ZFS guides.

[clarenceab]

Um... Ok. Hope it works that way.

[ahesford]

It works fine in our Alpine testbed, where we don't fool around with udev at all. Users should customize the installation to their liking, fighting whatever upstream issues there may be.

[clarenceab]

Unfortunately, without that configuration the installation does still fail.
When I try to create the vfat filesystem with
mkfs.vfat -F32 "$BOOT_DEVICE"
I get
mkfs.vfat: can't open '/dev/sda1': No such file or directory

[ahesford]

Under the "Define disk variables" section, note the comment:

Verify your target disk devices with lsblk. /dev/sda, /dev/sdb and /dev/nvme0n1 used below are examples.

Most likely, your disk isn't /dev/sda.

[clarenceab]

Yes, it is. All the other commands with "$BOOT_DEVICE" didn't fail.

[ahesford]

I just ran through the guide in a virtual machine and discovered that mdev -s is necessary after partitioning to generate all of the device nodes. I've added the command to the guide.

[clarenceab]

Just tried. Unfortunately it doesn't work either :(
None of the commands of the guide gave me any error, but at reboot the system hangs at the bios splash screen of the motherboard (Lenovo T470).
I changued beetween rEFInd and efibootmgr and the result is the same. Can't see any log or error nowhere to report, sadly.

[zdykstra]

That sounds like an entirely different issue that is not related to mdev/udev in the guide.

[clarenceab]

Can I do something to view at least a log to try to figure out what the issue is?
From my little knowledge I could say that with the actual process there's no setup of the device manager (not even the default mdev I mean)....

[clarenceab]

Do you think that maybe that's the case even considering I've tried with rEFInd also and got the same result?
Will try and report back.

[classabbyamp]

refind is also just an efi executable that follows the same rules as any other, if the firmware doesn't like anything but BOOTX64.EFI and refind wasn't installed as that it wouldn't work

[clarenceab]

I've just downloaded ZBM as /boot/efi/EFI/BOOT/BOOTX64.EFI and adapted the efibootmgr configuration just changing the location of the efi executable, nothing else.
I didnt't cp it to have a backup (is it doable under this configuration?), so I also skip that part with efibootmgr.

After finishing the installing throught all the steps, only changing the above, upon reboot, the firmware of my Lenovo laptop indeed shows me the menu and default countdown of 10 seconds with zroot/ROOT/alpine as the default choice. When I choose it and enter the given password, the system boots.

From that view, everything nice, but...

The system apparently did not loaded the zpool correctly. Everytime, the boot process shows me

cannot import '18132215140190722370' : a pool with that name already exists
use the form 'zpool import <pool | id > <newpool>' to give it a new name
cannot import 'zroot' : a pool with that name already exists
use the form 'zpool import <pool | id > <newpool>' to give it a new name

And besides that, the system seems broken (for instance I couldn't execute some scripts).

As I said, I did nothing but followed the guide only with the mentionated changes.

Sorry for the noise and for being a beginner. And, of course, thanks to all for the patience and help!

EDIT: When I go to ZBM menu I can see zroot/ROOT/alpine, efivars and /tmp mounted, the three with read/write permissions.

[ahesford]

Those messages always appear on Alpine. I haven't looked at their initialization scripts to see how they can be avoided, because I don't use Alpine.

As for post-installation help, that's beyond the scope of these discussions or this project in general. The purpose of the guide is to show how to deploy a boot environment compatible with ZBM; gaining familiarity with the operating system is another matter.

[clarenceab]

Thank you very much for your great help. I realize what you're saying and the fact that the installation did actually finish without any error. Those boot messages have to do, without any doubt, with something Alpine-specific then.
For the record, after getting a network connection, wich odly I had to do it with ethernet because wpa_supplicant and a few other utilities didn't launch correctly, I cloud start setting up the system according to my needs.
I also noticed the existence of a symlink in /boot to the same directory, that I removed without any drawback so far (dont't know where that came from).