The officially official Devuan Forum!

webman

Member

Registered: 2022-08-27

Posts: 45  

zfs on boot causes problems

Hello!

I am using KVM to try to install zfs on boot with chimaera,
I've done this since years with debian, using bios-boot
and separate partitions for the bpool and rpool (bootpol
and syspool - my names).
I followed the instructions for debian(!) bullseye, knowing,
that the missing systemd-part may leave "a hole", that I
cannot understand with sysvinit (wether OpenRC nor runit installed).
On a first glance, everything looks ok, but a red message
at shutdown/reboot indicates a (un)mount problem.
But network shares (cifs) do NOT mount at boot, as usual
(have hardware with chimaera to compare), which is a strong
requiremnent for me.
Additionally, if your last command was 'shutdown -r now'
and you login afterwards and use the up-arrow key, exact
this command must be back - but isnt. Something with the
root account not flushed storage/handled properly bevor shutdown.
The message at shutdown is nowhere to find (syslog/daemon).
bootlog (re-)installed (dont remember, if this was installed
by default) in the hope to get less logs to lookup (systemd
is unbeatable in this regard).
bootlogd shows mount errors at boot time:

mount: /home/shared: mount point does not exist.
mount: /ops/tools: mount point does not exist.
mount: /ops/install/global: mount point does not exist.
mount: /home/shared: mount point does not exist.
mount: /ops/tools: mount point does not exist.
mount: /ops/install/global: mount point does not exist.

This means, something looked for the mountpoints before
the syspool has been imported?
The logline above says:

Configuring network interfaces...if-up.d/mountnfs[eth1]: waiting for interface eth0 before doing NFS mounts ... (warning).

Additionally, the file /etc/network/if-up.d/mountnfs is not executed
(I added logger-statements).

My syspool is as follows:

zfs list -o name,canmount,mounted,overlay,mountpoint
NAME                               CANMOUNT  MOUNTED  OVERLAY  MOUNTPOINT
bootpool                           off       no       on       /boot
bootpool/BOOT                      off       no       on       none
bootpool/BOOT/devuan               on        yes      on       /boot
syspool                            off       no       on       /
syspool/ROOT                       off       no       on       none
syspool/ROOT/devuan                noauto    yes      on       /
syspool/home                       on        yes      on       /home
syspool/home/root                  on        yes      on       /root
syspool/home/shared                on        yes      on       /home/shared
syspool/ops                        on        yes      on       /ops
syspool/ops/install                on        yes      on       /ops/install
syspool/ops/install/global         on        yes      on       /ops/install/global
syspool/ops/install/local          on        yes      on       /ops/install/local
syspool/ops/install/local/zfsdone  on        yes      on       /ops/install/local/zfsdone
syspool/ops/tools                  on        yes      on       /ops/tools
syspool/usr                        off       no       on       /usr
syspool/usr/local                  on        yes      on       /usr/local
syspool/var                        off       no       on       /var
syspool/var/lib                    off       no       on       /var/lib
syspool/var/log                    on        yes      on       /var/log
syspool/var/mail                   on        yes      on       /var/mail
syspool/var/spool                  on        yes      on       /var/spool

Like in the ZOL docs for bullseye-on-root, some filesystems
(syspool/var, syspool/var/lib, syspool/usr) have been created like this:

zfs create -o canmount=off	syspool/var/lib

(can be seen in column CANMOUNT).

At initramfs-prompt, the pool can be listed, but nothing has been mounted so far.
This could mean, some sysvinit services come into the game and that is, where
I fail. I remember the times of debian-squeeze, where the zfs-mountpoints
were set to "legacy" and the fstab contains mounts of it (I am, at the moment,
not able to find my old notes), currently, no zfs mounts in fstab.
What I see is a wrong mount-oder - zfs, to be considered local, must be mounted
first!
Astoundig: Using 'service networking --full-restart' invokes netmounts
(and due to my inserted logging statements, I can see it) and it succeeds.
BTW, looking for a way to enhance logging-level!

NB: There is another problem with the network (not part of my question) wich
looks like a KVM problem: The interfaces come up in another order and so, the
static network configuration is not working. Most of the time, another boot fixed it.
Found many discussion about this (the VM gets a SR-IOV VF as NIC), without
final conclusion (bug or feature).

All things said above were noted, when the network was up properly.

Some help would be great and I can send full logs.

Thanks,
Manfred

danuan

Member

Registered: 2020-08-30

Posts: 16  

Re: zfs on boot causes problems

Try my howto (without a separate bpool)
a bit outdated but devuan specific

https://dev1galaxy.org/viewtopic.php?id=3794

no need to use backports now that zfs version is ok in chimaera

Last edited by danuan (2023-07-28 08:40:57)

danuan

Member

Registered: 2020-08-30

Posts: 16  

Re: zfs on boot causes problems

And i see that you have not placed your system folders under syspool/ROOT/devuan

they have to be there to get auto mounted with root on zfs setup .

zfs rename them to move like this

zfs rename syspool/usr syspool/ROOT/devuan/usr
(might need to have /usr mountpoint created in syspool/ROOT/devuan mount but empty dir)

and now make sure there is no /usr/local

(that can exist only in syspool/ROOT/devuan/usr as a mountpoint)
zfs rename syspool/usr/local syspool/ROOT/devuan/usr/local

but zfs should technically create last part of a mountpoint path if does not exit on mounting

etc...

and with that setup you do not have to set -o mountpoint ( they are inherited if sets are named after mountpoints)
zfs inherit -s mountpoint pool/dataset (to reset)

or manually set to legacy and  added to fstab

root on zfs has that behavior , of not auto mounting anything outside of current  root

and by default no over mounting if mountpoint already has file/dirs in it
(that is why you have to make sure to have mountpoint created in right paces if doing  submounts)

Last edited by danuan (2023-07-29 00:54:42)