Closed bjornstromberg closed 1 year ago
Hello, author here. I think the root password and pubkey was already setup in the very first steps, and then copied to the target disk. Is that not so?
hmm that might be possible, found no note of it in the text, and i never use a serious password when using liveusb's since the lifetime of that password usually is less then an hour..
so i did not try the dummy password also did not use the sshd way since it was on a laptop not a server
anyway right now I'm messing with the udev that seems to work a little as it wants, i botched the grub config somewhere along the road when testing so grub updates work as they should (usually the big issue with zfs-on-root)
a couple of hours ago it worked fine with just installing eudev like in the instructions, now i need to do after item 10 in the preparations and after booting into new system it was using sda names which was likely the grub issue
localhost:~# rc-service udev start
* Caching service dependencies ... [ ok ]
* Starting udev ... [ ok ]
localhost:~# udevadm trigger
localhost:~# ls -l /dev/disk/by-id/
[List of disks]
kinda funny how something that did work a couple of hours ago no longer does..
going to do a clean run of the instructions again now with sshd enabled, will check if the password & pubkey gets passed along as you expect
just checked, the .ssh folder with pubkey is not copied to the newly installed chroot
What about root password? I'm not sure about pubkey, but root password always worked for me -- less secure of course.
Maybe we really should add a step for copying the pubkey to the new root.
also the /root/grub2 file is not transferd. gives a error message on zpool status about it is missing.
looks like i forgot to set the password now that i used ssh style, but the passwd/shadow files are the same hash sums, so it looks like that transfer works as it should.
also adding
# rc-update add udev
* service udev added to runlevel sysinit
in the chroot so the udev get started on reboot so hopefully the stable names work.
when we're at it with edits, the exit from chroot should be a own entry, since the unmount calls are outside the chroot.
could also be a good option to note that the generated rsa keys for the sshd server actually also gets copied over cleanly..
after reboot even though i've started the udev service, there is also a mdev service, should they both be running or just udev? like during the install process the /dev/disk/by-* does not populate as they should
/root/grub2
I don't know why alpine does not package this file properly, but it is only used with zpool create
anyway. The error message is just an nuisance.
in the chroot so the udev get started on reboot so hopefully the stable names work.
I think stable names are not that important, hence the suggestion in the guide that
It can be removed after reboot with setup-devd mdev && apk del eudev.
ZFS does not need the stable names, it just scans the partitions and will find which partition belongs to which pool on its own. The stable names are only relevant for the installation itself. EFI system partitions are imported with UUID, I think.
when we're at it with edits, the exit from chroot should be a own entry, since the unmount calls are outside the chroot.
Good idea.
not sure why but this go around i tried without eudev, clean mdev and still get
localhost:~# grub-probe .
grub-probe: error: unknown filesystem.
so the grub-probe works fine in the chroot, but not when using the installed system, which is probably why i botched the grub files before.
not sure if this is a big problem with alpine, since the kernels use same naming scheme as arch (no version numbers) so it maybe does not trigger a reconfig on every kernel update?
edit: doh grub-probe /boot works fine as it should, and grub-mkconfig does not botch the config, no clue what went sideways last go round.
looks like I'm chasing ghosts..
/root/grub2
I don't know why alpine does not package this file properly, but it is only used with zpool create anyway. The error message is just an nuisance.
well since we define it as /root/grub2 zpool status looks for it there, its stored in the boot pool properties
edit: new morning, and fresh eyes.. the swap(s) does not get entered into fstab
as i'm not using the encrypted swap - so i cant test against the devmapper solution used in the guide, but i expect cryptsetup version got some kind of uuid solution too
DISK_SWAP_PART_ID=${DISK}-part4
echo -e "UUID=`blkid -s UUID -o value ${DISK_SWAP_PART_ID}` none swap sw 0 0" >> /etc/fstab
well since we define it as /root/grub2 zpool status looks for it there, its stored in the boot pool properties
Fixed in latest pull request. It does not use /root/grub2 any more.
edit: new morning, and fresh eyes.. the swap(s) does not get entered into fstab
Yes, that's intended. Or else the guide must include how to permanently configure encrypted swap. This information can be found elsewhere, so we now added a tip for user to configure swap. See the end of the link.
grub
Before tweaking grub, you should try to create a boot environment first, so that you can recover the system if anything goes wrong.
well since we define it as /root/grub2 zpool status looks for it there, its stored in the boot pool properties
Fixed in latest pull request. It does not use /root/grub2 any more.
at end of item 2. we should probably remove this line too, otherwise its misleading.
Features enabled with -o compatibility=grub2 can be seen [here](https://github.com/openzfs/zfs/blob/master/cmd/zpool/compatibility.d/grub2).
edit: new morning, and fresh eyes.. the swap(s) does not get entered into fstab
Yes, that's intended. Or else the guide must include how to permanently configure encrypted swap. This information can be found elsewhere, so we now added a tip for user to configure swap. See the end of the link.
that will work.
grub
Before tweaking grub, you should try to create a boot environment first, so that you can recover the system if anything goes wrong.
usually i use a zfs enabled usb stick, so that part i got covered.
just thought i should shime in on a quick review of install guide, since i usually use them when installing root-on-zfs installs, there is quite a few pitfalls on that road with all the ways it can be done and paint yourself into a corner..
great work and thanks for the guide in the first place.
another little thing about item 12 Apply GRUB workaround
This workaround needs to be applied for every GRUB update, as the update will overwrite the changes.
/etc/profile.d/zpool_vdev_name_path.sh
does not change, its created by 'us'.
/etc/grub.d/10_linux
gets installed as /etc/grub.d/10_linux.apk-new
/usr/sbin/grub-mkconfig
script is the only file that actually needs to be re-patched after an update of grub.
minor issues but the patching really should be automated with a script and hook after grub update on alpine, but as long as the user don't install another kernel or manually trigger a re-config of grub it will be fine
a reconfigure of grub.cfg is really seldom is needed, since the kernel image does not contain any version numbers on alpine.
so this is possibly solved with just a more informative note fix after the code in item 12.
on openzfs-docs at item 17 its unmount the filesystem, before this though, setting the root password is required to be able to login after the reboot (item 18).
kinda minor issue since its just the irritating sequence of chrooting via the liveusb just to set the password, before getting into the system.
another solution could also be to setup the sshd before rebooting and setup login via authorized pubkey.