Too long "Searching for Puppy files"

Booting, installing, newbie
Message
Author
User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

Too long "Searching for Puppy files"

#1 Post by Peakeen »

Booting Lupu 5.2.8 on Dell desktop with 2GB.

sda: 60 GB internal drive
- sda1: Dell utility partition
- sda2: XP Pro
sdb: 250 GB external USB hard disk
- sdb1: Data (NTFS 220 GB)
- sdb2: Ubuntu (EXT3 20 GB)
- sdb3: Linux swap
sdc: 4 GB USB flash
- sdc1: FAT32 with LUPU 5.2.8 "live CD" installed via Unetbootin

Puppy boots and a save file has been configured. Everything works fine except for one thing. The "Searching for Puppy files" boot phase takes about one minute to complete.

If I delete the Ubuntu EXT3 partition or simply disconnect the 250 GB external USB disk the search takes a just couple of seconds.

Is this expected behaviour? Or should Puppy be able to find its files without getting bogged down in the Ubuntu partition?

/etc/rc.d/PUPSTATE contains the following so it looks as though it does know where to find everything:
...
PDEV1='sdc1'
DEV1FS='vfat'
PUPSFS='sdc1,vfat,/lupu_528.sfs'
PUPSAVE='sdc1,vfat,/lupusave.2fs'
PMEDIA='usbflash'...

User avatar
rhadon
Posts: 1292
Joined: Thu 27 Mar 2008, 11:05
Location: Germany

#2 Post by rhadon »

Hi Peakeen,

At boot, Puppy searches on all drives for files. Try the boot command

Code: Select all

pdev1=sdc1
HTH
Rolf
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

#3 Post by Peakeen »

Thanks for the prompt reply, Rolf, but unfortunately pdev1=sdc1 doesn't help.

I have tried it as a parameter during boot and I have tried it in syslinux.cfg. Either way it fails to speed up the Searching for puppy files phase, which still takes about 1 minute.

If I remove pmedia=usbflash and just use pdev1=sdc1 in syslinux.cfg it actually slows down the process even more by about 15 seconds and I can hear it accessing the internal hard disk. If I specify pmedia=usbflash it only accesses the USB disk and the pendrive.

User avatar
rhadon
Posts: 1292
Joined: Thu 27 Mar 2008, 11:05
Location: Germany

#4 Post by rhadon »

You could also try pupsfs=sdc1:/name_of_your_savefile.sfs, small description here.

Just a guess, I've never tested.

~Rolf
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

#5 Post by Peakeen »

I've tried pointing pupsfs directly at the file. It says Searching for puppy files... and then pausing, then Searching deeper...pausing.

The good news is: This only takes a few seconds and then it continues, so it seems to be looking at the right device, nowhere else. But why look deeper than the top level?

The bad news is: The system comes up in the default configuration; it hasn't found and loaded the lupusave.2sf file, although it is in the same partition as the sfs, in the same top-level directory.

I've checked the F2 and F3 help and can't see any way to specify where to look for the 2sf file - why not default to where it found the sfs?!

sfeeley
Posts: 812
Joined: Sun 14 Feb 2010, 16:34

#6 Post by sfeeley »

sdc: 4 GB USB flash
- sdc1: FAT32 with LUPU 5.2.8 "live CD" installed via Unetbootin

I think that's the problem. I don't know why, but yesterday I was having the same problem with an install of 5.28 on a flashdrive using netbootin. It drove me nuts!

But-- I reinstalled onto the flash via the puppy universal installer, and now it boots much faster without the searching message.

(btw: you can back up your save file elsewhere, install onto the flash drive using the universal installer and then move your save file back and all should be well).

