Description of problem: Boot fails, if /home partition is missing - even in single user mode. The /home partition is not needed for the system to boot up. The normal non-root user could alternatively be alerted, that a login will fail as the home directory is missing. But the system should come up. Instead the boot process falls back to the administration console. Background: I've my home partition on a separate drive, which failed. I could hardly boot the system with the replacement drive installed. I had to reinstall the old failing drive containing the old filesystem in order to be able to comment out the /home entry in /etc/fstab. In addition - which is not part of this bug report - the administration console was unusable as my nvidia driver blackens the whole screen during the boot process. I couldn't see/use the administration console at all. Removing the rhgb and quiet entry in the grub boot configuration or booting to single user mode didn't help. A "normal" user is lost in that situation. Version-Release number of selected component (if applicable): n.a. How reproducible: Always Steps to Reproduce: 1. make the home partition entry in /etc/fstab invalid or provoke a missing home partition in any other way. 2. reboot 3. repair your system with a live disk Actual results: Boot fails Expected results: System should come up at least with no home partition mounted Additional info: I had that problem for several times also with previous fedora versions
Basesystem component has nothing to do with this issue (it is just metapackage with no content). I'm not really sure where to reassign based on your report, reassigning to distribution. Please provide more information (where exactly the boot failed, log ...).
systemd handles the mounting of partitions. Note that you can configure fstab so it's not a fatal error - see 'man fstab', particularly the 'nofail' option.
Booting up normally without /home might be problematic for security reason, hence we fail if /home cannot be found, by default. You can add "nofail" to the mount options in fstab to declare explicitly that a missing file system should not cause the boot to fail.
Sorry, but closing this bug at this stage is too easy. Please explain your statement. Editing /etc/fstab appropriately is a solution anyway, independent from whether you add the nofail option or comment out /home. I'm talking about the cases, when the /home partition fails unexpectedly(broken devices, broken filesystems, changed filesystem uuids or device names, ...). An average skilled user loses his/her system as the system isn't accessible any more. Booting up the system would at least allow to start gnome as root and try to fix the system with more convenient tools then a simple bash. I'm personally not limited with the bash, but the common desktop user is. In combination with the fact, that my screen remains black with the commonly used nvidia drivers (yes I know it's not officially supported by fedora) and that I cannot access the fallback bash at all, even I am close the situation to be forced to fix my system with a hopefully available rescue disk or reinstall the whole system. Why is there a security issue if /home is missing? The only scenario that I could imagine is, that there is some content under /home, that becomes visible with the home partition not mounted. But this is a failure of the sysadmin. A missing /home is definitely not a security issue. Please give some arguements, why this system behaviour is your favourite. I can't find any!? Best regards Boris
Rather than assuming that the system will work without certain system filesystems, a better experience for users to use in this case would be a rescue or safe mode, such as what is on the live images and the installer images.
(In reply to comment #4) > Why is there a security issue if /home is missing? The only scenario that I > could imagine is, that there is some content under /home, that becomes > visible with the home partition not mounted. But this is a failure of the > sysadmin. A missing /home is definitely not a security issue. Well, sometimes the absence of things creates security problems, since apps don't expect that. We generally follow the rule that we assume an fs if essential if not marked otherwise. This is easy to see for many file systems. Think: if /var is not around then a lot of sw will fail (already a DoS), go through generally untested error paths, and not be able to log about it, as no storage is available for that. A lot of software will fall back to (possibly insecure) defaults, rather then admin settings (think: a lot of PK privs are open to local users, but the admin might have closed them). Furthermore allowing to boot once without /var could break boot for the next one, for example, because dbus generates a new bus ID which is stored in /var, other apps assuming it is stable use it. When /var then is back at the next boot, the machine ids are out of sync. Now, what I wrote above is true for /var, but for many other fs too. So in summary: it's a complex mess of things. The only safe policy is to say that all fs are considered essential unless listed otherwise. systemd will never be able to figure out if specific directories are ok to be missing or not (this would require an ubounded whitelist...), hence this has to be configured. Now, if you think that /home should not be considered essential, then please consider filing a bug against anaconda, to mark is as such. I am not really sure though that it should be considered non-essential, as the machine is not particularly useful in that case. I think it would make more sense to put the user in the rescue mode but guide him better, i.e. explain what is going on, what he can do about it, and where he can ask for further help. (In reply to comment #5) > Rather than assuming that the system will work without certain system > filesystems, a better experience for users to use in this case would be a > rescue or safe mode, such as what is on the live images and the installer > images. We do have a rescue mode, that the system will enter when some essential disks aren't found. We could certainly improve it though, but that probably should be discussed in a different RFE bug. We nowadays output the last log lines (which hopefully include an explanation what is going on), plus the message catalog entries for that. We should work on improving the content of that, plus maybe a few other things (for example, it has been suggested that we turn out status output on boot for good on the first output). I hope this makes sense.