FransUrbo
commented
9 years ago Thanx for testing this, much appreciated! I DID test it several times on both Wheezy and CentOS 6.0, but apparently I missed a few things.
- First one is pretty simple, and I've already pushed that to #3560. @behlendorf usually commits on Friday afternoon/night (my time - which is tonight) and I'll update the packages after that with the new change to the dracut scripts as well then.
- The second one will need some more investigation and more information from you. Using the
mountpoint, if there is one, is by design… The root filesystem/dataset should have/set, so it would be mounted on/sysroot//(notice the double slashes).. - Your third point, the export… I've never touch that part as far as I can tell. All I did was move
export_all()fromzfs-lib.sh.inbefore deleting that file and put it inzfs-functionsand renamed it toexport_pools(). Other than that, I didn't touch the function! So please investigate this further if you can.
Now, regarding the refactoring… I get what you're saying, and that is the intention from @behlendorf as well. I could care less one way or the other really, although I'm slightly more in favor of keeping it. The code is in ZoL now and isn't "in the way" and keeping it with the other scripts and files with the same functionality seems more sane to me. Easier to maintain as well...
But so far no-one have stepped up and actually started pushing this. And if they do, I REALLY hope they'll reject it! Because the code, as it is today in the ZoL repo is pure and utter crap! it lacks a lot of functionality, the functionality it DO have is … "error prone". Last commit also removed very vital functionality for unknown reason. Granted, I obviously introduced a few minor issues as well, but the PR haven't been accepted yet, so it's still allowed :). It's at least a much better base to continue building on than what's there now, my bugs not withstanding ...
Whoever decides to do this push to Dracut upstream seriously needs to take a long, hard look at the code and do something about it. I did the most obvious and fastest - I removed all 'crap' and replaced it with code that have been throughly battle tested for years. I didn't go all the way, it was more a "proof of concept". Building on that should be simple.
I do understand that 'we' won't be able to push zfs-functions "as-is" to Dracut (and I'm not suggesting we do), but extracting the relevant parts from zfs-functions and put it in a (temporary) zfs-lib.sh for push to upstream is not a big deal. Then keeping the important content of those two files (zfs-functions here, in ZoL, and zfs-zfs-lib.sh in Dracut upstream) synced should be fairly simple.
And if the idea of 'ripping' the code from zfs-functions, put it in a upstream zfs-lib.sh is such a hassle, anyone is free to reinvent the wheel, I'm sure as heck is not going to stop them! The code exists, it's been battle tested and works… Why not take advantage of that??
I'm seeing lots of fallout since @FransUrbo's recent changes to the dracut scripts with 5aa94f1:
dracut_install grepcommand is missing in module-setup.sh so the script just fails on boot (did anyone, um, test this before release?)recursive_mount_filesystemsandmount_fsso that a mountpoint can be specified as an argument, which would be /sysroot in this case.As a general thought, having a library with common functions for initramfs and dracut scripts is a nice idea but in the long run, the dracut scripts should be submitted upstream and I doubt the dracut folks will be happy with a library in /etc, they will likely want everything in /usr/lib/dracut/modules, and also we'll have difficulty keeping the library in sync between initrams and dracut once this gets upstreamed. (Apologies if this sounds negative, just my 2 cents worth.)