First, an apology for not testing and reporting the results of your pet to fix the grub menu.lst problem on frugal installs. My test machine was disassembled until yesterday. You were correct in your assumption, the problem showed up in a case where grub had not previously been installed. I reformatted the disk and tested in the same configuration that failed before.

The files are all copied to /boot/puppy214R, (I normally put the puppy directory up in / where it is more visible,) but menu.lst won't boot because of several errors. (The error code is from memory. I don't guarantee the errors are letter for letter what I found.)

My own preference is to make psubdir=/puppy214R. This stays the same, regardless of whether or not any other Linux is installed on that partition, and is easy to find. If the partition is used as /home by another system, a boot directory is confusing.

Again, my apologies for not testing sooner. Your fast response to the problem simply got overlooked. If I was younger I would be in that code messing around. You're probably lucky I am not.

The files are all copied to /boot/puppy214R, (I normally put the puppy directory up in / where it is more visible,)

Are you sure all of them are in the subdir? The installer is supposed to only put the kernel and initrd in there -- the sfs files should go at the top level of the partition you chose to install Puppy to.

Quote:

My own preference is to make psubdir=/puppy214R. This stays the same, regardless of whether or not any other Linux is installed on that partition, and is easy to find. If the partition is used as /home by another system, a boot directory is confusing.

The idea of the boot directory is that it's on the boot partition and that's where all boot-related files go -- so if you have a few versions installed, all the kernels and initrd's go in there.

One thing I noticed when using puppy2.14r and .sfs files is that you can't just click on them to mount and view them, unlike the puppy 3.0 series, you click and look inside, In puppy 3.0+ they mount with a single click and disable the same way, very handy when your build your own custom version. Or just want a file etc.
thanks for your time ttuuxxx_________________http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games

One thing I noticed when using puppy2.14r and .sfs files is that you can't just click on them to mount and view them, unlike the puppy 3.0 series, you click and look inside, In puppy 3.0+ they mount with a single click and disable the same way, very handy when your build your own custom version.

That's intensional, as I don't believe laymen should have sfs files auto-mounted (I just press Ctrl+! and then type "mount -o loop file.sfs /mnt/data")._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

The idea of putting everything in one Puppy folder is my own, it helps keep down confusion about which system uses which files, particularly if you have multiple versions of Puppy. I need to go back and check on exactly what the frugal install did by default. This time I'll get exact copies for you.

On my Gentoo system /boot is a separate 130 MB partition, which is only mounted when I want to change kernels or booting. This has plenty of space for booting systems built under Gentoo, but I have enough confusion about which kernel I'm testing under Gentoo, I don't want foreign kernels in there, and I don't want to wipe out Puppy with a change to a Gentoo script under test. (The Gentoo machine is down at the moment. I just brought two machines back up, so having one down is par for the course.)

Damn Small Linux is another example of Linux with frugal installs, which can coexist in partitions with other systems. Several other systems now use squashfs files. (Just checked TinyFlux 1.0, which at least uses a different extension.) Placing these directly at the root of the directory tree has already caused me trouble with Puppy variants. Since we need a Puppy directory for kernels, initrd and sfs files I feel there should be a single directory with all, a personal preference.

Several local people who have tried Puppy have called me with questions. I've learned to find out if they have previously tried several versions. Getting one file from one version and another from a derivative is a recipe for chaos and madness.

Incidentally, I agree with what you told ttuuuxx about mounting sfs files. People who don't have a clue really can get in a mess. Trying to find out what happened afterwards, when they didn't know to begin with, is a lost cause.

Please don't take any reports of bugs as personal criticism. There are good reasons for my reporting a problem with the grub install script rather than trying to fix it myself. I'm not up to speed on Puppy, and at the rate it moves I may never catch up.

Sure, it's better that you report to me than just fix it for yourself! This way I can fix the bug once and for all._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

Just a little off topic. Is there any possibilities that this version of puppy will include the gslapt of Puppy 3.01? Because I like this Revisited version as a base for a customised puppy, its so fast in my laptop (Thinkpad T23).

Is there any possibilities that this version of puppy will include the gslapt of Puppy 3.01?

No, the filesystem in 2.14 doesn't match the Slackware libraries, so you'll have compatibility problems. (there was, however, a thread about adding Gslapt to Puppy prior to 3.0, so you might be able to install it and get it to work somehow)._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

