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

[Colin Guthrie]

'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.


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/