Multiple SFS support in initrd

Message

Karl Godt · #61 Post by **Karl Godt** » Tue 12 Mar 2013, 04:23

That is not your Windows files. It is an OS's files licensed to you.

mavrothal · #62 Post by **mavrothal** » Tue 12 Mar 2013, 04:48

greengeek wrote:Now that we have adrv, ddrv and zdrv, could you also add c:drv please (to contain all my Windows files). I noticed ever since I first tried puppy that the c:drv has been missing...

Regarding c:drv, let me recycleanother post

It can run from NTFS partitions.
Actually I find this a flaw! (also for puppy)
NTFS. So primarily you are a windows user, used to be asked 5 times if you "really, truly, positively want to open this application".
And now you are granted root access in a system that you do not know very well and you are one typo/click away from messing your Windows partition (and then spend a day try to recover your "graduation pictures" ).
Besides NTFS already implies that it is a hobby/test OS and is not really used

R-S-H · #63 Post by **R-S-H** » Tue 12 Mar 2013, 07:30

Hi mavrothal.

filemnt message is: could not find free loop device.

Do I have to increase them as well in initrd.gz or how could this be done?

My initrd.gz has loop0 to loop10. The sfs_load creates automatically new ones if more sfs files are loaded.

So, let's say sfs_load has created new loops up to 16 then the iso could not be mounted if all loops are used. Unloading an sfs and mounting a iso works.
After unmounting the iso and loading new sfs mounting a iso fails again and son on. --> sometimes sfs_load stops to create new loop device after mounting an iso has failed several times.

That's really weird for a beginner like me...

To set option -x (set -x) in filemnt would have which effect?

Thanks

RSH

mavrothal · #64 Post by **mavrothal** » Tue 12 Mar 2013, 09:41

R-S-H wrote: To set option -x (set -x) in filemnt would have which effect?

Not that I know off. But is the filemnt behavior changes in you setting depending on "set -x"?

If you have problem with number or the generation of loop devices in /dev you may just want to make them manually once and have them there
Just type "mknod -m664 /dev/loop<number> b 7 <number>", where number is 11, 12,... etc (you can do it with a script too).

This will not address the root of the problem but it may cover it (up to the number of loop devices you will make).

The problem with this kind of "debugging" is that you have introduce several changes in your code-base so is hard for anybody else to reproduce or even see what is going on.
If you are going to keep developing/changing things you may want to seriously consider a versioning system (git, svn, hg etc). If it is pubic is even better

R-S-H · #65 Post by **R-S-H** » Tue 12 Mar 2013, 18:28

Thanks for your long support here, mavrothal.

I have used a script to create the loop devices:

Code: Select all

#!/bin/bash -a
#------------------------------------------------------------------------------
# Make loop devices for LazY Puppy
#------------------------------------------------------------------------------

for i in 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64;
do
	mknod -m664 /dev/loop$i b 7 $i
done

exit 0

#------------------------------------------------------------------------------
# End 
#------------------------------------------------------------------------------

All loop devices are successfully created. But I'm not sure how to do this or better saying when/where.

Should I create the loop devices from within the init scipt (at boot up) or editing the initr.gz to create the loop devices. Path then would be:

Code: Select all

mknod -m664 /root/init_rd_temp/dev/loop$i b 7 $i

I assume different path makes no difference?

Thanks

RSH

P.S. Tests to create the loop devices has been made using a LazY Puppy version with no adrv options added (currently running it) - so, I couldn't test anything else yet.

mavrothal · #66 Post by **mavrothal** » Tue 12 Mar 2013, 18:42

R-S-H wrote: I assume different path makes no difference?

I do not know.
I have not seen devices outside /dev but this may just be a convention.

But I think we are getting waaaaay off topic here.
You may want to open a specific thread for these issues like "LazY puppy next" or something.

R-S-H · #67 Post by **R-S-H** » Tue 12 Mar 2013, 19:41

I do not know.
I have not seen devices outside /dev but this may just be a convention.

No, the devices are not outside /dev. What I meant is, if I'm extracting the initrd.gz to edit the files those files will be extracted to /root/init_rd_temp. Therefor the path for the mknod command script would be /root/init_rd_temp/dev. Sorry for confusing you.

However: currently running LazY Puppy 3.0.0 with adrv option added. Executing the script to create loop devices up to 64. Loading sfs files up to pup_ro35 and mounting an iso still works - even after unloading sfs files and loading new ones. Everything seems to be fine.

Thank you very much for your long support here, mavrothal. I will notice it in LazY Puppy 3 - when published!

BTW:

I think my issues on this here are not LazY Puppy specific - they might surely hurt any lupu user who wants to add such a nice feature!

Thanks again

RSH

Karl Godt · #68 Post by **Karl Godt** » Tue 12 Mar 2013, 20:18

