Too long "Searching for Puppy files"
Too long "Searching for Puppy files"
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'...
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'...
Hi Peakeen,
At boot, Puppy searches on all drives for files. Try the boot command
HTH
Rolf
At boot, Puppy searches on all drives for files. Try the boot command
Code: Select all
pdev1=sdc1
Rolf
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.
Raspberry Pi without Puppy? No, thanks.
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.
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.
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?!
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?!
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.
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
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
t
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
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
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?
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?
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.
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
Boot options on the initrd line doesn't work.
Please try
If it doesn't help, try adding pdev1=sdc1 to the kernel line.
HTH
Rolf
Please try
Code: Select all
...
label puppy
kernel vmlinuz pmedia=usbflash
append initrd=initrd.gz
HTH
Rolf
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.
Raspberry Pi without Puppy? No, thanks.
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:
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.
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:
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.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.
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.
It is good to ask, sfeeley.
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
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.
Raspberry Pi without Puppy? No, thanks.
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.
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.
Bug in init?
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?
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?
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!
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!
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!
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!
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
Slow
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
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
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.
"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.
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
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