2.17 frugal install problem

[jediborger]

My problem with my frugal install is that I want to put vmlinuz and initrd.gz into a folder besides /boot like /puppy so I can keep puppy's files separate from my main os's that are in boot. When I used the Universal Installer it overwrote Ubuntu's vmlinuz and initrd.gz, which of course created some issues. Below is my grub config for puppy, am I missing a parameter or something to make this work because it did work before 2.16.

title Puppy Linux
rootnoverify (hd1,0)
kernel (hd1,0)/puppy/vmlinuz root=/dev/ram0 pmedia=satahd
initrd (hd1,0)/puppy/initrd.gz
boot

What's interesting is that if i put vmlinuz and initrd.gz in /boot then the above config works, but if it isn't I get an error about pdev1 not being able to find puppy. I also have both sfs fies in root /.

[HairyWill]

psubdir bites again

title Puppy Linux
rootnoverify (hd1,0)
kernel (hd1,0)/puppy/vmlinuz root=/dev/ram0 pmedia=satahd psubdir=/puppy
initrd (hd1,0)/puppy/initrd.gz
boot

http://www.puppylinux.org/wikka/BootParms

[jediborger]

Well, I added the psubdir to grub and removed the files from /boot but it still didn't work. Has anyone else had success with this? I remember something in Barry's dev blog about this feature not really working located here:
http://www.puppylinux.com/news/comments ... 520-231220

I also tried the parameter like psubdir=puppy with the leading / but it still failed.

[Leon]

In Puppy 2.17 I noticed that psubdir parameter works for pup_save.2fs file and not for pup_217.sfs file as before.

Now I have all pup_xxx.sfs, devx_xxx.sfs, zdrv_xxx.sfs and pupswap.swp on / directory and different pup_save.2fs files each in its own directory.

This is a part of my menu.lst:

# Boot Puppy Linux
title Puppy-p2.17, idehd, bp217, pup_save.2fs file created by Puppy-p2.17
rootnoverify (hd0,4)
kernel /bp217/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=bp217
initrd /bp217/initrd.gz
boot

# Boot Puppy Linux
title Puppy-p2.17, idehd, bp217_, pup_save.2fs file upgraded from previous version
rootnoverify (hd0,4)
kernel /bp217_/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=bp217_
initrd /bp217_/initrd.gz
boot

# Boot Puppy Linux
title Puppy-p2.17, idehd, bp217-0, create new pup_save.2fs
rootnoverify (hd0,4)
kernel /bp217-0/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=bp217-0 pfix=ram
initrd /bp217-0/initrd.gz
boot

[jediborger]

I also have pup_217.sfs, zdrv_217.sfs and pup_save.2fs in /. Might there be a problem with the code for satahd? That seems to be the only difference in our configurations.

[Getnikar]

In Puppy 2.17 I noticed that psubdir parameter works for pup_save.2fs file and not for pup_217.sfs file as before.

Now I have all pup_xxx.sfs, devx_xxx.sfs, zdrv_xxx.sfs and pupswap.swp on / directory and different pup_save.2fs files each in its own directory.

This is a part of my menu.lst

My setup is essentially the same, but with only init.gz and vmlinux for any puppy version in /boot/puppy-(versionno). So I can choose to run eg 2.16 or 2.17at boot, just for a few hours after upgrade, in case there is a disastrous new release. After that I have no use for the old version.

I must try put the pup_saves there too, away from /.

I too run Ubuntu, so I do not run the Puppy Universal installer. I just download the Puppy iso, then run the attached small script to open it. Then I rox into it and copy out the files into where I want them.

[garlane]

Here's my experience with a 2.16 to 2.17 frugall upgrade / install:

I had a 2.16 frugal install in hda4. The 2.17 CD recognised the 2.16 and updated it automatically. Then I was booted into 2.17 desktop with my old 2.16 save_2fs setup. The boot manager started automatically asking if I wanted to load the Ooo.sfs module, which I did. However, neither 2.16 nor 2.17 would boot from then on, with the error: "could not find Puppy on idehd boot media".

I booted from the 2.17 CD again to try to do a frugall install. However, the install would not proceed because the hda4 partition was unmountable (the CD was using the save_2fs file on the partition).

I decided to just copy the files from the CD into the hda4 partition. I found that the 2.17sfs and 2.17dev.sfs modules had been added by the upgrade, but the 2.16 boot folder was still in place, and the 2.17 files of boot.msg and boot.cat had not been installed. After deleting all the 2.16 files and copying in all the 2.17 files and amending the menu.lst (which I have in Debian) Puppy 2.17 booted OK.

