Unable to boot as pup_4xx.sfs is not found.

[lapis]

I am trying to get a puplet frugally installed but it keeps coming up with the error unable to find pup_412.sfs.

The puplet is BrowserLinux and the sfs is actually called pup_412browserlinux353.sfs.

I have tried the psubdir parameter and I have tried putting it in / and I have even tried renaming it to just pup_412.sfs.

The boot sequence can never find it.

Rather than contacting the puplet maker or trying a different one I would like to learn a simple way to find what the boot sequence is trying to do.

I assume there is a script somewhere that specifies what it is looking for and how. I tried /initrd/sbin/init but couldn't find it there.

Edit: Hang on, I think I have found it in init. I am just having trouble reading it.

Edit: I am having the same problem with the official Puppy 4.31. I can boot with Puppy 3.01 and Puppy 2.1x without problem.

[chris]

Open ROX-Filer and navigate to /mnt/home (up arrow 'til you can't go anymore, then click mnt and then click home). Put the pup_412browserlinux353.sfs there.

Then you have to tell puppy to load it at boot time. Click Menu-> System->BootManager configure Bootup and click the button "Choose which extra SFS files to load at bootup." Select the SFS which will appear on the left side, click arrow to send it to the right side, OK and reboot.

You should see the name appear during the boot process I think.

If it doesn't work then I think there are some details about version numbers in the sfs name which I'm not sure of. Someone with more experience can sort that for you.

hth

[lapis]

Thanks Chris but you are talking about an additional sfs. Good instruction though.

I am referring to the initial pup_xxx.sfs from the live CD.

[diaeresis]

If you already have a frugal install then you can put the new sfs in the same directory as your current sfs. When you next boot you will be given a choice of which pupsave to use.
This works for me.
If you don't have a frugal install already then the sfs needs to be copied into /mt/home and it will/should be seen when you next boot.

hopefully

[lapis]

Hi diaeresis,
I think you are talking about the pupsave file. I am talking about the main squash file that is required to boot Puppy.

Anyway, I am having all sorts of trouble with getting either the 4.1 or 4.3 series to boot. It keeps saying pup_431.sfs not found even though I hear it searching the correct drive (which only has one partition)

I have tried putting the squash file in / and /boot/pup431 along with vmlinuz in both.

Both the 2 series and 3 series Puppies boot from the same drive without issue. I just don't know what to do. Is there anything I can do when it drops to the command prompt to find out specifically where it was searching?

[Jim1911]

Consider starting over.
1. Boot from CD and at the 5sec boot pause, enter "puppy pfix=ram" (without quotes).
2. If your CD does not boot, it is probably defective. Otherwise, if that version works on your computer, it should work properly since all the files it needs are on the CD.
3. You may create a frugal installation using several different techniques See: http://murga-linux.com/puppy/viewtopic.php?t=29356
4. I prefer a manual method where you mount your hard drive and using Rox create a new directory in root. Then copy from your CD these files, vmlinuz, initrd.gz and pup_xxx.sfs (and maybe z*.sfs, the "zdrv") to the new directory that you created.
5. Reboot using the CD, if it worked earlier, it will find your pup_xxx.sfs file that you just copied to the hard drive.
6. Grub or Grub4dos or other booting techniques can then be installed.

[lapis]

Consider starting over.

Thanks for the reply but I have done all that and I am using the manual method with grub4dos.

What works for Puppy 2.17 and 3.01 does not work for Puppy 4.12 and 4.31.

[Jim1911]

The method I described works for all the latest pups and derivatives on my machine. You may have a hardware problem.

[lapis]

The method I described works for all the latest pups and derivatives on my machine.

That may well be but there must be a difference between how pre-4 series puppies and 4 series work otherwise I could get the 4 series to work.

As for hardware problem, that is a bold statement which you have no evidence for. Why don't these hardware problems affect Puppy 3.01 in this way? Yes I tried a 4 series with a retro kernel just in case.

[ICPUG]

lapis,

Regarding your original problem - if the sfs file is called pup_412browserlinux353.sfs then it shouldn't be looking for pup_412.sfs. No wonder it cannot find it.

Does browserlinux work as a Live CD? If it is then make sure your frugal install is running the initrd.gz from browserlinux and not something else (4.1.2).
The best way is to keep all you series 4 based pups in separate directories and use the psubdir option when loading the kernel.

As an aside you mention that 4.3.1 doesn't work with the message pup_431.sfs not found. That may be a typo but 4.3.1 has a file name pup-431.sfs NOT pup_431.sfs.

Tell us what files are put where and a copy of your menu.lst. Then we may be able to see what is causing the problem.

For info - The 2 series is different from the 4 series in that you cannot put files in a directory - so that maybe why it works. However, the 3 series allowed the use of a directory - but maybe you don't use one.

I'm suspicious that due to the lack of directories being used or inappropriate use of psubdir (or even filenames being not quite right, including CAPITAL and small letters) the wrong vmlinuz, initrd.gz is being picked up thus causing the error message. The info requested above will help to check that.

[puppyite]

“Unable to boot as pup_4xx.sfs is not found.

[diaeresis]

Hi Lapis,

sorry, I made a typo in my first post. I didn't mean pupsave I meant sfs. What I was trying to say was that your new sfs should be either in the same folder as your pupsave and current sfs or the folder above that.

[lapis]

OK thanks people for replies. I have made a little progress towards identifying part of the problem. However, it appears I have created a new, more serious problem (for me anyway). I'll get to that later.

