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/
