Dracut 014 moved dracut modules directory #546

Closed
ryao opened this Issue Feb 1, 2012 · 55 comments

Comments

Projects
None yet
6 participants
@ryao
Member

ryao commented Feb 1, 2012

I am the Gentoo maintainer for ZFSOnLinux. One of our users reported that the current GIT code is putting the modules in the wrong place:

https://bugs.gentoo.org/show_bug.cgi?id=401709

Apparently, dracut-014 moved /usr/share/dracut/modules.d to /usr/lib/dracut/modules.d.

Changing the ZFSOnLinux GIT to use the new directory would address this, but Amadeusz Żołnowski (the Gentoo dracut maintainer) and I are both of the opinion that these should be sent upstream. We would like to move these modules into Gentoo's dracut package once dracut upstream has accepted them.

How does ZFSOnLinux upstream feel about this?

@pendor

This comment has been minimized.

Show comment Hide comment
@pendor

pendor Feb 1, 2012

Member

Issue #245 is also open on the topic of pushing Dracut module to upstream. Current feelings seem to be that's a big premature for the status of ZoL.

In the mean time, I could add something to the build to try to either detect the version of Dracut installed or else check the two known locations and put module into the currently existing directory? Not sure what the build would do in that case if Dracut isn't installed. Maybe it's more appropriate to not install the module at all if the system doesn't have Dracut?

Member

pendor commented Feb 1, 2012

Issue #245 is also open on the topic of pushing Dracut module to upstream. Current feelings seem to be that's a big premature for the status of ZoL.

In the mean time, I could add something to the build to try to either detect the version of Dracut installed or else check the two known locations and put module into the currently existing directory? Not sure what the build would do in that case if Dracut isn't installed. Maybe it's more appropriate to not install the module at all if the system doesn't have Dracut?

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Feb 1, 2012

Member

One way to handle this would be to make the new directory location the default while providing a build flag to permit it to be overridden until the module is sent upstream.

With that said, it would rather helpful to downstream if the dracut module was developed independently of the zfs kernel modules and userland tools. The change made by dracut upstream could be a good opportunity to do this, provided that people are willing to split the dracut module into a separate tree.

Member

ryao commented Feb 1, 2012

One way to handle this would be to make the new directory location the default while providing a build flag to permit it to be overridden until the module is sent upstream.

With that said, it would rather helpful to downstream if the dracut module was developed independently of the zfs kernel modules and userland tools. The change made by dracut upstream could be a good opportunity to do this, provided that people are willing to split the dracut module into a separate tree.

pendor added a commit to pendor/zfs that referenced this issue Feb 5, 2012

Add autoconf detection to find Dracut modules.d directory (different …
…versions of Dracut place it differently).

Add --with-dracutdir parameter to override detection.
Don't install Dracut modules if Dracut isn't installed on host.
Fixes #546
@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Feb 7, 2012

Owner

I think we should make the dracut install directory and support configurable. Pendor's got a good start on a patch which I just added some comments too. This provides us a lot of flexibility going forward and it should meet the needs of all the downstream maintainers.

As for pushing these changes upstream to the core dracut package I think that's still a little premature. However, I absolutely think that's the right way to go long term. What we need to make that happen is someone who's very familiar with dracut getting our changes in good shape and then working with the dracut developers to get them included. Personally, I'm too distracted with other aspects of the code right now to take this on. But I'm willing to work with anyone who wants to shepard this process.

Owner

behlendorf commented Feb 7, 2012

I think we should make the dracut install directory and support configurable. Pendor's got a good start on a patch which I just added some comments too. This provides us a lot of flexibility going forward and it should meet the needs of all the downstream maintainers.

As for pushing these changes upstream to the core dracut package I think that's still a little premature. However, I absolutely think that's the right way to go long term. What we need to make that happen is someone who's very familiar with dracut getting our changes in good shape and then working with the dracut developers to get them included. Personally, I'm too distracted with other aspects of the code right now to take this on. But I'm willing to work with anyone who wants to shepard this process.

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Feb 7, 2012

Member

As much as I would like to help the ZFSOnLinux project improve the ZFS dracut modules as the downstream maintainer for the kernel modules, Gentoo has its own solution called genkernel, which is my primary focus. Gentoo's dracut maintainer, Amadeusz Żołnowski, expressed interest to me in backporting ZFS support to Gentoo's older dracut ebuilds if this went upstream, but the current bundling situation prevents Amadeusz from touching them.

My downstream work has led many veteran Gentoo users to consider migrations from ext4 to ZFS, with a few already migrating. Some of them will likely try to assist downstream with dracut, The current situation will mean that they work with me, rather than Amadeusz. Unbundling the modules would put Amadeusz in a position to work with these users, which would be ideal as far as downstream's ability to assist is concerned.

Brian, I strongly recommend that these modules be split into a separate tree.

Member

ryao commented Feb 7, 2012

As much as I would like to help the ZFSOnLinux project improve the ZFS dracut modules as the downstream maintainer for the kernel modules, Gentoo has its own solution called genkernel, which is my primary focus. Gentoo's dracut maintainer, Amadeusz Żołnowski, expressed interest to me in backporting ZFS support to Gentoo's older dracut ebuilds if this went upstream, but the current bundling situation prevents Amadeusz from touching them.

My downstream work has led many veteran Gentoo users to consider migrations from ext4 to ZFS, with a few already migrating. Some of them will likely try to assist downstream with dracut, The current situation will mean that they work with me, rather than Amadeusz. Unbundling the modules would put Amadeusz in a position to work with these users, which would be ideal as far as downstream's ability to assist is concerned.

Brian, I strongly recommend that these modules be split into a separate tree.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Feb 8, 2012

Owner

@gentoofan Alright, so how about this. Let's create a zfsonlinux/zfs-dracut repository for this work as you suggest. Then someone can take the existing /dracut tree from the zfs repository and move it to the new repo. It will need a basic build system but that should be pretty trivial since it's largely just a bunch of scripts. Once everything with the new zfs-dracut repository is in order we can remove the existing dracut support from the zfs tree.

If someone (or several people) are willing to own this effort I'm happy to give them commit access to the zfsonlinux/zfs-dracut repository.

Owner

behlendorf commented Feb 8, 2012

@gentoofan Alright, so how about this. Let's create a zfsonlinux/zfs-dracut repository for this work as you suggest. Then someone can take the existing /dracut tree from the zfs repository and move it to the new repo. It will need a basic build system but that should be pretty trivial since it's largely just a bunch of scripts. Once everything with the new zfs-dracut repository is in order we can remove the existing dracut support from the zfs tree.

If someone (or several people) are willing to own this effort I'm happy to give them commit access to the zfsonlinux/zfs-dracut repository.

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Feb 8, 2012

Member

@behlendorf, if I have commit access to zfsonlinux/zfs-dracut, my time should permit me to do the initial split next week.

I am willing to fix any regressions that I introduce in the process of doing this, but given my focus on genkernel, it would be more appropriate for others to do the follow-up work necessary to prepare zfsonlinux/zfs-dracut for upstream.

Member

ryao commented Feb 8, 2012

@behlendorf, if I have commit access to zfsonlinux/zfs-dracut, my time should permit me to do the initial split next week.