Problems:

* The automatic update worked for the system files and save_2fs file, but not for the boot files.
* The boot manager option to load any sfs modules with 217 in them (ticked by default) did not work. After unticking this option and loading the sfs module manually Open Office icons appeared on the desktop upon reboot. The "fixmenus" command did not work and Open Office did not appear in the menu.
* The frugall install name is misleading - it sounds like only part of the system is installed and part runs off the CD. Perhaps a better name would be "coexist install", or "sfs install", or "RAM-like install".

When it works Puppy is awesome. There are just a few problems around the install / boot / sfs modules / boot manager area that could use some more work. For example, if the auto upgrade does not work so well is there really a need for it - especially when a new install is so quick and easy?

[garlane]

Sorry, the files mentioned above for Puppy 2.17 should have been:

pup_save.2fs, pup_217.sfs, and zdrv_217.sfs.

I have since downloaded devx_217.sfs, the kernel-src_217.sfs, and EZpup217. EZpup installed OK, put new icons on the desktop, and put Open Office applications in the menu instead of icons on the desktop. However, there was nothing to indicate the loading of the other sfs files, like a menu entry or icons.

Then I tested the boot manager again. I ticked the option to ignore choices and load all files with 217 in them. Rebooted and Open Office icons did not appear on the desktop or in the menu (which is correct). But I couldn't see anything that said that devx_217.sfs and the kernel-src_217.sfs were loaded (do they have menu entries or icons?). Then I unticked the "recognise all 217" option in the boot manager and loaded all 3 sfs files again manually. After rebooting, all the desktop icons were messed up - on the left side of the screen were Puppy 217 icons, and on the right were EZpup icons. Open Ofiice icons also appeared and their entries were also in the menu. But still no signs of dev_217.sfs or kernel-src_217.sfs.

So there does seem to be a problem with the boot manager and/or the sfs modules - unless I'm doing something wrong.

[MU]

Have the same problem.
I did not use the universal installer, but extracted all files by hand from the iso (checksum is ok).
It even happens if I hide the second partition.

/dev/hdc|iso9660|0|MATSHITADVD-ROM SR-8174
/dev/hda1|vfat|10251297|Win95 FAT32
/dev/hda2|none|13320720|Win98 Extended (LBA)
/dev/hda5|none|11476017|Unknown
/dev/hda6|swap|1678257|Linux Swap

sh-3.00# fdisk -l

Disk /dev/hda: 12.0 GB, 12068904960 bytes
240 heads, 63 sectors/track, 1559 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 678 5125648+ b W95 FAT32
/dev/hda2 679 1559 6660360 f W95 Ext'd (LBA)
/dev/hda5 679 1437 5738008+ 1b Hidden W95 FAT32
/dev/hda6 1449 1559 839128+ 82 Linux swap / Solaris

menu.lst:

Code: Select all

title Puppy Linux 2.17
        rootnoverify (hd0,0)
        hide(hd0,1)
        hide(hd0,4)
        kernel (hd0,0)/puppy217/vmlinuz acpi=off loglevel=3 root=/dev/ram0 PMEDIA=idehd
        initrd (hd0,0)/puppy217/initrd.gz

pup_217.sfs and zdrv_217.sfs are in c:\
I also copied them to the second partition to "/".
Grub is in c:\puppy\
vmlinuz and initrd.gz are in c:\puppy217

The problem occurs with (taken from an older Puppy) and without a pup_save.3fs.

I get a message "Puppy not found"
PUPMODE=idehd PDEV1=


Puppy 2.11 and 2.12 (Muppy007) work ok on this system.
Mark

[MU]

Here is a workaround, no solution.

First, be shure to have only one pup_217.sfs on your harddisk, in "/" (or c:\ or another driveletter in windows).

Download and extract the zip from here:
http://puppyisos.org/isos/Puppylinux-of ... orkaround/

It includes a new initrd.gz, replace yours with it.
Now edit the line in grubs menu.lst that loads the kernel.
Add a parameter "psubdir=/puppy217"

This should be the folder with your initrd.gz and vmlinuz.

So your grub-entry will look like this:

Code: Select all

timeout 30

title Puppy Linux 2.17
        rootnoverify (hd0,0)
        kernel (hd0,0)/puppy217/vmlinuz acpi=off root=/dev/ram0 PMEDIA=idehd psubdir=/puppy217 
        initrd (hd0,0)/puppy217/initrd.gz