Damn Small Linux is another example of Linux with frugal installs, which can coexist in partitions with other systems. Several other systems now use squashfs files. (Just checked TinyFlux 1.0, which at least uses a different extension.) Placing these directly at the root of the directory tree has already caused me trouble with Puppy variants. Since we need a Puppy directory for kernels, initrd and sfs files I feel there should be a single directory with all, a personal preference.

The reason I put the kernels and inird's in the /boot partition is for the same reason you have such a partition on your Gentoo machine: that partition has all the boot-related files and is used only when booting (I have a 50MB ext2 partition for it).

There is one reason why I am willing to change to having all Puppy files installed to one subdir: to keep things tidy. That way you just need to delete the pup214R directory and you've finished "uninstalling" (except for the grub entry).
In fact, I have now modified rc.shutdown so that on first boot it checks if you've booted from a subdir and then offers you to create the pup_save inside it.

So I went over the installer and modified it to put all files in $DESTMNTPNT/pup214R/ and spent quite a while going over the ugly kludge which is grubconfig and modified it to work with it, too.
I had only one thing I wasn't sure about: when Barry introduced the subdir option, he modified the installer so the grub entry includes the drive number not only in the root/rootnoverify line, but also in the kernel and initrd lines. For example:

Now, I always thought it was unneccesary -- the "root" line tells it where the root is...
Anyway, I decided to check: I have a full install on hdb2, so I created the directory /mnt/hdb2/boot and put the kernel in it, then modified the grub menu to say

Code:

root (hd1,1)
kernel (hd1,1)/boot/vmlinuz ...

and tried booting it.

I got an error (#21) from Grub: no such disk.
I tried playing around with with the grub shell and discovered that grub cannot see my hdb!!
I don't know what the deal is -- it's an old IDE drive, connected as primary slave -- but grub just kept offering me only hd0 and fd0...

So it seems like we're staying with having all the boot files in the boot partition...

Just ran your latest grubconfig (18 Dec) from the v 1.01 disk. On the first try I renamed the boot directory in the linux installation on hda6 to hide it, and formatted hda1. Did a frugal install to hda1. Everything went like clockwork and the system booted as intended.

Round two: formatted hda1 and rerenamed /reboot on hda6 back to /boot. This time grubconfig did not complete the install of grub. (I may have confused it by leaving entries in menu.lst for earlier installs.) This time it made a bizarre contribution to menu.lst

There is an old problem here, which people have been living with, grubconfig generates menu entries for linux partitions with no vmlinuz. This is obviously not urgent.

The initrd line for the system on hda6 is another matter entirely. That system will not boot unless it is changed. No idea what grubconfig thinks is going on.

My own preference here would be to add an entry for Puppy to the existing menu.lst, or even write the entry to a separate file and let the user edit it in. If the system is booting with Grub from an existing Linux installation we should do nothing to prevent that from working.

The "foreign" Linux system here is TinyFlux 1.0. I've been using that for testing because it is relatively small (235 MB) and quick to install, and it is a cut down version of PCLinuxOS, which is currently at the top of distrowatch's list. (If they consider 235 MB tiny, what would they call Puppy?)

What you have now will handle the most common cases: frugal install with no previous Linux and install to a flash drive. (Unless the latter has changed since I last tested.) If you see an easy fix, then go for it. If not, a small stable system with live CD, flash drive install and frugal install which works in most cases is worth releasing, as is.

One thing I noticed when using puppy2.14r and .sfs files is that you can't just click on them to mount and view them, unlike the puppy 3.0 series, you click and look inside, In puppy 3.0+ they mount with a single click and disable the same way, very handy when your build your own custom version.

So basically in a nutshell you want to complicate .sfs because you think new users are "laymen". and you have no support for slackware/Gslapt and by reading on don't want to. Really Dougal I really liked 2.14R. But I must say its a bit to swallow, that you want to complicate something that is simple and works well for the one out of 100 users that might muck something up looking into .SFS file. Couldn't you just have a notice like " Be Careful or Use at Own Risk or Are you Sure"??? Not type 34 characters/keys including spaces! Really are you a coder or do you like GUI? I'm not trying to argue and tell you how to do your thing, But when I feel something is wrong I always voice my concerns, If it falls on death ears then at least I tried.
ttuuxxx_________________http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games