I am willing to fix any regressions that I introduce in the process of doing this, but given my focus on genkernel, it would be more appropriate for others to do the follow-up work necessary to prepare zfsonlinux/zfs-dracut for upstream.

@pendor

This comment has been minimized.

Show comment Hide comment
@pendor

pendor Feb 9, 2012

Member

(Replying to comment on #561, makes more sense here I think.)

I'm not sure I'm prepared to characterize my efforts with Grub upstream as successful, but I'm willing to give it a go with the Dracut folks. Need to do a bit of debugging on Dracut 014 to figure out why it can't chroot into ZFS successfully. Up to 013 works.

Looks like Dracut is using Git on kernel.org at the moment. Do you think it would make sense to fork that here for now or try to maintain just the ZFS module separately somehow? I'm not sure what form it would be most useful to them outside of a patchset that can drop onto their current tree.

If @gentoofan has time as well, my current main focus is to get a usable Gentoo system by way of Portage overlay patches. I'm definitely willing to try to contribute upstream, but I'll feel better once I can bootstrap a Gentoo system successfully and at least have a reasonable test bed to develop patches on.

Member

pendor commented Feb 9, 2012

(Replying to comment on #561, makes more sense here I think.)

I'm not sure I'm prepared to characterize my efforts with Grub upstream as successful, but I'm willing to give it a go with the Dracut folks. Need to do a bit of debugging on Dracut 014 to figure out why it can't chroot into ZFS successfully. Up to 013 works.

Looks like Dracut is using Git on kernel.org at the moment. Do you think it would make sense to fork that here for now or try to maintain just the ZFS module separately somehow? I'm not sure what form it would be most useful to them outside of a patchset that can drop onto their current tree.

If @gentoofan has time as well, my current main focus is to get a usable Gentoo system by way of Portage overlay patches. I'm definitely willing to try to contribute upstream, but I'll feel better once I can bootstrap a Gentoo system successfully and at least have a reasonable test bed to develop patches on.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Feb 9, 2012

Owner

Starting with the upstream dracut sources from kernel.org does seem like the right place to start. Normally, I'd just fork the github mirror of the dracut sources, but it looks like these isn't one. So if we're agreed I'll just create a new zfsonlinux/dracut repository tomorrow and initially populate it with the latest source from http://git.kernel.org/?p=boot/dracut/dracut.git . I'll set both of you up with commit access and you can take it from there.

Owner

behlendorf commented Feb 9, 2012

Starting with the upstream dracut sources from kernel.org does seem like the right place to start. Normally, I'd just fork the github mirror of the dracut sources, but it looks like these isn't one. So if we're agreed I'll just create a new zfsonlinux/dracut repository tomorrow and initially populate it with the latest source from http://git.kernel.org/?p=boot/dracut/dracut.git . I'll set both of you up with commit access and you can take it from there.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Feb 9, 2012

Owner

Done, there's now a https://github.com/zfsonlinux/dracut repository and you both should have commit access.

Owner

behlendorf commented Feb 9, 2012

Done, there's now a https://github.com/zfsonlinux/dracut repository and you both should have commit access.

@pendor

This comment has been minimized.

Show comment Hide comment
@pendor

pendor Feb 13, 2012

Member

Github is only showing me the read-only link for that repo? Not sure if I've done something wrong to get commit on it.

In any event, I forked for now & applied the changes. The Dracut build isn't autoconf based, so it was pretty simple to add. Ended up having to hardcode the paths to /etc & /lib/udev, but Dracut itself does that everywhere, so I'm guessing that's considered acceptable. Also had to patch Dracut to deal with https://bugzilla.redhat.com/show_bug.cgi?id=738494. That patch allows 014, 015, and trunk to all work on my systems (without the patch, 013 was the last that worked).

End result is bootable on my Gentoo test systems using my genkernel/dracut branch.

Do you want to pull my fork over or should I just try committing it & see what happens? I ended up doing a pull/rebase against latest upstream as well, not that any of the changes were significant for this.

Member

pendor commented Feb 13, 2012

Github is only showing me the read-only link for that repo? Not sure if I've done something wrong to get commit on it.

In any event, I forked for now & applied the changes. The Dracut build isn't autoconf based, so it was pretty simple to add. Ended up having to hardcode the paths to /etc & /lib/udev, but Dracut itself does that everywhere, so I'm guessing that's considered acceptable. Also had to patch Dracut to deal with https://bugzilla.redhat.com/show_bug.cgi?id=738494. That patch allows 014, 015, and trunk to all work on my systems (without the patch, 013 was the last that worked).

End result is bootable on my Gentoo test systems using my genkernel/dracut branch.

Do you want to pull my fork over or should I just try committing it & see what happens? I ended up doing a pull/rebase against latest upstream as well, not that any of the changes were significant for this.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Feb 14, 2012

Owner

@pendor Try again, it looks like I forgot to add the Dracut team to the zfsonlinux/dracut repository. By the way you and gentoofan are on the Dracut team now. Go ahead and pull the zfsonlinux/dracut repository forward to the latest, you probably want to keep your changes on a branch until they get merged upstream.

Owner

behlendorf commented Feb 14, 2012

@pendor Try again, it looks like I forgot to add the Dracut team to the zfsonlinux/dracut repository. By the way you and gentoofan are on the Dracut team now. Go ahead and pull the zfsonlinux/dracut repository forward to the latest, you probably want to keep your changes on a branch until they get merged upstream.

@pendor

This comment has been minimized.

Show comment Hide comment
@pendor

pendor Feb 14, 2012

Member

That did it! master updated to latest from upstream, branch zfs created & two patches applied. I'm going to test this a bit more & will forward it on to the Dracut mailing lists.

Member

pendor commented Feb 14, 2012

That did it! master updated to latest from upstream, branch zfs created & two patches applied. I'm going to test this a bit more & will forward it on to the Dracut mailing lists.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Feb 14, 2012

Owner

@pendor Great, I'll try and take a look at this.

@dajhorn You'll probably want to look at this took and verify it's in a form you can live with for Ubuntu / Debian.

Owner

behlendorf commented Feb 14, 2012

@pendor Great, I'll try and take a look at this.

@dajhorn You'll probably want to look at this took and verify it's in a form you can live with for Ubuntu / Debian.

@dajhorn

This comment has been minimized.

Show comment Hide comment
@dajhorn

dajhorn Feb 15, 2012

Member

@behlendorf: I should have time to try it later this week.

It looks like Ubuntu 12.04 will ship with dracut-013 in universe. Earlier Debian and Ubuntu releases are still stuck near dracut-004.

Member

dajhorn commented Feb 15, 2012

@behlendorf: I should have time to try it later this week.

It looks like Ubuntu 12.04 will ship with dracut-013 in universe. Earlier Debian and Ubuntu releases are still stuck near dracut-004.

@dajhorn

This comment has been minimized.

Show comment Hide comment
@dajhorn

dajhorn Feb 20, 2012

Member

The Ubuntu dailies were broken for ZFS on Friday and Sunday. I will try again before the beta.

Member

dajhorn commented Feb 20, 2012

The Ubuntu dailies were broken for ZFS on Friday and Sunday. I will try again before the beta.

@dajhorn

This comment has been minimized.

Show comment Hide comment
@dajhorn

dajhorn Feb 20, 2012

Member

I did a quickie backport after trying the latest 12.04 build. The new dracut branch will need patching for dracut-013 on deb systems.

Dracut seems to correctly invoke the 90zfs rules, but the zfsutils are not put into the initrd. Handling /etc/hostid as a text file also seems like a regression because it is a binary file on all of the systems that I regularly test. Dunno yet whether things like the different zlib_inflate matter.

Debian let the dracut package go stale and unloved, and it still isn't current in the latest Ubuntu alpha release, so I would focus on the distributions where it is a first class component.

Member

dajhorn commented Feb 20, 2012

I did a quickie backport after trying the latest 12.04 build. The new dracut branch will need patching for dracut-013 on deb systems.

Dracut seems to correctly invoke the 90zfs rules, but the zfsutils are not put into the initrd. Handling /etc/hostid as a text file also seems like a regression because it is a binary file on all of the systems that I regularly test. Dunno yet whether things like the different zlib_inflate matter.

Debian let the dracut package go stale and unloved, and it still isn't current in the latest Ubuntu alpha release, so I would focus on the distributions where it is a first class component.

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Feb 20, 2012

Member

@dajhorn, what do you mean by a first class component?

Most distributions don't want their users to touch these components. Gentoo is an exception, but Gentoo currently promotes its native solution that handles both the initramfs and kernel, so few Gentoo users use Dracut. However, Dracut is rather well maintained and promoted by its Gentoo maintainer.

@pendor, my attention is focused on bug #441, so I do not expect to help with this for another week.

Member

ryao commented Feb 20, 2012

@dajhorn, what do you mean by a first class component?

Most distributions don't want their users to touch these components. Gentoo is an exception, but Gentoo currently promotes its native solution that handles both the initramfs and kernel, so few Gentoo users use Dracut. However, Dracut is rather well maintained and promoted by its Gentoo maintainer.

@pendor, my attention is focused on bug #441, so I do not expect to help with this for another week.

@dajhorn

This comment has been minimized.

Show comment Hide comment
@dajhorn

dajhorn Feb 20, 2012

Member

@gentoofan:

Brian asked for my input in the sixteenth post of this thread, so I tried it on Ubuntu.

The ZoL module is incompatible, but dracut is not in the main section, which means that distro doesn't care a whole lot about it, and that it won't get updates or regression testing between stable releases. Plus, the update history over the past few years is short and I can't find an active PPA to use an an indirect dependency.

Thus, dracut is not a first class component on Ubuntu, and deb integration shouldn't be an immediate concern for code review.

Member

dajhorn commented Feb 20, 2012

@gentoofan:

Brian asked for my input in the sixteenth post of this thread, so I tried it on Ubuntu.

The ZoL module is incompatible, but dracut is not in the main section, which means that distro doesn't care a whole lot about it, and that it won't get updates or regression testing between stable releases. Plus, the update history over the past few years is short and I can't find an active PPA to use an an indirect dependency.

Thus, dracut is not a first class component on Ubuntu, and deb integration shouldn't be an immediate concern for code review.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 23, 2012

Contributor

How is this going? I just submitted a pull request with changes to dracut merged to the main zfs repository. I could conceivably resubmit here, if this is any good.

Contributor

Rudd-O commented Jul 23, 2012

How is this going? I just submitted a pull request with changes to dracut merged to the main zfs repository. I could conceivably resubmit here, if this is any good.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Jul 24, 2012

Owner

This sort of stalled out. We do have an open related pull request which largely overlaps with your dracut improvements. We'll need to reconcile exactly which version to land.

#561

Owner

behlendorf commented Jul 24, 2012

This sort of stalled out. We do have an open related pull request which largely overlaps with your dracut improvements. We'll need to reconcile exactly which version to land.

#561

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 25, 2012

Member

I tried working on this a few months ago, but I ran into an issue where git reported that it could not parse an object. My knowledge of git at the time did not permit me to resolve it and I moved on to do other things. Consequently, this fell off my to do list.

I have updated zfsonlinux/dracut to use the latest code from upstream. I have also cherry-picked @pendor's work into an ryao branch off master. Now it needs testing. Afterward, assuming it works, we can then talk to upstream about merging it.

@Rudd-O, dracut is a low priority for me. If you worked on this, you would likely finish it before I do.

Member

ryao commented Jul 25, 2012

I tried working on this a few months ago, but I ran into an issue where git reported that it could not parse an object. My knowledge of git at the time did not permit me to resolve it and I moved on to do other things. Consequently, this fell off my to do list.

I have updated zfsonlinux/dracut to use the latest code from upstream. I have also cherry-picked @pendor's work into an ryao branch off master. Now it needs testing. Afterward, assuming it works, we can then talk to upstream about merging it.

@Rudd-O, dracut is a low priority for me. If you worked on this, you would likely finish it before I do.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 25, 2012

Contributor

It's up to you. You can always git revert the specific commit on my pull.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Brian Behlendorf reply@reply.github.com wrote:

This sort of stalled out. We do have an open related pull request which largely overlaps with your dracut improvements. We'll need to reconcile exactly which version to land.

#561


Reply to this email directly or view it on GitHub:
#546 (comment)

Contributor

Rudd-O commented Jul 25, 2012

It's up to you. You can always git revert the specific commit on my pull.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Brian Behlendorf reply@reply.github.com wrote:

This sort of stalled out. We do have an open related pull request which largely overlaps with your dracut improvements. We'll need to reconcile exactly which version to land.

#561


Reply to this email directly or view it on GitHub:
#546 (comment)

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 25, 2012

Contributor

The way my patch work is it defaults to /usr/lib in configure, and in the specfile, it defaults to /usr/share unless {%fc17} is defined.

The way the other patch works is it detects which directory to use.

Which patch to pick up is strictly not my choice :-)

Contributor

Rudd-O commented Jul 25, 2012

The way my patch work is it defaults to /usr/lib in configure, and in the specfile, it defaults to /usr/share unless {%fc17} is defined.

The way the other patch works is it detects which directory to use.

Which patch to pick up is strictly not my choice :-)

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 25, 2012

