Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 15 Nov 2019, 17:34
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
FirstRib default WeeDog Linux build system
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 42 of 48 [709 Posts]   Goto page: Previous 1, 2, 3, ..., 40, 41, 42, 43, 44, 45, 46, 47, 48 Next
Author Message
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Thu 26 Sep 2019, 18:14    Post subject:  

I'm running with changes=RAM so upper_changes folder is in ram. 'save' just tar's up that folder excluding /run and /mnt folders storing that tar file on hdd.

rdsh3 has upper_changes created in ram, but empty at that point. With rdsh3 kernel boot parameter the rdsh3.plug I'm using with that currently looks like ...
Code:
CD=`pwd`
cd /mnt/layers/RAM
clear
read -s -n1 -t 10 -p "Press <ENTER> or <SPACE> within 10 seconds to NOT AUTO LOAD THE SAVE FILE "
if [ $? -eq 0 ]; then # ENTER (or space) pressed
   clear
   echo "Press <ENTER> or <SPACE> to continue booting without loading a save file"
   echo -n "Or press any other key to drop to initramfs shell "
   read -s -n1 SELECT
   if [ "$SELECT" != "" ]; then
       clear
       echo "Populate (OR NOT) /mnt/layers/RAM/upper_changes as desired/required"
       echo "i.e. cd /mnt/layers/RAM;tar xvf /mnt/sda1/snapshot.tgz"
       echo
       echo "Run 'exit' when done to resume bootup"
           setsid cttyhack /bin/sh
   fi
   clear
else
    tar xf /mnt/sda1/snapshot.tgz
fi
cd $CD
so on bootup it pauses for 10 seconds (at the rdsh3 point) and if no keyboard action occurs it just carries on booting and automatically loads the save file (tar). Or if Enter is pressed it prompts to either press Enter again to resume bootup (with upper_changes remaining empty i.e. no save file loaded), or any other key to drop into initramfs shell (for instance to load a different save file into upper_changes or whatever).

My current save.sh script that runs within the main system currently looks like
Code:
cd /mnt/layers/RAM
if [ -f /mnt/sda1/snapshot.tgz ]; then
    if [ -f /mnt/sda1/snapshot.tgz.bak ]; then
              mv /mnt/sda1/snapshot.tgz.bak /mnt/sda1/snapshot.tgz.old
    fi
    mv /mnt/sda1/snapshot.tgz /mnt/sda1/snapshot.tgz.bak
fi
tar --exclude=\'run\' --exclude=\'mnt\' -zcvf /mnt/sda1/snapshot.tgz upper_changes

i.e. creates the save tar file (snapshot.tgz) of upper_changes (that's ram based). Keeping three copies (the one just created, old one renamed to .bak, and former .bak renamed to .old).

Manually you could rename/copy snapshot.tgz as you liked, i.e. have multiple choice of 'saves' to load as desired.

Using a compressed tar file to store upper_changes as you say makes it more portable. Just copying upper_changes folder/content to hdd if it was for instance a windows partition being used to store that and file/folder permissions etc. could be converted/lost.

Could have used mksquashfs/unsquashfs in a similar fashion, but tar is in in the default initramfs whereas mksquashfs isn't.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh

Last edited by rufwoof on Fri 27 Sep 2019, 12:26; edited 1 time in total
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Thu 26 Sep 2019, 18:40    Post subject:  

rufwoof wrote:

Manually you could rename/copy snapshot.tgz as you liked, i.e. have multiple choice of 'saves' to load as desired.

Using a compressed tar file to store upper_changes as you say makes it more portable. Just copying upper_changes folder/content to hdd if it was for instance a windows partition being used to store that and file/folder permissions etc. could be converted/lost..


Ah yes, that works nicely. Sorry I was just up and rushing about taking my partner to her work and just quickly glancing at your previous post. Now I'm away for a coffee...

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Thu 26 Sep 2019, 18:45    Post subject:  

Other changes I've made is to the hot corner detection script, that monitors the mouse location and launches skippy-xd (window selector) if the mouse moves into the bottom left corner, or xlunch (program launcher) if the mouse moves into the top left corner. Along with xload an volumeicon that were installed via the package manager (xbps-install), I've scripted a battery level indicator (100% charged at present so all blue, but as the available power level declines it turns progressively red); Also a caps lock indicator (lower case a and upper case A); Also a cpu temperature indicator that along with showing the temperature as a digital readout, changes colour (orange when 'relatively warm', red when 'hot'). I snitched code from others to do the automatic .svg image file creation for those.

Having that all in the single 'hot corner' script means I can refine how often each is tested/updated. hotcorners is tested at every loop, as is caps lock, whereas the temperature and battery levels are at around 10 second interval updates. Which all helps to lower overall cpu usage and keep the system cooler.

The date/time jwm tray clock ... as pretty much standard for me, has it function as a show/hide desktop when left mouse clicked, show jwm menu when right mouse clicked. I don't bother with multiple desktops as I tend to have each window maximised and just flip between windows rather than desktops.

Script as attached (xload is loaded separately - as part of .jwmrc).
skippy.gz
Description  Actual .gz file (gzip -d skippy.gz to decompress)
gz

 Download 
Filename  skippy.gz 
Filesize  3.39 KB 
Downloaded  11 Time(s) 
t.png
 Description   
 Filesize   5.06 KB
 Viewed   490 Time(s)

t.png


_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Sat 28 Sep 2019, 19:04    Post subject:  

Rather than running wiaks build firstrib script, a alternative is to use the voidlinux tarball to set up the main filesystem. Here's my notes for that (so its only using wiak's build_weedog_initramfs script). Sorry, they are quite lengthy, but better that than nowt.
Code:
Download the voidlinux rootfs live image tarball from
https://a-hel-fi.m.voidlinux.org/live/current/

For instance I downloaded the x86_64 rootfs tarball ...
https://a-hel-fi.m.voidlinux.org/live/current/void-x86_64-ROOTFS-20181111.tar.xz

Extract it to firstrib_rootfs and use that as the firstrib rootfs

mkdir /mnt/sda1/VL
mv void*.tar.xz /mnt/sda1/VL
cd /mnt/sda1/VL
mkdir firstrib_rootfs
cd firstrib_rootfs
tar xvf ../void*.tar.gz
cd ..

Do the chroot preparation i.e. mount binding proc ...etc.
and copy your current /etc/resolv.conf

mount --bind /proc firstrib_rootfs/proc
mount --bind /tmp firstrib_rootfs/tmp
mount --bind /dev firstrib_rootfs/dev
mount --bind /sys firstrib_rootfs/sys
mount -t devpts devpts firstrib_rootfs/dev/pts
cp /etc/resolv.conf firstrib_rootfs/etc/resolv.conf

chroot into that

chroot firstrib_rootfs

and run
xbps-install -Su
...so we can xbps-install things

Run
xbps-install linux
... to install void linux vmlinux and initrd into firstrib_rootfs/boot

use xbps-install ... to install other things if desired (or just leave as-is).

ALSO SET THE ROOT PASSWORD SO ITS NOT THE DEFAULT voidlinux i.e. as root run 'passwd'

Make other edits as appropriate ... see mine as of *A* below

'exit' to exit the chroot

umount all the mounts

umount -lf firstrib_rootfs/tmp
umount -lf firstrib_rootfs/proc
umount -lf firstrib_rootfs/dev/pts
umount -lf firstrib_rootfs/dev
umount -lf firstrib_rootfs/sys

and run weedog initramfs build script on that
./build_weedog_initramfs05_s203.sh void "-comp lz4 -Xhc"
When that finishes you'll have a frugal style vmlinuz..., initramfs... 01firstrib_rootfs.sfs (my 01firstrib_rootfs.sfs is 470MB file size).

I'm using grub4dos menu.lst entry of

title VL
   root (hd0,0)
   kernel /VL/vmlinuz-5.2.17_1 bootfrom=/mnt/sda1/VL changes=RAM inram_sz=100%
   initrd /VL/initramfs05,gz

Once booted you'll have a cli system.
Set up networking, network connect and xbps-install as desired

With my rdsh3.plug and rdsh3 kernel boot parameter added, along with save.sh script then that adds persistence option (still a work in progress to make it more generic) i.e. currently generally unavailable. A alternative is not to store changes in ram (i.e. exclude the changes=RAM kernel boot parameter) but in a upper_changes folder located on hdd, but that means all changes are persistent.

Likely once up and running you'll want to install other things like xorg, chromium ..etc
xbps-install xorg chromium libreoffice .... whatever


*A*

Networking notes :

I use wifi, so I create a /etc/wpa_supplicant/wpa_supplicant.conf file that looks like

ctrl_interface=/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=1
ap_scan=1
fast_reauth=1
update_config=1

# Add here your networks.
network={
  ssid="VM123456-2G"
  psk="abcd1234"
}

i.e. has my ssid and password (modified here to hide the actual ssid/password I use)

ifconfig shows my wireless device name to be wlp2s0, so to connect I run ...

wpa_supplicant -i wlp2s0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B
dhcpcd

For alsa sound, my default card is card 1 (yours may be card 0)
and I create a /etc/asound.conf containing

defaults.pcm.card 1
defaults.ctl.card 1

pcm.!default {
   type plug
   slave.pcm "dmixer"
}

# Cant get it to work with plugequal as the slave

pcm.dmixer  {
    type dmix
    ipc_key 1024
    slave {
      pcm "hw:1,0"
      period_time 0
      period_size 1024
      buffer_size 4096
      rate 44100
   }
   bindings {
      0 0
      1 1
   }
}

ctl.dmixer {
   type hw
   card 1
}

ctl.equal {
    type equal
}

pcm.plugequal {
    type equal
    card 1
    slave {
      pcm "dmixer"
   }
}


To initialise alsa at bootup I run
echo "alsactl init" >>/etc/rc.local

To actually install alsa I use ...
xbps-install alsa-tools alsa-utils alsa-plugins

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh

Last edited by rufwoof on Sat 28 Sep 2019, 21:32; edited 1 time in total
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Sat 28 Sep 2019, 20:39    Post subject: WeeDog-it: to use independent weedog initramfs
Subject description: with any official void root filesystem and those of some other distros
 

Yes, WeeDog initramfs (to some extent) is, as I've stressed in the past, pretty much distro-agnostic (but depends if underlying root filesystem contains core controlling parts that depends on its the distro's own official initramfs - such as Puppy, for example).

So same technique, you outline rufwoof, can (and has been) used to take the rootfs contents of live Void Distros (e.g. I used the full LXDE one) and similarly the root filesystem from Slackware live. Just need the root filesystem, make sure it contains the kernel and modules installed, and then "WeeDog-it" using build_weedog_initramfs script. See attached LXDE Void in operation on attached image here:

http://murga-linux.com/puppy/viewtopic.php?p=1033478#1033478

As touched upon in first post of this thread:

Quote:
You can also take an existing root filesystem of some distros (e.g. Slackware) and "WeeDog-it" such that the resulting booted distro provides all WeeDog features in terms of rollback capability and changes=RAM and so on. Example of frugal installed WeeDog running Slackware:


http://www.murga-linux.com/puppy/viewtopic.php?p=1035211#1035211

I also, but ultra-briefly, described the process here some while ago:

http://www.murga-linux.com/puppy/viewtopic.php?p=1033855#1033855

But thanks, rufwoof, for documenting the process in a proper and detailed HowTo. It might also encourage someone to take a Puppy distro and try to WeeDog-it.

