[Mageia-dev] M3 won't complete boot after update
Colin Guthrie
mageia at colin.guthr.ie
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/
More information about the Mageia-dev
mailing list