Member

The dracut ZFS module should be merged into the upstream dracut repository and then removed from the ZFSOnLinux repository.

Member

ryao commented Jul 25, 2012

The dracut ZFS module should be merged into the upstream dracut repository and then removed from the ZFSOnLinux repository.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 25, 2012

Contributor

I agree, but we need to get this code into the ZFS repo first, and then give it a test.

I strongly believe that the pending pull requests (mine and others') for the dracut ZFS module should be merged into the ZFS repository first, and ASAP. Then, once it's there and people have tested it, should it be submitted to be moved into the upstream dracut repository. Every day we waste not merging this code, is a day that people don't get these important fixes. Already you can't use the packages on Fedora 17, because of the lack of fixes to the code I contributed a while ago (code that is now available).

If you guys don't take this step, and instead punt this to whoever pushes the Dracut code upstrea, the dracut people will simply say "this is untested code, nobody uses it because there is no Linux distribution that will execute this code", and then reject it. Justifiably so. Ensuring, of course, that the Dracut support for ZFS never gets to the end user.

If anyone removed the Dracut code from this repo or refused to add fixes to the existing code, without the code being included in upstream Dracut first, that would be terrible for almost everybody here. If my views count, then I tell you, I'm pretty sure that I would switch to btrfs, shoud that happen.

The code I am pushing here is merely a fix for the code that is already in the ZFS repository. Let's not block a fix to the code in our repo, just because of dissenting opinions on where the code should live, that we have zero control of.

Contributor

Rudd-O commented Jul 25, 2012

I agree, but we need to get this code into the ZFS repo first, and then give it a test.

I strongly believe that the pending pull requests (mine and others') for the dracut ZFS module should be merged into the ZFS repository first, and ASAP. Then, once it's there and people have tested it, should it be submitted to be moved into the upstream dracut repository. Every day we waste not merging this code, is a day that people don't get these important fixes. Already you can't use the packages on Fedora 17, because of the lack of fixes to the code I contributed a while ago (code that is now available).

If you guys don't take this step, and instead punt this to whoever pushes the Dracut code upstrea, the dracut people will simply say "this is untested code, nobody uses it because there is no Linux distribution that will execute this code", and then reject it. Justifiably so. Ensuring, of course, that the Dracut support for ZFS never gets to the end user.

If anyone removed the Dracut code from this repo or refused to add fixes to the existing code, without the code being included in upstream Dracut first, that would be terrible for almost everybody here. If my views count, then I tell you, I'm pretty sure that I would switch to btrfs, shoud that happen.

The code I am pushing here is merely a fix for the code that is already in the ZFS repository. Let's not block a fix to the code in our repo, just because of dissenting opinions on where the code should live, that we have zero control of.

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 26, 2012

Member

@Rudd-O The ZFS dracut module belongs in dracut. Having the dracut module bundled in ZFSOnLinux is a maintenance headache for downstream ZFS maintainers. The Gentoo dracut maintainer has already agreed to backport ZFS support to all of the older dracut versions available in Gentoo once support is merged upstream. If we do update the dracut module in the repository, I will disable it in Gentoo. I expect that my counterparts in other distributions will do the same. It is simply not worth the headache in trying to adapt the package to compensate for changes in dracut.

With that said, the proper path is to do a checkout of the latest dracut code and adapt these patches to apply to it. Once that is tested, we can get it merged upstream. The dracut developers believe that their initramfs generator is the future. Until Fedora started using dracut, no distribution used it. I highly doubt that they will not reject a ZFS module on the basis that no distribution ships it.

Member

ryao commented Jul 26, 2012

@Rudd-O The ZFS dracut module belongs in dracut. Having the dracut module bundled in ZFSOnLinux is a maintenance headache for downstream ZFS maintainers. The Gentoo dracut maintainer has already agreed to backport ZFS support to all of the older dracut versions available in Gentoo once support is merged upstream. If we do update the dracut module in the repository, I will disable it in Gentoo. I expect that my counterparts in other distributions will do the same. It is simply not worth the headache in trying to adapt the package to compensate for changes in dracut.

With that said, the proper path is to do a checkout of the latest dracut code and adapt these patches to apply to it. Once that is tested, we can get it merged upstream. The dracut developers believe that their initramfs generator is the future. Until Fedora started using dracut, no distribution used it. I highly doubt that they will not reject a ZFS module on the basis that no distribution ships it.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 26, 2012

Contributor

If you want to port the dracut support in the zfs repo, and integrate my fixes, you are more than welcome to do the work :)

It won't be me, though. I don't particularly care about it. I am content with maintaining my own ZFS tree with the dracut and systemd bits. You can go ahead and fish out the working code if you like.

If this means that your users get broken dracut support in the interim, I will gladly tell them that mr. richard yao was too intransigent to let them have their fix. I will even post a note to that effect on my own branch, complete with links to places where users can politely share their views on your opinions with you.

:D

Sounds cool? Cool :)

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

