dracut fails to see swap-on-zfs device, barfs

[Rudd-O]

Since the problem is that initrd is waiting for the swap device to appear, but the swap device is not there because the pool is not imported yet, the solution is as follows:

Right after 99base has created the initrd/etc/systemd/system/initrd.target.requires/*.device, we do the following:

Get that list of devices and figure out which ones are backed by ZFS pools.

Add a dependency on each one of those to the corresponding zpool-import-escapedpoolname.service.

Create the zpool-import-escapedpoolname.service file, importing the necessary pool (with -f if the kernel command line parameter so deems)

Add requires dependencies for the devices that the pool needs, before the import can happen. These dependencies must be whatever the _pdev function used in 99base spits out.

This should ensure that the pools are imported properly, in the right order, and using the necessary devices to bring them to full operation.

---

Alternative plan:

If $hostonly, then:

Check out all pools, and for those pools that contain used swap devices (in fstab) or the root file system, create zpool-import-escapedpoolname.service units that depend on the backing devices, and make initrd.target depend on these pool imports. The import :fthESE pools as services will ensure that the swap devices in question appear just fine.

We can use zdb to detect which devices back the pools.

---

Another alternative: if I write a zfs generator for the initramfs then I can bypass this work and ensure that ael pools get imported at boot the right way -- any pools available as per the cache statement (or, if absent, the root= command line parameter), can be imported with systemd that way, and the proper devices will appear.

I need to discover if generators are supported in initrd. If they are, well then they will work fantastically.

[Rudd-O]

Maybe the zimport approach is worth investigating. If zimport can get the pool imported as devices appear, then it works as the necessary pool-backed devices just appear as pools are imported. We have to do no special work. I just have to ensure that zimport does not actually Mount anything. It works with systemd as devices appear, and it also works in non-systemd systems as the pools get imported fine. I have to see if import waits for cache devices and the like. I also have to see if it works without or/and with forced imports.

[zssfred]

I think we saw the same issue almost at the same time. But it is weird that I did successfully resume F19 from swap on zol several times(less than 3). And soon the OS crashed with the whole rpool lost(I put the swap in the same rpool as root). From very limited info from console, the kernel accused swap for syncing. I guess that may be due to I enabled dedup and compression on this swap on zol. Later, I re-installed F19 for many times to try to restore swap on zol. But I got no success. Finally, I switched the swap to a partition -- a real block device. And now, the resume works well. The root cause should be on dracut in initramfs for the resume starts before the kernel boots from root.

[Rudd-O]

I have some dracut code in my fork of zfs that works with hostonly (as generated by f19) initrds, where the swap device (required by the initramfs) is waited upon correctly by detecting at initramfs generation time that the block device is in ZFS, and initializing the right pool at initramfs time.