Bug 373569

I was right. Caught on the serial console:

10) sda11 (6.5 GB, ext3)

> 10
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..

Hello, 

please boot another linux and send me these informations:

1. dmesg
2. lspci -vvv or/and lshw
3. lsmod
4. If you have configuration od your kernel (in /boot/ or sometimes in /proc/config.gz) please send it too

Thanks !

Created attachment 206733 [details]
efika hw info

This is from 10.3, as I don't have a bootalbe factory at the moment...

Current factory (2008-04-09) still expresses this behavior. Logs for factory attached.

Created attachment 207043 [details]
efika hw info from factory

Still there in beta1. Raising severity, as this makes installation even for experienced users difficult.

Problem also occurred on PowerBook Wallstreet G3 Series II laptop.  

Description:

Installation starts and proceeds normally.  After initial reboot, installation initrd and linux32 files are used(because the Old World Macs can't boot directly and have to use BootX, and there is no provision to copy the new initrd and vmlinux files to the MacOS drive) for 2nd boot.  After choosing "start installed system", the system hangs up and then reboots after approx 3 minutes.

By pressing Alt-F3 immediately after starting the installed system, I got a screen full of stuff(unfortunately, I can't see the beginning because I can't scroll back).  I've included what I see on the screen as an attachment.(note:  this is what I got AFTER I managed to finish the install using the following work-around.  I have no idea if this will make a difference or not).

By pressing Alt-F4 this is displayed:

REISERFS (device hda9): found resierfs format "3.6" with standard journal
REISERFS (device hda9): using ordered data mode
REISERFS (device hda9): journal params: device hda9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
RESIERFS (device hda9): checking transaction log (hda9)
REISERFS (device hda9): Using r5 hash to sort names
init has generated signal 4 but has no handler for it
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..

Work-around:  By starting the rescue system and mounting / and the MacOS partition, I was able to copy the initrd_2_6_22_17_0.1_default and vmlinux_2_6_22_17_0.1_default files to the MacOS partition and select them with BootX and then the system started fine and finished the installation.

Suggestion:  Since the installation DVD no longer has the linux32 and initrd files(the have to be extracted from the linux32.gz file), have these files and then the installed initrd and vmlinux files in a tarball available for download.  This would help not only in this situation, but it would help out on any installation so that the installed initrd and vmlinux files are available on the MacOS drive at the beginning.  The only problem I forsee would be having to also have the current initrd and vmlinux files after any new kernel update available as well.  I wish there was a better way to boot on Old World Macs.....

Created attachment 210565 [details]
Info from Powerbook Wallstreet Series II

Includes:  

dmesg.txt
lspci.txt
lsmod.txt
problem.txt - output of Alt-F3 screen after lockup

Steffen, does booting into the installed system still work on x86?

No, I don't think it works. I think the way to go presently is
to start the rescue system and use kexec.

(In reply to comment #9 from Olaf Hering)
> Steffen, does booting into the installed system still work on x86?
> 

No, just tested with beta2 on an Intel Core2Duo machine. The only difference from PPC is that, there is no kernel panic, but it goes back to the linuxrc opening screen. I get a red screen with:

"sorry, linuxrc crashed at address 0x7f823c756a00
linuxrc has been restarted in manual mode"

And on F4 the last lines are:

init[1] segfault at 7fff44000000 ip 7f823c479623 sp 7fff451825c0 error 4 in libc-2.8[7f823c402000+14f000]
Startup...

(no guarantee, that numbers are correct, I can't read my own handwriting :-) )

I really hope that booting into the installed system did not turn into rocket science.

It never really worked in the past.

As already mentioned, use kexec, if you really need to do this.

And how do we use kexec?  Also, linuxrc has always worked.  That's how I started the installed system on all my Powermacs since v10.0Beta1.  While I like the way that the new system works(because it did on my Thinkpad), but isn't a little confusing for the inexperienced user who sees "preparing to reboot" and then sees that the system starts properly.  While there is a work around, it would be more helpful to have the initrd and linux32 files for both the install and the installed system available to download for the Old World users(unless I am the only one?).

Just start the rescue system and kexec kernel & initrd.

'start installed system' _never_ really worked. Simply because it is
a broken concept and _cannot_ work.

The only case where it sometimes works is the scenario described here. That
is, when a fresh install does not boot and you have to fix up the bootloader
setup. And that is a thing you can as well (resp. better) do from the rescue
system (even without kexec). And that is IMO, quite frankly, abusing this
feature. I do not see it as linuxrc's main task to cover up for broken ppc
bootloader config tools. I know it probably doesn't help you, but: What's
that 'repair installed system' option for, anyway?

I'm programming linuxrc for several years now and I can't remember a
single case where I used that option. It's basically there because this
was the way to start the second install phase, but that was really long
ago.

If it were possible to get Apple to release the code for their older Open Firmwares, a better bootloader could probably be written.  There is the quik bootloader, but it is a pain to use because of all the broken pieces of open firmware in these old macs.  So long as there is a way to get at the installed system and move the kernel and initrd files, that is what is needed.  The advantage to using the boot installed system option is if you haven't updated the system after installation, it lets you go ahead and finish the install and get to the system.  Booting the rescue system is one extra step in this type of situation.

As I have asked before, why is it that the initrd.gz and linux32 files are no longer in the suseboot directory?  Why not add a directory to the installation disc like "boot-Old World Macs"?  Then you can have the install kernel and boot kernel available at one time.  The only downside is that if you do an update during the installation the kernel is the wrong one.

I realize that it can be a lot of work to support older systems.  Perhaps we can spilt off the Old World Mac support into a seperate area, that I would more than willing to help setup, for anyone interested in running openSUSE on these old machines.  Basically a "Not officially supported" section?  I've actually managed to install v11.0Beta2 on a PowerMac 6500(603ev/250, 256k motherboard L2, 128MB RAM(Max).  Other than a segfault during installation when trying to uncheck the "automatic configuration" and then trying to run SaX2 from the command line and hard locking the system(which is strange, because the gui version worked fine), everything worked properly, albiet slowly.( and a G3 upgrade would probably make the system very useful for browsing and work processing at least).  A G4 upgraded system (like my 9600 with the G4/700 or my G3-AIO w/ a G4/366) is a decent desktop system.

That's a question for Olaf.

(In reply to comment #15 from Steffen Winterfeldt)
> Just start the rescue system and kexec kernel & initrd.

kexec says:
"Supported kernel file types and options:
elf-ppc64
elf support is still broken
"
And that seems to be the case, as running kexec says:
"could not get memory layout"

> 'start installed system' _never_ really worked. Simply because it is
> a broken concept and _cannot_ work.

In practice it works. Even on x86 (see below). On PPC there are just too many different booting methods to cover them all from YaST, so obviously, even if in an ideal world all of them are supported from YaST (or at least those I use :-) ), in practice some boards can't be installed without 'boot installed system'.


> I'm programming linuxrc for several years now and I can't remember a
> single case where I used that option. It's basically there because this
> was the way to start the second install phase, but that was really long
> ago.

Well, I use it quite a lot also on x86, it is very handy. It is a lot better, than chroot-ing from 'rescue' or use the 'repair' tools. So it works nicely not just for freshly installed systems, even on x86.

kexec is not an option on ppc32, unimplemented.
booting into the installed system cant be rocket science, if initrd can do it, linuxrc can do it too.
I moved the linux32/initrd32 files from FTP to CD1.

I have needed boot installed system on many occasions, including when alpha testing has killed my system. There is nothing easier than booting the installed system and reinstalling the kernel and / or fixing the bootloader.

I also used it frequently.  For example if you recompile a kernel and mess it up.
I needed it in OpenSuSE 11 when the detected pae kernel did not work, and I had to install the default kernel.  YaST wouldn't run in rescue system.

*** Bug 411904 has been marked as a duplicate of this bug. ***

*** Bug 414149 has been marked as a duplicate of this bug. ***

Is back.

Well, at least linuxrc does not crash.

Is that in the factory or the Alpha 1?  And does that cover x86 or ppc?  If you need ppc tested, either myself(might take a few days) or Peter should be able to find out.

The fix is (will be) in alpha2, all archs.