@Rudd-O The ZFS dracut module belongs in dracut. Having the dracut module bundled in ZFSOnLinux is a maintenance headache for downstream ZFS maintainers. The Gentoo dracut maintainer has already agreed to backport ZFS support to all of the older dracut versions available in Gentoo once support is merged upstream. If we do update the dracut module in the repository, I will pull it from Gentoo. I expect that my counterparts in other distributions will do the same. It is simply not worth the headache in trying to adapt the package to compensate in dracut.

With that said, the proper path is to do a checkout of the latest dracut code and adapt these patches to apply to it. Once that is tested, we can get it merged upstream. The dracut developers believe that their initramfs generator is the future. Until Fedora started using dracut, no distribution used it. I highly doubt that they will not reject a ZFS module on the basis that no distribution ships it.


Reply to this email directly or view it on GitHub:
#546 (comment)

Contributor

Rudd-O commented Jul 26, 2012

If you want to port the dracut support in the zfs repo, and integrate my fixes, you are more than welcome to do the work :)

It won't be me, though. I don't particularly care about it. I am content with maintaining my own ZFS tree with the dracut and systemd bits. You can go ahead and fish out the working code if you like.

If this means that your users get broken dracut support in the interim, I will gladly tell them that mr. richard yao was too intransigent to let them have their fix. I will even post a note to that effect on my own branch, complete with links to places where users can politely share their views on your opinions with you.

:D

Sounds cool? Cool :)

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

@Rudd-O The ZFS dracut module belongs in dracut. Having the dracut module bundled in ZFSOnLinux is a maintenance headache for downstream ZFS maintainers. The Gentoo dracut maintainer has already agreed to backport ZFS support to all of the older dracut versions available in Gentoo once support is merged upstream. If we do update the dracut module in the repository, I will pull it from Gentoo. I expect that my counterparts in other distributions will do the same. It is simply not worth the headache in trying to adapt the package to compensate in dracut.

With that said, the proper path is to do a checkout of the latest dracut code and adapt these patches to apply to it. Once that is tested, we can get it merged upstream. The dracut developers believe that their initramfs generator is the future. Until Fedora started using dracut, no distribution used it. I highly doubt that they will not reject a ZFS module on the basis that no distribution ships it.


Reply to this email directly or view it on GitHub:
#546 (comment)

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 26, 2012

Member

@Rudd-O I had been willing to work with you to push ZFS dracut support upstream, but if you don't care about it, I will have to delay this work until I no longer have anything better to do.

Member

ryao commented Jul 26, 2012

@Rudd-O I had been willing to work with you to push ZFS dracut support upstream, but if you don't care about it, I will have to delay this work until I no longer have anything better to do.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 26, 2012

Contributor

As I said, I don't care. I suspect it will be years until your users will have dracut support working and fixed. Your loss.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

@Rudd-O I had been willing to work with you to push ZFS dracut support upstream, but if you don't care about it, I will have to delay this work until I no longer have anything better to do.


Reply to this email directly or view it on GitHub:
#546 (comment)

Contributor

Rudd-O commented Jul 26, 2012

As I said, I don't care. I suspect it will be years until your users will have dracut support working and fixed. Your loss.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

@Rudd-O I had been willing to work with you to push ZFS dracut support upstream, but if you don't care about it, I will have to delay this work until I no longer have anything better to do.


Reply to this email directly or view it on GitHub:
#546 (comment)

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 26, 2012

Member

@Rudd-O Gentoo Linux and its derivatives use software called genkernel. Debian Linux and its derivatives use software called initramfs-tools. The only distributions that actually need dracut support are RedHat derived distributions and they are free to obtain it from third party repositories like users of Debian Linux derivatives do. This does not change that.

