Bug 1072966
| Summary: | Upgrade from 208 to 210 made my system unbootable (now needs CONFIG_FHANDLE) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Zdenek Kabelac <zkabelac> | ||||
| Component: | systemd | Assignee: | systemd-maint | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | johannbg, lnykryn, msekleta, plautrba, systemd-maint, vpavlin, zbyszek | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-06-21 03:51:45 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: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
An error will now be printed (http://cgit.freedesktop.org/systemd/systemd/commit/?id=e6c4747). |
Created attachment 870982 [details] rd sos report Description of problem: I've made upgraded my rawhide from a week old setup to current rawhide. And after that I've been left with completely unusable system. The only thing I could see was that dev-sda2.device timed out. After playing with the mostly unusable system around - I've tried some other kernels - and notice some of them are usable. After even more checking and testing - I'm using and build my own kernel and I've been missing CONFIG_FHANDLE kernel option which appears from version 210 to be mandatory to boot my system (so all my previous kernel are now useless since I keep them for regression tests...) So - if this is the reason why udev&systemd cannot mount my filesystem anymore (which is kind of interesting since it's been able to do so for years...) - it should at least tell the user the reason why it doesn't work. I'll attach reports gathered from systemd ramdisk Version-Release number of selected component (if applicable): systemd-210-3.fc21.x86_64 How reproducible: Steps to Reproduce: 1. Try 210 with kernel without CONFIG_FHANDLE 2. 3. Actual results: Expected results: Tell the user where is the problem instead of waiting 1:30 for impossible to happen thing... Additional info: