Deprecated? boot parameters

[williwaw]

Following @mikewalsh's request here https://forum.puppylinux.com/viewtopic. ... 627#p61627 I tried pmedia=satahd instead of pmedia=ataflash on the kernel line to see what difference it would make when using pfix=ram.

My observation in the other thread was that using pfix=ram with pmedia=ataflash did not boot vanilladpup without the savefile.
Changing to the suggested pmedia=satahd did not either.

Maybe some of the parameters we use have been deprecated?

On a different but related question, I usually include pfix=fsck, but I see in Mike's example, he uses pfix=fsckp. Is one deprecated? Are they both deprecated? What's the difference, and when is the use of this parameter recommended, and which is correct?

[TerryH]

I think this post by @rockedge in the Getting Started and System Requirements,Section is of great assistance for this thread, answering all these questions. It's a great resource.

https://forum.puppylinux.com/viewtopic. ... 875#p52875

[williwaw]

Thanks TerryH,
After reading that post, It seems the issue might be that vanilladpup 9.2.5 does not include DISTRO_SPECS, which seems to be a prerequisite for pfix=ram and pfix=fsck.

Feek's method, https://forum.puppylinux.com/viewtopic. ... 624#p61624 is a nice workaround.

[BarryK]

I think this post by @bigpup in the Getting Started and System Requirements,Section is of great assistance for this thread, answering all these questions. It's a great resource.

https://forum.puppylinux.com/viewtopic. ... 875#p52875

@rockedge
Some of the explanation in that post is not clear to me. For example:

Code: Select all

ex: pupsfs=0db94719-cdf1-44b7-9766-23db62fb85a5

Then a bit further down:

Code: Select all

ex: pupsfs=sdb2:/puppy/precise/puppy_precise_5.7.1.sfs

Does that mean you can have filesystem UUID instead of sdb2, with the path to sfs?:

Code: Select all

 pupsfs=0db94719-cdf1-44b7-9766-23db62fb85a5:/puppy/precise/puppy_precise_5.7.1.sfs

[rockedge]

Does that mean you can have filesystem UUID instead of sdb2, with the path to sfs?:

Code: Select all

 pupsfs=0db94719-cdf1-44b7-9766-23db62fb85a5:/puppy/precise/puppy_precise_5.7.1.sfs

Yes that is possible. Also using this syntax possibility in KLV where UUID and path is used.

[williwaw]

Does that mean you can have filesystem UUID instead of sdb2, with the path to sfs?:

Code: Select all

 pupsfs=0db94719-cdf1-44b7-9766-23db62fb85a5:/puppy/precise/puppy_precise_5.7.1.sfs

Yes that is possible. Also using this syntax possibility in KLV where UUID and path is used.

using this syntax, should it be possible to boot a pup on another disk without chainloading?

[williwaw]

much of what @rockedge posted on https://forum.puppylinux.com/viewtopic. ... 875#p52875
is quite similar to the README.txt found in a few of the pups I have installed recently. README.txt is not attributed to anyone, but perhaps someone can comment on the parameter pdrv? does it still have a place in the recent pups, and if so, what for? Its seems to be used to specify a UUID, but for what purpose?

[bigpup]

using pfix=ram with pmedia=ataflash did not boot vanilladpup without the savefile.
Changing to the suggested pmedia=satahd did not either.
I created a frugal install of both the latest voidpup and vanilladpup on sda2 of an internal ssd.

I assume you are using Vanilladpup 9.2.6
I assume after you made the save you did a boot up using the save.
Then a reboot, trying to use the pfix=ram option.

In my frugal install of Vanilladpup 9.2.6 using a save folder. (save file or save folder does not matter for this option to work)
Booting with the pfix=ram option in the boot loader entry.
It boots not using the save.
It is working for me.

[williwaw]

I assume you are using Vanilladpup 9.2.6

actually, a fresh install with vanilladpup-x86_64-9.2.5 with an extra reboot

1st boot, set up some stuff, made a save folder.

2nd boot, the save was loaded, the icon on desktop was there, but first run setup appeared again.

3rd boot, save was loaded looking good, added pfix=ram

4th boot, no save loaded and offered to create save in spite of no DISTRO_SPECS
good enough this time around, maybe something different happening here? this is a bios boot machine btw.

Actually, more interested what is known about pdrv parameter. and this Q.
https://forum.puppylinux.com/viewtopic. ... 672#p61672
tx

[williams2]

what is known about pdrv parameter

From the FossaPup64 readme:

Code: Select all

pupsfs=<partition> Specifies the puppy...sfs partition
zdrv=<partition>   Specifies the zdrv...sfs  partition
fdrv=<partition>   Specifies the fdrv...sfs  partition
adrv=<partition>   Specifies the adrv...sfs  partition
ydrv=<partition>   Specifies the ydrv...sfs  partition
psave=<partition>  Specifies the save layer  partition