I have no authority to decide what is committed to the main ZFSOnLinux repository. However, supporting it would cause a degree of pain for both myself and the Gentoo dracut maintainer. I imagine that the same would be true for @dajhorn, who is my Debian/Ubuntu counterpart. @behlendorf is free to commit updated dracut support. However, it is unlikley to obtain even semi-official status in any major distribution unless you can convince either myself or @dajhorn to ship it. That ignores the fact that the portion of our userbases that use dracut is miniscule.

Amadeusz Żołnowski is the Gentoo dracut maintainer. He and I concluded that the ZFS dracut module should be included with dracut itself. Amadeusz graciously offered to backport support to older dracut versions once the ZFS dracut module is merged upstream. It is my intention to work toward that. I offered to work with you to accelerate this process and you refused.

Member

ryao commented Jul 26, 2012

@Rudd-O Gentoo Linux and its derivatives use software called genkernel. Debian Linux and its derivatives use software called initramfs-tools. The only distributions that actually need dracut support are RedHat derived distributions and they are free to obtain it from third party repositories like users of Debian Linux derivatives do. This does not change that.

I have no authority to decide what is committed to the main ZFSOnLinux repository. However, supporting it would cause a degree of pain for both myself and the Gentoo dracut maintainer. I imagine that the same would be true for @dajhorn, who is my Debian/Ubuntu counterpart. @behlendorf is free to commit updated dracut support. However, it is unlikley to obtain even semi-official status in any major distribution unless you can convince either myself or @dajhorn to ship it. That ignores the fact that the portion of our userbases that use dracut is miniscule.

Amadeusz Żołnowski is the Gentoo dracut maintainer. He and I concluded that the ZFS dracut module should be included with dracut itself. Amadeusz graciously offered to backport support to older dracut versions once the ZFS dracut module is merged upstream. It is my intention to work toward that. I offered to work with you to accelerate this process and you refused.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 26, 2012

Contributor

What "pain" are you talking about? If you don't use dracut, just don't install it. Ignore the files. Pretend they aren't there. Problem SOLVED.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

@Rudd-O Gentoo Linux and its derivatives use software called genkernel. Debian Linux and its derivatives use software called initramfs-tools. The only distributions that actually need dracut support are RedHat derived distributions and they are free to obtain it from third party repositories like users of Debian Linux derivatives do. This does not change that.

I have no authority to decide what is committed to the main ZFSOnLinux repository. However, supporting it would cause a degree of pain for both myself and the Gentoo dracut maintainer. I imagine that the same would be true for @dajhorn, who is my Debian/Ubuntu counterpart. @behlendorf is free to commit updated dracut support. However, it is unlikley to obtain even semi-official status in any major distribution unless you can convince either myself or @dajhorn to ship it. That ignores the fact that a the portion of our userbases that use dracut is miniscule.

Amadeusz Żołnowski is the Gentoo dracut maintainer. He and I concluded that the ZFS dracut module should be included with dracut itself. Amadeusz graciously offered to backport support to older dracut versions once the ZFS dracut module is merged upstream. It is my intention to work toward that. I offered to work with you to accelerate this process and you refused.


Reply to this email directly or view it on GitHub:
#546 (comment)

Contributor

Rudd-O commented Jul 26, 2012

What "pain" are you talking about? If you don't use dracut, just don't install it. Ignore the files. Pretend they aren't there. Problem SOLVED.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

@Rudd-O Gentoo Linux and its derivatives use software called genkernel. Debian Linux and its derivatives use software called initramfs-tools. The only distributions that actually need dracut support are RedHat derived distributions and they are free to obtain it from third party repositories like users of Debian Linux derivatives do. This does not change that.

I have no authority to decide what is committed to the main ZFSOnLinux repository. However, supporting it would cause a degree of pain for both myself and the Gentoo dracut maintainer. I imagine that the same would be true for @dajhorn, who is my Debian/Ubuntu counterpart. @behlendorf is free to commit updated dracut support. However, it is unlikley to obtain even semi-official status in any major distribution unless you can convince either myself or @dajhorn to ship it. That ignores the fact that a the portion of our userbases that use dracut is miniscule.

Amadeusz Żołnowski is the Gentoo dracut maintainer. He and I concluded that the ZFS dracut module should be included with dracut itself. Amadeusz graciously offered to backport support to older dracut versions once the ZFS dracut module is merged upstream. It is my intention to work toward that. I offered to work with you to accelerate this process and you refused.


Reply to this email directly or view it on GitHub:
#546 (comment)

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 26, 2012

Member

MrMEEE/bumblebee-Old-and-abbandoned@a047be8 was caused by this kind of thinking. Installing the files without proper QA probably won't delete /usr (I hope), but ZFS support should be something that solves problems and not something that introduces them.

There are several people who will receive bug reports whenever a new dracut release causes things to break and they will also receive additional bug reports when the fixes for those things cause older releases to break. Users do not like it when their systems fail to boot. The users will consider them responsible and they will consider me responsible. On top of that, I will need to produce a fix that they will need to go through the trouble of distributing each time.

I have spent a great deal of time talking to developers of Gentoo derivatives about tighter ZFS integration on the basis that it solves problems. Packaging ZFS support in a way that is prone to break jeopardizes that. An updated ZFS dracut module will enter Gentoo through the dracut package, not the ZFS package. It will either enter Gentoo this way or not at all.

Member

ryao commented Jul 26, 2012

MrMEEE/bumblebee-Old-and-abbandoned@a047be8 was caused by this kind of thinking. Installing the files without proper QA probably won't delete /usr (I hope), but ZFS support should be something that solves problems and not something that introduces them.

There are several people who will receive bug reports whenever a new dracut release causes things to break and they will also receive additional bug reports when the fixes for those things cause older releases to break. Users do not like it when their systems fail to boot. The users will consider them responsible and they will consider me responsible. On top of that, I will need to produce a fix that they will need to go through the trouble of distributing each time.

I have spent a great deal of time talking to developers of Gentoo derivatives about tighter ZFS integration on the basis that it solves problems. Packaging ZFS support in a way that is prone to break jeopardizes that. An updated ZFS dracut module will enter Gentoo through the dracut package, not the ZFS package. It will either enter Gentoo this way or not at all.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 26, 2012

Contributor

Your comparison between me supporting dracut in the ZFS repo with the bumblebee rm -rf incident is both baseless and insulting to say the least.

Close this issue if you want -- I have already repeatedly told you that I don't care what you do, and I have no interest whatsoever. And I know for sure I don't want to waste a single second of my time talking to you anymore.

Contributor

Rudd-O commented Jul 26, 2012

Your comparison between me supporting dracut in the ZFS repo with the bumblebee rm -rf incident is both baseless and insulting to say the least.

Close this issue if you want -- I have already repeatedly told you that I don't care what you do, and I have no interest whatsoever. And I know for sure I don't want to waste a single second of my time talking to you anymore.

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 26, 2012

Member

@Rudd-O The commit I linked demonstrates that making changes to something without proper QA can have consequences that are impossible to predict in advance.

Furthermore, you threatened to incite harassment toward me in an attempt to coercise me to use my commit privileges to make changes to Gentoo that I do not believe should be made:

If you want to port the dracut support in the zfs repo, and integrate my fixes, you are more than welcome to do the work :)