Now save and reboot.
USE AT OWN RISK! Works for me, but not tested at all in different situations..

What I changed:
there seems to be a cumulation of bugs.
Without psubdir, many variables remain empty, like $PDEV1.
You can use my included script "editinitrd" to check the lines around line 300.
I added debug-output.
Click on it to edit initrd.gz in the same folder.

So we need the psubdir option in grub.
Now the variables are filled, but a second bug occurs.
Puppy cannot mount /puppy217/pup_217.sfs (even if you would copy it)
This happens somewhere later.

I had no time to check that in detail, so I reactivated an old entry around line 300:
#line uncommented by #MU
PUPSFS="${FSTYPE},${PDEV1},/pup_${PUPPYVERSION}.sfs"

This will use pup_217.sfs in "/".

I did not check, if zdrv_217.sfs is mounted now, too.

But these hints might help Barry to write a "clean" solution, and at least you can run Puppy now in a frugal installation.
Works for me, I also can save.


Mark

[ICPUG]

While I am not going to solve the problem here I would like to add some comments to help others who might come this way , in the hope that it might lead to a solution, or at least to an understanding of why failures occur. It is the latter that interests me.

Anyone who follows my posts elsewhere will know I do frugal installs differently. I am always running a dual boot with Windows and I use files from the Grub4DOS project to provide my grub. The Universal Installer uses a full grub installation.

My technique can be found at the link below - although some mods are needed to bring it up to 2.17 standard. I don't think it is relevant to jediborger because it looks as if he uses a Linux machine, rather than a Windows machine:
http://www.icpug.org.uk/national/linnwin/contents.htm

When psubdir was introduced in Puppy 2.16 it was supposed to allow vmlinuz and initrd.gz to be stored in a user defined directory. I found it worked in 2.16 and, contrary to the experience in this thread, it works in 2.17 as well. Attempts were made to allow the .sfs to be stored in the same user defined directory as well, but, as Barry says, this never worked. I presume it still doesn't in 2.17, because he has not said anymore. I looked at the 2.16 code and like MU could see some anomalies, but having no time and being a beginner at this bash scripting I have not taken it further. I have not yet looked at the 2.17 code to see where any differences may be.

I will say the following - which is based on the code I did decipher - as well as, in some cases, what Barry has said:

- If psubdir is NOT used then the directory for vmlinuz and initrd.gz defaults to /boot. This ties in with the jediborger experience of when he puts his files in /boot it works.

- If psubdir IS used then it does not expect a leading or trailing '/'.
i.e. if we have /puppy/vmlinuz and /puppy/initrd.gz files then we have:
psubdir=puppy
The code will add the leading and trailing '/'. If you put a leading or trailing '/' in the psubdir parameter then a double '/', i.e. //, will appear in the code on substitution. I do not know if this is harmless or causes errors.

- the .sfs files HAVE to be in the root directory of a partition. Leon makes a comment that in 2.17 the pupsave.2fs can also be saved in the psubdir directory in 2.17. I have not checked this so far. It does not happen automatically when the pupsave is created. I have kept it in the root directory along with the .sfs files.

- make sure the file names and paths match case-wise in menu.lst and where they are located. I keep them all lower case to make certain.

With all the above conditions met I find my frugal install works, without any need to make use of MU's modified initrd.gz. I revised my set up last night to mimic what I thought was jediborger's setup.

I had the following files defined in a Windows C partition (vfat), = Linux hda1:
/puppy_217.sfs
/zdrv_217.sfs
/pupsave.2fs
/puppy.217/vmlinuz
/puppy.217/initrd.gz
/boot/grub.exe (this is the grub4DOS file)
/boot/menu.lst

My menu.lst stub for puppy was:

title Puppy Linux 2.17
kernel (hd0,0)/puppy.217/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=puppy.217
initrd (hd0,0)/puppy.217/initrd.gz
boot

This also worked without any need for a modified initrd.gz.

Now, I respect highly MU's work so I am fascinated to know why my frugal install can use the default initrd.gz but MU's requires a modified version. He uses IDE drives like me. He uses Windows partitions like me. The only thing different is he uses the full grub rather than my grub4DOS file. Is this causing the problem??? I must say, I do not understand all the intricacies of grub. I just use what works for me. I have just found out from the comments in Distrowatch (30 July 2007) that the full grub has problems in mixed sata, ide environments, but that does not affect me or MU.

