Bugzilla – Bug 166895
system unbootable after update to RC1 (black screen in grub)
Last modified: 2006-04-30 15:38:32 UTC
After updating beta9 to RC1, my system was no longer bootable :-( The last things I could see: Grub loading stage1.5 Grub loading, please wait Then my screen was black. The system did not respond to any key (tested the "usual suspicious" keys esc, return, ctrl-alt-del). I booted from CD, run grub-install /dev/hda manually (I remembered bug 144688 ;-)), but this didn't help. After some more testing, I found the solution: uncommenting gfxmenu (hd0,6)/boot/message made grub working at least in text mode. This could be related to bug 164771 - but 164771 doesn't seem to prevent booting.
Created attachment 78590 [details] y2logs
Created attachment 78591 [details] /boot/grub/menu.lst "gfxmenu" commented out to make the system booting, otherwise unchanged since update to RC1
Created attachment 78592 [details] /boot/message - probably broken
do you have a backup of the B9 installation? Is there a difference between /boot/grub/menu.lst /boot/grub/devices.map /etc/sysconfig/kernel ?
/etc/sysconfig/kernel: DOMU_INITRD_MODULES was added, otherwise no changes. Content of the file after removing all comments: --- b9-sysconfig-kernel-nocomment 2006-04-15 13:30:55.000000000 +0200 +++ rc1-sysconfig-kernel-nocomment 2006-04-15 13:31:17.000000000 +0200 @@ -1,9 +1,10 @@ INITRD_MODULES="piix processor thermal fan jbd ext3" MODULES_LOADED_ON_BOOT="" ACPI_DSDT="" SHMFS_SIZE="" SCHED_MINTIMESLICE="" SCHED_MAXTIMESLICE="" SHMFS_OPTIONS="" SKIP_RUNNING_KERNEL="" DEV_ON_TMPFS="yes" +DOMU_INITRD_MODULES="xennet xenblk" /boot/grub/devices.map contains the following line (unchanged IIRC): (hd0) /dev/hda Unfortunately, I don't have a backup from /boot as of beta9 - but I found a menu.lst.old dated 2006-04-02 - this should match the beta9 timeframe. I see some changes, but none of them should be related to this bug: --- menu.lst.old 2006-04-02 20:39:44.000000000 +0200 +++ menu.lst 2006-04-14 23:16:47.000000000 +0200 @@ -1,50 +1,50 @@ -# Modified by YaST2. Last modification on So Apr 2 17:23:54 CEST 2006 +# Modified by YaST2. Last modification on Fr Apr 14 22:59:55 CEST 2006 color white/blue black/light-gray - default 1 + default -> default was lost during update - another (minor) bug? timeout 8 - gfxmenu (hd0,6)/boot/message +# gfxmenu (hd0,6)/boot/message -> as described, I commented this out manually in rc1 title SUSE LINUX 10.0 color white/blue black/light-gray - default 0 + default timeout 8 gfxmenu (hd0,6)/boot/message kernel (hd0,4)/boot/vmlinuz root=/dev/hda5 vga=0x342 selinux=0 resume=/dev/hda2 splash=silent showopts initrd (hd0,4)/boot/initrd The remaining changes were changes to the "title" of sections (10.1 10.1 - already handled in another bug) and to kernel parameters - but nothing that could affect grub itsself.
Created attachment 78601 [details] /boot/grub/menu.lst.old (probably from beta9)
What happens if you change the vga setting to vga=0x1 ? (And uncomment gfxmenu) Of course you hit as well bug #164771, but as you boot another section, this doesn't fail. I'm wondering why back.jpg is about 31k larger than on my machines. maybe this is the culprit. Torsten?
(In reply to comment #7) > What happens if you change the vga setting to vga=0x1 ? > (And uncomment gfxmenu) What exactly do you mean? If you are talking about kernel parameters: this probably won't help because it's already grub that shows the black screen. As described, the last message I see is "grub loading, please wait". (If I understood you wrong, please provide a (pseudo-)diff of menu.lst containing your changes/idea.) BTW: The machine is a Acer Travelmate 803 laptop with 1400x1050 display. BTW2: Maybe you should send me a working 1400x1050 /boot/message - I can then test if "just" /boot/message is broken or if there's another problem.
Created attachment 78868 [details] proposed patch to menu.lst
As already expected in comment #8, vga=normal did not cause a relevant [1] change here. With the following "global" section in menu.lst, my laptop boots: color white/blue black/light-gray default 1 timeout 8 As soon as I add gfxmenu (hd0,6)/boot/message _grub_ gets stock with a black screen again. (The linux kernel is never reached.) [1] Of course, the boot splash was lost and I don't need my glasses to read the boot messages ;-) And I found out that the radeon10b X driver problem (TTYs broken) is not a general problem, but related to the framebuffer ;-) (freedesktop.org #1669 IIRC)
The other problems in this bug seem to be duplicates. The remaining problem is that gfxmenu /boot/message does not work. Were there any changes in RC1 that cause /boot/message to fail? Assigning to snwint.
/boot/message is too large, namely due to the large background picture. I've no idea where the 50k back.jpg comes from. Certainly not from one of may packages.
_my_ packages, of couse :-)
Yes, this comes from bootloader-theme-SUSELinux-Prof-2006.3.31-3 changelog: * Fri Mar 31 2006 - dobey@suse.de - Update to the blue SUSE Linux bootloader background which is a 800x600 true color image and about 50k Size. Wondering why this didn't hit anybody else..... reassigning to maintainer
It seems to work with the large (50k) image on bizet. Open questions: jsrain: - Is this fixed in bootsplash-theme? snwint: - What are the size restrictions for the back.jpg image? - What does this depend on? - So will this bite us with other pictures or at other points?
That package is only on the ftp server and not on our media. I added a lower resolution version to it - and a check that the image is less than 36KB (which is the file size).
ad 15) Larger images may or may not work, depending on the memory size the BIOS leaves us. The picture I provide is about the max size. ad 17) Andreas, not *NOT* add another picture! Whatever package you are talking about: remove it, delete it in our PDB and forget that it ever existed! And 36k is certainly too large. bootsplash-theme-XXX already _does_ have the right picture that is provided by the gfxboot package.
Steffen, you told me once that 36 k is enough. Ok, package marked as frozen for now.
It depends on the size of the other files, too. Besides, for betas we can risk a bit more. The real nuisance is that those extra packages exist at all.
Will take care of the packages after 10.1, not a blocker anymore.
Sorry, but I have to re-Blocker this bug :-( The update to RC 2 showed exactly the same symptoms (black screen in grub) and commenting out the gfxmenu line in menu.lst again helped to make the system bootable. I'll attach fresh y2logs and the current /boot/message from RC2. If there's anything I can test for you, just let me know. The relevant section from menu.lst (in bootable form, remove the # from the first gfxmenu line to make it unbootable): # Modified by YaST2. Last modification on Mo Apr 24 22:06:08 CEST 2006 color white/blue black/light-gray default 1 timeout 8 # gfxmenu (hd0,6)/boot/message # gfxmenu (hd0,6)/boot/message title SUSE LINUX 10.0 [...] ###Don't change this comment - YaST2 identifier: Original name: linux### title SUSE LINUX 10.1 root (hd0,6) kernel /boot/vmlinuz root=/dev/hda7 vga=0x342 resume=/dev/hda2 splash=silent showopts initrd /boot/initrd
Created attachment 79771 [details] /boot/message from RC2
Created attachment 79772 [details] y2logs from update to RC2
You still have the large picture. Which version of bootloader-theme-SUSELinux-Prof do you have?
btw. bootloader-theme-SUSELinux-Prof is not even in factory right now - downgrading severity.
# rpm -q bootloader-theme-SUSELinux-Prof bootloader-theme-SUSELinux-Prof-2006.3.31-3 rpm -qi says Install Date: Fr 14 Apr 2006 20:59:55 CEST
So, that's much older than RC2. Delete it and your system will be fine. This bug will not hit anybody doing a normal update, and the package has been fixed meanwhile.
I uninstalled bootloader-theme-SUSELinux-Prof-2006.3.31-3 and upgrade to RC3 went fine :-) However, (In reply to comment #21) > Will take care of the packages after 10.1, not a blocker anymore. Does this mean you should reopen the bug?