Bug 481354

Summary: Factory doesn't boot in VirtualBox anymore
Product: [openSUSE] openSUSE 11.2 Reporter: Peter Poeml <poeml>
Component: YaST2Assignee: E-mail List <yast2-maintainers>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Blocker    
Priority: P5 - None CC: chrubis, jdd, mantel, schoppehaller
Version: Factory   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: VirtualBox log, with a successful log snippet added for comparison

Description Peter Poeml 2009-03-03 08:40:53 UTC
Every Factory image upgraded yesterday or the day before ceased to work
for me, and the current images out there fail in the same way. They all
stop with a black screen at the time where the kernel should be
loading (or starting to be loaded maybe). VirtualBox aborts and says
"aborted". 

It doesn't seem to be a quirk in VirtualBox, and not a bug in the
handling of the snapshots I had accumulated (which was my first
suspicion). It didn't change anything to start with a fresh harddisk
without snapshots.
Other images I have around (FreeBSD, Ubuntu, ArchLinux, 11.1) work.

I played with VirtualBox config options, to no avail. Reinstalling the
bootloader didn't help.

I booted a rescue system, recreated the initial ramdisk, and noticed
that mkinitrd includes about 87 modules into the initial ramdisk, which
seems weird. (It gives an initrd 13 megs in size, uncompressed). I
wondered why the initrd is just a simple gzipped cpio archive, I had
expected something fancier, but maybe this is the way things are done
today.

I later was able to boot the system with an 11.1 kernel, with an initrd
created with 11.1 mkinitrd.
Comment 1 Stephan Kulow 2009-03-03 10:57:51 UTC
the initrd is gzipped cpio since about forever.

Does failsafe boot?
Comment 2 Peter Poeml 2009-03-03 11:00:57 UTC
No, it didn't work either.
Comment 3 Jean-Daniel Dodin 2009-03-03 17:53:41 UTC
same here, and still no other kernel (zypper up says: nothing to do).

I could boot with the only kernel I found on the factory cd, that is the one named vmlinuz-xen and it's initrd-xen

many time ago there where kernel problems I though now updates could let a default kernel stay.

The crash occurs very early in the process. I can boot with the grub console, it crashes at "probing EDD", nearly immediatly when pressing boot
Comment 4 Jean-Daniel Dodin 2009-03-03 18:12:33 UTC
note: the pae kernel, installed from YaST, boots (with the correct option in virtualbox)
Comment 5 Peter Poeml 2009-03-03 18:57:49 UTC
Interesting - I had tried the VirtualBox pae option, but not the pae
kernel (I had only one kernel on the system unfortunately).
I can confirm the pae kernel works here, too (with the option).
(Thanks for finding out!)

> I though now updates could let a default kernel stay

"could" is the magic word, it is now *possible*, but it's not actually
*done*. Factory expects from its users that they want to spend
considerable time in training their recovery abilities, or that kernel
updates never break, which is both rather unlikely IMO... ;)
Comment 6 Jean-Daniel Dodin 2009-03-03 19:44:07 UTC
I found the pae kernel seraching any other kernel with YaST. I noticed that even if YaST installed the new kernel, it didn't cnange the default (the new kernel is install together with the old one)
Comment 7 Peter Poeml 2009-03-04 21:42:10 UTC
Created attachment 277169 [details]
VirtualBox log, with a successful log snippet added for comparison

It just occured to me that VirtualBox has a log file. What it logs looks
rather unconspicious to me, though.

With the PAE kernel booting, this isn't a blocker for me anymore. But
maybe for other people.
Comment 8 Cyril Hrubis 2009-03-19 15:37:51 UTC
Well not sure where this problem came from, lets yast people have a look.
Comment 9 Daniel Fuhrmann 2009-03-19 15:56:52 UTC
The newest update (netinstallcd build 035) solved this problem for me. I could update my installation with the netiso. In the factory-list this thread was also solved.

Do you still want to search why this happend?
Comment 10 Jean-Daniel Dodin 2009-03-19 17:14:40 UTC
if you want. But what can I do? my instal boots, now :-(
Comment 11 Hubert Mantel 2009-03-23 12:28:48 UTC
If one kernel works and another not, this sounds like a kernel issue to me, not a YaST bug. But judging from comments #9 and #10, it seems the problem is already fixed. Can you confirm that?
Comment 12 Jean-Daniel Dodin 2009-03-23 18:47:31 UTC
seems to work, now, don't know why. But it's obviously a boot problem, so grub or kernel related
jdd
Comment 13 Steffen Winterfeldt 2009-04-01 10:32:07 UTC
I'll close the bug as the reported issue seems to be gone.