BDRV or maybe CDRV

Programming issues and discussion
Scooby
Site Admin
Posts: 826
Joined: 09 Sep 2013, 16:52

BDRV or maybe CDRV

Postby Scooby » 16 Oct 2013, 19:03

Sim I was thinking.

I always add the same stuff to new AlphaOS'es

I'm thinking making a sfs and load it to BDRV-layer (sfs added to iso)

I've seen BDRV is paired with desktop_*.sfs

Do you think its a good idea to add it as BDRV or should I create CDRV?

Maybe easiest would be a custom sfs loaded with sfs_load and not in iso at all?
Will customs sfs "overwrite" files from alpha_12.sfs and extra_12.sfs?

What is the difference between a savefile (*.2fs) and sfs module made by for example makesfs?
i.e. could you rename a savefile *.sfs and load it with sfs_load (in readonly mode)?


BTW

sfs_load is not nice to me if I dont have a savefile

it thinks I'm booting off a cd???

and throws up another dialog window and when I choose to load with NOCOPY then I get

Code: Select all

sfs_load: ERROR: fatal:Failed to append '/initrd/pup_ro5' to unionfs.


*edit*
For future reference the problem with sfs_load was that I ran makesfs without savefile and it creates
/mnt/home folder wich interferes/fools with sfs_load's operation. If I remove /mnt/home dir all is fine again.

.
.

Marv
Proficient
Posts: 81
Joined: 16 May 2013, 16:42

Re: BDRV or maybe CDRV

Postby Marv » 16 Oct 2013, 20:52

Scooby wrote:Sim I was thinking.

I always add the same stuff to new AlphaOS'es

I'm thinking making a sfs and load it to BDRV-layer (sfs added to iso)

I've seen BDRV is paired with desktop_*.sfs

Do you think its a good idea to add it as BDRV or should I create CDRV?

Maybe easiest would be a custom sfs loaded with sfs_load and not in iso at all?
Will customs sfs "overwrite" files from alpha_12.sfs and extra_12.sfs?



I have the same need exactly. Made a little test SFS and loaded it first as a custom, and then renamed it desktop_marv.sfs and put it in the alpha boot directory where it loaded automatically on boot. In both cases, it adds new files nicely, is overlayered by the true save file (good), but does not overwrite the alpha_12.sfs or extras_12.sfs files (not good). Since I also add the same set of things to each alphaOS and would like to keep the save file for ongoing work and disasters a clever solution would be great.

Edit: Just for play, I merged extra_12.sfs into alpha_12.sfs. Then I changed extra_12.sfs to adrive_12.sfs in DISTRO_SPECS both in initrd.gz and in /etc. My little test sfs, now named adrive_12.sfs, in the alphaOS boot directory now loads on boot and is layered correctly over alpha_12 and under alphasave. This is all in the nature of an experiment and I hope is taken as such.

Edit: savefile with all my customizations and printing etc. extracted to dir, cleaned and resquashed as adrive_12.sfs (22Mb). Put in boot dir, reboot with no save file and I'm all here. Made new save file (totally empty for now) and it's running just fine. Experiment complete. Good thing is I didn't have to add anything to the original sfs's and my adrive is an easy pkg to port or maintain. Bad thing is I had to merge alpha and extra. I could have kept the extra_12 name for my 'adrive' but that might have confused my peabrain sometime in the future.

Scooby
Site Admin
Posts: 826
Joined: 09 Sep 2013, 16:52

Re: BDRV or maybe CDRV

Postby Scooby » 17 Oct 2013, 10:11

in init script contained in initrd.gz at line 1226 under paragraph SETUP LAYERED FILESYSTEM


Code: Select all

 RECORDLIST="$SAVEFILENAMEONLY $AFACTOR $SFSFILENAMEONLY $EXTRASFSLIST $BFACTOR"


where ...

$SAVEFILENAMEONLY # savefile
$AFACTOR # extra_XX.sfs
$SFSFILENAMEONLY # alpha_XX.sfs
$EXTRASFSLIST # Custom sfs i.e. loaded with sfs_load
$BFACTOR" # desktop_*.sfs

if you want to use desktop_*.sfs you could reorder as

Code: Select all

 RECORDLIST="$SAVEFILENAMEONLY $BFACTOR $AFACTOR  $SFSFILENAMEONLY $EXTRASFSLIST"



or you could introduce CFACTOR (not the best name, right?)

Code: Select all

 RECORDLIST="$SAVEFILENAMEONLY $CFACTOR $AFACTOR $SFSFILENAMEONLY $EXTRASFSLIST $BFACTOR"


But then you would have to add more code in init which is not to hard, basically copy&paste

Me myself would like to have that sfs as custom sfs with sfs_load maybe you could have a
sfs with special predefined name (SPECIALNAMEDSFS="special_XX.sfs"?? ) searched out in init script and handled apart from the other custom sfs
in EXTRASFSLIST and that gets loaded apart and on top of the others something like

RECORDLIST="$SAVEFILENAMEONLY $SPECIALNAMEDSFS $AFACTOR $SFSFILENAMEONLY $EXTRASFSLIST $BFACTOR"[/code]

Would maybe depend on you having a savefile.

maybe I'm reading code wrong? there is also this

Code: Select all

mount -t aufs -o udba=reval,diropq=w,dirs=${UMNTRW}${UMNTRO0}${ALAYER}${BLAYER}${UMNTRO1}${UMNTRO} unionfs /pup_new

which maybe affects the order of loaded sfs's. I'll have to try

Marv wrote:... but that might have confused my peabrain sometime in the future.

peabrain huh? And here I always thought you was a nut :D

Scooby
Site Admin
Posts: 826
Joined: 09 Sep 2013, 16:52

Re: BDRV or maybe CDRV

Postby Scooby » 17 Oct 2013, 11:33

I also found this code in init script line: 1393

Code: Select all

if [ -d $PUPSFSDEVMNTPT/precfg ];then
 echo -en $BBlue":: "$Color_Off"Overlaying preconfig files..." > /dev/console
 SRC="$PUPSFSDEVMNTPT"/precfg
 DEST="/pup_new"
 cd $SRC
 for i in `find . -not -type d -print`; do
  BASEFILE="$i"
  SRCFILE="$SRC/$BASEFILE"
  DESTFILE="$DEST/$BASEFILE"
  DESTDIR=`dirname $DESTFILE`
  MASK="777"
  if test -f "$DESTFILE"; then
   MASK=`stat -c %a $DESTFILE`
  fi
  mkdir -p $DESTDIR
  cp -f $SRCFILE $DESTFILE
  chmod $MASK $DESTFILE
 done
 check_status 0
fi


which would suggest you could put files in /precfg in same dir as alpha_XX.sfs? and they would be loaded
as a non-writable savefile. Saw a comment this must be done on a Linux filesystem? files should be extracted and
not squashed then I think?

maybe one could finicky up a solution that uses a squash file here instead?

seems to overwrite stuff from savefile though maybe not so good?

Marv
Proficient
Posts: 81
Joined: 16 May 2013, 16:42

Re: BDRV or maybe CDRV

Postby Marv » 17 Oct 2013, 15:37

Great thoughts Scooby. One of my goals is to stay as close to the alphaOS structure as I can while getting an 'adrive' back. Offhand, the thing that would seem to me to do that most cleanly would be to do the reorder you suggest

Code: Select all

 RECORDLIST="$SAVEFILENAMEONLY $BFACTOR $AFACTOR  $SFSFILENAMEONLY $EXTRASFSLIST"


I can't think how that would change current OS structure at all and even makes a kind of semantic sense since one of the things we all customize is panels and look and feel (desktop) and that really should overlayer the stock desktop. Thoughts on going that route? I worked on initrd way back in the days of getting pupmode 13 to work with flash drives and my thought is the less code change the better ;)

Edit: looked at and tried the above out. Oops, more code change is involved, lines 1031 to 1139 or so at least. Don't want to make that many changes. Currently running with an adrive and non-merged alpha and extras using this modified DISTRO_SPECS as the only change. Less change than my 'merged approach' and runs ok. Again, thoughts?

Code: Select all

DISTRO_NAME='alphaOS'
DISTRO_VERSION='12'
DISTRO_BINARY_COMPAT='arch'
DISTRO_FILE_PREFIX='alpha'
DISTRO_COMPAT_VERSION='none'
DISTRO_KERNEL_PET='3.11.4'
DISTRO_XORG_AUTO='yes'
DISTRO_TARGETARCH='i686'
DISTRO_IDSTRING='000ALPHA0002013XXXXXXXXXXXXX1234'
DISTRO_PUPPYSFS='alpha_12.sfs'
DISTRO_ADRVSFS='adrive.sfs'
DISTRO_BDRVSFS='extra_12.sfs'
DISTRO_PUPPYDATE='Okt 2013'

Scooby
Site Admin
Posts: 826
Joined: 09 Sep 2013, 16:52

Re: BDRV or maybe CDRV

Postby Scooby » 17 Oct 2013, 17:40

Marv wrote:One of my goals is to stay as close to the alphaOS structure as I can while getting an 'adrive' back.

Thats my goal too provided it meets my needs, If it doesnt I'm prepared to go out into the djungle.

Marv wrote:Currently running with an adrive and non-merged alpha and extras using this modified DISTRO_SPECS as the only change. Less change than my 'merged approach' and runs ok. Again, thoughts?


I love it. Obviously the best approach.

Did you change DISTRO_SPECS at both places?

simargl
Site Admin
Posts: 466
Joined: 16 May 2013, 10:54
Contact:

Re: BDRV or maybe CDRV

Postby simargl » 17 Oct 2013, 18:03

Marv,
I've changed Distro specs as you suggested, it makes more sense that way: module made by user, Adrive, should have higher priority and be loaded on top of Bdrive and main sfs so to allow overwriting files that come with the iso, for example to set custom commands in /root/.start.

Marv
Proficient
Posts: 81
Joined: 16 May 2013, 16:42

Re: BDRV or maybe CDRV

Postby Marv » 17 Oct 2013, 20:25

Scooby wrote:
Did you change DISTRO_SPECS at both places?

Yep, both places.

Sim,
Thanks :D :D :D If you think it would help people keep things straight, It could be Adrive_alphaOS.

simargl
Site Admin
Posts: 466
Joined: 16 May 2013, 10:54
Contact:

Re: BDRV or maybe CDRV

Postby simargl » 17 Oct 2013, 21:42

That name may be too long, but what about abundle.sfs? Or some other suggestion?

Bundle -http://www.thefreedictionary.com/bundle- seems appropriate name for what we call module.

Marv
Proficient
Posts: 81
Joined: 16 May 2013, 16:42

Re: BDRV or maybe CDRV

Postby Marv » 17 Oct 2013, 22:30

simargl wrote:That name may be too long, but what about abundle.sfs? Or some other suggestion?

Bundle -http://www.thefreedictionary.com/bundle- seems appropriate name for what we call module.


I used adrive_12 when I first was working on it in alphaOS 12. That worked, would work for me and the name adrive is somewhat familiar to people. I didn't want to tie it to a version when I suggested _alphaos but the more I think the more sense using a version specific name makes.


Return to “Scripting and Programming”

Who is online

Users browsing this forum: No registered users and 18 guests

cron