From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-July/017642.html | 192 +++++++++++++++++++++++++++++++ 1 file changed, 192 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-July/017642.html (limited to 'zarb-ml/mageia-dev/2012-July/017642.html') diff --git a/zarb-ml/mageia-dev/2012-July/017642.html b/zarb-ml/mageia-dev/2012-July/017642.html new file mode 100644 index 000000000..d63106ed7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-July/017642.html @@ -0,0 +1,192 @@ + + + + [Mageia-dev] Systemd improvement + + + + + + + + + +

[Mageia-dev] Systemd improvement

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Jul 24 11:55:50 CEST 2012 +

+
+ +
'Twas brillig, and Olivier Thauvin at 24/07/12 10:47 did gyre and gimble:
+> * Colin Guthrie (mageia at colin.guthr.ie) wrote:
+>> 'Twas brillig, and Olivier Thauvin at 24/07/12 10:02 did gyre and gimble:
+>>> I have some minor issues with systemd so I report it in case some
+>>> improvment could be done:
+>>>
+>>> 1) The timeout is very long when the system failed to ask the passphrase
+>>> for encrypted partition, os it is very long to reach any console (this
+>>> happend only when there is a problem)
+>>>
+>>> 2) When everything work fine, the timeout occur if the passphrase for
+>>> encrypted partition is not enter early enough: I power up my laptop, do
+>>> something else, come back and it report the boot has failed, surprising!
+>>
+>> So it's both too long and too short :)
+>>
+>> I'm not sure how to deal with this, but I would suggest that we need to
+>> do something a bit more creative to deal with your particular use case.
+>>
+>> For yourself, it's not a "critical" filesystem - e.g. it's not /usr or
+>> similar, but /home.
+> 
+> No you misunderstood, if the system succeed to launch
+> '/usr/bin/ask-the-passphrase' or whatever its name is, it must wait an
+> answer for ever and not continue booting and finally claim "hey
+> surprising, I failed to boot w/o the passphrase".
+> The firest time it happend I really thought my system was broken.
+
+So what if you cannot enter your password and want to rescue the system?
+Should it still wait forever until you enter your passphrase? Or would
+you have to deliberately enter your passphrase wrong X number of times
+to get the the rescue mode?
+
+> However, if it cannot launch '/usr/bin/ask-the-passphrase' it is sure
+> booting will failed as it cannot get the passphrase, no need to wait an
+> impossible user input.
+> Again, the case I just talk about happend only in case of bug and must
+> not happend on stable distro.
+
+In this particular case it was not that it could not run the password
+prompt, simply that it didn't know how to mount something completely
+alien to it.
+
+You have to remember that all this is happening completely
+asynchronously these days. It's not like systemd is specifically poking
+things and failing. It's waiting for the system to do it itself, hence
+the timeouts.
+
+That's not to say this can't be solved, it's just that we're treating
+one mount much like any other - and some mounts take a loooooong time to
+happen (e.g. just try recent btrfs stuff with all the krud it does when
+mounting).
+
+But the "waiting-for-password" case and the "there is no subsystem to
+handle even asking for the password" case are essentially treated the
+same way.
+
+This is likely a discussion to take to the upstream mailing list.
+
+>>> 3) the boot process hang/stop/wait if my wireless card is down (using
+>>> the hardware switch on the side of my laptop). This step need just one
+>>> second when the card is on, even it does not connect to any network.
+>>
+>> If you have any NFS (or other network mounts) mounts that are NOT marked
+>> with nofail, then we consider them to be "critical" filesystems. If
+>> these filesystems are NOT needed for boot, then just mark them as
+>> "nofail" and they will still be mounted but your DM/logins will not be
+>> delayed while waiting for the network.
+> 
+> 
+> I don't have nfs in my fstab but maybe this is triggered by another
+> service.
+> But I don't see the point of waiting the card to be on, especially when
+> the card is on it don't connect to any network and don't wait this
+> happend.
+
+Hmm in that case it sounds like a different issue than the deliberate
+stuff that waits for the network to be ready.
+
+Do you know which bit of the system is waiting for this? Is it
+network-up.service or something else? (I doubt it can be network-up as
+this shouldn't delay logins unless the afore mentioned NFS mounts are
+present)
+
+Col
+
+
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited http://www.tribalogic.net/
+Open Source:
+  Mageia Contributor http://www.mageia.org/
+  PulseAudio Hacker http://www.pulseaudio.org/
+  Trac Hacker http://trac.edgewall.org/
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1