RSH : If the initrd.gz initscript should mount these dozen .sfs to merge them into the layered aufs/unionfs filesystem, then it must be altered. This sfs_load by shinobar is a nice and apparently good working script to mount and merge .sfs by /etc/rc.d/rc.sysinit or rc.local or /root/Startup/my_sfs_load_script.sh .

Happy crashes while experimenting with /init !

R-S-H · #69 Post by **R-S-H** » Tue 12 Mar 2013, 20:23

Hi Karl Godt.

RSH : If the initrd.gz initscript should mount these dozen .sfs to merge them into the layered aufs/unionfs filesystem, then it must be altered. This sfs_load by shinobar is a nice and apparently good working script to mount and merge .sfs by /etc/rc.d/rc.sysinit or rc.local or /root/Startup/my_sfs_load_script.sh .

As usual useful information!

Happy crashes while experimenting with /init !

Thanks, but so far: nothing crashed!

greengeek · #70 Post by **greengeek** » Thu 29 May 2014, 08:55

Sorry guys - I didnt read this whole thread - I just got linked here by a discussion elsewhere about zdrv usage.

My question is - could it be possible that puppy could use a 'pdrv' which contains the personal configuration? At its most simple I can imagine a pdrv containing a single text file that holds information like wifi SSID and key.

Maybe it could be more complex - like containing the following:
$TIMEZONE (or maybe $GMT_OFFSET would be simpler).
$KBD_LAYOUT
$LANGUAGE
$WIFI_SSID
$WIFI_KEY
$WIFI_ENCRYPTION (eg Open, WEP, WPA, WPA2) (Although I think Frisbee can detect this automatically...)
$HOSTNAME (Probably don't need this - Puppy does a good job of allocating a random name at present)

My personal usage of this concept would be a Live CD, containing some recent puppy, but with the ability to incorporate an added text file (or pdrv sfs) which would tailor that puppy to suit my own needs (or the needs of some friend of mine on the other side of the world who uses a qwetrz keyboard and some weird language like Swahilli or Antarctican)

Doesn't seem that hard - instead of the init scripts choosing the current defaults like Perth, En_US and US_Intl keyboard the scripts would look for the personal text file or pdrv and automatically set the defaults to that predetermined combination.

Could the initrd or init scripts be made to look back at the CD for a text file, or would it have to be an sfs?
.

rufwoof · #71 Post by **rufwoof** » Thu 29 May 2014, 10:21

I just remastered to the particular PC with the locale (keyboard), network etc all set to the PC. Really light version (basic desktop/utils), so boots quickly, with the rest being added in by loading SFS's/PET's. As part of the SFS/PET load scripts I copy each individual programs config files to /root, so that any program config changes are restored across reboots. If any of those are changed and wanted to be preserved I just replace the outside puppy copy of the config file(s).

So I'm LiveCD booting with no savefile loaded nor saved, but with selective persistence (manual/selective bits saved/restored).

For that purpose I created sfs load (sfs_load) and pet load (petget) scripts that don't prompt for anything (just run to completion) so that they can be run in a script. I also copy and run everything in ram (so CD and HDD's can all be unmounted after having booted).

I have a single script that calls all of the individual load scripts, so boot, run that script and all of Libre, SOFFICE, utils (compress, flash, magnifier, etc), multimedia (OpenShot, Blender, GIMP, InkScape, VNC, etc), Skype ..etc all get loaded - whilst the desktop is available (can be browsing the net, checking online email etc whilst all the others are being loaded).

greengeek · #72 Post by **greengeek** » Thu 29 May 2014, 10:39

What I am wanting to achieve is a method where the puppy "pre-configuration" can be done without any form of remastering or running wizards on a specific machine.

eg: imagine if your friend across the other side of the world said "hey, I would like to try the latest puppy - can you send me a copy?" - it would be great if you could simply ask him for basic details and manually build a text file or sfs to force that puppy to run on his PC without wizards or remastering.

He would just have to tell you the following:
Timezone
Language
Keyboard Layout
Wifi MAC address
Wifi password key
Wifi SSID

etc.

If such a manually created sfs could be picked up at boot time (ie while initrd is running prior to booting) his puppy would boot into a correct configuration and he would not even have to run Quicksetup to get it set up correctly. It would be all ready to go.

Better still if initrd could grab a simple text file of pre-determined layout, rather than an sfs.

mavrothal · #73 Post by **mavrothal** » Thu 29 May 2014, 11:11

greengeek wrote: My question is - could it be possible that puppy could use a 'pdrv' which contains the personal configuration?