It won't be me, though. I don't particularly care about it. I am content with maintaining my own ZFS tree with the dracut and systemd bits. You can go ahead and fish out the working code if you like.

If this means that your users get broken dracut support in the interim, I will gladly tell them that mr. richard yao was too intransigent to let them have their fix. I will even post a note to that effect on my own branch, complete with links to places where users can politely share their views on your opinions with you.

:D

Sounds cool? Cool :)

I have answered your questions solely to explain my position to the Fedora users you stated that you would incite against me. I find it quite incredulous that you only appear to believe that you wasted your time in doing this.

This issue will remain open until it is fixed. Please do not flood it with any more spam.

Member

ryao commented Jul 26, 2012

@Rudd-O The commit I linked demonstrates that making changes to something without proper QA can have consequences that are impossible to predict in advance.

Furthermore, you threatened to incite harassment toward me in an attempt to coercise me to use my commit privileges to make changes to Gentoo that I do not believe should be made:

If you want to port the dracut support in the zfs repo, and integrate my fixes, you are more than welcome to do the work :)

It won't be me, though. I don't particularly care about it. I am content with maintaining my own ZFS tree with the dracut and systemd bits. You can go ahead and fish out the working code if you like.

If this means that your users get broken dracut support in the interim, I will gladly tell them that mr. richard yao was too intransigent to let them have their fix. I will even post a note to that effect on my own branch, complete with links to places where users can politely share their views on your opinions with you.

:D

Sounds cool? Cool :)

I have answered your questions solely to explain my position to the Fedora users you stated that you would incite against me. I find it quite incredulous that you only appear to believe that you wasted your time in doing this.

This issue will remain open until it is fixed. Please do not flood it with any more spam.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Jul 27, 2012

Owner

Alright, here's the deal.

I'm of the opinion that the right long term fix is to get proper zfs support added to the upstream dracut packages. It would be wonderful if someone would pursue it, I myself don't really have the time to spend on it.

However, considering how long that sort of thing can take. I'm not opposed to improving the existing zfs-dracut packages. I just ask that these changes be as self contained as possible and easy to disable. I'll find some time to review the proposed patch stack and we'll get in what makes sense.

At the end of the day this is really a distribution specific problem for the various downstream maintainers. Unfortunately, we don't have a Fedora maintainer so quite of bit of that integration logic is still in the upstream tree.

Owner

behlendorf commented Jul 27, 2012

Alright, here's the deal.

I'm of the opinion that the right long term fix is to get proper zfs support added to the upstream dracut packages. It would be wonderful if someone would pursue it, I myself don't really have the time to spend on it.

However, considering how long that sort of thing can take. I'm not opposed to improving the existing zfs-dracut packages. I just ask that these changes be as self contained as possible and easy to disable. I'll find some time to review the proposed patch stack and we'll get in what makes sense.

At the end of the day this is really a distribution specific problem for the various downstream maintainers. Unfortunately, we don't have a Fedora maintainer so quite of bit of that integration logic is still in the upstream tree.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 27, 2012

Contributor

Thanks. I agree with you Brian.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Brian Behlendorf reply@reply.github.com wrote:

Alright, here's the deal.

I'm of the opinion that the right long term fix is to get proper zfs support added to the upstream dracut packages. It would be wonderful if someone would pursue it, I myself don't really have the time to spend on it.

However, considering how long that sort of thing can take. I'm not opposed to improving the existing zfs-dracut packages. I just ask that these changes be as self contained as possible and easy to disable. I'll find some time to review the proposed patch stack and we'll get in what makes sense.

At the end of the day this is really a distribution specific problem for the various downstream maintainers. Unfortunately, we don't have a Fedora maintainer so quite of bit of that integration logic is still in the upstream tree.


Reply to this email directly or view it on GitHub:
#546 (comment)

Contributor

Rudd-O commented Jul 27, 2012

Thanks. I agree with you Brian.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Brian Behlendorf reply@reply.github.com wrote:

Alright, here's the deal.

I'm of the opinion that the right long term fix is to get proper zfs support added to the upstream dracut packages. It would be wonderful if someone would pursue it, I myself don't really have the time to spend on it.

However, considering how long that sort of thing can take. I'm not opposed to improving the existing zfs-dracut packages. I just ask that these changes be as self contained as possible and easy to disable. I'll find some time to review the proposed patch stack and we'll get in what makes sense.

At the end of the day this is really a distribution specific problem for the various downstream maintainers. Unfortunately, we don't have a Fedora maintainer so quite of bit of that integration logic is still in the upstream tree.


Reply to this email directly or view it on GitHub:
#546 (comment)

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 28, 2012

Member

The ryao branch of zfsonlinux/dracut now has working ZFS support based on the work of @pendor and @Rudd-O. At the time of this writing, it is in sync with upstream:

https://git.kernel.org/?p=boot/dracut/dracut.git;a=summary

It includes a fix for a regression caused by recent a commit to dracut HEAD. The fix was trivial and I sent the lead dracut developer a message about it. I am waiting for his response.

With that said, this needs more testing. Then we can do a pull request with upstream. Several commits by another Gentoo developer were accepted into dracut a few days ago, so I anticipate no issue getting this merged.

Member

ryao commented Jul 28, 2012

The ryao branch of zfsonlinux/dracut now has working ZFS support based on the work of @pendor and @Rudd-O. At the time of this writing, it is in sync with upstream:

https://git.kernel.org/?p=boot/dracut/dracut.git;a=summary

It includes a fix for a regression caused by recent a commit to dracut HEAD. The fix was trivial and I sent the lead dracut developer a message about it. I am waiting for his response.

With that said, this needs more testing. Then we can do a pull request with upstream. Several commits by another Gentoo developer were accepted into dracut a few days ago, so I anticipate no issue getting this merged.

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 28, 2012

Member

@behlendorf How long do you expect this process to take?

Member

ryao commented Jul 28, 2012

@behlendorf How long do you expect this process to take?

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 28, 2012

Contributor

If you can drive this upstream, I have no problem continuing any dracut
work in this fashion. I will fork from your branch later in case there
needs to be any extra work.

On Fri, 2012-07-27 at 18:20 -0700, Richard Yao wrote:

The ryao branch of zfsonlinux/dracut now has working ZFS support based on the work of @pendor and @Rudd-O. At the time of this writing, it is in sync with upstream:

https://git.kernel.org/?p=boot/dracut/dracut.git;a=summary

I encountered an issue with a commit to dracut HEAD that occurred earlier today. The fix was trivial and I sent the lead dracut developer a message in IRC about it. I am waiting for his response.

With that said, this needs more testing. Then we can do a pull request with upstream. Several commits by another Gentoo developer were accepted into dracut a few days ago, so I anticipate no issue getting this merged.


Reply to this email directly or view it on GitHub:
#546 (comment)

Contributor

Rudd-O commented Jul 28, 2012

If you can drive this upstream, I have no problem continuing any dracut
work in this fashion. I will fork from your branch later in case there
needs to be any extra work.

On Fri, 2012-07-27 at 18:20 -0700, Richard Yao wrote:

The ryao branch of zfsonlinux/dracut now has working ZFS support based on the work of @pendor and @Rudd-O. At the time of this writing, it is in sync with upstream:

https://git.kernel.org/?p=boot/dracut/dracut.git;a=summary

I encountered an issue with a commit to dracut HEAD that occurred earlier today. The fix was trivial and I sent the lead dracut developer a message in IRC about it. I am waiting for his response.

With that said, this needs more testing. Then we can do a pull request with upstream. Several commits by another Gentoo developer were accepted into dracut a few days ago, so I anticipate no issue getting this merged.


Reply to this email directly or view it on GitHub:
#546 (comment)

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 28, 2012

Member

@Rudd-O The initramfs image that this branch generated was a drop-in replacement for the initramfs image generated by Gentoo's genkernel on my desktop.

I anticipate no problems sending this upstream, but I would prefer you and @pendor to look at the branch before I do. You know dracut far more intimately than I do.

Member

ryao commented Jul 28, 2012

@Rudd-O The initramfs image that this branch generated was a drop-in replacement for the initramfs image generated by Gentoo's genkernel on my desktop.

I anticipate no problems sending this upstream, but I would prefer you and @pendor to look at the branch before I do. You know dracut far more intimately than I do.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 28, 2012

Contributor

Did you snag my latest fixes from the zfs pull request I made a few days ago? It is gone now since I rewrote the pull request to eliminate dracut support from ZFS.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

@Rudd-O There should be no problems sending this upstream. The only thing blocking a pull request is my desire for feedback.


Reply to this email directly or view it on GitHub:
#546 (comment)

Contributor

Rudd-O commented Jul 28, 2012

Did you snag my latest fixes from the zfs pull request I made a few days ago? It is gone now since I rewrote the pull request to eliminate dracut support from ZFS.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

@Rudd-O There should be no problems sending this upstream. The only thing blocking a pull request is my desire for feedback.


Reply to this email directly or view it on GitHub:
#546 (comment)

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 28, 2012

Member

@Rudd-O I did with the exception of README.zfs changes. Not all of the changes to that file made sense in the dracut source tree and I wanted to review them with you before adapting it.

