Scan a fixed directory for .sfs, .3fs, .swp, .iso at boot

[joki]

from:
http://www.murga.org/~puppy/viewtopic.php?p=77133#77133

just thought for frugal installs it'd be neater for the puppy boot process to scan a named folder name for these files instead of, or as well as (for backward compatibility), the root directory of all devices.

that way all files are in one place and the root drive won't get cluttered up.

[sunburnt]

This has been suggested repetedly... & I agree completely!

The contense of the file: /etc/puppyversion could be used to search for the dir.

The trouble is not all remasters have the name in the file changed.
But if this "puppyversion renaming" were made part of the remaster script...?
So that during remaster, a new version name was "forced", then it'd work.

[Dougal]

I went over the init script a while ago and tried to figure out a way to make it more efficient and the only way I found was something like you mention. I thought of either having a "marker" file on the used partition or having a parameter, in both cases intending to save puppy the search through all partitions.

In the end I decided that the time saved will be negligible and that it will only limit Puppy's flexibility (now you can have different things in different places and they're still found).

[sunburnt]

Dougal; But I don't beleave it'll look in sub dirs. as joki suggested.
Having ALL 4 files for any Puppy version in a sub dir. would REALLY help.
Such modularizing of Puppy's files will allow multiple versions to exist on ANY boot media.
Also a common dir. for common files, such as "usr_devx.sfs" & MU's "MegPup".
This way no matter what version was booted, the extra Squash files would be loaded.

Also in this line... TedDog suggested "cleaning up Puppy's monolitic code".
I suggested breaking it into the common code in "init", & then separate scripts for each boot type, the PMEDIA value would call the appropriate boot script for that device, scripts for: CD/DVD, HD, HD-Full, USB.
This would greatly ease the maintaining of the boot code, & make it easier to learn & understand.

[Dougal]

Sunburnt: About finding files inside directories:
You could possibly replace the "ls pup_save*.3fs" and "ls *_$PUPPYVERSION.sfs" expressions with "find", but that might cause problems later with how parameters are used.
For example, PUPSAVE is defined as "ext3, hda4, /pup_save.3fs" or something like it, so replacing "/pup_save.3fs" with "/puppdir/pup_save.3fs" might not work somewhere..
Maybe it could be arranged that the script will search inside directories named "puppdir*" or something, then you can add to the expressions above something like: "ls puppdir*/pup_save*.3fs" and "ls puppdir*/*_$PUPPYVERSION.sfs"

Someone asked a few days ago and I looked it up and it might be possible to change a few lines and solve this, but there could be further complications, it needs to be thoroughly checked (which isn't simple -- we've only just encountered the problem of remastering from multisession CD/DVD-- no-one bother to test it and comment until now

[sunburnt]

Yep; I've looked at the boot code for quite awhile now making LanPuppy...
Monolithic; "mono" meaning "one", in the case of Puppy2... the init file.
The thought I had was the ease of dealing with code for a paticular boot type.
Once the common code is run, do: exec usb-boot (or something like that).
The code wouldn't be replicated, just moved to a script expressly for that.
This way the code is undoubtedly easier to learn & maintain.
Also changes are far less likely to have any bad effects with the code sectioned.

For the sub dir. thing, cycle through the DRIVEs, & do:
if [ -d ${DRIVE}/$PUPPYVERSION ];then
MAINsfs=${DRIVE}/$PUPPYVERSION
fi

And do the same for a common dir. for the extra Squash files.
So it'll use a sub dir. if it's there, or if not, it'll do the usual ransacking search.
The search code should be a "last resort", not the usual way of booting.
I agree, using "find" or even "ls" is a precarious way of resolving boot issues.
Yep, Puppy was a "live CD" distro, but not just that any more,
it seems the code has been simply added on to, to accommodate new stuff.

The forum requests are for booting multiple versions of Puppy on one drive.
I beleave TedDog's intention (and I agree) was for a more structured boot.
Many have asked for a more flexable boot (and I agree), I've had to change the boot code to get Puppy to boot on a USB flash drive.
I don't know just what was the problem, but cutting out the bulk of the ransacking & using only the USB boot code allowed it to boot.
So separating it would make this job easier & maybe unnessasary, as it seemed to be getting lost trying to find the USB.

The init file should do common setup, & the PMEDIA & ransacking if needed.
And the actual booting from the given media in sub scripts... that's modular programming.
But one could say that using functions or even "if" statements is modular...

Whatever the final solution, it SHOULD be incorperated into Puppy to solve the users problems, after all... aren't the users what any distro is about?

[Dougal]

And the actual booting from the given media in sub scripts... that's modular programming.
But one could say that using functions or even "if" statements is modular...

That's eaxactly my point: it uses functions and case structures, so in fact it's modular, while if you used separate scripts for different boot options they would be modular...

Another problems with scripts for different media is how many? You have the case structures for PMEDIA and for PUPMODE which give you heaps of ways Puppy is run...
And the media is determined part way down the script, so you'll need the script to get to that quickly so it can decide which other script to run...
Maybe a boot parameter could be added, so that if you give nothing it assumes live-cd, but when you boot off a partition the boot manager will give it... but that could add other complications (like pupmode).

As for users wanting to boot multiple versions on the same drive, do you actually mean "versions" or "variants"?
Variants should use different filenames than the original Puppy -- it is the responsibility of their creators to take care of that, not Barry's to solve the problems they create.
Different versions of Puppy shouldn't be a problem, since it searches for pup_$PUPPYVERSION.sfs that fits the appropriate version you're trying to boot...

In any case, look below at what I managed to do.

Oh, and if you had to change the init script to get it to boot somehow you should inform Barry of it! That's what's so good about him being around: you mention the problem you had and he fixes it... He won't know to fix it if don't tell him about it first.


OK, here's what you asked for.

I've got here a modified init script that searches for pup_save on the root of the partition and one level into directories (i.e. doesn't go into subdirectories) and then uses a pup_2xx.sfs that's in the same directory as the pup_save you chose.

It also searches for extra sfs files (like devx) on the root of the partition pup_save is and down one level.

Note that you will need to use Pizzasgood's initrd-editor in order to put this script into initrd/sbin.

This script is a modification of the one from 2.10. If you want to apply the modifications to a newer version, you can find them by searching for my name and for '#####'.

[sunburnt]

Looks great Dougal! Just what joki was talking about.

I still think putting in first a check for a dir. named for the contense of /etc/puppyversion would be good.
It'd save the ransacking the H.D.s for the dirs., speeding up the boot process (a popular request).
It also may avoid getting the wrong files if there's multiple Puppies in dirs. & on different media.
But as I said, the contense of puppyversion would HAVE to be unique!

As to just what was wrong with USB booting, I don't know, but it was the same as many of the posts.
Deleting the ransacking code allowed it to boot straight to the USB, & of course it worked.
Separating the code may do the same thing, I don't know for sure.
The suggestion amounted to the PMEDIA value calling the separate scripts,
so how ever many values there are for PMEDIA (CD/DVD, HD, HD-Full, USB... 4 is all?).

[Dougal]

I think removing the "ransacking" is probably not good, since then Puppy will lose some of it's flexibility -- finding files everywhere -- which is what allows things like me booting from hda1, having pup_save on hdb1 and pup_2xx.sfs on hda3

[GuestToo]

the process of the original script only terminates after init-lan finishes

exec init-lan should start init-lan running as a continuation of the same process as the original script ... it will have the same pid ... that's what exec does ... so that should not be a problem

in other words, the original process would be replaced by the init-lan process

[sunburnt]

Correct, I was saying I got it to USB boot by removing the drive parsing,
but I wasn't suggesting it as a code change.
The observation I made was that Barry's USB code worked fine,
but the parsing or something else was keeping it from working.
The boot failure was the same as many of the USB boot help posts.

As far as the LanPuppy boot code goes, it'd probably be most consistant to add it into the init code.
If Barry so chose to separate the code I think folks would learn it easier,
and it'd be easier to maintain & modify.

I could offer the LanPuppy-1 code for Puppy 1.10 as it's for Puppy-1.
It's just like Puppy-1 in that the file structure is the same & there's no login.
But I don't know if there's going to be a Puppy 1.10 ... does anyone know?

I haven't bothered with Puppy-2 as Puppy-1 kind of lends itself to LAN boot.
Plus I'm not sure if Puppy-2 does anything that Puppy-1 won't do (except for the kernel).

LanPuppy-1.1 will have login & a client common install dir. instead of /.usr
I've been side tracked again by other jobs & autos needing my attention.

Note; I just had to save this post so it wouldn't be lost by server error.

[Dougal]

My suggestion about the LAN code was an example of a quick-n-dirty way that users can help add features/ solve problems.

If something happens during the "ransacking" that messes up booting from USB, then the point should be to try and find out what it is

[pakt]

[quote="Dougal"]Good to see someone else but sunburnt and me is reading this thread

[Pizzasgood]

I'm keeping an eye on it, mainly because I'm going to have to mess with the init scripts for Pizzapup: A.T.E.

[sunburnt]

As usual... No word here as to Puppy1 or Puppy2, the problem & fix I made was to Puppy1.
So the code changes aren't relevant to Puppy2, BUT... the problem seems to still be there.
It seems to be a case of not finding the USB drive in the ransacking.
I haven't looked at Puppy2 to see how this is done, but if probepart is used...
I had a pickle of a time while writing usb-auto & I finally axed probepart & began using dmesg instead & I had MUCH better luck finding the USB.
I don't know if using dmesg at boot would work, maybe not...

As others have suggested, more boot options would allow handling "special boot situations".
My suggestion in another post was: boot arguments that override everything,
then a config. file at the next level does the same thing,
then the ransacking as a failsafe/firstboot with a choice to make a config. file.
This increases complexity, but not much, & it may solve some boot problems.

Note: This server is working GREAT today!

[Dougal]

usbstoragecompletionfun actually uses dmseg for looking up which usb devices were detected, but just for the sake of finding out when the scan is completed and letting you know...

Code: Select all

USBSTORAGES=`/bin/dmesg | grep -o "usb-storage: device found at.*" | wc -l | sed -e 's/ //g'`
   AVAILABLEUSBSTORAGES=`/bin/dmesg | grep -o "usb-storage: device scan complete" | wc -l | sed -e 's/ //g'`

You could easily create a loop that gets info from dmesg and compares it with PCPARTS and if it's not there, adds it (at the beginning).
Then you can put that loop into the "usbflash" part of PMEDIA case structure....

In the case of USB, the init script gets a list of drives from "cat /proc/partitions" and passes it on to findpupfunc which looks for relevant partitions in PCPARTS (which was created by probepart).
So to find devices that probepart misses you need to get actual partitions from /proc/partitions (which doesn't give you the fs) or dmesg.

Maybe something like this would do the job:

Code: Select all

USBLIST=""
dmesg | grep -i 'sd[a-z][1-9]' | tr A-Z a-z | egrep 'ext2|ext3|reiserfs|msdos|vfat|minix' | fgrep -v 'warning'  | sort | uniq | cut -d' ' -f1,4 | tr -d ',' | tr ' ' '|' | while read ONE ; do
APART=`echo "ONE" | cut -d'|' -f2`
AFS=`echo "ONE" | cut -d'|' -f1`
USBLIST="$USBLIST $APART|$AFS"
done

You will have to filter out the SATADRIVES somehow:

Code: Select all

for ASATA in $SATADRIVES ; do
USBPARTS=`echo -n "$USBPARTS" | tr ' ' '\n' | fgrep -v "$ASATA" | tr '\n' ' '` ; done

Then you can add USBPARTS to PCPARTS:

Code: Select all

PCPARTS=`echo -n "$USBPARTS $PCPARTS" | tr ' ' '\n' | sort | uniq | tr '\n' ' ' | tr -s ' '`

If you can get something like this working properly, you can probably offer it to Barry...

[sunburnt]

This is a bit like what I considered for usb-auto, but the differences between Puppy-1 & Puppy-2 killed it.
I had a lot of folks post dmesg output & it was rather inconsistant with what my PC output.
The output changed from old to new PCs, different MB chipsets & USB controller chipsets.
Even my PC didn't consistantly produce the same dmesg output while developing it.
USB flash drives worked okay, but card readers with several cards in them torqued it!

At this time I'm putting together a distro of PupServer & LanPuppy1-01
At the same time I'm finishing up the code for LanPuppy1-10 to start testing.
For now I need to concentrate on this to kick it out as soon as possable.


The last couple of days the forum's been working great for me, everyone else too?

[joki]

happy to see others wanting the same thing

I've had a look at the init script myself and it looks doable. however i'm a newbie to puppy so not clued up on the banana skin areas.

if we're taking modularisation to the max then maybe the directory sturcture should be 2 deep in order to handle multiple puppy versions on boot media.
eg:

\pup\210
pup_save.3fs
pupswap.swp
pup_210.sfs or iso
\pup\211
pup_save.3fs
pupswap.swp
pup_211.sfs or iso

i'd be happy with the boot process just scanning for then reading and storing all puppy files in a fixed folder name. ie:

\pup (no version)

but if

\pup_211

is doable even better

[sunburnt]

I'm not sure how Dougal did his boot setup.
But I was thinking each Puppy version being 1 dir. deep was good.
Most folks will probably have 3 to 6 Puppies on their HD.

I made a simple setup for booting multiple Puppies.
All 4 files in a sub dir., pup_211.sfs & pup_save.3fs are moved to /
So there's only one set of pup_211.sfs & pup_save.3fs files in /

I boot in DOS & type the name of a batch file to run Puppy.
The batch file makes a file with the name of the Puppy version it ran.
So when running another version it first moves the 2 files from the
previous Puppy it ran from / back to the sub dir. of that Puppy version.
Then it moves the 2 files for the Puppy it's booting to /
Moving files is quick, so this way it boots just as fast as usual.

I did this in Puppy-1 versions & it works, Puppy-2 versions will work too.
What's nice is that even different copies of the same Puppy version work.
Very simple to setup, & it doesn't require modifications to initrd.gz
Using Grub to boot, it should be possable to use this setup also.
So then ext2 & ext3 partitions will work as well as fat32 partitions.

[Dougal]

Joki: I thought you wanted to have /pup1, /pup2 etc. directories, so I only made it one dir deep.
It it trivial to change it: just search the init script I posted for the places where "find" is used to search for pup_save*.3fs (and *_$PUPPYVERSION.sfs if you want), then increase the number after "maxdepth" by one