9:48 a.m.
I am not able to boot either of the Rawhide 3.5.0-0.rc4 kernels in runlevel 3
(adding "3" to the boot options). Since booting in default graphical mode has
resulted for me in a black screen immediately after X starts for a long time
now, this makes these rc4 kernels unusable (although X apparently is working for
some other people, so they would be able to boot in graphical mode). Is this a
known issue?
9:55 a.m.
On 06/27/2012 09:48 AM, Andre Robatino wrote:
I am not able to boot either of the Rawhide 3.5.0-0.rc4 kernels in
runlevel 3
(adding "3" to the boot options). Since booting in default graphical mode has
resulted for me in a black screen immediately after X starts for a long time
now, this makes these rc4 kernels unusable (although X apparently is working for
some other people, so they would be able to boot in graphical mode). Is this a
known issue?
You may be running into the same problem that I have. Check out this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=830916
Kevin
10:06 a.m.
Kevin Martin <ktmdms <at> gmail.com> writes:
You may be running into the same problem that I have. Check out this
bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=830916
Should have mentioned that my Rawhide is a VirtualBox 4.1.18 guest (which uses
the vesa driver).
10:46 a.m.
On Wed, 2012-06-27 at 15:06 +0000, Andre Robatino wrote:
Kevin Martin <ktmdms <at> gmail.com> writes:
> You may be running into the same problem that I have. Check out this bugzilla:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=830916
Should have mentioned that my Rawhide is a VirtualBox 4.1.18 guest (which uses
the vesa driver).
Assuming the guest still brings up networking, you should be able to ssh
into it and inspect /var/log/Xorg.0.log. Alternatively I assume vbox
has serial console support.
- ajax
11:10 a.m.
Adam Jackson <ajax <at> redhat.com> writes:
> Should have mentioned that my Rawhide is a VirtualBox 4.1.18
guest (which
> uses the vesa driver).
Assuming the guest still brings up networking, you should be able to ssh
into it and inspect /var/log/Xorg.0.log. Alternatively I assume vbox
has serial console support.
I booted in graphical mode, then when the black screen with the eternal spinning
cursor appeared, switched to VT3 and grabbed Xorg.0.log - see
http://robatino.fedorapeople.org/Xorg.0.log . The file grows gradually, so this
is just a snapshot of it. I also noticed that there is an setroubleshootd
process that respawns no matter how many times I kill it - that probably
accounts for the high CPU usage I'm currently seeing. However, the black screen
problem has existed for weeks at least. The high CPU usage has only happened for
a week or two.
I'll file bugs as soon as it's clear which of these problems are unknown.
11:52 a.m.
On Wed, Jun 27, 2012 at 16:10:40 +0000,
Andre Robatino <robatino(a)fedoraproject.org> wrote:
I booted in graphical mode, then when the black screen with the
eternal spinning
cursor appeared, switched to VT3 and grabbed Xorg.0.log - see
http://robatino.fedorapeople.org/Xorg.0.log . The file grows gradually, so this
is just a snapshot of it. I also noticed that there is an setroubleshootd
process that respawns no matter how many times I kill it - that probably
accounts for the high CPU usage I'm currently seeing. However, the black screen
problem has existed for weeks at least. The high CPU usage has only happened for
a week or two.
I'll file bugs as soon as it's clear which of these problems are unknown.
There was recently a bug like that, where I had to set selinux to permissive
to be able to login in (or see the gdm background screen) as gdm was blocking
being unable to access a file it needed. This was about 1 to 2 weeks ago
though, so I don't think you'd still be seeing it.
12:45 p.m.
Bruno Wolff III <bruno <at> wolff.to> writes:
There was recently a bug like that, where I had to set selinux to
permissive
to be able to login in (or see the gdm background screen) as gdm was blocking
being unable to access a file it needed. This was about 1 to 2 weeks ago
though, so I don't think you'd still be seeing it.
"enforcing=0" gets rid of the unkillable CPU-sucking setroubleshootd process,
but doesn't help with the black screen problem. Same with "selinux=0".
I should note that the only nonstandard thing I'm doing is using VirtualBox
4.1.18. The Rawhide guest is pure 64-bit with no 3rd-party software or repos. I
was able to get the VB guest additions fully installed using the workaround at
https://www.virtualbox.org/ticket/10709 although that shouldn't have anything to
do with the black screen problem. Until a few days ago, there were essentially
no broken dependencies, and no obsolete packages installed. The black screen
problem predates that.
12:04 p.m.
On Wed, 2012-06-27 at 16:10 +0000, Andre Robatino wrote:
Adam Jackson <ajax <at> redhat.com> writes:
> > Should have mentioned that my Rawhide is a VirtualBox 4.1.18 guest (which
> > uses the vesa driver).
^^^^
Nope:
I booted in graphical mode, then when the black screen with the
eternal spinning
cursor appeared, switched to VT3 and grabbed Xorg.0.log - see
http://robatino.fedorapeople.org/Xorg.0.log
... contains:
[ 19.757] (==) Using config file: "/etc/X11/xorg.conf"
[ 19.757] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 19.757] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 19.819] (==) No Layout section. Using the first Screen section.
[ 19.819] (**) |-->Screen "Screen[0]" (0)
[ 19.819] (**) | |-->Monitor "Monitor[0]"
[ 19.819] (**) | |-->Device "Device[0]"
...
[ 21.016] (II) VBoxVideo(0): VirtualBox guest additions video driver
version 4.1.18
If this were a video driver problem you would want to confirm that by
varying xorg.conf between vboxvideo and vesa, and using 'X -retro' from
runlevel 3 to see if you get the ugly black/white stipple. If only one
driver works, the other is at fault; if both work, something about the
rest of the session is to blame.
But it's almost certainly not a driver problem, since if you can see the
spinning cursor then the driver is working and it's the session busily
doing nothing.
- ajax
9:58 a.m.
On 6/27/2012 10:48 AM, Andre Robatino wrote:
I am not able to boot either of the Rawhide 3.5.0-0.rc4 kernels in
runlevel 3
(adding "3" to the boot options). Since booting in default graphical mode has
resulted for me in a black screen immediately after X starts for a long time
now, this makes these rc4 kernels unusable (although X apparently is working for
some other people, so they would be able to boot in graphical mode). Is this a
known issue?
The command line switch you want is:
systemctl isolate multi-user.target
which came from here:
"Systemd"
<http://fedoraproject.org/wiki/Systemd>
--
David
10:14 a.m.
Andre Robatino <robatino <at> fedoraproject.org> writes:
I am not able to boot either of the Rawhide 3.5.0-0.rc4 kernels in
runlevel 3
(adding "3" to the boot options).
Should have mentioned that what happens when I try this is that I get dropped to
a rescue prompt. Just found that I can sidestep it by booting in default
graphical mode, then when I get the black screen with the spinning cursor,
switch to a VT. It's not ideal but it works.
10:20 a.m.
On 27/06/12 15:48, Andre Robatino wrote:
I am not able to boot either of the Rawhide 3.5.0-0.rc4 kernels in
runlevel 3
(adding "3" to the boot options).
Both Working fine here KVM Guest qxl graphics option.
Thought there are masses of never-ending systemd-journal spew:
https://bugzilla.redhat.com/show_bug.cgi?id=835867
cpu 100%
Since booting in default graphical mode has
resulted for me in a black screen immediately after X starts for a
long time
now,
If your are using ligthdm, slowness is known:
https://bugzilla.redhat.com/show_bug.cgi?id=834427
--
Regards,
Frank
"Jack of all, fubars"
10:32 a.m.
Frank Murphy <frankly3d <at> gmail.com> writes:
Since booting in default graphical mode has
> resulted for me in a black screen immediately after X starts for a long time
> now,
If your are using ligthdm, slowness is known:
https://bugzilla.redhat.com/show_bug.cgi?id=834427
My Rawhide is a VirtualBox guest (which uses vesa). What happens if you boot
adding the options "xdriver=vesa nomodeset"?
10:49 a.m.
On 27/06/12 16:32, Andre Robatino wrote:
Frank Murphy <frankly3d <at> gmail.com> writes:
>
> If your are using ligthdm, slowness is known:
> https://bugzilla.redhat.com/show_bug.cgi?id=834427
My Rawhide is a VirtualBox guest (which uses vesa). What happens if you boot
adding the options "xdriver=vesa nomodeset"?
Normal slow lightdm boot to DE, which does show up after app 3mins total
--
Regards,
Frank
"Jack of all, fubars"
2:10 p.m.
On Wed, 2012-06-27 at 16:49 +0100, Frank Murphy wrote:
On 27/06/12 16:32, Andre Robatino wrote:
> Frank Murphy <frankly3d <at> gmail.com> writes:
>>
>> If your are using ligthdm, slowness is known:
>> https://bugzilla.redhat.com/show_bug.cgi?id=834427
>
> My Rawhide is a VirtualBox guest (which uses vesa). What happens if you boot
> adding the options "xdriver=vesa nomodeset"?
>
Normal slow lightdm boot to DE, which does show up after app 3mins total
xdriver= is only parsed by anaconda, AFAIK. regular boot does nothing
with it. nomodeset will force the use of the vesa driver on almost all
hardware, though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:49 a.m.
On Wed, Jun 27, 2012 at 14:48:31 +0000,
Andre Robatino <robatino(a)fedoraproject.org> wrote:
I am not able to boot either of the Rawhide 3.5.0-0.rc4 kernels in
runlevel 3
(adding "3" to the boot options). Since booting in default graphical mode has
resulted for me in a black screen immediately after X starts for a long time
now, this makes these rc4 kernels unusable (although X apparently is working for
some other people, so they would be able to boot in graphical mode). Is this a
known issue?
It is not a general (all systems) issue, as I am running
3.5.0-0.rc4.git0.1.fc18.i686.PAE.
4336
days inactive
4336
days old
14 comments
7 participants
participants (7)
-
Adam Jackson -
Adam Williamson -
Andre Robatino -
Bruno Wolff III -
David -
Frank Murphy -
kevin martin