I am trying to get puppy running on an AMD Pentium III machine with 128 MB RAM which runs Win98 just fine. I am using grub and a poor man's install. Disk inventory is as follows:
c:\vmlinuz
c:\initrd.gz
c:\pup_210.sfs
All of these are copied right off the live CD.
My menu.lst looks like this
title Puppy RAM
rootnoverify (hd0,0)
kernel /vmlinuz root=/dev/ram noapic PFILE=pup001-none-262144 PHOME=hda1
initrd /initrd.gz
My autoexec.bat file has a line to put c:\boot\grub on the path.
To start puppy I boot to DOS and then start grub
This has worked before on a machine with 256 MB RAM. However when I attempt to boot puppy 2.10 it boots the very first time. I save the configuration and attempt to boot again. On the second and all subsequent boots the boot hangs at 'loading kernel modules'.
I think this is related to the low amount of RAM on the machine but I don't know how to get a swap file turned on if puppy won't get to where it is executing /etc/rc.d so it can use the swap file.
I am sure the problem goes with the machine as after I boot once and configure puppy, it won't boot from the live CD either.
All boots hang at the 'loading kernel modules' line.
puppy 2.10 will only boot once
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
seems to be memory related
Thanks for trying to help.
I changed the menu.lst lines to match yours but it had no effect. It seems to be a RAM problem. If I boot from the live CD, sometimes it works but sometimes it hangs (at "loading kernel modules"). Sometimes I get a segmentation fault just before the "loading kernel modules" line but the boot keeps going.
I am going to try adding RAM. Is there a way to run a RAM diagnostic from Puppy because I think I have a segment that is giving random parity errors.
I changed the menu.lst lines to match yours but it had no effect. It seems to be a RAM problem. If I boot from the live CD, sometimes it works but sometimes it hangs (at "loading kernel modules"). Sometimes I get a segmentation fault just before the "loading kernel modules" line but the boot keeps going.
I am going to try adding RAM. Is there a way to run a RAM diagnostic from Puppy because I think I have a segment that is giving random parity errors.
Re: seems to be memory related
Not from Puppy, but there is a better way. Get yourself a copy of the Ultimate Boot CD (not the Windows version). It contains a heap of diagnostics and it runs under ISOLINUX.swarnick wrote:I am going to try adding RAM. Is there a way to run a RAM diagnostic from Puppy because I think I have a segment that is giving random parity errors.
http://www.ultimatebootcd.com/
Hope that helps.
An alternate stand-alone bootable linux rescue media such as RescueCD is available IF you can boot from CD -
it contains many useful Linux tools -including Memtest.
System RescueCD
Create a Linux swap partition - Puppy will find, use it.
If you cannot boot a Linux CD there are floppy rescue disks
such as R.I.P (Rescue is Possible - Google for others.)
Most will include md5sum as well as more Linux commands/utilities
-
Don't most commercial Sys Admins have Linux Memtest
However that program accesses same Mem addresses in infinite loop.
A better randomised stressing of chips is to use md5sum against a huge graphlcal DB
OR run md5sum against generated
Rainbow Tables
First try swapping physical slots - if one flag does not reliably reset -swapping positions may place the faulty bank
in linnear paging array so that it never gets touched in same sequence again.
(it is not known if flag fails at open or closed state.
It may also be the "pointer" that is faulty.
RAM
it contains many useful Linux tools -including Memtest.
System RescueCD
Create a Linux swap partition - Puppy will find, use it.
If you cannot boot a Linux CD there are floppy rescue disks
such as R.I.P (Rescue is Possible - Google for others.)
Most will include md5sum as well as more Linux commands/utilities
-
Don't most commercial Sys Admins have Linux Memtest
However that program accesses same Mem addresses in infinite loop.
A better randomised stressing of chips is to use md5sum against a huge graphlcal DB
OR run md5sum against generated
Rainbow Tables
First try swapping physical slots - if one flag does not reliably reset -swapping positions may place the faulty bank
in linnear paging array so that it never gets touched in same sequence again.
(it is not known if flag fails at open or closed state.
It may also be the "pointer" that is faulty.
RAM