Also, the Gentoo dracut maintainer reviewed the code. He had the following objections to its current state:

  • The headers used in the scripts should match the ones used in other dracut scripts.
  • module-setup.sh should use #!/bin/bash, not #!/bin/sh
  • All local variables should use the local keyword
  • Do not use environment variable names like TMP for local variables. Use something like local _tmpf.
  • Do not use capitalized names in local variables.
  • Underscores before local variable names are recommended.
  • Use shell substitution instead of backticks.
  • basename should be ${somevar##*/}
  • Use [ -n "$var" ] instead [ "$var" != "" ]
  • Use type or command instead of which
  • Use either the basename or full command path consistently.
  • Do not use cut
  • The 98usrmount module should mount /usr.
  • The 95rootfs-block module should mount /.

In addition, ./module-setup.sh uses a hack to regenerate zpool.cache. We should push this functionality into the zpool command so we can simply invoke that. This would also benefit genkernel, initramfs-tools and rootfs on ZFS installs.

Anyway, these issues will need to be resolved before upstream will merge it. So far, I have only addressed a few of them.

Member

ryao commented Jul 28, 2012

@Rudd-O I did with the exception of README.zfs changes. Not all of the changes to that file made sense in the dracut source tree and I wanted to review them with you before adapting it.

Also, the Gentoo dracut maintainer reviewed the code. He had the following objections to its current state:

  • The headers used in the scripts should match the ones used in other dracut scripts.
  • module-setup.sh should use #!/bin/bash, not #!/bin/sh
  • All local variables should use the local keyword
  • Do not use environment variable names like TMP for local variables. Use something like local _tmpf.
  • Do not use capitalized names in local variables.
  • Underscores before local variable names are recommended.
  • Use shell substitution instead of backticks.
  • basename should be ${somevar##*/}
  • Use [ -n "$var" ] instead [ "$var" != "" ]
  • Use type or command instead of which
  • Use either the basename or full command path consistently.
  • Do not use cut
  • The 98usrmount module should mount /usr.
  • The 95rootfs-block module should mount /.

In addition, ./module-setup.sh uses a hack to regenerate zpool.cache. We should push this functionality into the zpool command so we can simply invoke that. This would also benefit genkernel, initramfs-tools and rootfs on ZFS installs.

Anyway, these issues will need to be resolved before upstream will merge it. So far, I have only addressed a few of them.

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 30, 2012

Member

As an additional comment, it looks like we can (ab)use zpool reguid to regenerate the pool's zpool.cache. The only issue is that reguid was only implemented after the most recent tagged release, which could cause problems with existing systems.

Member

ryao commented Jul 30, 2012

As an additional comment, it looks like we can (ab)use zpool reguid to regenerate the pool's zpool.cache. The only issue is that reguid was only implemented after the most recent tagged release, which could cause problems with existing systems.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 30, 2012

Contributor

Code to fall back to zpool create then destroy if reguid returns an error,shoud be simple, rite?

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

As an additional comment, it looks like we can (ab)use zpool reguid to regenerate the pool's zpool.cache. The only issue is that reguid was only implemented after the most recent tagged release, which could cause problems with existing systems.


Reply to this email directly or view it on GitHub:
#546 (comment)

Contributor

Rudd-O commented Jul 30, 2012

Code to fall back to zpool create then destroy if reguid returns an error,shoud be simple, rite?

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Richard Yao reply@reply.github.com wrote:

As an additional comment, it looks like we can (ab)use zpool reguid to regenerate the pool's zpool.cache. The only issue is that reguid was only implemented after the most recent tagged release, which could cause problems with existing systems.


Reply to this email directly or view it on GitHub:
#546 (comment)

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Jul 30, 2012

Owner

Thanks guys, I'm glad we came to agreement about this.

How long do you expect this process to take?

That largely depends on how aggressively it gets pursued. Getting it upstream is one thing. But even after that occurs we'll still need to wait for it to be picked up by the various distributions.

For a distribution like Gentoo I imagine that's quite quickly. For something like Fedora which is still pretty aggressive I wouldn't expect it before FC18 (scheduled for early November). Note that FC17 is currently using dracut-018 plus minor patches and dracut-022 is the latest version in git. It will probably be the better part of a year before it appears in many of the other distributions. And with some luck if we get it in now we'll see it in RHEL7 which is currently in alpha and expected out in over a year.

So if you two can iterate on the dracut repository getting it compliant with upstream and tested that would be great. In the meanwhile I'm happy to merge in reasonable changes to the zfs repository to facilitate this.

Then at some point, hopefully in the fairly near future, we can apply @Rudd-O's patch to drop dracut entirely from the
zfs repository. We'll just need a clear update path in place for those who are currently relying on it.

Owner

behlendorf commented Jul 30, 2012

Thanks guys, I'm glad we came to agreement about this.

How long do you expect this process to take?

That largely depends on how aggressively it gets pursued. Getting it upstream is one thing. But even after that occurs we'll still need to wait for it to be picked up by the various distributions.

For a distribution like Gentoo I imagine that's quite quickly. For something like Fedora which is still pretty aggressive I wouldn't expect it before FC18 (scheduled for early November). Note that FC17 is currently using dracut-018 plus minor patches and dracut-022 is the latest version in git. It will probably be the better part of a year before it appears in many of the other distributions. And with some luck if we get it in now we'll see it in RHEL7 which is currently in alpha and expected out in over a year.

So if you two can iterate on the dracut repository getting it compliant with upstream and tested that would be great. In the meanwhile I'm happy to merge in reasonable changes to the zfs repository to facilitate this.

Then at some point, hopefully in the fairly near future, we can apply @Rudd-O's patch to drop dracut entirely from the
zfs repository. We'll just need a clear update path in place for those who are currently relying on it.

@ryao

This comment has been minimized.

Show comment Hide comment
@ryao

ryao Jul 31, 2012

Member

@Rudd-O Yes.

@behlendorf It might be best to cherry-pick dajhorn/pkg-zfs@ed781b9 when we are ready to remove dracut support from the repository.

Member

ryao commented Jul 31, 2012

@Rudd-O Yes.

@behlendorf It might be best to cherry-pick dajhorn/pkg-zfs@ed781b9 when we are ready to remove dracut support from the repository.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Jul 31, 2012

Owner

@ryao Yes, Rudd-O had a similar commit in his patch stack. I'll certainly drop the dracut bits entirely from the tree once it's all in the dracut packages, and tested.

Owner

behlendorf commented Jul 31, 2012

@ryao Yes, Rudd-O had a similar commit in his patch stack. I'll certainly drop the dracut bits entirely from the tree once it's all in the dracut packages, and tested.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 31, 2012

Contributor

However you prefer. Do you want me to re-engineer my commits such that the elimination of dracut is not available? I am rewriting the systemd support anyway, to take into account the availability of devices during boot time.

Contributor

Rudd-O commented Jul 31, 2012

However you prefer. Do you want me to re-engineer my commits such that the elimination of dracut is not available? I am rewriting the systemd support anyway, to take into account the availability of devices during boot time.

@Rudd-O

This comment has been minimized.

Show comment Hide comment
@Rudd-O

Rudd-O Jul 31, 2012

Contributor

OK. For the dracut code I wrote, it would be okay if you guys changed it by attempting to zpool reguid if possible, or use the (admittedly undesirable) hack if not available.

I will be submitting a patch for ZFS systemd support that causes zfs to write out the known file systems that need to be mounted, storing them in a cache. I need this information to remount the appropriate file systems on boot, since we do not register the file systems in /etc/fstab. It will all be clear once I submit these patches.

Contributor

Rudd-O commented Jul 31, 2012

OK. For the dracut code I wrote, it would be okay if you guys changed it by attempting to zpool reguid if possible, or use the (admittedly undesirable) hack if not available.

I will be submitting a patch for ZFS systemd support that causes zfs to write out the known file systems that need to be mounted, storing them in a cache. I need this information to remount the appropriate file systems on boot, since we do not register the file systems in /etc/fstab. It will all be clear once I submit these patches.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Aug 1, 2012

Owner

However you prefer. Do you want me to re-engineer my commits such that the elimination of dracut is not available? I > am rewriting the systemd support anyway, to take into account the availability of devices during boot time.

I think it would make the most sense to open two pull requests. The first onecan simply drop the dracut bits, although I'd say this is option because I can always just cherry pick one of the existing patches for this. And the second one can now we solely for any of your systemd changes. All the non-systemd specific changes you had in the previous pull request have been merged.

Owner

behlendorf commented Aug 1, 2012

However you prefer. Do you want me to re-engineer my commits such that the elimination of dracut is not available? I > am rewriting the systemd support anyway, to take into account the availability of devices during boot time.

I think it would make the most sense to open two pull requests. The first onecan simply drop the dracut bits, although I'd say this is option because I can always just cherry pick one of the existing patches for this. And the second one can now we solely for any of your systemd changes. All the non-systemd specific changes you had in the previous pull request have been merged.

@ryao ryao referenced this issue Aug 1, 2012

Closed

Preemption Support #674

@maci0

This comment has been minimized.

Show comment Hide comment
@maci0

maci0 Apr 24, 2014

Contributor

RHEL 7 RC uses /usr/lib/dracut/modules.d
zfsonlinux currently installs into /usr/share/dracut/modules.d

this should be addressed. for now i just created a symlink for the 90zfs dir

other than that zfs runs great on RHEL 7

Contributor

maci0 commented Apr 24, 2014

RHEL 7 RC uses /usr/lib/dracut/modules.d
zfsonlinux currently installs into /usr/share/dracut/modules.d

this should be addressed. for now i just created a symlink for the 90zfs dir

other than that zfs runs great on RHEL 7

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Apr 25, 2014

Owner

@maci0 You can specify the install path with the --with-dracutdir configure option. There is a block at the top of the zfs.spec.in file which sets this properly based on the distribution. We'll just need to add RHEL7 to that conditional.

Owner

behlendorf commented Apr 25, 2014

@maci0 You can specify the install path with the --with-dracutdir configure option. There is a block at the top of the zfs.spec.in file which sets this properly based on the distribution. We'll just need to add RHEL7 to that conditional.

@maci0

This comment has been minimized.

Show comment Hide comment
@maci0

maci0 May 6, 2014

Contributor

@behlendorf on rhel7 i tried to use --with-dracutdir...

./autogen.sh
./configure --with-config=user --with-dracutdir=/usr/lib/dracut
make rpm-utils rpm-dkms

but ...

bash-4.2# rpm -qlp zfs-dracut-0.6.2-271_gaa7d06a.el7.x86_64.rpm 
/usr/share/doc/zfs-dracut-0.6.2
/usr/share/doc/zfs-dracut-0.6.2/README.dracut.markdown
/usr/share/dracut/modules.d/90zfs
/usr/share/dracut/modules.d/90zfs/module-setup.sh
/usr/share/dracut/modules.d/90zfs/mount-zfs.sh
/usr/share/dracut/modules.d/90zfs/parse-zfs.sh

this doesnt seem right

Contributor

maci0 commented May 6, 2014

@behlendorf on rhel7 i tried to use --with-dracutdir...

./autogen.sh
./configure --with-config=user --with-dracutdir=/usr/lib/dracut
make rpm-utils rpm-dkms

but ...

bash-4.2# rpm -qlp zfs-dracut-0.6.2-271_gaa7d06a.el7.x86_64.rpm 
/usr/share/doc/zfs-dracut-0.6.2
/usr/share/doc/zfs-dracut-0.6.2/README.dracut.markdown
/usr/share/dracut/modules.d/90zfs
/usr/share/dracut/modules.d/90zfs/module-setup.sh
/usr/share/dracut/modules.d/90zfs/mount-zfs.sh
/usr/share/dracut/modules.d/90zfs/parse-zfs.sh

this doesnt seem right

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf May 7, 2014

Owner

@maci0 I've filed #2310 for this specific RHEL7 packaging issue. Let's sort this out there.

Owner

behlendorf commented May 7, 2014

@maci0 I've filed #2310 for this specific RHEL7 packaging issue. Let's sort this out there.

@behlendorf

This comment has been minimized.

Show comment Hide comment
@behlendorf

behlendorf Oct 6, 2014

Owner

This has been sorted by the #2310 commits.

Owner

behlendorf commented Oct 6, 2014

This has been sorted by the #2310 commits.

@behlendorf behlendorf closed this Oct 6, 2014

@behlendorf behlendorf modified the milestones: 0.6.3, 0.6.7 Oct 6, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment