KLV-BspwmCE-1.5 Stable

[wiak]

I create and maintain the main actual build root filesystem scriipt, which is build_firstrib_rootfs.sh (and that does the tricky chroot stuff for the user), and
the FR skeleton initrd, which provides all the overlayfs frugal install functionality, and
in the build_firstrib_rootfs I provide a 'hook' in the form that during its internal chroot it looks for and processes the:

f_plug, which is something the user/builder/distro-creator needs to provide.

Thanks, let's see if I have it straight:

At the point that the f_plug is envoked in the build script, the build script has already done the chroot, so references that I make to /root are pointing to the buildrootfs/root, and not the host distro where the build is taking place.

Assuming I have it correct, that raises the question of copying files to the chroot/rootfs, if those files I want to copy into the build chroot/rootfs using a command in the f_plug like

Code: Select all

cp /mnt/sda1/GEO'sFILES/somefile /root/.config/

will /mnt/sda1 be a valid location in the chroot?

You have it correct except /mnt/sda1 won't be 'seen' by the chroot commands since can't access files on host during build when in chroot except for those in firstrib_rootfs.

However, build_firstrib_rootfs.sh script includes workaround: ANY file that you give a filename starting with the two chars f_ gets copied into location firstrib/tmp and since firstrib dir is all accessible by the chroot, such files are all seen as being in /tmp (note, from chroot point of view it becomes /tmp, not firstrib_rootfs/tmp).

[wiak]

I create and maintain the main actual build root filesystem scriipt, which is build_firstrib_rootfs.sh (and that does the tricky chroot stuff for the user), and
the FR skeleton initrd, which provides all the overlayfs frugal install functionality, and
in the build_firstrib_rootfs I provide a 'hook' in the form that during its internal chroot it looks for and processes the:

f_plug, which is something the user/builder/distro-creator needs to provide.

Thanks, let's see if I have it straight:

At the point that the f_plug is envoked in the build script, the build script has already done the chroot, so references that I make to /root are pointing to the buildrootfs/root, and not the host distro where the build is taking place.

Assuming I have it correct, that raises the question of copying files to the chroot/rootfs, if those files I want to copy into the build chroot/rootfs using a command in the f_plug like

Code: Select all

cp /mnt/sda1/GEO'sFILES/somefile /root/.config/

will /mnt/sda1 be a valid location in the chroot?

No. During the build_firstrib_rootfs part, the chroot is active so /mnt/sda1 is not accessible. EDIT: Sorry, that is incorrect; mount script mounts /dev so yes, /dev/sda1 will be available - Sofiya is correct about that; and there was me about to suggest she shoudn't drink too much vodka. Instead, prior to running the build you must rename anything you want accessible as f_somename (EDIT: well, this works too...). Any file named like that in main build directory can then be used/referred-to in main f_plug since will be available during the chroot as stored in dir /tmp of the chroot filesystem.
EDIT2: Regarding that /dev/sda1 matter though. /mnt/sda1 is outside the chroot so that will not be available, but the device /dev/sda1 can be, but you'd need to mount it once in the chroot (this is too complicated overall); e.g. mkdir -p tempmount; mount /dev/sda1 tempmount will work inside the chroot so Sofiya was half-correct only I'd say since /mnt/sda1 certainly isn't directly accessible - too much vodka afterall maybe

[wiak]

Note that whilst the main f_plug cannot access host filesystem directly since on chroot at that stage, it CAN access the internet so can wget files during that chroot from internet. That's why Sofiya is also correct that using the likes of gitlab or github server soon becomes best way to fetch extras in your main f_plug.

[wiak]

so, if you run the scripts, but then decide to further modify the rootfs, (but say for instance, you are not able to yet boot or wish to get online) you can use chroot manually from the host at will.

And whilst you can do a chroot manually if you know what you are doing and know how to clean up any mounts afterwards, there is a FirstRib utility script that will do the necessary chroot work for you (just run it also from the build directory when you want to add things to existing uncompressed root filesystem there). That single utility script, which is named mount_chroot_umount.sh, does both the entry into the chroot (of for example underlying firstrib_rootfs) and also the clean up of the mounts that were used during the chroot once you have finished and exited from the chroot. As soon as you have finished doing work inside the firstrib_rootfs (in chroot) you simply enter 'exit' command until you find yourself out of the chroot; on exit that mount_chroot_umount.sh command will auto-clean-up the mounts. Note that this is an optional utility script only, for use with an already built/existing uncompressed root filesystem such as firstrib_rootfs or whatever it is called; it is not used at all during a typical build_firstrib_rootfs.sh actual auto-build.

To get that mount_chroot_umount.sh utility script from FirstRib gitlab:

Code: Select all

wget -c https://gitlab.com/firstrib/firstrib/-/raw/master/latest/build_system/mount_chroot_umount.sh && chmod +x mount_chroot_umount.sh

and can get help instructions per usual with command:

Code: Select all

./mount_chroot_umount.sh --help

For example, if your unsquashed root filesystem is called 07KLV-blah-blah/ you can chroot into it and thus add to it using that utility script with command:

Code: Select all

./mount_chroot_umount.sh 07KLV-blah-blah 

As often as not though, the root filesystem part is sometimes just called "firstrib_rootfs".

Then you can run xbps-install commands, or whatever, inside that chroot and thus remaster your root filesystem by doing so.

By the way, there is also a version of same utility, but split into two parts. These are mount_chroot.sh and umount_chroot.sh
Sometimes umount.chroot.sh is handy to have in case something went wrong with cleaning up the chroot mounts so can simply run it again.

[Sofiya]

I usually use Smplayer, after installing Celluloid I was significantly surprised at how well they improved the design in version 0.26

[Sofiya]

Through Smplayer I watch Youtube through links

[wiak]

EDIT2: Regarding that /dev/sda1 matter though. /mnt/sda1 is outside the chroot so that will not be available, but the device /dev/sda1 can be, but you'd need to mount it once in the chroot (this is too complicated overall)

Having written this, I feel I should advise you again the idea of mounting any part of host filesystem to make it available inside chroot. I have good reasons to say that. In earlier version of umount_chroot.sh, that was used for a long time, I did in fact mount --bind a host directory for use by the chroot. Then one day, because of that, I managed to delete my whole partition. I can't remember how - but I suspect I had not cleaned up the mounts after leaving the chroot and then in deleting what had been the root-filesystem I had chrooted into, because I wanted to start again, I took out the whole host partition... I thus removed that mount --bind facility from mount_chroot facility and would never use that technique of sharing with the host again...

It so happens that that was the worst such 'accident' I've ever had - I lost tons of un-backed up dev work on the occasion so the memory still haunts me.

[williwaw]

And whilst you can do a chroot manually if you know what you are doing and know how to clean up any mounts afterwards, there is a FirstRib utility script that will do the necessary chroot work for you.........

running the mount_chroot script and the umount_chroot script was what I meant when I typed "manually''
sorry for the confusion.

I have yet to use Barrys chroot script, which is designed to be run for each command. Maybe a prudent method for not trying to too much inside a chroot envvrionment.

https://forum.puppylinux.com/viewtopic. ... 963#p98963

[rockedge]

I have experimented with running a chroot'ed system started with @wiak's mount_chroot.sh and umount_chroot.sh in Xnest instances able to start a windows manager. To be safe the trick is NEVER mount any partitions outside of the chroot and important, after exiting the chroot terminal in the mounted rootfs to run the umount_chroot.sh script to disconnect and clean up leaving the chroot environment.

One can copy files into the chroot'ed rootfs, edit and manage files directly in the system. Then being able to test the changes immediately. I have pushed some chroot experiments but have not destroyed any partitions and drives using a basic check list to go in to and out of a chroot environment cleanly using the scripts.

[geo_c]

After reading these chroot discussions, I won't be doing chroot to build systems apart from whatever the minimal build script does on it's own to create the base filesystem.

It's seems to me the simplest way to build customized local root file systems is PFI (edited for typo) method. I may modify the plug file to install apps from the repository, or make links within the rootfs, but it's looks like it's a lot more complicated and dangerous to try and mount the host file system while in a chroot simply to copy in changes or make links.

The flexibility of KL allows it to be done without that kind of risk.

[rockedge]

@geo_c The PFI method is exactly what I would recommend. The chroot is method is low level and uses the host machine resources to run a rootfs like the kernel, which can make the results of some commands and procedures unstable later on. Where the PFI is actually running the complete distro in a decompressed state., making this method less prone to making mistakes that can have a significant negative impact. The PFI will use the kernel that is supplied with that distro.

[williwaw]

simply to copy in changes or make links

seems sensible.

the only advantage to chroot I have found is to run a non native package manager. Perhaps I have missed other functionalities? PSI? PFI?

[wiak]

For the most part both PFI and using mount_chroot_umount.sh are perfectly fine. Chroot is very handy when you are in different distro and no issues at all to worry about as long as you don't take risky shortcuts via mounting host filesystems into the choot.

If you need access to some files or directories that are normally stored in host system filesystem it is simply a matter of copying these to somewhere in the firstrib_rootfs (or whatever it is called) prior to runniing the ./mount_chroot_umount.sh firstrib_rootfs command - that way they become part of the chrooted to directory. Actually, that's exactly what is done with f_XXX files when automating new build using build_firstrib_rootfs.sh; we don't need tons of places to bring in files or directories so only one mechanism was required so that's why I chose to make it that ANY file whose name starts with f_ characters gets automatically copied by the build_firstrib_rootfs.sh script into the newly being made firstrib_rootfs/tmp directory, just prior to the chroot occurring.

if it is a directory you want to get in as part of new empty run of build_firstrib_rootfs.sh, well that's easy too - just create an archive (for example a tar file or compressed tar file) so any directory hierarchy you may want included is in that archive with filename again starting with f_ character name. Then you can have main f_00xxxxx plugfile decompress the tar wherever you want it and that is all done inside a chroot.

But if firstrib_rootfs already made, then that's even easier since you can manually just copy anything you want into that already build filesystem prior to running mount_chroot_umount.sh command. Yes, there is a place for PFI - that effectively remasters the root filesystem in live run (which means all desktop graphics and runit and/or systemd and so on are involved, but just for adding a new app or changing a config or two then mount_chroot_umount.sh or similar chroot scripts are really handy and not unsafe if you don't do something obviously dangerous anyway.

But yes, the other really handy way to include wanted files or archives of files and/or directories is simply to download them during the build from some internet server or other using the likes of wget or curl since such internet access works fine during the chroot part of the build too.

[wiak]

To be safe the trick is NEVER mount any partitions outside of the chroot and important, after exiting the chroot terminal in the mounted rootfs to run the umount_chroot.sh script to disconnect and clean up leaving the chroot environment.

Which is a reason I decided to write the combined version mount_chroot_umount.sh, which seems to work fine and thus safer. I habitually do tend to check via a mount command after doing such work to make sure all mounts involved have indeed been auto-umounted. If not, I'd try ./umount_chroot.sh script to clean up again, but I don't think I've ever needed to do what after a mount_chroot_umount.sh so that script is what I normally use nowadays (unless choosing to do that pseudo full install trick when wanting to remaster the main rootfs during live use).

[geo_c]

But if firstrib_rootfs already made, then that's even easier since you can manually just copy anything you want into that already build filesystem

I'm about to run the build script, and I added some packages to the plugfile, and I think the easy method for copying custom config files from outside the build directory would be to simply write a separate script with cp commands to run after the rootfs is built and uncompressed.

Links it seems would be another matter, and those would probably be done better by switching to PFI while the rootfs is still uncompressed, creating them, and then resquashing. Perhaps it would be even better NOT to use a PFI, and simply add a layer with my local links, As this would give me the ability to create a rootfs that might be shared at a later date by simply uploading the above mentioned copied files and adding wget lines for those.

[geo_c]

Just ran the build from the script!

That was easy, and has all my favorite additional apps installed by adding them to the plug file.

Also, since I didn't compress the rootfs, that was the fasted boot time of any OS I've ever experienced. Makes me wonder if there's really any reason to compress the rootfs. If I'm worried about accidentally altering it, I could always set the permissions to read-only.

Now one thing I'm wondering about. This particular install is using menu.1st, and although I removed w_changes=RAM2 from the boot stanza, there is still a "save2flash" icon on the desktop. Not a problem, just checking if that's to be expected.

EDIT: This build looks so good out of the box, I might not even install other gtk-themes. Nice work @Sofiya!

[Sofiya]

Just ran the build from the script!

That was easy, and has all my favorite additional apps installed by adding them to the plug file.

Also, since I didn't compress the rootfs, that was the fasted boot time of any OS I've ever experienced. Makes me wonder if there's really any reason to compress the rootfs. If I'm worried about accidentally altering it, I could always set the permissions to read-only.

Now one thing I'm wondering about. This particular install is using menu.1st, and although I removed w_changes=RAM2 from the boot stanza, there is still a "save2flash" icon on the desktop. Not a problem, just checking if that's to be expected.

EDIT: This build looks so good out of the box, I might not even install other gtk-themes. Nice work @Sofiya!

The files are compressed in order to pack it into an ISO, the save2flash file is a desktop file, you can delete it in the Desktop folder .it was created by me because I use on-demand save.

EDIT:
@geo_c Thank you for liking my work, I am very pleased to read this

[geo_c]

The files are compressed in order to pack it into an ISO

Yeah, everything is running so fast uncompressed, I'll simply have to uncompress the filesystems of all my other OS's. The sfs layers can be archived as backups.

It didn't help that I compressed my other OS layers .gz, as I believe it's quite a slower than other compression methods. Nevertheless, it will always be fastest running uncompressed.

Instantaneous boot up of applications, not to mention super fast system boot, is hard to beat.

[williwaw]

If I'm worried about accidentally altering it, I could always set the permissions to read-only.

I wondered the same about unwanted or unexpected alterations.
afaik, when rootfs. or rather 07rootfs is booted with FR, your changes all supposed to be relegated to upper_changes

but are there other circumstances which might allow unintentional alteration to 07rootfs?

[geo_c]

If I'm worried about accidentally altering it, I could always set the permissions to read-only.

I wondered the same about unwanted or unexpected alterations.
afaik, when rootfs. or rather 07rootfs is booted with FR, your changes all supposed to be relegated to upper_changes

but are there other circumstances which might allow unintentional alteration to 07rootfs?

Not from within the filesystem per se, only when fiddling around within the install directory from /mnt/INSTALL-DIRECTORY/07-rootfs, or copying to a new install, experimenting and copying files in from that directory, things of that nature. Copying squashed filesystems is a lot safer in terms of permissions also. I always use the terminal cp -ar when copying system directorys, 07rootfs, upper_changes, and other layers. Moving uncompressed directories around with file managers can cause things not work. Not the case with a squashed file system.

[rockedge]

but are there other circumstances which might allow unintentional alteration to 07rootfs?

No. None that are known. Unless in a pseudo full install mode with the rootfs completely copied into upper_changes and a 07Dummy is supplied can the rootfs be altered by being directly written too.

In any other modus of operation the 07rootfs compressed or uncompressed can not be altered by the running system.

[williwaw]

In any other modus of operation the 07rootfs compressed or uncompressed can not be altered by the running system.

understood.

Unless in a pseudo full install mode with the rootfs completely copied into upper_changes and a 07Dummy is supplied

can you give an example how such a write might occur?

[rockedge]

can you give an example how such a write might occur?

The screenshot shows what a PFI (Pseudo Full Install) file system looks like. Note the 07Dummy_rootfs is an empty directory. The entire actual 07rootfs is renamed to /upper_changes which means that the rootfs is entirely in the /upper_changes layer which is the top most layer of the system and read-write. All actions are directly written to the upper_changes, which is the rootfs. It is always possible to later rename the upper_changes back to 07KLV_rootfs or similar, or squash the upper_changes into a 07KLV_rootfs.sfs and that would return the rootfs to a read-only state.

Screenshot(15).jpg (25.09 KiB) Viewed 1415 times

The system behaves as if it is a full install yet is a frugal installation.

[wiak]

Unless in a pseudo full install mode with the rootfs completely copied into upper_changes and a 07Dummy is supplied

can you give an example how such a write might occur?

The pseudo full install mode is entirely different. In that configuration you are meaning for the rootfs (named as upper_changes) to be written into since upper_changes IS the topmost read/write layer of the overlay.

When, on the other hand you leave the rootfs as something like 07rootfs/, it is an uncompressed (i.e. normal) directory mounted read-only at layer 7 of the overlay. It is never written into in that state, by the system itself, in terms of it being part of the overlay (and it is considered read-only by overlayfs operations).

However, it is a normal uncompressed directory, and if the root user of the system wants they could purposively go to where that directory is in its partition on the system and write into it whilst the system is running. So you can indeed put stuff in it if you want whilst the system is running but you are not advised to do so since from the overlaid filesystem perspective the result of doing so is undefined according to overlayfs kernel documentation. The mechanism is basically as safe as you are... if you write a script to delete all or part of that normal directory via direct path to its partition and location, of course that would not be a good idea - but then again you could write a script that simply deleted any and every sfs file on your system too; we just don't do that!

Summary is that NO, unless you purposively go to the directory where upper_changes is and write into it manually, that will not happen (save to flash writes to it of course - that's its purpose being at upper_changes - persistence folder!). In pseudo full install mode the main root filesystem is the save folder and save folders, on all frugal-install type distros, are always writable to or they wouldn't work!

In terms of 'security', using uncompressed directories anywhere is same security-wise like normal frugal install, but yes file system changes can be directly made to any uncompressed directory that will certainly come into play on reboot. If you think sfs files are safer because needs some work to write to them, just make all layers, apart from upper_changes, sfs files; personally I don't think that is really safer at all (not from hacker point of view) - easy to change contents of an sfs file. Using a layer in uncompressed dir form is perfectly fine. Think about it, upper_changes is ALWAYS writable - so hacker could just always write there! But most all normal booting computers use a writable filesystem or would be of limited use...

Using uncompressed layers and/or sfs layers is fine. So is pseudo full install mode.

[wiak]

Now one thing I'm wondering about. This particular install is using menu.1st, and although I removed w_changes=RAM2 from the boot stanza, there is still a "save2flash" icon on the desktop. Not a problem, just checking if that's to be expected.

Well all icons only appear if someone has made them appear. For example, if you put a desktop file in /usr/share/applications that item will normally appear in the start menu.

So if you don't want an icon to appear when not in RAM2 mode you'll have the perhaps complicated job of writing some code that detects you are in RAM2 mode and disabling/removing the icon. Can be done of course, but would have to be in some script prior to the desktop coming up - probably not worth the effort - the alternative of some yad dialogue saying can't save to persistence cos not in RAM2 mode is easier.

[geo_c]

Now one thing I'm wondering about. This particular install is using menu.1st, and although I removed w_changes=RAM2 from the boot stanza, there is still a "save2flash" icon on the desktop. Not a problem, just checking if that's to be expected.

Well all icons only appear if someone has made them appear. For example, if you put a desktop file in /usr/share/applications that item will normally appear in the start menu.

So if you don't want an icon to appear when not in RAM2 mode you'll have the perhaps complicated job of writing some code that detects you are in RAM2 mode and disabling/removing the icon. Can be done of course, but would have to be in some script prior to the desktop coming up - probably not worth the effort - the alternative of some yad dialogue saying can't save to persistence cos not in RAM2 mode is easier.

Not a big deal to me. I tried running RAM2 the other day. Just not my cup of tea really. I was checking because puppies do have some code that pops the save icon on the desktop if you're running a ram mode.

I always run realtime save even when using usb thumb drives (I know the drive will conk out sooner, but it's worth not wondering what I saved or when.) The thing is when running audio software and resource intensive stuff like large downloads, pups would sometimes max out the ram, and I would be saving in the middle of a routine to try and keep it from crashing. So I just said, why bother?

[Sofiya]

Now one thing I'm wondering about. This particular install is using menu.1st, and although I removed w_changes=RAM2 from the boot stanza, there is still a "save2flash" icon on the desktop. Not a problem, just checking if that's to be expected.

Well all icons only appear if someone has made them appear. For example, if you put a desktop file in /usr/share/applications that item will normally appear in the start menu.

So if you don't want an icon to appear when not in RAM2 mode you'll have the perhaps complicated job of writing some code that detects you are in RAM2 mode and disabling/removing the icon. Can be done of course, but would have to be in some script prior to the desktop coming up - probably not worth the effort - the alternative of some yad dialogue saying can't save to persistence cos not in RAM2 mode is easier.

Not a big deal to me. I tried running RAM2 the other day. Just not my cup of tea really. I was checking because puppies do have some code that pops the save icon on the desktop if you're running a ram mode.

I always run realtime save even when using usb thumb drives (I know the drive will conk out sooner, but it's worth not wondering what I saved or when.) The thing is when running audio software and resource intensive stuff like large downloads, pups would sometimes max out the ram, and I would be saving in the middle of a routine to try and keep it from crashing. So I just said, why bother?

I also liked saving in real time, but during tests and settings it just doesn’t work well
because I can’t cancel saving what I don’t need

[geo_c]

I also liked saving in real time, but during tests and settings it just doesn’t work well
because I can’t cancel saving what I don’t need

I think the next thing I will do to aid in experimenting is use @wiak's new multi-instance script.

[wiak]

I think the next thing I will do to aid in experimenting is use @wiak's new multi-instance script.

Yes, I highly recommend that; all my own installs are now multi-instance and I boot always starting with instance1 provided grub_config.txt stanza. I leave instance0 untouched generally since that is the underlying boot files the other instances symlink. But you can boot instance0 if you want, which is useful for upgrading its upper_changes which is optionally available as layer 60 to all other instances.

It is a 30 second job to make a multi-instance install out of an existing KL frugal install:

1. Boot into a host not being included in the multi-install.

2. Make an empty directory to contain the multiple instances on same partition as the frugal install you are converting to multi. For example:

Code: Select all

mkdir /KL_frugals

3. Copy the script wd_convert32multi into there and make sure it is executable.

4. Cut the original frugal install (e.g. /KLV-BspwmCE) and paste into the /KL_frugals directory (no actual copying takes place since on same partition). For example use your favourite file manager or via commandline:

Code: Select all

mv /KLV-BspwmCE /KL_frugals

5. Change dirname of /KL_frugals/KLV-BpswmCE to /KL_frugals/KLV-BpswmCE.MKL # i.e. add special extension .MKL, which indicates it is to be converted. That could have been done in step 4, but by commanline now could from /KL_frugals directory use command:

Code: Select all

mv KLV-BspwmCE KLV-BspwmCE.MKL

or can do same in filemanager GUI.

6. Make the multi-instances from terminal at that /KL_frugals directory. For example, for 50 instances:

Code: Select all

./mk_convert2multi 50

Note that each extra instance only takes a few thousand bytes extra space (i.e. next to nothing, so you can have as many as you want).

7. Then look inside, for example, the resulting KLV-BspwmCE/instance1 folder and open its grub_config.txt file to get exact working grub stanza to be used for booting that instance1 and add to your main grub.cfg. Can so same for any other instances you want available in boot menu at this time. Of course you COULD boot instance0 if you want to via same update grub procedure and indeed the upper_changes of instance0 always gets used as a read-only layer file by all other instances (unless you don't want it in any instance and choose to delete the symlink 60instance0uc, which is the symlink to instance0 upper_changes folder.

Nothing else to it - you now have 50 independently able to be booted instances of that distro and each with their own upper_changes independent read/write save folder.

[geo_c]

Well, now I'm rolling. I put together a bash script to fully configure the customized CE-1.5, so now I have a plugfile that installs all the apps I need, and a script to run on first boot that fully configures my system.

At some point I'll figure out how to accomplish all of this in a plug file, so I don't have to use the extra step, though the extra step is probably the best way to access local settings.

Here's the custom local script:

Code: Select all

#!/bin/bash

## GEO CUSTOM LOCAL SETUP - BSPWM-RC5

## create /mnt/home
ln -s /mnt/sda1 /mnt/home

## autostart firewall
ln -s /etc/sv/ufw /var/service

## add desktop files
cp -av /mnt/home/sync-script/scriptLIB/applications/desktop-files-KLVb/*.* /usr/share/applications

## create directories
mkdir /root/my-applications/bin
mkdir /root/.cache/ranger
mkdir /root/.config/ranger
mkdir /root/.config/xfe
mkdir /root/.config/calcurse

## link config files
ln -s /mnt/home/portableAPP/LibreWolf-img/.librewolf /root/.librewolf
ln -s /mnt/home/tcons/xfe32-16 /root/.config/xfe/Xfe-icons
ln -s /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/.newsboat /root/.newsboat
ln -s /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/.calcurse/apts /root/.config/calcurse/apts
ln -s /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/Documents/MusesScore4 /root/Documents/MuseScore4

## copy config files
cp -arv /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/.calcurse/conf /root/.config/calcurse/conf
cp -arv /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/root-/lynx_bookmarks.html /root/lynx_bookmarks.html 		
cp -arv /mnt/home/sync-script/scriptLIB/applications/my-applications-KLVb/classy-Bspwm-rc5 /root/Startup
cp -arv /mnt/home/KLV-bspwm-RT/fs-store/colors/xferc /root/.config/xfe
 # -cp -arv /mnt/home/KLV-airedale-RT/fs-store/colors/.Xresources /root

## copy utility scripts
cp -arv /mnt/home/sync-script/scriptLIB/applications/my-applications-KLVb/* /root/my-applications/bin
		
## install lv2 plugins
 # mkdir lv2 (already present in KLV-bspwm-rc5)		
cp -arv /mnt/home/dbox.sync.mir/app.sys/linxsys/SysT-DPi7/usr-lib/lv2/*.* /usr/lib/lv2
		
## config ranger file manager
cp -arv /usr/share/doc/ranger/config/*.* /root/.config/ranger
cp /mnt/home/KLV-bspwm-rc5/fs-store/ranger/*.* /root/.config/ranger
cat /mnt/sda1/KLV-bspwm-rc5/fs-store/ranger-bash_profile > /root/.bash_profile