As I said at the beginning, I have submitted this to provide as much information as possible in the hope it might help to lead to an understanding of what is going wrong and ultimately how to solve it.

I'd just like to finish by thanking MU for his submission of editinitrd. I have not tried it yet, but this could become very useful if I start trying to alter the initrd.gz to remove some of the psubdir anomalies.

ICPUG

[MU]

thanks for this important background knowledge.
I think I did not try /boot.
I think I also used psubdir with a leading "/".
This might explain my problems.
It is too late to re-check it now, must sleep.
But maybe others now can confirm your results

Thanks a lot, Mark

[edoc]

I had the following files defined in a Windows C partition (vfat), = Linux hda1:
/puppy_217.sfs

ICPUG

I have been wrestling with this as well and understand it far more poorly
than do you or MU. MU directed me here and I am now trying to duplicate
your setup.

Did you intend to type /puppy_217.sfs OR /pup_217.sfs

The former would require renaming the file from the CD, the latter is as
it comes off the CD.

Also, you haver deleted the line:
rootnoverify (hd0,0)

Was that intentional (due to your dual-boot setup) or an unintentional
typo, please?

I have occasionally considered a dual-boot but at the moment my
laptop is pure-bred Puppy!

[edoc]

I think that I follow3ed the instructions correctly and finally booted
without errors, and all of the displayed text showed as 217, but at
the end I was back in 216.

It is doubly weird that I get to 216 after executing all of the 217 stuff,
or appearing to, and that it still doesn't pick up the nic modules there
but does when I boot from CD to 217.

I have run pfix=clean and pfix=purge and gone aro0und deleting 216
everywhere that I find it and still I end up in 216 ... feels as though my
laptop has a demon to torture me!

Any idea where I can look to purge the 216 demon? (EDIT: Ooops!
Just looked with morning eyes and from inside of the 216 load and found a copy of pup_216.sfs, will now delete and reboot ...)

Also, and clarifications as to my questions posted last night, please?

So far your suggestions have gotten me further than anyone elses.

[ICPUG]

edoc

My apologies. With regard to the filename of the puppy sfs I got confused with the directory name puppy.217 I was testing and the file name! It should be as it comes off the CD (converting to lower case if necessary):

pup_217.sfs

However, the ommission of rootnoverify(hd0,0) in the puppy stub was intentional.

I do have that line in the top of my menu.lst as listed here:

title Default Boot on HD 0
rootnoverify (hd0,0)
chainloader +1
boot

Any stubs for various OS are added to this default portion.

I intend to update my dual boot instructions to cope with Puppy 2.17 this coming weekend - hopefully to cater for 2.17.1 if the full release comes out in time.

However, if you have a pure bred puppy laptop why crossbreed it with the beast of Redmond?!

ICPUG

[ICPUG]

edoc,

Each of our last mails were written at the same time. I was responding to your one of 31st July at x:53.

I hope that after you deleted the errant pup_216.sfs all was well but I am a little surprised. I thought the 2.16 initrd.gz searched for the pup_216.sfs and the 2.17 initrd.gz searched for the pup_217.sfs! However I am not yet entirely sure of the mechanism for determining the puppy version so I may be wrong. No doubt your next mail will say whether all is OK now or not.

ICPUG

[edoc]

edoc,

Each of our last mails were written at the same time. I was responding to your one of 31st July at x:53.

I hope that after you deleted the errant pup_216.sfs all was well but I am a little surprised. I thought the 2.16 initrd.gz searched for the pup_216.sfs and the 2.17 initrd.gz searched for the pup_217.sfs! However I am not yet entirely sure of the mechanism for determining the puppy version so I may be wrong. No doubt your next mail will say whether all is OK now or not.

ICPUG

I had to give up for the moment, this was all happening on my main laptop
and it had been down for two days.

I deleted all of the 2.17 files I could find, tweaked GRUB, then copied back
the four 2.16 Frugal files I had saved to a USB HDD.

I am now back up on 2.16 with the same failed gxine and now my USB
mouse also does not work - good thing I have the touchpad!

Next time I have a chance I will backup the entire laptop contents and
wipe the HDD and do a clean new install -- I did that a few releases ago
and had hoped it would not again be necessary because restoring my
Seamonkey address book, bookmarks, several specialty apps, and some
other things is a real time-consuming nuisance -- I suppose I need to
figure out a way to 'automate' all of that.

Thanks for your assistance and words of encouragement!

[tazoc]

