|
Bugzilla – Full Text Bug Listing |
|
Description
Terje J. Hanssen
2011-01-13 17:11:07 UTC
Can you check your menu.lst, difference between regular and failsafe kernel parameters, to find out which particular parameter prevents X11 from starting? Can you check whether the runlevel is specified in the Failsafe section (just standalone number 3 in the parameters)? These two sections are from the default /boot/grub/menu.lst installation. The same happends on two different machines with 11.4 x86_64 Milestone 5.
###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop -- openSUSE 11.4 Milestone 5 of 6 - 2.6.37-rc5-12
root (hd2,2)
kernel /boot/vmlinuz-2.6.37-rc5-12-desktop root=/dev/sdc3 resume=/dev/disk/by-id/scsi-200e09e0000baec4c-part1 splash=silent quiet showopts vga=0x31a
initrd /boot/initrd-2.6.37-rc5-12-desktop
###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.4 Milestone 5 of 6 - 2.6.37-rc5-12
root (hd2,2)
kernel /boot/vmlinuz-2.6.37-rc5-12-desktop root=/dev/sdc3 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x31a
initrd /boot/initrd-2.6.37-rc5-12-desktop
So if I understand it correctly your kdm or gdm doesn't start. It looks like problem of video drivers...Maybe they doesn't survive nomodeset parameter, could you please attach your Xorg log when kdm or gdm doesn't start? Thanks Created attachment 408770 [details]
Xorg.0.log for Asus M4A89 GTD
The above menu.lst sections are from an ASUS M4A89 GTD/ AMD 890GX machine.
I'll attach both Xorg.0.log and output from hwinfo --gfxcard (radeon)
Created attachment 408771 [details]
hwinfo --gfxcard for Asus M4A89 GTD (radeon)
Created attachment 408772 [details]
sections from menu.lst on hp8710w
I'll also attach the corresponding three files/output for my hp8710w /nVidia 3600M mobile workstation as follows
Created attachment 408773 [details]
Xorg.0.log on hp8710w
Created attachment 408774 [details]
hwinfo --gfxcard for hp8710w (nouveau)
A side effect: Logging in to console mode after booting Failsafe mode on both machines nor use my local keyboard layout (Norwegian) setting, probably just the default layout (English). Hmm, Xorg log looks fine...so if it boot to console can you start there X? or does it fail? 'startx' works from console mode as root, yes (not as normal user: cannot move Xorg.0.log to ..old). But tell me, does anyone get 11.4 M5 Failsafe mode to boot into GUI mode? It starts listing textmode during the whole boot process and I cannot see it does any attempts to start gui mode at all. Just stops with the console login prompt. As I haven't had this problem with 11.3 in dual boot on the same machines, I compared the menu.lst sections. A new argument 'x11failsafe' has been introduced with 11.4. I did a test with removing it, then booted 11.4 failesafe which displayed the GDM login screen the first time, but was back to the console login prompt on the next following attempts. Does the 'x11failsafe' work properly? I try to reproduce it with our own M5 and experiment with it, thanks for cooperation. (In reply to comment #10) > Hmm, Xorg log looks fine...so if it boot to console can you start there X? or > does it fail? Just a thought; In case Failsafe mode doesn't try start gui mode at all, possibly this Xorg.0.log may be from the last Desktop startup (?) (In reply to comment #13) > (In reply to comment #10) > > Hmm, Xorg log looks fine...so if it boot to console can you start there X? or > > does it fail? > > > Just a thought; > In case Failsafe mode doesn't try start gui mode at all, possibly this > Xorg.0.log may be from the last Desktop startup (?) But if you can start it manually then problem is not in failed xdm init, so I must check if there is not any condition for failsafe. Just to add the latest experiences, hopefully not too confusing: 'gdm start' after root login bring up the GDM login screen. Logging in from there, doesn't use vga resolution mode (some messages popup) but "falls back" and use my high resolution 1920x1200 Gnome Desktop setup. (similar resolution for 'startx' but there with a with a default, simple desktop content). So to the most confusing thing: After adding back 'x11failsafe' in the Failsafe menu.lst section, Failsafe booted correctly a couple of times as follows: 1) Booting Failsafe - GDM login screen - Gnome login in Lowres vga mode - manual Logout - Restart from GDM 2) Booting Failsafe - GDM login screen - Gnome login in Lowres vga mode - Restart from Gnome 3) Booting Failsafe - Console login I don't know if Restart from GDM login screen (1) and Restart from Gnome desktop (2) had any influence or not. But after this I haven't been able to reproduce 1) or 2) GDM login screen booting Failsafe. I even tried to do the same changes in menu.lst again, but just get 3) console login again. All the above as previous 'startx' was on my hp8710w-Intel/nVidia laptop. Trying 'startx' or 'gdm start' on the Asus machine, causes black screen and expected 'out of range' monitor freeze, as it doesn't display console mode with Ctrl-F1 either. I have to use the machine Reset button. The external monitor has a limit of 1280x1024@75Hz which works nicely in Desktop mode. Steffan - Do you have idea what can cause it? As it is strange for me, that it sometime work and then stop working with same parameters x11failsafe boot option let X use /etc/X11/xorg.conf.install from installation (see /etc/init.d/xdm), which should work. Otherwise graphical installation wouldn't have worked. (In reply to comment #17) > x11failsafe boot option let X use /etc/X11/xorg.conf.install from installation > (see /etc/init.d/xdm), which should work. Otherwise graphical installation > wouldn't have worked. So it means that there must be such file? I think that we now don't create it automatic, do we? (In reply to comment #18) > (In reply to comment #17) > > x11failsafe boot option let X use /etc/X11/xorg.conf.install from installation > > (see /etc/init.d/xdm), which should work. Otherwise graphical installation > > wouldn't have worked. > > So it means that there must be such file? I think that we now don't create it > automatic, do we? Yes. We did create it in the past. We no longer do? Sorry, I didn't test any 11.4 installation. OK, I test it 11.4 M5 in virtual box. For me xorg.conf.install is created and failsafe work for me always ( three success attempts ). Terje - could you please attach your /etc/X11/xorg.conf.install to compare what you have there ( maybe it is badly created). Created attachment 409138 [details]
xorg.conf.install for hp8710w
(In reply to comment #21) > Created an attachment (id=409138) [details] > xorg.conf.install for hp8710w This looks same as my config on VirtualBox...do you run on real hardware or use also some virtualization tool? Created attachment 409139 [details]
xorg.conf.install for Asus M4A89 (currently on factory)
Thanks. That's an xorg.conf.install as it should look like. (In reply to comment #22) > (In reply to comment #21) > > Created an attachment (id=409138) [details] [details] > > xorg.conf.install for hp8710w > > This looks same as my config on VirtualBox...do you run on real hardware or use > also some virtualization tool? Native, real hardware on both machines, see also #8 (hp8710)and #5 (Asus) above. I have however also Xen installed and it is an option on the menu.lst. I'll attach the complete menu.lst (hp8710) which also contains multiboot sections for 11.4, 11.3 and Windows. Created attachment 409167 [details]
complete, multiboot menu.lst for hp8710w
(In reply to comment #24) > Thanks. That's an xorg.conf.install as it should look like. And it just boot Failsafe to console mode (Asus). Also in this case the menu.lst contains dualboot sections for 11.4 and 11.3 Tumbleweed; the latter works flawless. Apparently xdm init script isn't running at all. Otherwise we would see in the X logfile, that xorg.conf.install is read. No idea why xdm init script doesn't run in failsafe mode. Also Josed can't reproduce that issue at all. Hence I recommend to close the bugreport as WORKSFORME. As I also already have mentioned, I cannot see any attempt to start X either. Where are the last console messages located (saved) that might tell what happends just before console login appear? Regarding closing, I will suggest to wait a couple of days until a fresh install of Milestone 6 can be tested. Also more test results from real hardware should be received. Maybe it is related to the type of init implementation. Do you use sysvinit or systemd for starting services? Maybe maitainer of such tools has idea how to debug this issue. Thanks for responses I haven't selected any specific, what's the default here? My installations are fairly standard plus the added dual desktop Gnome+KDE patterns and import/edit of existing mount points for multiboot setup with existing installations. A principle I've used for years since SUSE 9.x. My only previous experience with not booting into gui mode has been with Xen only, which now however for 11.4. M5 also boot into gui mode. Hi werner, do you have idea how we can debug this issue? ( random not starting xdm service in failsafe ) Especially if we can ensure that sysvinit try start it and if any output appear. Thanks The scripts /etc/init.d/xdm will be started by /etc/init.d/rc, simply enable boot logging ( ENFORCE_BLOGD="yes" in /etc/sysconfig/boot) and have a look into /var/log/boot.msg after a reboot. Terje - could you please try it reproduce it with enabled logging as Werner mention in comment#33 and then attach log? Created attachment 410272 [details]
/var/log/boot.msg (hp8710w, boot logging enabled, failsafe console login)
hp8710w, boot logging enabled, failsafe console login
Created attachment 410276 [details]
/var/log/boot.msg (hp8710w, boot logging enabled, failsafe GUI login)
hp8710w, boot logging enabled, failsafe gui login
cat boot.msg2 | grep xdm
service earlyxdm start
service earlyxdm done
<notice -- Jan 25 19:01:48.277199000> service xdm start
<notice -- Jan 25 19:01:48.307602000> service xdm done
In the above, first case (console login) no xdm was found
Hmm, really strange. There is no notice even for attempt to start xdm. Werner - do you have idea what can cause it or how we can debug why it is even try to start? thanks earlyxdm only starts xdm if no NIS nor NFS is used.
To debug /etc/init.d/xdm simply add a
set -x
after
start)
and see what can be seen with
rcxdm start
Hm, I've had both the NFS client (mount), NFS server (share), SSHD and partly Samba in use on my networked machines before today, 2011-01-25. Because this machine got a boot delay at NFS (timeout) during the boot process, I expect due to another machine (NFS server) has been powered off, I've disabled NFS on this machine some days ago. Created attachment 410333 [details]
/var/log/boot.msg (GUI login)
/etc/init.d/xdm with added 'set -x' as follows
start) set -x
~> cat boot.msg3 | grep xdm
service earlyxdm start
service earlyxdm done
+ '[' -x /etc/X11/xdm/keytable ']'
+ /etc/X11/xdm/keytable
+ test -x /etc/X11/xdm/TakeDevices
+ /etc/X11/xdm/TakeDevices
<notice -- Jan 25 21:52:43.168701000> service xdm start<notice -- Jan 25 21:52:43.216627000> startproc: execve (/usr/sbin/gdm) [ /usr/sbin/gdm ], [ DO_FASTBOOT=no CONSOLE=/dev/console ROOTFS_FSTYPE=ext4 SHELL=/bin/sh TERM=linux ROOTFS_FSCK=0 powersaved=off INIT_VERSION=sysvinit-2.88 apm=off DO_BLOGD=yes KDEROOTHOME=/root/.kdm REDIRECT=/dev/tty1 COLUMNS=156 PATH=/bin:/sbin:/usr/bin:/usr/sbin vga=0x31a DO_CONFIRM=no RUNLEVEL=5 PWD=/ SPLASHCFG=/etc/bootsplash/themes/openSUSE/config/bootsplash-1280x1024.cfg DO_QUIET=no LANG=nb_NO.UTF-8 edd=off PREVLEVEL=N LINES=60 QT_SYSTEM_DIR=/usr/share/desktop-data HOME=/ SHLVL=2 XORGCONFIG=xorg.conf.install XCURSOR_THEME=DMZ DO_FORCEFSCK=no WINDOWMANAGER=/usr/bin/gnome SPLASH=yes ROOTFS_BLKDEV=/dev/disk/by-id/ata-Hitachi_HTS722020K9SA00_080201DP0410DTGB5EZP-part11 _=/sbin/startproc DAEMON=/usr/sbin/gdm ]
<notice -- Jan 25 21:52:43.258469000> service xdm done<notice -- Jan 25 21:52:43.518884000> startproc: execve (/sbin/auditd) [ /sbin/auditd -s disable ], [ DO_FASTBOOT=no CONSOLE=/dev/console ROOTFS_FSTYPE=ext4 SHELL=/bin/sh TERM=linux ROOTFS_FSCK=0 powersaved=off LC_ALL=POSIX INIT_VERSION=sysvinit-2.88 apm=off DO_BLOGD=yes REDIRECT=/dev/tty1 COLUMNS=156 PATH=/bin:/sbin:/usr/bin:/usr/sbin vga=0x31a DO_CONFIRM=no RUNLEVEL=5 PWD=/ SPLASHCFG=/etc/bootsplash/themes/openSUSE/config/bootsplash-1280x1024.cfg DO_QUIET=no edd=off PREVLEVEL=N LINES=60 HOME=/ SHLVL=2 DO_FORCEFSCK=no SPLASH=yes ROOTFS_BLKDEV=/dev/disk/by-id/ata-Hitachi_HTS722020K9SA00_080201DP0410DTGB5EZP-part11 _=/sbin/startproc DAEMON=/sbin/auditd ]
+ '[' -x /etc/X11/xdm/keytable ']'
+ /etc/X11/xdm/keytable
+ test -x /etc/X11/xdm/TakeDevices
+ /etc/X11/xdm/TakeDevices
Created attachment 410335 [details]
/var/log/boot.msg (Console login)
/etc/init.d/xdm with added 'set -x' as follows
start) set -x
~> cat boot.msg4 | grep xdm
(nothing)
And as mentioned before, when Console login the default English Keyboard layout is available after login as root, not my local set Norwegian.
You should grep for gdm not xdm: you log with ereased environment informations <notice -- Jan 25 21:52:43.168701000> service xdm start <notice -- Jan 25 21:52:43.216627000> startproc: execve (/usr/sbin/gdm) [...] <notice -- Jan 25 21:52:43.258469000> service xdm done <notice -- Jan 25 21:52:43.518884000> startproc: execve (/sbin/auditd) [...] + '[' -x /etc/X11/xdm/keytable ']' + /etc/X11/xdm/keytable + test -x /etc/X11/xdm/TakeDevices + /etc/X11/xdm/TakeDevices as you can see if you have look on /etc/init.d/xdm the /etc/X11/xdm/TakeDevices only will be called if startproc is not able to start the gdm. Make sure that you're using the latest sysvinit package and retry as there was a small bug which only hurts if and only if a partition was mounted twice. If this does not help you should investigate why gdm fails or return with an exit status not equal to zero. You may add the option -v to startproc, then it will report the pid of the process id of the gdm (which could be the pid of the parent of the gdm deamon as). (In reply to comment #42) > You should grep for gdm not xdm: you log with ereased environment informations > Ok, i wasn't sure about that as xdm was mentioned. However, I won't be on this machine for about 8-10 hours later this evening. But the complete boot.msg files are already attached. boot.msg3.gz leads me to the assumption that gdm is started twice the first start was with success and the second one with: + echo 'Using failsafe X.Org configuration /etc/X11/xorg.conf.install' Using failsafe X.Org configuration /etc/X11/xorg.conf.install + startproc -p /var/run/gdm.pid /usr/sbin/gdm ** (gdm:1766): WARNING **: Failed to acquire org.gnome.DisplayManager ** (gdm:1766): WARNING **: Could not acquire name; bailing out startproc: exit status of parent of /usr/sbin/gdm: 1 + rc_status You should try to disable with insserv -r earlyxdm the first try. IMHO something goes wrong here, in normal case if the /etc/init.d/earlyxdm has success the second try with /etc/init.d/xdm should not happen. Please show me the result of cat /proc/self/mountinfo on this system. .. and also the result of rpm -q --changelog sysvinit | head -n 4 With Failsafe GUI login: ~> cat /proc/self/mountinfo 17 20 0:5 / /dev rw,relatime - devtmpfs devtmpfs rw,size=1989512k,nr_inodes=497378,mode=755 18 17 0:16 / /dev/shm rw,relatime - tmpfs tmpfs rw 20 1 8:11 / / rw,relatime - ext4 /dev/sda11 rw,user_xattr,acl,barrier=1,data=ordered 19 20 0:3 / /proc rw,relatime - proc proc rw 15 20 0:15 / /sys rw,relatime - sysfs sysfs rw 16 15 0:7 / /sys/kernel/debug rw,relatime - debugfs debugfs rw 21 17 0:11 / /dev/pts rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000 22 20 8:9 / /data rw,relatime - ext3 /dev/sda9 rw,errors=continue,commit=15,barrier=1,data=ordered 23 20 8:7 / /home rw,relatime - ext3 /dev/sda7 rw,errors=continue,commit=15,barrier=1,data=ordered 24 20 8:8 / /sled11 rw,relatime - ext3 /dev/sda8 rw,errors=continue,user_xattr,acl,commit=15,barrier=1,data=ordered 25 20 8:6 / /suse112 rw,relatime - ext4 /dev/sda6 rw,barrier=1,data=ordered 26 15 0:10 / /sys/kernel/security rw,relatime - securityfs securityfs rw 27 15 0:17 / /sys/fs/fuse/connections rw,relatime - fusectl fusectl rw 28 23 0:18 / /home/terje/.gvfs rw,nosuid,nodev,relatime - fuse.gvfs-fuse-daemon gvfs-fuse-daemon rw,user_id=1000,group_id=100 29 20 0:3 / /var/lib/ntp/proc ro,nosuid,nodev,relatime - proc proc rw ~> rpm -q --changelog sysvinit | head -n 4 * Tue Nov 09 2010 werner@suse.de - Change showconsole to use newest /proc/tty/consoles API * Fri Oct 29 2010 werner@suse.de Hmmm ... should work as there is no device mounted twice the time.
Please disable earlyxdm, that is no next boot only xdm boot
script should start gdm only once.
You may also try in the running system on the console
rcxdm stop
rcxdm start
to see what does happen here.
(In reply to comment #49) > Hmmm ... should work as there is no device mounted twice the time. > Please disable earlyxdm, that is no next boot only xdm boot > script should start gdm only once. You have to tell me in more details how to disable earlyxdm (?) Yesterday I upgraded to 11.4 Milestone 6 using 'zypper dup' on this hp8710w Intel based machine. On my other machine Asus/AMD (commented i.e in #4 and #5 previously) I made a fresh new installation from NET iso. On both machines this issue still occures randomly, sometimes Failsafe boot to GDM login (maybe more often just the first time after startup), and some times Failsafe boot stops with a console login. Logging in as root in the latter case: # rcxdm stop Shutting down service gdm # rcxdm start Starting service gdm Using failsafe X.org.configuration /etc/X11/xorg.conf.install ***(gdm:1270): Warning***: Couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_system_bus_socket: Connection refused (In reply to comment #50) > (In reply to comment #49) > > Hmmm ... should work as there is no device mounted twice the time. > > Please disable earlyxdm, that is no next boot only xdm boot > > script should start gdm only once. > > You have to tell me in more details how to disable earlyxdm (?) insserv -r earlyxdm; reboot As author of insserv I do not ask how to use insserv ;) ... Nevertheless we have a problem with gdm <-> dbus. 1. Failsafe boot console login: # insserv -r earlyxdm; reboot 2. Failsafe boot console login: # reboot 3. Failsafe boot console login: # init 0 Power ON 4. Failsafe boot GDM login .... ...... 5. Desktop boot GDM login Restart 6. Failsafe boot console login: The above is my latest test order. I'm not sure if the Failsafe console login happends quite randomly. My impression is that 4, 5 and 6 possibly might be some kind of a tendency (?) Make this one Critical, change the Component (GNOME or Basesystem) and reassign to the GDM maintainer (choose from gdm.changes otherwise no one of the mailing list become suitable) The first comments indicated that this was an issue with kdm. Is it still the case? Hmmm .. if this is true, both GDM and KDM do have a problem with dbus ... Timo? What do you think about this? Did someone try this with a less recent version of D-Bus? I haven't followed the changes of D-Bus which were checked into Factory by others lately. But as there haven't been much changes in D-Bus lately I doubt that this is related. (In reply to comment #55) > The first comments indicated that this was an issue with kdm. Is it still the > case? During installation I normally select Gnome as my default desktop, and then add the software pattern for KDE during the installation or later with YaST, to have both desktops and applications available. Therefore I normally also use GDM as the default display manager. Due to the Failsafe boot issue to console login, I also did test to change the display manager to kdm4 (using YaST). I've now repeated this kdm4 test with Milestone 6, and have been able to reproduce the Failsafe boot to console login. No idea what's going on here. Giving up from my side. 11.4 x86_64 Milestone 6 Failsafe mode doesn't boot to GDM login screen on a third workstation, Dell Precision 490, either. As this has worked and works when booting 11.3 on the same machines, I feel sure this is an issue with 11.4. Any experience on this topic from other running 11.4 Gnome/GDM on native hardware? The final 11.4 (2.6.37) and Tumbleweed (3.0.4) both work. |