The adrv and ydrv are already in woof-CE and slacko-5.7 initrd could use them if defined in DISTRO_SPECS. You could use those instead of a pdrv.
For a puppy that does not use a zrdv (most don't) you can just make your changes and save them as a zdrv.

mikeb · #74 Post by **mikeb** » Thu 29 May 2014, 11:27

Ok booted lucid today... from the piccy the kvm sfs was loaded as shown no config needed... the archive was loaded as shown containing the last session

heres df output
# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 1.4G 8.5M 1.4G 1% /
/dev/root 2.2M 1.9M 281K 88% /initrd
tmpfs 130M 129M 512K 100% /initrd/mnt/tmpfs
/dev/loop3 17M 17M 0 100% /initrd/Kernel-lucid-kvm_sfs4.sfs
/dev/loop2 112M 112M 0 100% /initrd/pup_ro2
tmpfs 1.4G 8.5M 1.4G 1% /initrd/pup_rw
unionfs 1.4G 8.5M 1.4G 1% /
shmfs 466M 0 466M 0% /dev/shm

and from mount
# mount
rootfs on / type rootfs (rw)
/dev/root on /initrd type ext2 (rw,relatime,errors=continue)
tmpfs on /initrd/mnt/tmpfs type tmpfs (rw,relatime,size=132588k)
/dev/loop3 on /initrd/Kernel-lucid-kvm_sfs4.sfs type squashfs (ro,noatime)
/dev/loop2 on /initrd/pup_ro2 type squashfs (ro,noatime)
tmpfs on /initrd/pup_rw type tmpfs (rw,relatime,size=1417440k)
unionfs on / type aufs (rw,relatime,si=250deed8)
none on /proc type proc (rw,relatime)
none on /dev/pts type devpts (rw,relatime,gid=2,mode=620)
none on /sys type sysfs (rw,relatime)
shmfs on /dev/shm type tmpfs (rw,relatime,size=476976k)
none on /proc/bus/usb type usbfs (rw,relatime)

look no drives..

no adrv, zdrv, nutdrive, willydrv or any other avoidances of the simple

cup cakes
mike

greengeek · #75 Post by **greengeek** » Thu 29 May 2014, 17:56

mavrothal wrote:The adrv and ydrv are already in woof-CE and slacko-5.7 initrd could use them if defined in DISTRO_SPECS. You could use those instead of a pdrv.

OK thanks thats a good start - two things I want to clarify -

1) My question is really directed at the idea of HOW such a drv.sfs is used when the initrd grabs it and uses it. What I am trying to convey is this:

Current puppies (I'm using Slacko 5.6 as an example) seem to have a really good ability to detect a usable video setting, and even when there is no savefile they automatically boot to a functional desktop with a Quicksetup screen that is defaulting to Perth timezone, En_US language, and US-Intl qwerty keyboard layout. What I am asking is - is it actually possible for the initrd to include reference to a specific drv.sfs that has the unique function of setting those quicksetup defaults (and including wifi key) so that this info is present right at the time of first booting the initrd.
I am not talking about a situation where the advanced user can build a zdrv or adrv (using advanced skills and experience) to achieve what they want - I need to know if people think it could be possible for puppy to accept a "standardised' drv.sfs (or even better a text file called something like 'user_defaults.txt) that can easily be changed by the user and burned into the iso.
Is it possible for the initrd to be easily modified to look back at the CD and find (alongside syslinux.cfg etc) such a textfile? If it can easily look back at the CD and grab a drv.sfs can it do the same with a textfile? Or does it HAVE to be an sfs?

I know some of these parameters can be specified as boot prompts - but the Wifi SSID and Wifi key cannot. I am trying to visualise an initrd structure where these parameters can be 'pre-configured'. If we did standardise such a 'pdrv.sfs' contaiing these parameters would it be the initrd that had responsibility for placing the parameters in the correct places or would it require changes to other files in the main puppy.sfs too?

Would Quicksetup have to be altered to understand the data that was in the user_parameter.sfs or could it be an easy 'plug-in'. I have already satisfied myself that I can graft a wifi SSID and Key into a zdrv.sfs (and after it is loaded by the initrd it automatically gets picked up by the sns functionality at boot time), but I'm not sure how to go about doing the same with default language, keyboard layout, timezone etc.

Could there be a future time where this preconfiguring could be commonplace - rather than waiting till shutdown time to build a savefile. (I am only talking here about basic default parameters - not about building an entire filesystem with applications etc. Just the basic boot parameters for user customization of the desktop and wifi)

2) If such a thing could be understood and made commonplace I would choose the name 'pdrv' because it would be handy for the 'p' to stand for 'personal' or 'parameter'. Or maybe 'udrv' for user parameters. or defdrv for 'defaults drv'

Not even pdrv_slacko_5.6.sfs. Just pdrv. Or personal.txt. Or defaults.txt. Or user-defaults.txt. Or user_defaults.sfs

Something with a standard name and a standard function.

I'm probably not conveying this very clearly, but Oh Well, never mind...

mavrothal · #76 Post by **mavrothal** » Thu 29 May 2014, 19:39

greengeek wrote: 1) My question is really directed at the idea of HOW such a drv.sfs is used when the initrd grabs it and uses it.

As I said adding the a,y,zdev name in initrd DISTRO_SPECS will make it mountable when present.
But why do you think that building an cdrv.sfs with ones personal setting will be easier than just a good old puppy remaster?

greengeek · #77 Post by **greengeek** » Thu 29 May 2014, 22:59

But why do you think that building an cdrv.sfs with ones personal setting will be easier than just a good old puppy remaster?

Firstly because it is much easier to add a xdrv into an iso by using isomaster than it is to remaster a puppy, and secondly I was hoping someone would say 'yes, we can force the initrd to load a textfile from the cd' which would be a very simple way of grabbing a users setup parameters. Simpler even than making an xdrv. One simple text file containing basic desktop setup defaults in a standard format - for puppy init scripts to refer to during boot.

greengeek · #78 Post by **greengeek** » Sat 31 May 2014, 19:06

Now that I have spent a couple of days tinkering with the zdrv.sfs in slacko 5.6 I understand a bit more about the relative priorities in how the initrd treats the main puppy.sfs versus other .sfs files that are available to it.

I see that a file in the zdrv will be grafted into the running system ONLY if that file is NOT currently existing in the main puppy.sfs.

If that file already exists within the main puppy.sfs then the 'new' version available within the zdrv.sfs is ignored. This compromises the effect of the zdrv.

My question is - are there any types of .sfs files that ARE able to overwrite the main.sfs? Is there any version of puppy that has an initrd which contains the ability to accept an "xdrv.sfs" that can be used to 'override' or 'overwrite' a file within the main puppy.sfs?

If this does not exist then I think it should be a priority for future puppies. Obviously there are good reasons why the use of such a file could be dangerous - but just as many reasons why it could be an advantage. For instance - I want a user to be easily able to change the default timezone that is used by puppy during the boot process. (rather than waiting for a chance to run quicksetup after boot). I could achieve this if the zdrv (or similar) had the ability to let me overwrite a single file within the puppy sfs.

mikeb · #79 Post by **mikeb** » Sat 31 May 2014, 21:42

My question is - are there any types of .sfs files that ARE able to overwrite the main.sfs? Is there any version of puppy that has an initrd which contains the ability to accept an "xdrv.sfs" that can be used to 'override' or 'overwrite' a file within the main puppy.sfs?

It appears I am the only one. If it were dangerous then pets are even more so

Its not the squashfs/aufs system...its how its used you are observing...Slax and porteus are 2 examples of layering on top....actually in their cases the layering order is determined by the alphabetical naming of the squash files...01-blah is under 02-blah

I was hoping there might have been at least one of these wonder sfs that would have been suitable for your purposes

but you seem to be finding the same old brick wall.

Mike

greengeek · #80 Post by **greengeek** » Sat 31 May 2014, 23:20

I guess it doesn't cause problems for most people - in general people are happy that their savefile can take the higher ground, and over-ride the files in the main puppy.sfs.

If you boot from an HDD or a usb stick they are R/W media and you can easily change the files the way you want.

However, this is not true when trying to load from a CD. You can load the main puppy.sfs, but the initrd has no way to force the boot process to also grab (and overlay) a set of personal files that are 'contained' within an sfs. Multisession allows you to grab a save FOLDER / DIRECTORY, but for some reason restricts this behaviour in such a way that an sfs cannot achieve the same thing. (And also multisession keeps wanting to save further updates to those personal files, which is something I would like to be able to avoid...)

I don't know if this was done deliberately to make it easy to start in a pristine mode (pfix=ram from cd) but if it could be changed it would allow someone to easily make a CD that had the main puppy.sfs that they wanted, and simply graft personal files (like wifi SSID etc) over the top - WITHOUT ANY FURTHER ATTEMPT BEING MADE TO CHANGE OR RE-SAVE THE PERSONAL SETTINGS.

I would like the initrd to recognise the puppy.sfs as an unchangeable 'kernel', then allow the addition of a personal sfs to over-ride that kernel, and to respect the option of not making any savefile that could cloud the integrity of what had been set up by the puppy.sfs and personal.sfs

This is the kind of ability needed to make a fully read-only, yet perfectly configured puppy that does exactly what you want. Pristine files at every boot.

EDIT : I probably need to look at how multisession mounts the savedirectory from cd (it MUST be mounted with higher priority than the main puppy.sfs) and see if that code could be modified to do the same with an sfs rather than a directory structure.

EDIT 2 : Maybe what I really need is a way to make the initrd capable of pulling a .2fs or.3fs etc file off the CD - instead of only looking through the HDDs and USB sticks.
.

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Multiple SFS support in initrd