-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/21/2014 06:46 PM, Michael Biebl wrote:
> Am 22.07.2014 00:21, schrieb Joe: > >> So I plugged in the drive, and suddenly it all burst into life. >> Well, nearly all, no networking, which is a bit limiting for a >> workstation... >> >> This drive has its own fstab entries by UUID, as it often gets >> plugged into this desktop. My assumption is that failing to find >> the drive present had blocked proper startup. Once it was mostly >> going, I commented out the fstab entries, along with the network >> mounts, unplugged the drive, rebooted, and it has reached the point >> where I can post this. At least, I'm assuming it will post when I >> press this... > > I assume this partition on the removable drive is not marked "noauto" > or "nofail" > > Since systemd can't know which mount points are essential for your > system to come up properly, the default is to drop you into a rescue > shell if the devices do not show up during boot (the timeout is 90 > secs). What does sysvinit do in this case? Just continue trying to boot even if one or more of the non-'noauto'-type mount entries fails? (I presume it does something different from what you describe for systemd, or else this would not be new behavior and Joe wouldn't have been surprised by it.) Why would it not be appropriate for systemd to do that same thing? I don't think I have any non-'noauto' fstab entries which aren't considered "required" for a successful boot, so this probably won't affect me, but this does look like the sort of area where any regression at all (compared with the previous init system) would be sufficient grounds to consider the init-system transition unsuccessful. (Or, alternatively, to consider the new init system "not ready for prime time".) If it's expected for this behavior to be rectified by the time the transition goes through, such that this Just Works in any scenario where it would Just Work under sysvinit, fair enough; we are still in testing, after all. But the way I read your response above (and the snipped bit) is as indicating that this is in fact the expected behavior, and by implication, not something that's likely to get fixed. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTzdJyAAoJEASpNY00KDJrCboQAIemWHwUFXGG+3D2bGHdRoct YQBM0AfyU++O+htiwBWVn21SVZ/oqQfeJ9pSrLZJBPkQ3WdYa5Lqtya2Mucp8oLC Fg5NbgaKBZmN3zLq1gJCAFBqGMaWhsFdA0FQFNtjEpLzung0y4pp7DqyPyuLiYpB uToOJuaqYTj9W0p+6g7b7GB6K7fv96vsDE+Y2VZO6NJREhOg86Zdun/UkgkRkW5N zhedSqgRI4d5b179EgnEuygBaWgau9QPfzvOGD6Kgvb69Ko+vKYzMC0oX1vdfnpR VSZrgYdTOr8lcjQw6aim+5hHNZ4Mlz3OMWvfKn8iLZUWVYbRwzqtxLzwtIsqrH66 xFYduIe0LMkWk8lT9fKtm7CAtBlod5Cl4eMSnFMhhiUDqOWqOZu7u0bWbu/oNLpQ oJWZ8YUuGZwzovq5vr0lzufLZjGFxHyZd38K15odaqwoKk2mZbSOvGY4tbUyx3+9 sqVoYIJ1UxP/BouuDrq/q4dMVfdUakEnV74p4Splp4Tw4Vehbcd7qE9wnVBJLgc8 RyU+RV6aamV4Wjc62zActeUQFqFIIcAO4SWBgaayXGf4IZMd8y+C5eeGcNa0x54t Tl9+uOeTfBl7IOFKtDgyaFUF6mCpLTVO0oGGoa9ZiRQTprGzRq5hwAxgXx4Jk0Qt 5v9UYe3GsCsVGKl89HLZ =U6IF -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53cdd272.6080...@fastmail.fm