lapis,
Regarding your original problem - if the sfs file is called pup_412browserlinux353.sfs then it shouldn't be looking for pup_412.sfs. No wonder it cannot find it.

I am guessing it was just that the error message wasn't changed and remained generic. I did get the thing working eventually and pup_412browserlinux353.sfs was correct.

As an aside you mention that 4.3.1 doesn't work with the message pup_431.sfs not found. That may be a typo but 4.3.1 has a file name pup-431.sfs NOT pup_431.sfs.

Yes, habit, more than typo. It was correctly named as I just copied it as is was.

I'm suspicious that due to the lack of directories being used or inappropriate use of psubdir (or even filenames being not quite right, including CAPITAL and small letters) the wrong vmlinuz, initrd.gz is being picked up thus causing the error message. The info requested above will help to check that.

I had tried all sensible variations, all files in /boot folder, all files in /browserlinux folder, all files in /
I also tried mixing them up. The weird thing was it worked when I had the kernel files on one disk and the squash file on another.

Now, the reason for that I think has something to do with that from the 2.6.25.16 kernel on, it uses new libata PATA drivers for the IDE drives. These renames hda to sda and apparently that made a mess somehow for me. I have three drives, two internal and one external usb hard disk for backup as the internal drives are a bit small by current standards. Prior to that kernel they were named hda(laptop main hard disk), sda(an additional hard disk in the laptop multibay) and sdb(external usb).

Now I normally boot grub and linux variations from sda and Windows from hda.

Now grub sees whatever it is booted from as hd0. So vmlinuz was on (hd0,0) as referred to in the grub menu so I had this:
kernel (hd0,0)/browserlinux/vmlinuz root=/dev/ram0 psubdir=browserlinux PDEV1=sda1 and so.

However, with the new kernel it renamed hda1 to sda1 and renamed sda1 to sdc1. So if that makes sense to you then you are better than me as it seems grub sees one order and then linux shuffles it to a different order.

So to sum up, I found that I can get Puppy 4.0 to work fine straight off as normal but the newer puppies with the newer kernel are a no go. I had tried the retro of Puppy 4.3.1 but its seems I did not retro enough.

Is there a better way to word the grub menu? I can't find a description of PDEV. Is it correct?

So anyway, I seem to have created a new problem in that my main Puppy system 2.17 has ceased to boot. I get

Error, cannot find Puppy on 'idehd' boot media.
PUPMODE=9 PDEV1=
Exited to initial-ramdisk (initramfs) commandline...
(the Linux-guru can now debug, 'e3' editor is available)

/bin/sh: can't access tty; job control turned off

The weird thing is that I have not altered anything to do with the 2.17 install (not the files or grub menu reference) for over a year and it worked fine until this debacle.
I have tried reinstalling, redownloading, rewording, applying backup, installing in a different place and the error continues.

So any ideas?

Thanks

[puppyite]

Is this where you download BrowserLinux?

After you downloaded BrowserLinux did you run a checksum?

If needed you can find most versions of Puppy at any of the Ibiblio sites on the Puppy Linux Wiki Links page.

Did you try the frugal install I suggested previously?

[lapis]

Is this where you download BrowserLinux?

Yes that was it.

After you downloaded BrowserLinux did you run a checksum?

No, but I wasn't burning to disc anyway.

If needed you can find most versions of Puppy at any of the Ibiblio sites on the Puppy Linux Wiki Links page.

I am not sure what you are getting at there. I stated I redownloaded 2.17 even though it was fully working up until yesterday. I had another copy anyway plus 2.17 fat free and I did a hard disk recovery from backup. Nothing worked.

Did you try the frugal install I suggested previously?

I know my ramblings were a bit, well, rambly but my problems are a bit beyond that. I did get the browserlinux going eventually but having bits on separate disks is not envisaged by those instructions. Neither is why a 2.17 install which was fully working for over a year decided to stop working because 4.3.1 was installed and remains un-working even though every file belonging to 4.3.1 has been removed.

[CatDude]

Hi

Tell us what files are put where and a copy of your menu.lst. Then we may be able to see what is causing the problem.

That seemed like a fair request to me, which was ignored (or maybe just overlooked),
but if anybody could possibly help you, then i suspect ICPUG would be the man.

After you downloaded BrowserLinux did you run a checksum?

No, but I wasn't burning to disc anyway.

I think what puppyite was getting at, was did you verify that the download was not corrupted,
the fact that you did not intend to burn a disc is irrelevant.

CatDude
.

[lapis]

Hi

Tell us what files are put where and a copy of your menu.lst. Then we may be able to see what is causing the problem.

That seemed like a fair request to me, which was ignored (or maybe just overlooked)

But I had described where I put the files even before ICPUG's post and I included the line from menu.lst in reply to that post.
I don't see what other information I can provide.

I think what puppyite was getting at, was did you verify that the download was not corrupted,
the fact that you did not intend to burn a disc is irrelevant.

Is it irrelevant? Would it open and the files extracted boot up hundreds of times and then just stop working? What about the other backups that I tried as well that had previously worked? I use a download manager which has never given me a bad download without saying so. If I would have had a suspicion that the iso was sus I would have checked it.

But just because I know you will not take my word for it:

sh-3.1# md5sum -c /mnt/hda1/puppy-2.17.1-nolzma-seamonkey-fulldrivers.iso.md5.txt
puppy-2.17.1-nolzma-seamonkey-fulldrivers.iso: OK
sh-3.1#