might make you think that pdrv specifies the puppy...sfs partition

Looking in BionicPup64's /initrd/init:

Code: Select all

# 
# grep -i pupsfs /initrd/init
[ $pupsfs ] && PDRV=$pupsfs
echo "PUPSFS='$PDRV'"
# 

which sets PDRV to the value in $pupsfs if it was set in the kernel line.

Setting pdrv or pupsfs should tell Puppy where the sfs files are that it booted from,
or at least where the sfs files should be.

Looking in init for pdrv, there are lines like this:

Code: Select all

# grep -i pdrv /initrd/init
[ $pdev1 ] && PDRV=$pdev1 #boot parameter, partition have booted off. ex: hda3
[ $pdrv ] && PDRV=$pdrv #format partition:<path><filename> ex: sda2:/slacko/puppy_slacko_6.3.0.sfs
echo "PUPSFS='$PDRV'"

Some of the code is debugging, some of the code seems to be searching partitions for the sfs files.

Basically, pdrv seems to be the partition where the Puppy...sfs file should be, and where the other sfs files probably are also.

[williams2]

should it be possible to boot a pup on another disk without chainloading?

Yes.

You can chainload another boot loader, but you already have a boot loader running. All it needs to boot Puppy are a few lines in the menu.lst or grub.conf file.

Basically, the boot loader needs to be told where vmlinuz and initrd.gz are.
It loads those 2 files to ram and executes them.
That is all the boot loader does. it does not know about sfs files.
The initrd knows about sfs files.

[bigpup]

Documentation is getting to be the last thing anyone wants to do for Puppy Linux.

Things get added, and the documentation about it, does not get made or updated, in the documentation that is already there.

pdrv got added a few years ago, as an optional boot loader entry filter.

it is used to identify the exact location of the Puppy files, so the boot process does not have to search for them.
Think of it as saying this is the drive partition the files are on.
Most modern boot loaders use this to identify the uuid of the drive partition.
The uuid is a specific identifier that only that drive partition will have.

Example boot menu entry:
title Puppy fossapup64 9.5 (sdb3/fossapup6495)
find --set-root uuid () 24a14d90-6d75-4276-a6a0-ef026f8d07cf
kernel /fossapup6495/vmlinuz pdrv=24a14d90-6d75-4276-a6a0-ef026f8d07cf psubdir=/fossapup6495 pmedia=atahd pfix=fsck
initrd /fossapup6495/initrd.gz

The pdrv= is saying the files are on this partition (uuid)24a14d90-6d75-4276-a6a0-ef026f8d07cf on the drive.

[williwaw]

Basically, pdrv seems to be the partition where the Puppy...sfs file should be, and where the other sfs files probably are also.

pdrv=ce4ef232-b351-49dd-b07c-5abeb8a0281a:/pups/vanilla/puppy_vanilladpup_9.2.5.sfs
as a kernel line parameter with the full path to puppy.sfs, the pup booted with only the puppy.sfs
not too useful without the other sfs's
the psubdir parameter was not present during this boot, and without documentation for using pdrv, I'm not sure what its intended use is.

The pdrv= is saying the files are on this partition (uuid)24a14d90-6d75-4276-a6a0-ef026f8d07cf on the drive.

Bigpup
I assume your example stanza was for use with grub4dos?
find --set-root uuid () 24a14d90-6d75-4276-a6a0-ef026f8d07cf

with grub4dos, find --set-root seems to be sufficient for the loader to find vmlimz and initrd.gz
and so long as psubdir=/subdirectory is used, the pdrv=24a14d90-6d75-4276-a6a0-ef026f8d07cf was not needed.

[bigpup]

Just because it is not needed does not hurt anything if you do use it.

To be honest, it depends on the Puppy version and how it's specific boot process is working.

Some of the older Puppy versions, had issues booting, and fixes where made in the boot processes.
However, those fixes are not going to be in these older Puppies.
Only in newer Puppy versions made using newer versions of Woof-CE build system.

pdrv=ce4ef232-b351-49dd-b07c-5abeb8a0281a:/pups/vanilla/puppy_vanilladpup_9.2.5.sfs

This is only loading the vanillapup_9.2.5.sfs because that is what you are telling it to do.
/pups/vanilla/puppy_vanilladpup_9.2.5.sfs

psubdir=/pups/vanilla is what you should use.
This says the files are all in this directory.
I am assuming the vanillapup files are in /pups/vanilla directory.

[amethyst]

and so long as psubdir=/subdirectory is used

Yes, the way I have used it for ages. This is useful when you do a "manual" install of the bootloader in order not to overwrite the existing boot record (for instance a dual-boot with Windows). Very safe method.