Re: Sid Systemd upgrade
-----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-----
Reply to: