Can't boot because of kernel panic

[BenoitRen]

Target: Pentium II 350 Mhz, 128 MB RAM, Matrox video card
ISO: puppy 2.12 seamonkey

I wanted to let my siblings use Puppy Linux on the Linux box while I mess with the Linux installation on the hard drive. Sadly, Puppy doesn't boot, it throws a kernel panic. I didn't find any more information on my issue searching Google and this message board.

I burned the ISO again, thinking that maybe there was an error, since I had SeaMonkey open at the time, even though I was only typing, and not browsing (so no disk activity), but maybe there was not enough free RAM. Didn't help.

I tried booting Puppy on my personal PC thanks to pakt's WakePup, and it went fine. So the ISO must be okay.

Here's the output of the boot procedure on the Linux box:

Code: Select all

Now executing 'init' script in initial-ramdisk...
(Note: initial-ramdisk is retained and in /initrd after bootup)
Loading kernel modules...                                       done
Looking for Puppy in hdc...                                     done
Looking for pup_save.3fs in hdc... hda1...                      done
Loading swap partition /dev/hda5...                             done
Mounting /dev/hdc on (/initrd)/mnt/dev_ro1...                   done
Creating tmpfs for pup_212.sfs on (/initrd)/mnt/tmpfs...        done
Copying pup_212.sfs to tmpfs... mounting on (/initrd)/pup_ro2...failed
Dumping last lines of /tmp/bootinit.log...
USB-Storage: Device scan complete, found 0 devices
mount: /dev/hdc is write-protected, mounting read-only
reading '/mnt/dev_ro1/pup_212.sfs': Input/output error
mount: Mounting /dev/loop0 on /pup_ro2 failed: Invalid argument
Dumping last lines of kernel log...
attempt to access beyond end of device
loop0: rw=0, want=132556, limit=35040
SQUASHFS error: sb_bread failed reading block 0x102e5
SQUASHFS error: unable to read uid/gid table
Pausing for 60 seconds...
Mounting tmpfs on (/initrd)/pup_rw...                           done
Creating unionfs on (/initrd)/pup_new (to become '/')...        done
Kernel panic - not syncing: Attempted to kill init!

Thanks in advance.

By the way, I want to curse at whoever made it so difficult to find WakePup. The official Puppy Linux page references it, and tells you to create it from the setup menu. Um, what setup menu, I need WakePup to boot Puppy in the first place! Weeks ago I found it through the beginner topic, this time I found it through Google.

[Sit Heel Speak]

One common cure for this sort of thing, is to (during the 5-second live-CD boot interval when you can specify these things) start Puppy using the

puppy irqpoll

option. Or perhaps

puppy irqpoll nodma

in the rare case where it's an add-in CD drive, and DMA isn't enabled for it in both BIOS setup and via the drive's own (if so equipped) jumpers.

[BenoitRen]

Thanks, that worked... at least for a while.

When I quit Puppy, I asked it to back-up to the HDD. Next time I started up, it threw an additional error. Trying to boot with the second option didn't change anything.

This is what it gave. I put a '-' before what changed. Notice also that it didn't try to search for a USB drive, if that matters.

Code: Select all

Now executing 'init' script in initial-ramdisk...
 (Note: initial-ramdisk is retained and in /initrd after bootup)
 Loading kernel modules...                                       done
 Looking for Puppy in hdc...                                     done
 Looking for pup_save.3fs in hdc... hda1...                      done
-Using personal data file pup_save.3fs which is on partition hda1done
 Loading swap partition /dev/hda5...                             done
 Mounting /dev/hdc on (/initrd)/mnt/dev_ro1...                   done
 Creating tmpfs for pup_212.sfs on (/initrd)/mnt/tmpfs...        done
 Copying pup_212.sfs to tmpfs... mounting on (/initrd)/pup_ro2...failed
 Dumping last lines of /tmp/bootinit.log...
-mount: /dev/hdc is write-protected, mounting read-only
 mount: /dev/hdc is write-protected, mounting read-only
 reading '/mnt/dev_ro1/pup_212.sfs': Input/output error
 mount: Mounting /dev/loop0 on /pup_ro2 failed: Invalid argument
 Dumping last lines of kernel log...
 attempt to access beyond end of device
 loop0: rw=0, want=132556, limit=35040
 SQUASHFS error: sb_bread failed reading block 0x102e5
 SQUASHFS error: unable to read uid/gid table
 Pausing for 60 seconds...
 Mounting tmpfs on (/initrd)/pup_rw...                           done
 Creating unionfs on (/initrd)/pup_new (to become '/')...        done
 Kernel panic - not syncing: Attempted to kill init!

So I deleted the back-up file, and then it booted again. But then something happened as my sister powered down the computer incorrectly, or something. I'm not sure. Anyway, there was no back-up file that I could see, yet it still wouldn't boot. Strangely enough, using the second option did work.

So, what's going on here?!

[BenoitRen]

Bumpity bump.

[BenoitRen]

Bumpity bump again.
Is there no one that can help me with my problem?

[Sit Heel Speak]

loop0: rw=0, want=132556, limit=35040

That "want" value is, I suspect, how many kilobytes of memory the mounting of the squashfile needs. Unfortunately you have only (1024*128=) 131,072

Just a small enough difference that it was somewhat able to load before.

Perhaps if you were to try pakt's "Barely Pup" and add the packages you need, one at a time...

Otherwise, I guess you need more memory.

Someone correct me if I'm mistaken as to what "want=" means...

[GuestToo]

reading '/mnt/dev_ro1/pup_212.sfs': Input/output error
mount: Mounting /dev/loop0 on /pup_ro2 failed: Invalid argument

there seems to be a problem reading the pup_212.sfs file ... could be a hardware problem (bad disc, a disc that does not work well with that particular drive, not enough ram, bad ram, dma problems, possible irq conflict, etc etc) ... or it could be software (corrupted file system on the disc because the iso was corrupted, Puppy's drivers may not work well with your hardware, etc etc)

the disc might work well in one drive and not well in another

SQUASHFS error: sb_bread failed reading block 0x102e5

again, it seems to be having trouble reading from the disc ... you could do a scandisk of the disc to see whether it looks like a good burn ... Nero's drivespeed works well (Windows program) or you can do a similar scan using Dvdisaster (available as a dotpup package) ... or you can do a c2scan using readcd (a c2scan using readcd does not work in Puppy on my machine, but readcd.exe does work well in Windows, on my machine)

sometimes just installing a different cd drive works

http://www.cdspeed2000.com/
http://murga-linux.com/puppy/viewtopic.php?&t=12326

[BenoitRen]

I don't think the CD is at fault, because on my personal PC it boots fine (and without a save file it does on the other PC too). Yesterday I made a save file on my personal PC, and booted Puppy Linux again. Still no problems.

I've read problems with Matrox video cards, though that was with version 2.13. The video card the Linux box has is a Matrox one. Maybe that's the problem?

Maybe in the end a better CD drive would be the only way out...

[Sit Heel Speak]

I've read problems with Matrox video cards, though that was with version 2.13. The video card the Linux box has is a Matrox one. Maybe that's the problem?

Could be. If you are trying Xorg, the logfile is /var/log/Xorg.0.log so if you can post that we might see clues. Or might try XVesa and see if that works.

[BenoitRen]

I always use Xvesa. Puppy Linux always boots fine if it manages to copy pup_212.sfs, so X isn't the problem.

By the way, yesterday I couldn't boot with either option, and there is no save file. I have the suspicion that Puppy Linux is leaving some files on the hard drive when it doesn't shut down properly. Or something.

[Sit Heel Speak]

Hmm. Sometimes yes, sometimes no...makes me suspect memory...specifically, perhaps the particular machine is somehow occupying part of your 128MB with shadow RAM or is sharing its RAM for video purposes, which means that you have (effectively) less than 128MB. What I would try is, go into BIOS setup and see to it that all your shadow RAM is disabled. If it's an AGP video card then set AGP aperture to minimum, like 16MB, or zero if it's a PCI video card. Then, see if freeing up all this memory enables the machine to boot Puppy off the live-CD or -DVD.

According to WhoDo (and I've read this elsewhere also), writing at

http://murga-linux.com/puppy/viewtopic.php?t=15490

...if you have 128MB of RAM, then a frugal install (vmlinuz, pup_2xx.sfs, initrd.gz, and a dummy file pupxide copied from the CD into C:\ and then booted using grub, lilo, or what-have-you) is the best boot-from-disk option because Puppy will load most of itself in RAM for speed, and only call on the hdd as it needs to save or open other stuff; and, if you had less than 128MB of RAM then a normal hdd install (i.e. all Puppy on one or more ext2 or ext3 partitions, like an ordinary Linux install) would be better.

I suspect that, since you are right on the threshold at 128Mb of RAM, if any is being occupied for system or video purposes then a full hdd install might be safer. Either that, or else go spend $10-20 on an additional memory stick, provided you have an open slot. I don't have a low-on-memory problem, since none of my machines carries less than 256MB of RAM.

[BenoitRen]

Earlier today it booted, and now that my sister wanted to use it, it didn't want to. With either option. Aargh!

When it boots, it mentions the system BIOS and the video BIOS being shadowed. I've looked everywhere in the BIOS setup multiple times. I've turned off what I think could be loading those into RAM under PCI devices. In the memory cache section, there's this "Shadow/Cache ISA Option ROMs" entry that is inaccessible.

It's a PhoenixBIOS. If anyone is familiar with it...

[Sit Heel Speak]

Still insufficient memory, in all likelihood. All I can suggest at this point is:

1. Take the computer to your local hole-in-the-wall computer shop, or CompUSA or the like, and add another $25, 128MB stick of RAM. Or even a $15, 64MB stick might be enough. I can run Puppy 2.12 in 192MB of RAM, no problemo.

or

1. Boot without loading the savefile:

puppy pfix=ram irqpoll

2. File Managers--RoxFiler up and over to initrd/mnt/dev_save and erase the pup_save.2fs file.
3. Shut down.
4. When Puppy asks to create the new savefile, choose a small size--say, half the free disk space (shown in Utilities--MUT) or 256MB, whichever is lesser, for the size of the savefile.

If creating this small savefile allows you to start Puppy reliably, then next I would suggest you use GPartEd to shrink the existing partition and make yourself a small Linux swap partition (after defragging, if Windows is on the machine), of size 256MB, to ease the memory crunch somewhat.

[BenoitRen]

I really don't want to buy additional RAM for the sole purpose of booting a LiveCD, so that's out. I tried making a save file of 128 MB, the same size as my RAM. That didn't work out at all.

I went looking for another distro to experiment with. But they all were these huge affairs with a load of crap you don't need, and resource-hungry window manager (Gnome, KDE). Then I realised that Puppy Linux is mostly the distro I wanted in the first place.

I installed Puppy Linux on the PC with GRUB as boot loader. I first had remove the extended partition and format the ext3 one, and then the installation went fine, without it detecting a mystery vfat partition.

It's fast, light, saves my settings, and has SeaMonkey. I'm happy, and I guess my siblings and parents will be too.

Thank you for the assistance, both of you.

[Sit Heel Speak]

I installed Puppy Linux on the PC with GRUB as boot loader. I first had remove the extended partition and format the ext3 one, and then the installation went fine, without it detecting a mystery vfat partition. It's fast, light, saves my settings, and has SeaMonkey. I'm happy, and I guess my siblings and parents will be too.

Glad it worked out. I suspect that it would help when having multiple windows open, if you were to re-install and, this time, put a 128 or 256MB Linux swap partition (not swap file) on the disk. Puppy auto-senses a swap partition upon bootup and can use it as a full-fledged extension to the physical RAM. It can't do that with a swap file.