[Mageia-dev] M3 won't complete boot after update

Thu Sep 27 10:40:08 CEST 2012

Anne,
+
+I pointed you at this mail in the archives when you were having
+troubles, but I don't think you're replied to it to give the necessary
+debug info.
+
+Col
+
+'Twas brillig, and Colin Guthrie at 25/09/12 17:35 did gyre and gimble:
+> 'Twas brillig, and Anne Wilson at 25/09/12 16:37 did gyre and gimble:
+>> On 25/09/12 15:41, Colin Guthrie wrote:
+>>> 'Twas brillig, and Anne Wilson at 25/09/12 15:02 did gyre and 
+>>> gimble:
+>>>> Sent yesterday, but not seen on-list, so apologies if this is a 
+>>>> duplicate.
+>>>>
+>>>> I finally got around to connecting my netbook, which has been 
+>>>> running Cauldron for some time.  This was fully up to date
+>>>> before my holidays, and apart from the recent display problem
+>>>> (which as Angelo Naselli suspected, is a KDE problem) it has
+>>>> behaved beautifully.  Today, though, needed almost 3 weeks worth
+>>>> of updates, and when it finished, it won't boot.
+>>>>
+>>>> There are obviously problems with my remote mounts, but we are 
+>>>> talking in detail about that on another thread.  Mostly things
+>>>> look to be going well up to that stage, then I see messages like
+>>>>
+>>>> Started RPC bind service Reached target Remote File Systems
+>>>> (Pre). Mounting /mnt/QNAS-Lydgate-Data... Mounting
+>>>> /mnt/borg2/home... Mounting /mnt/borg2_Data1... Reached target
+>>>> RPC Port Mapper. Failed to mount /mnt/QNAS-Lydgate-Data. See
+>>>> systemctl status /mnt-QNAS\x2dLydgate\x2dData.mount for details.
+>>>> .... (other similar pairs of lines) Dependency failed for Remote
+>>>> File Systems
+>>>>
+>>>> After these lines, suddenly two of the QNAS mounts (one of which 
+>>>> is /mnt/QNAS/Lydgate-Data mentioned above) do succeed.  The two 
+>>>> borg2 mounts still fail, as do some of the other QNAS mounts.
+>>>>
+>>>> A few more lines, and all looks reasonable, until
+>>>>
+>>>> [FAILED] Failed to start Wait for Plymouth Boot Screen to Quit
+>>>>
+>>>> then Reached target Multi-User Reached target Graphical
+>>>> Interface
+>>>>
+>>>> and there it freezes.
+>>>>
+>>>> Later:
+>>>>
+>>>> I tried booting from the older kernel.  On the graphical screen, 
+>>>> it appears to get a lot further, 5 bubbles instead of 2, but when
+>>>> I tried it again watching the messages it appears to follow the
+>>>> same path as the new kernel boot, ending at the same place.
+>>>>
+>>>> Interestingly, though, the nfs mount that succeeds, after saying 
+>>>> it had failed, was not the same one as yesterdays.  Still, that's
+>>>>  probably a side-issue.
+>>>>
+>>>> The situation now is that I appear to have a completely unusable 
+>>>> M3. The line
+>>>>
+>>>> [DEPEND] Dependency failed for Remote File Systems
+>>>>
+>>>> is obviously important.  Not knowing what that dependency is, I 
+>>>> don't know whether it could do more damage than failing to mount 
+>>>> remote systems.  It doesn't sound likely, but....
+>>
+>>> If the remote mounts are not critical, just add nofail to the
+>>> fstab options.
+>>
+>>> I suspect strongly that any issues with these mounts is entirely 
+>>> separate to the actual graphical boot.
+>>
+>> Agreed.  Adding nofail makes no difference.  I've also tried removing
+>> all options, down to a minimum defaults.  However, they shouldn't stop
+>> boot.  FWIW, I'm still seeing that message about a dependency failure
+>> for remote file systems.
+>>
+>>> Personally, I was seeing crashes with qt4... perhaps try switching 
+>>> to gdm as you're DM and see if the graphical boot comes up OK,
+>>> that way we could see easily if it's something high level.
+>>
+>> No, gdm doesn't get that far either.
+>>
+>>> Also you could try and look and see what systemctl status 
+>>> prefdm.service says to you (you might need to switch to tty2).
+>>
+>> prefdm.service - Display Manager
+>>   Loaded: loaded (/usr/lib/systemd/system/prefdm.service: static)
+>>   Active: inactive (dead)
+>>   CGroup: name=systemd:system/prefdm.service
+>>
+>> (This from looking over my shoulder, so ignore any typos)
+>>
+>> I'll worry about the mounts later - the first thing is to get the
+>> system back :-)
+> 
+> Can you try doing "systemctl show prefdm.service | grep
+> ActiveEnter.*Mono" after a fresh boot.
+> 
+> I don't need to know the results, just whether it's non-zero or still at 0.
+> 
+> Assuming it's still at zero, then we've not even tried to start the
+> graphical server.
+> 
+> I suspect this is because we're considering your remote mounts as
+> critical to the user sessions (i.e. think of /home on NFS). Normally,
+> putting nofail in the fstab is enough to break this linkage.
+> 
+> Can you comment out all remote mounts entirely and see if you can boot.
+> 
+> If it still fails, then try starting prefdm.service manually (systemctl
+> start prefdm.service) and see what happens.
+
+
+
+
+-- 
+
+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/
+