I did that early on, just for an experiment, with some success (and posted about it, but can't remember where),

[EDIT: was here: http://www.murga-linux.com/puppy/viewtopic.php?p=1029849#1029849 but that was an attempted build from scratch - easier to add WeeDog intiramfs to ready made Puppy rootfilesystem as I did with Slackware and Void LXDE root filesystems]

but Puppy internal control/operation depends quite a bit on its own initramfs organisation and its package management depends on various spec files that need to be made available. I'm sure it would be quite simple to work around most of that if anyone wanted the WeeDog facilities via WeeDog independent initramfs use on Puppy, but probably not worth the bother in Puppy's case. WeeDog official Slackware live is nice though.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130

Last edited by wiak on Sat 28 Sep 2019, 23:25; edited 1 time in total
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Sat 28 Sep 2019, 21:03    Post subject:  

I'll add that how to use official void root filesystem post to the user contributions how to list, rufwoof. Its very useful facility.

http://www.murga-linux.com/puppy/viewtopic.php?p=1029029#1029029

Note that once you untar the root filesystem, and rename it firstrib_rootfs, you can simply use the scripts mount_chrootXXX.sh and umount_chrootXXX.sh as a convenience to modify it and add kernel and firmware/modules:

http://murga-linux.com/puppy/viewtopic.php?p=1028957#1028957

As I said in my immediately above post, you can do the same with Void live graphical desktop root filesystem's, such as LXDE, and also with live Slackware (but using Slackware's own kernel/modules/firmware), and others...

http://www.murga-linux.com/puppy/viewtopic.php?p=1038053#1038053

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Sun 29 Sep 2019, 09:23    Post subject:  

Just a observation ... removing mouse hot corner detection, along with removing xload, cpu temp, caps lock and battery level indicators from my jwm tray ... and the cpu runs with around 5% less usage and 3 degrees lower temperature. Which also means longer running on battery time.
_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Sun 29 Sep 2019, 10:12    Post subject:  

Currently I'm using tar to make/restore 'saves' i.e. just simple 'copies' of upper_changes. I've set that the loading (or not) to occur in rdsh3.plug, so the system boots with either upper_changes loaded with the save tarball content, or not. Running 'save' tar's the upper_changes content to a replacement 'save' tarball.

Looking however to move that 'save' loading activity to use rsync instead of tar. rsync is much better for when a small number of changes are being made to a existing large amount of stored changes (compared to having to re-tar the whole).

The more preferable way to run/boot is to use a frugal setup, booting from a usb, loading into ram, such that the usb (boot partition, bootloader, kernel) can be physically detached/isolated once booted. Put out of harms way. For stability a encrypted swap file on hdd helps avoid system lock-up's due to having exhausted available ram. If therefore we're going to have the hdd accessible (swap file) anyway, then we might as well store upper_changes on disk also (rather than in ram as I am currently doing). If that upper_changes is encrypted (encfs) then that makes it secure (laptop lost/stolen, then they can't see the content of our save folder).

As-is the base initramfs system doesn't support encfs nor rsync. Whilst I could compile static versions of those to add to initramfs there's no actual need as we can just mount the main sfs that does (assuming it was built as such) have encfs and rsync. Mounting that however is ro (being a non-layered sfs); However we can also bind mount ... in my case ... /mnt/sda1/VOID6 where the 01firstrib_rootfs and other files/folders are stored, and run rsync (and/or encfs) against files/folders in /mnt/sda1/VOID6 ... such as to load using rsync the upper_changes folder content.

The way encfs works is to have a dot (hidden) folder containing all of the encrypted files/folders, so .upper_changes for instance. That when 'opened' makes the decrypted versions visible in upper_changes.

At least that's the concept, I've yet to actually code/implement that.

Running that way and not only is the MBR/bootloader/kernel physically isolated, but our swap content is encrypted (using a different randomly generated key at each reboot), and so also is the save content. Whilst the system runs mostly in ram, but where swap and save content are disk based, such that we're not limited to ram limits against changes or system loading (system loading limited to disk based swap file size, unlimited (to free disk space limit) amount of 'changes' permissible). Both encrypted swap and save (.upper_changes.rsync) could be stored in a file filesystem, such that that file filesystem could be stored and run from any form of disk format (ext2/3/4/ntfs/fat ...etc.).

Lose the boot usb ... and that just contains OS files anyway, that could just as easily have been downloaded. Lose the laptop/hdd .. and swap, saves are encrypted. If a in-session cracker achieves root access then they can't get to the physically unplugged usb (MBR/bootloader/kernel) but they would have access to the open (decrypted) save content (upper_changes) as well as any HDD data (so as ever backups are mandatory). If the .upper_changes.rsync is also on usb however, then they can't change things and run a 'save' command to make those changes persistent (as the usb is physically detached).

The great thing about wiak's scripts is that making such changes or extensions is so simple. No need to dive into intramfs (cpio extract/change/reform etc.), but instead just simple scripts (rdsh3.plug ...etc.) Smile

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh

Last edited by rufwoof on Sun 29 Sep 2019, 19:09; edited 3 times in total
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Sun 29 Sep 2019, 12:55    Post subject:  

Bug in build_weedog_initramfs05_s203.sh
_rdsh function.

By the time rdsh5 is reached the mountfrom= parameter mount point has been moved from for example /mnt/sda1/VOID6 to under the merged folder (/mnt/layers/merged/mnt/sda1/VOID6). So if you create a rdsh5.plug within /mnt/sda1/VOID6 it isn't 'seen' by _rdsh function and it just drops to a shell instead of sourcing the rdsh5.plug file.

This additional else block within the _rdsh function works for me ...
Code:
# process any grub linux/kernel line rdshN argument to active plugin or debug sh
_rdsh (){
        if `grep -q $1 /proc/cmdline`; then
                # if plugin exists and isn't empty then source it
                if [ -s "${mountfrom}"/${1}.plug ]; then
                        . "${mountfrom}"/${1}.plug
                else # rdsh5 has the mountfrom moved
                  if [ -s /mnt/layers/merged/"${mountfrom}"/${1}.plug ]; then
                        . /mnt/layers/merged/"${mountfrom}"/${1}.plug
                  else
                        # Start a busybox job control debug shell at initramfs/init rdshN code li
                        echo "In initramfs/init at $1. Enter exit to continue boot:"
                        setsid cttyhack sh
                  fi
                fi
        fi
}

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Sun 29 Sep 2019, 18:35    Post subject:  

rufwoof wrote:
Bug in build_weedog_initramfs05_s203.sh
_rdsh function.

By the time rdsh5 is reached the mountfrom= parameter mount point has been moved from for example /mnt/sda1/VOID6 to under the merged folder


It's not a bug rufwoof. I actually commented prior to release of s203 that rdshN.plug would only work up to rdsh4.plug (as the comment in the code says, it will still drop to busybox sh at that point if required). Since I noted you might want a plugin just prior to the chroot I specially put in a pre_switch_root.plug position instead as the relevant s203.sh code shows:

Code:
# If grub kernel-line rdsh5 specified then start busybox job control shell
_rdsh rdsh5

[ "$umount_bootdevice" == "allowed" ] && echo -e "\e[96mYou can now umount bootdevice if you wish\e[0m" >/dev/console

# if pre_switch_root.plug exists in bootfrom directory source it
[ -s merged"${mountfrom}"/pre_switch_root.plug ] && . merged"${mountfrom}"/pre_switch_root.plug


Of course it could be done the way you write it in previous post, but I liked giving actual position name to this plug since it describes the critical position where it is used. Also, don't need additional rdsh kernel line parameter to activate it. I thought of positioning it exactly beside the rdsh5 position, but didn't see any advantage to placing it as near the switch_root as I could whilst /proc and so on still mounted (but only one line further than rdsh5 breakpoint anyway. So just place your save code in pre_switch_root.plug (best anyway, since the other plugin positions are not always fixed as the program develops).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Sun 29 Sep 2019, 19:01    Post subject:  

Thanks for the clarity wiak. My brains been like the weather here today (cloudy)
_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1281
Location: Connecticut, United States

PostPosted: Mon 30 Sep 2019, 11:51    Post subject:  

experimenting on getting a weedog to boot from an ISO in Virtualbox.
not successful yet, getting kernel panic so far
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Mon 30 Sep 2019, 18:45    Post subject:  

rockedge wrote:
experimenting on getting a weedog to boot from an ISO in Virtualbox.
not successful yet, getting kernel panic so far


I'm still to try making any kind of iso. I've never made isos before, since I never use them (though some scripts I've tried in the past have auto-built iso's, just as woof-CE and mklive-stretch) - so I don't know exactly how to do it aside from something to do with isolinux and xorriso.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Mon 30 Sep 2019, 19:11    Post subject:  

You might be able to use isomaster, to open up a existing iso from another similar distro, and swap out the vmlinuz, initramfs ...etc. change the .cfg file inside that (like menu.lst ... but different) and then save/write that to another named .iso file.
_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Mon 30 Sep 2019, 19:35    Post subject:  

I've been playing with using a small main sfs (voidlinux rootfs as I outlined the other day), and having a massive save file (upper changes) with the rest (X, libreoffice, browser ...etc.).

As a straight folder that's around 3.3GB of upper_changes content. I have that rsync'ing at startup ... so back to a clean copy and mostly rsync runs through quickly (due to just 'differences' being copied across).

Whilst pondering how to better secure that clean copy rsync folder, I decided a reasonable choice is to simply store it in a file filesystem, so its also a single file, and rather than encrypting the whole of that file (I created a 5GB file filesystem that takes a couple of minutes to 'open' (decrypt) when encrypted, I've been experimenting with just encrypting the first 20MB of that file (filesystem), so that when the first 20MB are encrypted it can't be loaded/mounted. Whilst opening it up again is quick, and requires the password to be entered.

The trick is to use dd with the notrunc i.e. with a big.img file of 5GB extract the first 20MB ...

dd if=big.img of=header bs=1M count=20

to a file called header, and then encrypt that smaller 20MB block

openssl enc -AES-256-CBC -in header -out header.encrypted

and then dd that back as the first part of the big file

dd conv=notrunc if=header.encrypted of=big.img

Try and mount that and it complains/fails (obviously). Then to reverse that its pretty much the same but using openssl decode instead ...

dd if=big.img of=header.encrypted bs=1M count=20

then decrypt the header part

openssl enc -AES-256-CBC -d -in header.encrypted -out header

and dd conv=notrunc if=header of=big.img

Mount that and it mounts ok.

I just arbitrarily selected 20MB of 'header' (encrypted) which pretty much flies though both the dd and openssl encryption very quickly. But that could be even smaller, perhaps even just a couple of MB. Doesn't really prevent a concerted cracker effort of changing things as most of the file is open, but does prevent a in session crack potentially making configuration changes and then running the 'save' command to get those changes preserved across reboots. As ever a trade off between speed or security.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 42 of 48 [709 Posts]   Goto page: Previous 1, 2, 3, ..., 40, 41, 42, 43, 44, 45, 46, 47, 48 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1076s ][ Queries: 13 (0.0367s) ][ GZIP on ]