Well this thread was just what I needed to get my 2.17 frugal/dual boot with LighthousePup working. I'm using full grub and separate pup_save files.
Here's the folder structure:

(hd0,7)/

Code: Select all

pup_215.sfs   (LighthousePup 215 fs)
zdrv_215.sfs
initrd.gz 
vmlinuz
pup_save-lhp215Beta4.2fs
pup_217.sfs       (Puppy 2.17 fs)
zdrv_217.sfs

(hd0,7)/boot/pup217

Code: Select all

initrd.gz
vmlinuz
pup_save-217a.2fs

Here are the menu stubs

Code: Select all

title         LighthousePup 215 Beta4 (frugal on hda8)
rootnoverify    (hd0,7)
kernel         (hd0,7)/vmlinuz root=/dev/ram0 PMEDIA=idehd PDEV1=hda8 PHOME=hda8 loglevel=3 vga=normal
initrd         (hd0,7)/initrd.gz

title         Puppy Linux 2.17 nolzma (frugal on hda8)
rootnoverify    (hd0,7)
kernel         (hd0,7)/boot/pup217/vmlinuz root=/dev/ram0 PMEDIA=idehd PDEV1=hda8 PHOME=hda8 psubdir=boot/pup217 loglevel=3 vga=normal
initrd         (hd0,7)/boot/pup217/initrd.gz

Results

/etc/PUPSTATE - LighthousePup

Code: Select all

PUPMODE=12
PDEV1='hda8'
DEV1FS='ext3'
PUPSFS='pup_215.sfs'
PUPSAVE='ext3,hda8,/pup_save-lhp215Beta4.2fs'

/etc/PUPSTATE - Puppy 2.17

Code: Select all

PUPMODE=12
PDEV1='hda8'
DEV1FS='ext3'
PUPSFS='ext3,hda8,/pup_217.sfs'
PUPSAVE='ext3,hda8,/boot/pup217/pup_save-217a.2fs'

LighthousePup 215 Beta4, based on Puppy 215CE doesn't look for a pup_save in subfolders, it uses the one in /. That's why I put Lighthouse in the / folder and 2.17 in a subdir, not the other way around. Puppy 2.17 finds both pup_save files and prompts me during bootup whether to use:
0 - none
1 - /pup_save-lhp215Beta4.2fs on hda8
2 - /boot/pup217/pup_save-217a.2fs on hda8
From the PUPSTATE above you can see which option I chose.
Can load and share SFS modules in both systems. With Lighthouse the filename must end with _215.sfs. (Edit 2 Aug) With Puppy 2.17 the filename cannot end with '_nnn.sfs' unless nnn=217. http://www.murga-linux.com/puppy/viewto ... 8&start=45

To share SFS files without copying, I create a symlink <whatever>_217.sfs to <whatever>_215.sfs (Edit 2 Aug) (Of course, some SFS modules will not work as well in versions for which they were not designed. But this will enable testing and design for multiple versions. I'm doing exactly that right now with K3b/GIMP/pgs graphics SFS development pgs_K3b-12.17-01_215.sfs 115M, which is missing some libs needed for 2.17 but version -02 to be available in a couple of days is tested with Puppy 2.17) www.lhpup.org/download.htm
-TazOC

[ICPUG]

Well done tazoc.

Thanks for posting your results back. This shows how to dual boot two Puppies (where one is 2.17). You have also confirmed what Leon found that Puppy 2.17 will now find a Pupsave in the subdirectory denoted by psubdir. Great news.

ICPUG

[edoc]

Well done tazoc.
Thanks for posting your results back. This shows how to dual boot two Puppies (where one is 2.17). You have also confirmed what Leon found that Puppy 2.17 will now find a Pupsave in the subdirectory denoted by psubdir. Great news.
ICPUG

I have printed his post and am downloading the tmxxine Puppy as I type this.

The children want me to load GamePup somewhere though I think TeenPup is
likely to promote a little more productivity!

Am looking at ChurchPup as it would be neat to have a version deliberately
designed to facilitate Bible study and application.

Now if only I could find a version of Puppy that will run on the old Panasonic
CF-41 MKiii laptop here with 16MB of RAM (32MB if I spend $40. on a 16M
memory card) - that would be really cool!.

Now tell me, can the billionnaire Bill Gates and his chronically defective
and bloated MS versions of windows do all this? Yeah, right. Great marketing
and poor product ... oh yeah, I remember that product, magic elixir!

Thanks ICPUG and tazoc and Barry, et al!