If you don't have a cd drive, I did something like this:
-install onto flash via netbootin
-boot using the flashdrive
(note this has to be either without a savefile on it, or as pfix=ram)
-look onto the flashdrive-- copy the required linux files elsewhere (onto harddrive. Don't worry you can erase these later).
-unmount flashdrive
-reformat and set boot flag with gparted
-click universal installer and follow instructions.
-(I used one of the bootloader options-- I can't remember which one, but I think that the instructions mentioned it being a good choice)

(hopefully i don't mislead you because I did this after much trial and error, and may have forgotten some steps or taken a forgotten detour somewhere). If you can use a CD to boot from first, and then install onthe flash it it works much easier.

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

#7 Post by Peakeen »

As you suggested, booting with pfix=ram allowed me to use the puppy universal installer to install to sdc1.

First, to change as little as possible, I didn't reformat the partition but just let the installer delete all the files and then copy in the puppy files from lupu_528.004.iso. Everything worked but Searching for puppy files still took a minute.

So I tried again, this time using gparted to format the partition as ext2 and again everything works. But again it is still taking a minute to search for puppy files.

So unetbootin can't be blamed in this case. My problem seems to be down to the existence of the ext3 Ubuntu partition on sdb3

sfeeley
Posts: 812
Joined: Sun 14 Feb 2010, 16:34

#8 Post by sfeeley »

t
his time using gparted to format the partition as ext2
So unetbootin can't be blamed in this case
.

so did you let the universal installer put on a different bootloader? (this is what I did--its not the default option). As you said, it might not be the solution, but I'm just trying to cover all the possibilities.
I think what netbootin does is put on its own bootloader, and you're trying to replace this (my limited understanding of such things)

good luck

ICPUG
Posts: 1308
Joined: Mon 25 Jul 2005, 00:09
Location: UK

#9 Post by ICPUG »

I don't understand why this is happening as specifying PDEV1 should be enough to stop it searching the sdb1. However here is a workaround that might work.

Instead of keeping your puppy files in the top directory, create a directory called puppy528 and put them in there, including the save file.

Change the boot configuration file to not only include PDEV1=sdc1 but also psubdir=puppy528

Is it possible to post your configuration file here so we can check if it is written correctly?

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

#10 Post by Peakeen »

sfeeley: I used gparted to create the target partition and set it active. Puppy's installer reckoned this was ok so I didn't change it.

But, the way see it, it is booting without any problem. The problem arises further down the line. And don't forget that it "searches" in only a second or two when I remove the USB hard disk or delete Ubuntu's ext3 partition.

ICPUG: Thanks to you too for the suggestions. Actually I don't think it is searching sdb2 - I think it is just hanging and timing out. Two reasons I say this: (1) there is little or no activity on the USB hard disk, (2) I copied the sfs and 2fs into the top level directory on sdb2 and nothing changed; it didn't find them, it didn't finish the searching phase any quicker, it eventually loaded them from sdc1 as usual.

It's worth pointing out that the Ubuntu partition is fully accessible when Puppy is up and running, as are the NTFS partitions.

I've tried several variations of syslinux.cfg but this is what I think should work. I changed pmedia from cd to usbflash, otherwise it's straight out the box.

Code: Select all

default puppy
display boot.msg
prompt 1
timeout 50

F1 boot.msg
F2 help.msg
F3 help2.msg

label puppy
kernel vmlinuz
append initrd=initrd.gz pmedia=usbflash

User avatar
rhadon
Posts: 1292
Joined: Thu 27 Mar 2008, 11:05
Location: Germany

#11 Post by rhadon »

Boot options on the initrd line doesn't work. :wink:

Please try

Code: Select all

...
label puppy 
kernel vmlinuz pmedia=usbflash 
append initrd=initrd.gz 
If it doesn't help, try adding pdev1=sdc1 to the kernel line.

HTH
Rolf
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.

sfeeley
Posts: 812
Joined: Sun 14 Feb 2010, 16:34

#12 Post by sfeeley »

question (and I know I'm beating a dead horse, so I'm mostly just asking out of curiosity since as a newbie I'm still trying to learn how things work--my apologies):
what bootloader is actually in use here? If when you are trying to use the puppy linux on the flash key usb, are you using unetbootin? does unetbootin work with/understand the commands that we have been trying?

looking at your configuration from the first post, it looks like you have xp on your main harddrive, ubuntu on an external harddrive, and puppy on a flash.

-So when you boot to xp, what bootloader is being used? Where is it located? (i'm guessing its the native xp bootloader and that its on your hd)

-So when you boot to ubuntu what bootloader is being used? Where is it located? (i'm guessing that the bios is detecting the external harddrive, that the harddrive is formatted as bootable, and that you're given a bootup option of choosing the external harddrive-- which by passes the xp bootloader)

-so when you boot to to puppy what bootloader is being used? where is it located ((i'm guessingthat the bios is detecting the external flashdrive and whatever unetbootin put in place is being used the boot the files. My suspicion is the what unetbootin does is search all external drives for usable linux files. This might explain:
And don't forget that it "searches" in only a second or two when I remove the USB hard disk or delete Ubuntu's ext3 partition.
I haven't noticed anyone mention grub, grub4dos, lin-n-win, etc which makes me think that each external drive is using its own set of protocols.

again excuse my repetition or if I got some terminology wrong, since I'm mostly trying to understand how all this works. Best of luck. :D

User avatar
rhadon
Posts: 1292
Joined: Thu 27 Mar 2008, 11:05
Location: Germany

#13 Post by rhadon »

It is good to ask, sfeeley. :D

At least for me, because I've never used Unetbootin.

I guessed that unetbootin makes the stick bootable and uses syslinux or extlinux for booting. Maybe I was barking up the wrong tree?

Best regards
Rolf
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

#14 Post by Peakeen »

Thanks for your input, guys.

rhadon: The out-of-the-box syslinux.cfg contains:
append initrd=initrd.gz pmedia=usbflash

I just changed it from cd to usbflash and it does seem to work. However I tried putting it on the kernel line as you suggest. If anything it took longer to boot and I could hear it accessing the internal hard disk, as it does without pmedia=usbflash.

sfeeley: Yeh, I'm trying to understand how things work too! Your right about my configuration. I mainly use XP but I've been experimenting with various Linux distros for a while. XP boots from the 'active' partition on the boot device selected in the BIOS. Pressing F12 immediately after power on allows me to choose to boot from a USB device. Grub is installed on sdb and points at the Ubuntu partition, or alternatively syslinux boots from the active partition on flash drive sdc. I have used unetbootin on many occasions both on Windows and Linux to create a bootable flash drive from a Linux iso. Read all about it here:- http://unetbootin.sourceforge.net/

I can't help feeling that the problem lies in Puppy - after all it fails (or rather hangs) after it says "Searching for Puppy files" so it's using puppy-specific code at that point to find the sfs and 2fs. These types of file are unique to Puppy.

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

Bug in init?

#15 Post by Peakeen »

Searching for puppy files is done in the init script. As far as I can make out it looks for vmlinuz and assumes it's found the puppy files when it finds vmlinuz.

But Ubuntu (among many others) also uses vmlinuz and, in my case, it finds Ubuntu's vmlinuz and then gets very confused for a while because the sfs and 2sf files aren't where it expects to find them.

I've checked this by simply deleting vmlinuz from Ubuntu's top-level directory (actually just a symbolic link to the file in /boot) and sure enough Searching for puppy files is almost instantaneous.

Since vmlinuz is used by many varieties of linux wouldn't it be better to search for a puppy-specific file like *.sfs?

ICPUG
Posts: 1308
Joined: Mon 25 Jul 2005, 00:09
Location: UK

#16 Post by ICPUG »

That's a very interesting find Peakeen.

The last time I looked at the init file was at version 4.2 and it definitely did not look for vmlinuz then!

I know Barry updated the init search routine a year or so ago but this seems quite a major change and a little illogical. By the time the init file is running vmlinuz has been found! It is the puppy files that are needed and in 4.2 it was the sfs file that was searched for.

I must have a look at the init file in a recent Puppy!

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

#17 Post by Peakeen »

I could be wrong - I won't pretend I followed the init script in detail!

The Searching for puppy files section of init starts at line 484 and some comments in the script make suspect it was looking for vmlinuz so I simply removed the symlink from the Ubuntu partition and the "Searching" time dropped from 50 sec to 2 sec. So, whatever it did, the effect was dramatic!

I'll dig further. I'll make it fail again and try to find out exactly where it's spending the extra 48 seconds!

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

#18 Post by Peakeen »

Below are listings of the /initrd/tmp log files from a 'fast' boot and from a 'slow' boot. The only filesystem difference between the two is the presence of vmlinuz in / of Ubuntu partition sdb3 as a symlink to /boot/vmlinuz-3.0.0-12-generic. I have also tried a "dummy" vmlinuz in the Ubuntu / (just an empty text file) and it still does a fast boot, so it needs a real vmlinuz to affect the boot process.

Note that, in the fast (18 sec) boot, the time difference between ALLDRVS0 and PUPSAVES-complete is 4 seconds and in the slow (58 sec) it is 44 seconds.

I have compared each pair of logs and can find no differences in their contents.

I have gone through this several times and it is completely reversible and reproducible.

Any thought or suggestions gratefully received!

Fast

Code: Select all

-rw-r--r-- 1 root root  859 11:15:44 bootinit.log
-rw-r--r-- 1 root root    4 11:15:44 ATADRIVES0
-rw-r--r-- 1 root root 8281 11:15:49 uevents.log
-rw-r--r-- 1 root root   67 11:15:51 usb-drives-probe
-rw-r--r-- 1 root root 1021 11:15:51 probepart.log
-rw-r--r-- 1 root root  200 11:15:51 PCPARTSALL
-rw-r--r-- 1 root root    8 11:15:51 OPTICALDRIVES0
-rw-r--r-- 1 root root   64 11:15:51 LESSPARTS0
-rw-r--r-- 1 root root   20 11:15:51 ALLDRVS0
-rw-r--r-- 1 root root   25 11:15:55 PUPSAVES-complete
-rw-r--r-- 1 root root   25 11:15:55 PUPSAVES2
-rw-r--r-- 1 root root   25 11:15:55 PUPSAVES
-rw-r--r-- 1 root root   24 11:15:55 PUPSAVE2SFSS
-rw-r--r-- 1 root root  496 11:15:55 puppy-file-search.log
-rw-r--r-- 1 root root    0 11:16:02 LOGONEBASES
-rw-r--r-- 1 root root    0 11:16:02 EXTRASFSS
Slow

Code: Select all

-rw-r--r-- 1 root root  859 12:39:06 bootinit.log
-rw-r--r-- 1 root root    4 12:39:06 ATADRIVES0
-rw-r--r-- 1 root root 8281 12:39:11 uevents.log
-rw-r--r-- 1 root root   67 12:39:13 usb-drives-probe
-rw-r--r-- 1 root root 1021 12:39:13 probepart.log
-rw-r--r-- 1 root root  200 12:39:13 PCPARTSALL
-rw-r--r-- 1 root root    8 12:39:13 OPTICALDRIVES0
-rw-r--r-- 1 root root   64 12:39:13 LESSPARTS0
-rw-r--r-- 1 root root   20 12:39:13 ALLDRVS0
-rw-r--r-- 1 root root   25 12:39:57 PUPSAVES-complete
-rw-r--r-- 1 root root   25 12:39:57 PUPSAVES2
-rw-r--r-- 1 root root   25 12:39:57 PUPSAVES
-rw-r--r-- 1 root root   24 12:39:57 PUPSAVE2SFSS
-rw-r--r-- 1 root root  496 12:39:57 puppy-file-search.log
-rw-r--r-- 1 root root    0 12:40:04 LOGONEBASES
-rw-r--r-- 1 root root    0 12:40:04 EXTRASFSS

User avatar
Peakeen
Posts: 14
Joined: Sat 28 Jan 2012, 12:28

#19 Post by Peakeen »

I've been away from Puppy for a couple of months but tried it again with the latest releases.

"Searching for puppy files" on Lupu (5.2.8-005) is still affected in the way I described by the presence or absence of vmlinuz in an Ubuntu partition.

However, neither Wary nor Racy (5.3) are affected.

Am I the only one to see this effect? To me it spoils one of the most attractive features of Puppy - the fast boot.

sfeeley
Posts: 812
Joined: Sun 14 Feb 2010, 16:34

#20 Post by sfeeley »

how are you installing puppy to the flash stick? Still using unetbootin?

maybe try this homegrown alternative . . . (or the universal installer)

http://www.murga-linux.com/puppy/viewto ... 250#517250

(I see that you found some weird searches in init that seem to come later than would matter from the install method, but I had the same issues as you a second time since the thread started with unetbootin, and resolved it again by switching to the universal installer-- maybe its a coincidence, maybe its illogical, but weirder things have happened) Do me a favor, give it a go, and I'll be quiet . . .
sorry for being a pest :D

Post Reply