|
Bugzilla – Full Text Bug Listing |
| Summary: | system refuses to boot if /home is not available | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Oliver Neukum <oneukum> |
| Component: | Basesystem | Assignee: | E-mail List <bnc-team-screening> |
| Status: | RESOLVED FEATURE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | aschnell, bwiedemann, oneukum, systemd-maintainers, thomas.blume, yast2-maintainers |
| Version: | 13.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Oliver Neukum
2015-04-08 09:03:34 UTC
it usually helps to mark those with the "nofail" option in /etc/fstab maybe this should be the default from yast2 disk partitioner... (In reply to Oliver Neukum from comment #0) > If /home cannot be mounted (eg. on a RAID array or bcache and no driver in > the initrd) the whole system refuses to come up. The system should be able > to boot without /home Hm, your example suggests that the whole device holding /home is not present. In this case, fsck would fail, even before the mount is attempted. I thought that even on System V systems, the boot would fail if an fsck fails. However, on an systemd system it will fail for sure if a device holding a mount is not present. This works as designed. If you don't want this, you need to add the nofail mount option as Bernhard already wrote. Ok, with this? (In reply to Thomas Blume from comment #2) > If you don't want this, you need to add the nofail mount option as Bernhard > already wrote. > > Ok, with this? Certainly, but I think that is YaST's job. (In reply to Oliver Neukum from comment #3) > > > > Ok, with this? > > Certainly, but I think that is YaST's job. Ok, adding yast2-maintainers to CC. (In reply to Thomas Blume from comment #2) > Hm, your example suggests that the whole device holding /home is not present. > In this case, fsck would fail, even before the mount is attempted. > I thought that even on System V systems, the boot would fail if an fsck > fails. Just tested on SLE-11-SP3 adding to fstab /somedir /dev/vdx ext3 default 0 0 and this just boots fine. It only fails, when setting the last param to 2 to trigger a fsck and then goes into a sulogin with the rootfs mounted. (In reply to Bernhard Wiedemann from comment #5) > > Just tested on SLE-11-SP3 adding to fstab > /somedir /dev/vdx ext3 default 0 0 > > and this just boots fine. > It only fails, when setting the last param to 2 to trigger a fsck > and then goes into a sulogin with the rootfs mounted. Ok, but the default is 2 when adding a mountpoint via YaST. If you do it manually, you can as well just add the 'nofail' mount option. :-) (In reply to Thomas Blume from comment #6) > Ok, but the default is 2 when adding a mountpoint via YaST. > If you do it manually, you can as well just add the 'nofail' mount option. The problem with the nofail option is that nothing tells you about it. It would have been different, if you would have to add a "fail" option to the important entries... meaning that the default was still the same as before, but you could change it explicitly. man fstab and man mount just describes it as nofail: do not report errors if ... so nothing about the actual importance of it. Would also help, if there was a comment in the default fstab file. (In reply to Bernhard Wiedemann from comment #1) > it usually helps to mark those with the "nofail" option in /etc/fstab > > maybe this should be the default from yast2 disk partitioner... No, I don't think so. For example we had bug reports with encrypted devices where the boot process continued after some time even without providing a password and users where confused because there home directory was missing. For me the problem is simply that fixing boot problems with systemd is currently to difficult (if at all possible). (In reply to Arvin Schnell from comment #8) > No, I don't think so. For example we had bug reports with encrypted > devices where the boot process continued after some time even without > providing a password and users where confused because there home > directory was missing. Then at least they can fix the omission. If you cannot boot, that's it. (In reply to Arvin Schnell from comment #8) IMHO this is not a problem of systemd in the case that /home is part of the local-fs.target (former /etc/init.d/boot.localfs or $local_fs) and there are services do hard depend on local-fs.target. This is more that you get what you have requested. Btw: What is wrong adding 'nofail' to the /home partition? Or do you think that systemd should ignore hard dependencies? Adding nofail is wrong since you get a system that does not work as desired. And no, I don't think systemd should ignore hard dependencies but it should make fixing issues easy right when they appear. (In reply to Arvin Schnell from comment #11) And how does this look like in your opinion? It should provide whatever Oliver is missing in systemd but would be available in the system. (In reply to Arvin Schnell from comment #13) > It should provide whatever Oliver is missing in systemd but would be > available in the system. I am not really missing a feature in systemd. This looks to me like a question of configuration. In this case systemd should wait for the attempt to mount /home to finish, but not to succeed. (In reply to Oliver Neukum from comment #14) Hmmm ... for a not decypted /home this become infinite. Do you really think this is the solution? Also dropping into a emergency shell does not help (IMHO). (In reply to Dr. Werner Fink from comment #15) > (In reply to Oliver Neukum from comment #14) > > Hmmm ... for a not decypted /home this become infinite. Do you really think > this is the solution? Also dropping into a emergency shell does not help > (IMHO). It is better than the current setup. And I think it can be done with minimal changes, like adding "nofail". Encryption is IMHO a special case. It requires interaction with people. And I don't think that a missing /home should drop me into an emergency shell. It should boot up. Ideally the GUI would immediately make obvious that the system has come up in a diminished state, but that would be a feature request. (In reply to Oliver Neukum from comment #16) > It is better than the current setup. And I think it can be done with minimal > changes, like adding "nofail". > Encryption is IMHO a special case. It requires interaction with people. The problem seems to be that Arvin does not like the `nofail' option for a separate /home partition as i can read from comment #11 @Arvin: Second try: What is wrong to use "nofail" as default for a separate /home partition? At least as an option showed up to the user as further information. Feel free to make a feature request. FATE#319069 created |