(old)Puppy Linux Discussion Forum

Old desktop: AMD Athlon XP processor, 256MB RAM, 30GB hard drive

I've done a frugal install of Browser Linux 5.0.1 to the hard drive (ext4 partition) and done some customizations to jwmtray and installed Google Chrome. Nothing major.

If I shutdown the computer, the next time it boots, it hangs on the error message:

"waiting for modules to complete loading... usb"

I kill the power, start the computer again it boots up fine.

If I select "Reboot" from the shutdown menu, it reboots fine.

So, it seems that something is going wrong in the shutdown process - and yet it's being fixed on the 2nd boot attempt (strange).

Any ideas?

Has this old computer only got USB 1.1? (If you're not sure, try Menu -> System -> Hardinfo.)

I think it is USB 1.1.

Hardinfo shows the USB controllers but doesn't show "2.0" in the description. Also, searching online for the model (Compaq Presario 6029US) I found no mention of this model having USB 2.0 support.

Assuming it's USB 1.1, is this the cause of the problem? And if so, is there a way to fix this?

I can't say if the problem is due to the USB 1.1. It just came to me to ask about it.

I assume you installed Puppy from a CD. Did the CD boot without errors or delays before you installed Puppy?

Also I think ext4 is a troublesome format for Puppy. However, I've never installed Puppy in a hard disk so don't go by me.

Yup boots fine from a CD. I think the problem is definitely connected with the shutdown process, since it reboots fine (choosing "reboot" from the shutdown menu).

Does anyone else have any insight on this problem? Should I post in a different forum? I've already posted in Puppy Derivatives and got no answer there.

Hi there,

Be warned, I'm a bit crap at diagnosing problems but have you tried creating a new save file? boot from the CD with puppy pfix=ram, drag your existing savefile to another partition or just rename it so it's not found, shut down and create new savefile and see if the problem remains.

I've never used ext4, don't know if that might cause the problem. I always opt for ext3, don't usually have any problems.

You could try a newer puppy, I think browser linux is pretty old, although that shouldn't really be a problem. I've run older without any major issues.

Let us know how you get on.

I've tried doing both a frugal install and a full install on both ext3 and ext4 file systems. The problem persists regardless.

I have determined that the problem is connected to the "nosmp" switch in grub's menu.lst. With "nosmp" in place, the problem occurs like clockwork (system hangs on waiting for USB module at next boot). If I remove the "nosmp" switch the problem goes away - BUT the computer no longer powers off at the end of the shutdown process (I have to manually press the switch).

If anyone can suggest a good alternative to browser linux I'd be happy to try, but I want something that's very minimal: practically nothing extra installed as all I want running is Chrome or Firefox. Basically I want something like Chrome OS but which runs well on old machines (Chrome OS won't boot on systems without PAE support).

Well, I told you I was crap

What about using grub4dos for booting?

There are several Puppy versions with PAE. Perhaps one of them will work and can be used to do what you want.

I don't need PAE by any means, and in a broader sense (a lightweight linux solution for older computers) it's probably better if it doesn't have PAE since that prevents incompatible computers from booting.

Would using grub4dos possibly solve this? I figure that the nosmp switch is something that's passed to the kernel so it's more to do with the kernel itself, and I'd run into the same problem with grub4dos (a choice between the computer either hanging on boot or not powering off automatically at the end of the shutdown process).

I am surprised that there isn't a better option for a Chrome OS alternative based on Puppy. It seems like the perfect platform for that purpose for older PCs.

Look into /etc/rc.d/rc.sysinit .

Lupu 5 series relies on /sbin/pup_event_backend_modprobe_protect return value .

If you manage to mount the partition read-only somehow, the /tmp/pup_event_backend_modprobe_protect-pipe might not work correctly
and rc.sysinit waits forever for a return value .

Same if the files in /tmp remain somehow at shutdown .

Since Puppy-5.3 /sbin/pup_event_backend_modprobe_protect has been dropped,

and since around Puppy-5.4 /tmp/* gets deleted at boot, so no disturbing files left in there then .

A debug console on ALT+F11 : Put into /etc/rc.d/rc.sysinit , if boot hangs, you can switch there and use tools like ps to see whats going on .