| Summary: | dracut created initramfs fails to boot (zfs) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kostya Berger <bergerkos> |
| Component: | dracut | Assignee: | dracut-maint-list |
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 23 | CC: | bergerkos, dracut-maint-list, gregory.lee.bartholomew, harald, jonathan, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-08-22 09:15:28 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Kostya Berger
2016-01-19 18:42:41 UTC
Forgot to mention, this may be important: previous version of dracut had this problem caused by /usr/lib/dracut/modules.d/98dracut-systemd/rootfs-generator.sh. That caused the creation of the file /usr/lib/dracut/initqueue/finished/devesists-$(_name).sh in initramfs pointing to the root device (as dracut obviously believed) in /dev/disk/by-uuid/***. While in reality my whole disk zpool is linked to a device name in /dev/disk/by-id. With that version of dracut scripts I dirty fixed it by manually removing the commands creating that file $hookdir/initqueue/finished/devesists-$(_name).sh. from rootfs-generator.sh where functions are defined. Because it caused system to hang on boot: for some reason /dev/disk/by-uuid failed to appear within the 5 min. timeout set for dracut shell to do its job. Separate problem, I know... Now with the present version of dracut this file devexists***sh is NOT created in $hooksdir/initqueue/finished dir. There is only zfs.sh in there... Is this, possibly, the cause of the problem? Does the system refuse to boot because that file is somehow considered essential? /usr/lib/dracut/initqueue/finished/devexists-$(_name).sh is the correct name of the file, sorry. So now dracut drops into shell without even having started mount hooks. What is your kerne command line? What is the output of: # dracut --print-cmdline Actually it's "root=zfs:mypool/ROOT/linux ro systemd.unit=graphical.target" This used to work. dracut does not support zfs natively, so there must be some dracut zfs plugin module. Please talk to the maintainers of this. The output of: # rpm -qf /usr/lib/dracut/modules.d/* | sort -u might help in finding the corresponding rpm. Yes, there is dracut zfs mount hook provided with ZFS On Linux. I'm using it. Already asked this question at zol mailing list, they're eager to have some answers from dracut people... Besides, here systemd also comes into play. And how can I possibly debug systemd issues with dracut? All this talking of "targets" that are "destructive" -- systemd language... Anyways, I can still try git bisect with dracut code. We'll see at least if the problem is indeed with dracut. Or maybe with systemd, which wouldn't surprise me at all Is the zfs kernel module in the initramfs? # lsinitrd | fgrep zfs If not, maybe you just have to recreate the initramfs after you build your custom kernel with: # dracut -f --kver <kernel-version> Please, reread my first post here. Boot hangs until dracut 5 min timeout runs out, then drops into shell. At that point zfs.ko is loaded and all zfs utils are fully functional. With earlier versions (Fedora 21) when having problems of this sort I would just manually import the pool and log out of the emergency shell. Then normal boot would resume and the system start all right. Those were problems were related to my zpool being associated with device string in /dev/disk/by-partuuid,which is not standard with ZFS on Linux. Additional command line options were to be added to mount-zfs.sh dracut mount hook supplied with ZOL package. This time the startup scripts don't have that problem. When dropped into emergency shell the target zpool is manually imported without any difficulties or special custom command line options whatsoever. Just "zpool import $mypool" makes it! But when I log out of emergency shell to let the system resume booting process, it JUST refuses to use that kind of root and says "the target is destructive". This is how I read it. OK, this bug is not due to Fedora|RedHat proveded code. Actually, it's due to ZFS on Linux code, which adds zfs-capable scripts and systemd services. These scripts take it over once the "zfs:*" root is detected, they replace accordingly any needed Fedora dracut code or add what is needed. I have pinpointed what exactly they fail to do. Once the pool imported and mounted (ZOL part job), invoking `systemctl start initrd-switch-root.service` resumes normal boot. So I guess it can be closed here as unrelated to RedHat/Fedora provided dracut code. |