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-September/018985.html | 233 ++++++++++++++++++++++++++ 1 file changed, 233 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-September/018985.html (limited to 'zarb-ml/mageia-dev/2012-September/018985.html') diff --git a/zarb-ml/mageia-dev/2012-September/018985.html b/zarb-ml/mageia-dev/2012-September/018985.html new file mode 100644 index 000000000..854da7bd3 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-September/018985.html @@ -0,0 +1,233 @@ + + + + [Mageia-dev] Fwd: Re: M3 won't complete boot after update + + + + + + + + + +

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

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Sep 27 14:31:15 CEST 2012 +

+
+ +
'Twas brillig, and Anne Wilson at 27/09/12 11:02 did gyre and gimble:
+> On 27/09/12 10:15, Colin Guthrie wrote:
+>> Does it work when forcing a runlevel 3 boot instead. This is
+>> closer to a proper boot and likely a better testing environment. I
+>> presume the getty's are showing for you in level 3?
+> 
+> To my surprise, the same, text boot, to level 3 does complete perfectly.
+>  There are a couple of gpg messages, though:
+> 
+> gpg-agent: enabled debug flags: assuan
+> can't connect to '/home/anne/.gnupg/log-socket': No such file or
+> directory.
+
+Curious but almost certainly unrelated.
+
+> I don't know whether this is to be expected, or whether it has any
+> relevance at this point.
+> 
+> "systemctl show prefdm.service | grep ActiveEnter.*Mono" returns 0
+> 
+> I presume this is to be expected at this stage.
+
+Yes, this is expected on runlevel 3.
+
+> "systemctl start prefdm.service"
+> Failed to issue method call: Access denied
+
+Yes, this is because you are not root.
+
+> In case that has to be root, I used "su -" then the same command, but
+> that just gives me a flashing cursor.
+
+So it was just hanging there? It would be interesting to run systemctl
+--no-block start prefdm.service and then run "systemctl status
+prefdm.service" and see what kind of state it was in. i.e. is it
+starting, or failed etc.
+
+It should eventually fail after a couple minutes and perhaps give you
+some interesting log message about it.
+
+>> The results of this test are only really valuable if you do a
+>> normal boot to runlevel 5 as this is when the service should be
+>> started.
+> 
+> Doesn't runlevel 5 attempt to launch the desktop, though?  I don't see
+> how I can do that.
+
+Indeed, the test there would be weather or not the system is even trying
+to start the graphical desktop or something has prevent it getting that far.
+
+I presume it does try and start a graphical desktop then? If so, can you
+not switch to vt2 at this stage and get a login getty prompt to do some
+debugging? (e.g. systemctl status prefdm.service and see what state it's
+in etc.)
+
+>> What I'm trying to work out here is if the job relating to
+>> starting the prefdm.service had to be ejected due to some kind of
+>> conflict.
+> 
+>> If there is a conflict then the values will be 0 and this will 
+>> explain why your graphical desktop does not start.
+> 
+> While the new reboot is completing, and while I remember - irqbalance
+> daemon always fails to start.  I've assumed it's not relevant?
+
+I noticed this yesterday too. It has a very incomplete systemd unit for
+some reason. Will have to investigate who added that without checking it.
+
+
+>>>>>> If it still fails, then try starting prefdm.service
+>>>>>> manually (systemctl start prefdm.service) and see what
+>>>>>> happens.
+>>>>
+>>>> Nothing at all happens.  It returns to the prompt.
+>> This is curious. Does this also occur at runelevel 3? What does 
+>> systemctl status prefdm.service tell you after it returns you to
+>> the prompt?
+> 
+> prefdm.service - Display Manager
+>   Loaded: loaded (/usr/lib/systemd/system/prefdm.service: static)
+>   Active: inactive (dead)
+>   CGroup: name=systemd:/system/prefdm.service
+> 
+>> Is there anything useful in the kdm log file about why kdm failed
+>> to launch X11?
+> 
+> Looks like an X11 problem.  The netbook is Atom N550, Intel everything.
+> 
+> tail kdm.log
+> 
+> Fatal server error:
+> no screens found
+> (EE)
+> Please consult......
+> (EE) Please also check the log file at "var/log/Xorg.0.log" for
+> additional information
+> (EE)
+> Server terminated with error (1). Closing log file.
+
+Yup, it's an X problem plain and simple, ignore all the rest of the
+systemd debugging options above.
+
+> from Xorg.0.log file:
+> 
+> LoadModule "v4l"
+> Warning, couldn't open module v4l
+> UnloadModule "v4l"
+> Unloading v4l
+> Failed to load module "v4l" (module does not exist, 0)
+> LoadModule "glx"
+> Loading /usr/lib/xorg/modules/extensions/libglx.so
+> Module glx: vendor="X.Org Foundation"
+>   compiled for 1.13.0 module version = 1.0.0
+>   ABI class: X.Org Server Extension, version 7.0
+> AIGLX enabled
+> Loading extension GLX
+> LoadModule "intel"
+> Warning: couldn't open module intel
+> UnloadModule: "intel"
+> Unloading intel
+> Failed to load module "intel" (module does not exist, 0)
+> No drivers available
+> Fatal server error:
+> no screens found
+> Please consult.....
+> 
+> Looks as though we've found it.
+> 
+>>>> We have all spent a lot of time on this.  There are files on
+>>>> the netbook that I must recover, so now it's decision time.
+>>>> It would probably be easier and quicker to grab the latest
+>>>> image (in which case can you remind me where to go for that)
+>>>> but I am willing to continue if there is any possibility that
+>>>> what we discover could save grief for others.
+>>>>
+>>>> What do you think?
+>> Plenty more to debug if you want to continue.
+> 
+> Probably Intel graphics are less common than ATi and NVidia, but if
+> there is a real problem here (as opposed to user-caused one) we should
+> continue.  I can hold on a bit longer.  Just give me the next steps :-)
+
+Oh I would disagree. I think intel is more common (but I base this on
+very little evidence!) Certainly I *always* ensure I have an intel card
+in anything I purchase. Their Open Source commitment is just much better
+than the others IMO.
+
+Are you sure the packages are all up-to-date? I guess this relates to
+the recently(ish) updated X11 stack.
+
+I presume you have the x11-driver-video-intel package installed?
+
+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