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 Sun 15 Dec 2019, 10:14
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 45 of 49 [722 Posts]   Goto page: Previous 1, 2, 3, ..., 43, 44, 45, 46, 47, 48, 49 Next
Author Message
wiak

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

PostPosted: Thu 03 Oct 2019, 13:28    Post subject:  

I'll check it tomorrow rufwoof, cheers
_________________
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 
wiak

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

PostPosted: Thu 03 Oct 2019, 13:50    Post subject:  

rufwoof wrote:


Ahh! Its because immediately after the _rdsh rdsh1 there's also a _rdsh inram action and as I have inram_sz=100% as a kernel boot parameter _rdsh function is picking that up in its grep inram /proc/cmdline search, finding inram_sz=100% and dropping to shell

Code:
_rdsh (){
        [ -s "${mountfrom}"/${1}.plug ] && . "${mountfrom}"/${1}.plug
        if grep -q $1 /proc/cmdline || [ "$2" == "debug" ]; then
                        # Start a busybox job control debug shell at initramfs/init rdsh break po
                        echo "In initramfs/init at $1. Enter exit to continue boot:"
                        setsid cttyhack sh
        fi
}

Needs perhaps a translate or sed to filter out "inram_sz"


I don't have the code in front of me. Just android phone since about to sleep, but yes I think my 'simplification' missed that inram result... I'll fix that tomorrow, wiak

That is the trouble with flexible plugin capability -have a lot of variables and alternatives to remember, but many hands testing indeed helps pick up these mistakes... Really it's a namespace clash. The previous _rdsh function method avoided it. New method either needs filter or inram name change or inram.plug not being handled by _rdsh function

_________________
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 Thu 03 Oct 2019, 20:04; edited 1 time in total
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Thu 03 Oct 2019, 15:01    Post subject:  

So best, to avoid messy filters is just to change plugin name to avoid name clash. Thus changing inram.plug to inram00.plug and change call line to _rdsh inram00

Also such plugin name also useful in case ever chaining with other inramNN plugins, whether likely or not.

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 
wiak

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

PostPosted: Thu 03 Oct 2019, 20:29    Post subject: build_weedog_initramfs05_s205.sh uploaded
Subject description: fixes inram plug name clash but needs plugin now named to inram00.plug
 

build_weedog_initramfs05_s205.sh uploaded to usual "Downloads" post here:

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

CHANGES

# Revision 2.0.5 Date: 04 Oct 2019
# YMD 20191003: implemented seaside's wait on bootpartition idea

Thanks for the idea seaside, which I implemented only slightly differently:
To get variable seek, simply do not enter ANY usbwait=NN grub kernel commandline parameter. If you do specify any usbwait=NN parameter, the resultant delay will be fixed at NN seconds (including NN=0 case). I have also hard-coded in a timeout value of 30 seconds for the variable delay - if timeout occurs the boot process will immediately drop to a debug sh.

NOTE WELL: rdsh plugin mechanism has been altered slightly since version s203.

Sorry for any inconvenience this causes, but too good opportunity to miss since best to minimize number of needed grub kernel cmdline parameters, which this change does.

Previously needed rdshN on grub kernel line to activate related rdshN.plug. Now, the mere existence of the rdshN.plug results in it being sourced at relevant position in the initramfs/init script.

Owing to the new mechanism, you can now both source the rdshN.plug (if it exists) and immediately after that force a debug sh. The debug sh will occur in the usual fashion if the rdshN argument is provided on the grub kernel line.

Fixed related 'namespace clash' in previous s204 version, where inram plug name clashed with grub kernel line use of inram_sz resulting in unwanted drop to debug sh when running. Unfortunately, you do need to change the name of any previous inram.plug file you were using to inram00.plug. Sorry for that inconvenience. Also, the position of rdsh1.plug (at least - please always check) has changed since no required besides inram00.plug position. If you do want to use two plugins at that inram00 plug position, I suggest you simply source a second inram related plug from inside inram00.plug (e.g. second plug of inram01.plug).

Obviously, I prefer not to change default naming schemes or plugin code positions since that has a knock-on effect on other user's scripts, but I believe WeeDog initramfs code is becoming quite mature now so hopefully such adjustments will become rare. If any changes prove intolerable and unable to be easily worked around in your plugin creations, please let me know and I'll consider best way forward. Similarly, if current plugin facility isn't adequate for your modular plugin addition ideas, again please make me aware of what you need and I'll endeavour to provide some solution.

Thanks again to seaside for his variable usbwait idea. I hope my implementation of that is working well for you seaside (I didn't quite understand your last message...). It certainly does for me (no need to wait on uneasy to determine fixed usbwait delay now). Recommended use now is to NOT put any usbwait=NN commandline argument on grub kernel line since the auto-seek method seems to work very reliably and efficiently (please let me know if any problems).

Thanks also to rufwoof for so quickly noticing that name clash error in previous s204 version (I was half asleep by that time). I didn't notice it because I didn't have any inram_sz=NN% kernel cmdline arg in my brief tests (I should maybe remind you that, since s203 version, inram_size defaults to 100% if no such argument given to kernel).

Disclaimer. The build_weedog_initramfs_s205.sh script remains only briefly tested. There could be other errors, which I'd like to find and fix soon as possible so all testing and reports are appreciated. I will make an effort to fix any errors as soon as I am notified.

I believe future development effort moves very much into the development of the plugins and utilities, both build rootfs firstrib00.plug (thanks particularly to rockedge and rufwoof for current ones of these), and enhancements to initramfs/init via the likes of inram00.plug: such things as (already covered) zram, and most important save changes merge mechanisms such as the good work in that direction done by rufwoof.

It may be that AndresC2 has some things he wants to add (just let me know, Andres) - hopefully any such changes can be easily implemented via the plugin facilities on offer. I certainly don't want to add any extra bloat to the core scripts where possible and it is always risky anyway to disturb what is already working nicely...

Cheers,

wiak

EDIT: To the one person who downloaded the first uploaded s205 script, would you kindly redownload (your download beat my fix by seconds...). There remained a very minor error which I immediately fixed and re-uploaded (in practice probably something irrelevant but best fixed for consistency).

_________________
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: 3681

PostPosted: Fri 04 Oct 2019, 08:23    Post subject: Using rdsh1.plug as a security measure  

Boot from usb so that the MBR, bootloader, vmlinuz and initramfs are all on that, and if you run in a manner where the usb can be unplugged after bootup, then those files remain physically out of harms way (in session cracks). Transferring/loading the main sfs and any changes from/to usb however is a relatively slow activity, so instead we can store those on hdd, frugal boot style. But being on hdd those files could potentially be compromised (cracked) during a session. Not that their content is secret, its just OS and configuration (here, it is assumed that you keep all data outside/separately). To detect such potential tampering we can keep md5sum checksums on usb (I actually keep them inside the initramfs) and validate the sfs(s) on bootup.

So the setup here is bootloader, MBR, vmlinuz and initramfs on usb, main sfs and changes sfs on hdd (sda1 in my case) and a bootup that looks something like
Code:
title VOID6
   root (hd0,0)
   kernel /VOID6/vmlinuz-5.2.18_1 bootfrom=/mnt/sda1/VOID6 changes=RAM
   initrd /VOID6/initramfs05.gz

All session changes are stored in ram, so no trace of activities if the laptop is stolen. And where during bootup rdsh1.plug is run that validates the sfs's on hdd

rdsh1.plug
Code:
# Validate 01firstrib_rootfs.sfs md5sum compares to pre-created copy stored
# within the initramfs on usb ... and also for 02changes.sfs if that exists
# i.e. after creating 01firstrib_rootfs.sfs we open up initramfs and store
# its md5sum (directly from the folder where it is stored so the md5sum
# line has just the filename, no path). Separate script(s) to do that recording.

_logo () {

   echo "voidlinux"
   echo
   
}

SFSLOC=`env | grep bootfrom | awk -F= '{print $2}'`
CD=`pwd`
cd $SFSLOC

_logo
echo "Running Intrusion Detection checks ... please wait "
if [ ! -f 01firstrib_rootfs.sfs ]; then
    echo
    echo No 01firstrib_rootfs.sfs file found
    echo -n "Press Enter "
    read n
else # Don't bother wasting time if there's no recorded md5
    if [ -f /01.md5 ]; then
   md5sum 01firstrib_rootfs.sfs >/tmp/01.md5
    fi
fi
if [ -f 02changes.sfs ]; then
    if [ -f /02.md5 ]; then
   md5sum 02changes.sfs >/tmp/02.md5
    fi
fi

_logo
if [ -f /01.md5 ] && [ -f 01firstrib_rootfs.sfs ]; then
    D01=`diff /01.md5 /tmp/01.md5`
    if [ ! -z "$D01" ]; then
   echo "01firstrib_rootfs.sfs md5 checksum does not match"
   echo "That could mean the sfs on HDD may have been tampered with"
   echo -n "Power down and investigate, or Press Enter to continue "
   read n
    else
   echo "01firstrib_rootfs.sfs validated as OK"
    fi
else
    echo "No checksum recording found for 01firstrib_rootfs.sfs"
    echo "Unable to validate, integrity checks not fully operational"
fi
if [ -f /02.md5 ] && [ -f 02changes.sfs ]; then
    D01=`diff /02.md5 /tmp/02.md5`
    if [ ! -z "$D01" ]; then
   echo "02changes.sfs md5 checksum does not match"
   echo "That could mean the sfs on HDD may have been tampered with"
   echo -n "Power down and investigate, or Press Enter to continue "
   read n
    else
   echo "02changes.sfs validated as OK"
    fi
else
    echo "No checksum recording found for 02changes.sfs"
    echo "Unable to validate, integrity checks not fully operational"
fi

if [ ! -f /01.md5 ]; then
    _logo
    echo "No pre-recorded checksum for 01firstrib_rootfs.sfs"
fi
if [ -f 02changes.sfs ]; then
    if [ ! -f /02.md5 ]; then
   echo "No pre-recorded checksum for 02changes.sfs"
    fi
fi
if [ -f /tmp/01.md5 ]; then
   rm /tmp/01.md5
fi
if [ -f /tmp/02.md5 ]; then
   rm /tmp/02.md5
fi
cd $CD
echo
echo -n "Remove USB and Press Enter "
read n
clear


Infrequent saves i.e. saves are considered as only for OS tweaks/changes, typically by clean booting, making changes, running save; Otherwise just booting, using and shutting down without saving. Where the save action just replaces the current 02changes.sfs (that gets loaded as part of bootup) with the latest copy of the upper_changes folder (save folder) content.

save.sh
Code:
#!/bin/sh
# This is my machine specific, usb boot (sdb1) hdd storage of sfs's (sda1)
cd /mnt/sda1/VOID6 #where my sfs's are stored (and booted from) on hdd
if [ -f 02changes.sfs.bak ]; then
    rm 02changes.bak
fi
mv 02changes.sfs 02changes.bak
mksquashfs /mnt/layers/RAM/upper_changes 02changes.sfs -comp lz4 -Xhc
echo "Ensure your boot usb is attached and then press Enter"
read n
msdb1
store02md5 /mnt/sda1/VOID6 /mnt/sdb1/VOID6/initramfs05.gz

(note msdb1 is a local script I have that just mounts /dev/sdb1 to /mnt/sdb1)

As part of save (and when a new main sfs is built), the initramfs is updated to store the md5sum (checksum) of the 02changes.sfs (or 01firstrib_rootfs.sfs) file(s). Here's my script for doing that for 02changes.sfs

store02md5 script ... (note store01md5 is near identical, but that uses 01firstrib_rootfs.sfs instead of 02changes.sfs)
Code:
#!/bin/bash

# $1 where hdd 02changes.sfs is stored i.e. /mnt/sda1/VOID6
# $2 PRE MOUNTED location of usb's initramfs05.gz i.e. /mnt/sdb1/VOID6/initramfs05.sfs

_usage () {
    echo Requires two parameters
    echo "$1 where hdd 02changes.sfs is stored i.e. /mnt/sda1/VOID6"
    echo "$2 pre mounted location of usb's initramfs05.gz i.e. /mnt/sdb1/VOID6/initramfs05.gz"
    exit
}

if [ -z $2 ]; then
   _usage
fi

if [ ! -f $2 ]; then
    _usage
fi

if [ ! -f $1/02changes.sfs ]; then
    echo $1/02changes.sfs not found
    _usage
fi

CD=`pwd`
cd /tmp
mkdir extracted
cd extracted
echo Extracting usb initramfs
zcat $2 | cpio -id
cd $1
echo Recording md5sum
md5sum 02changes.sfs >/tmp/extracted/02.md5
cd /tmp/extracted
echo Recreating the initramfs
find . | cpio -o -H newc | gzip >$2
cd ..
echo "Syncing (flushing)"
sync
rm -rf extracted
echo "Done. Don't forget to umount and unplug the usb"
cd $CD


Under this model we strive to always boot a known clean system/OS and strive to keep that clean. No general mixing of OS/data content but instead separating those. Where we boot from a usb and immediately physically disconnect that after (during) bootup so no in-session cracks can get at those files, and where if any of the main sfs or changes sfs files are modified we detect such modification. A crackers attempt to modify things and then run a save command action will fail in the absence of the boot usb also being connected. In short - a secure setup. Data and online security are considered as being totally separate, but in having a clean base starting point that goes some way towards helping with data and online security. If a cracker can't get to install a persistent crack that might monitor/report your activities and passwords across multiple sessions, then your data/security is the better for that.

With the above setup, the additional amount of boot time from having vmlinuz/initramfs on usb is negligible compared to had those files been on hdd. Yes there is the additional time of measuring and comparing md5 checksums, but that's the price of better security and greater peace of mind. Crackers will typically go after inserting a sub layer system they control if they can get at your bootloader, MBR, kernel ..etc. So the less you save, and only saving in a secure manner (not after having browsed around here/there/anywhere) and you'll be far less likely to have such hidden sub-systems being installed on you laptop/desktop.

_________________
( ͡° ͜ʖ ͡°) :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: 3681

PostPosted: Fri 04 Oct 2019, 08:49    Post subject:  

My intent is to extend that validation code to also check filesizes and to replace the super-block of the sfs's stored on hdd with empty (or rather random) content. Unlike standard filesystems, ext2/3/4 that store multiple copies of the super-block (due to its importance), squashed filesystems (sfs) store it just the once, as the first 100 bytes or so of the file. That contains such detail as what compression was used, and pointers to the start of the directory, inodes, data ...etc. This for example is the code I use to inspect a sfs to see what compression method it is using after first checking that the files magic number indicates it is actually a sfs file (68 73 71 73 test part).
Code:
#!/bin/sh

# show compression method used in a sfs ($1)

V=`hexdump -C ${1} | head -1 | grep "00000000  68 73 71 73"`
if [ -z "$V" ]; then
    echo $1 is not a sfs
    exit
fi

M=`hexdump -C ${1} | head -2 | tail -1 | awk '{print $6}'`
echo -n "Looks like the named sfs file was compressed using : "
case $M in
    01) echo gzip;;
    02) echo lzma;;
    03) echo lzo;;
    04) echo xz;;
    05) echo lz4;;
    06) echo zstd;;
    *) echo unknown - perhaps not a sfs;;
esac

Being compressed content without the super-block its that more difficult to inspect (or change) the expanded (non compressed) data content. By storing the superblock on usb and inserting useless content in its place into the sfs stored on hdd, then that's like a key to actually open/use the sfs, and better ensures against being tampered with in a undetectable manner (would take a immense effort to substitute in a modified sfs that had a valid md5sum that matched the one recorded on usb for the valid one).

_________________
( ͡° ͜ʖ ͡°) :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 
seaside

Joined: 11 Apr 2007
Posts: 935

PostPosted: Fri 04 Oct 2019, 10:40    Post subject: Re: build_weedog_initramfs05_s205.sh uploaded
Subject description: fixes inram plug name clash but needs plugin now named to inram00.plug
 

wiak wrote:


# Revision 2.0.5 Date: 04 Oct 2019
# YMD 20191003: implemented seaside's wait on bootpartition idea

Thanks for the idea seaside, which I implemented only slightly differently:
To get variable seek, simply do not enter ANY usbwait=NN grub kernel commandline parameter. If you do specify any usbwait=NN parameter, the resultant delay will be fixed at NN seconds (including NN=0 case). I have also hard-coded in a timeout value of 30 seconds for the variable delay - if timeout occurs the boot process will immediately drop to a debug sh.

.


Wiak,

Your implementation is working very nicely and I just wanted to mention that because the original idea was to use the SECONDS variable. the 30 number was actually 30 seconds. As the loop was changed to a counter method. the 30 is now the number of loops which consist of 30 times of .5(one half second) sleep seconds, it translates to 15 seconds.

I did three tests on different usb devices and they mounted. So this will cover most usb devices.

You're right that you can almost eliminate the "usbwait=" command.

Cheers,
s
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Fri 04 Oct 2019, 10:45    Post subject: Re: build_weedog_initramfs05_s205.sh uploaded
Subject description: fixes inram plug name clash but needs plugin now named to inram00.plug
 

seaside wrote:
I just wanted to mention that because the original idea was to use the SECONDS variable. the 30 number was actually 30 seconds. As the loop was changed to a counter method. the 30 is now the number of loops which consist of 30 times of .5(one half second) sleep seconds, it translates to 15 seconds.


Ah, yes, of course you are right. !5 seconds is a wee bit on the low side, though is working fine on my system usb too - I was erroneously imagining timeout of 30 secs (forgot the sleeps wer just 0.5sec), which I'd prefer; I'll fix that next time I upload a new version just to cover possibility of slower devices.

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: 3681

PostPosted: Fri 04 Oct 2019, 11:58    Post subject:  

Just to say that the latest build scripts worked fine for me. I've also removed the inram_sz=100% from my menu.lst (since its the default anyway) Embarassed . Handy that I'd forgotten to do that as otherwise that conflict wouldn't have come to light so quickly Smile
_________________
( ͡° ͜ʖ ͡°) :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: 1842
Location: not Bulgaria

PostPosted: Sat 05 Oct 2019, 02:44    Post subject: Void Live install iso; HowTo 'WeeDog-it'
Subject description: or WeeDog Slackware live if you wish...
 

Following on from rufwoof's howto use offical void linux base root filesystem with WeeDog:

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

Here is a HowTo WeeDog an official LXDE graphical desktop Void Linux ‘live’:

Keep in mind that the result is Void Linux live installer disk running under control of WeeDog initramfs. What I've done in the past instead is to make an actual Void Linux full-install from same Void live install disk and then copied the resultant root filesystem into an empty firstrib_rootfs. That is better in the end (since things better set up) but the procedure is otherwise the same as below and running ‘live’ Void install via WeeDog changes= facilities is useful anyway.

Note that you'll need Linux filesystem with around 5GB free space on it to undertake the following.

1. Download wanted Void Linux live iso image for either system architecture (i386 or x86_64). For example:
https://a-hel-fi.m.voidlinux.org/live/current/void-live-x86_64-20181111-lxde.iso

2. Mount the iso and copy out squashfs.img to an empty directory of your choice, let's say directory void_lxde

3. Now unsquashfs that image with command:

Code:
unsquashfs squashfs.img


That should produce a squashfs-root directory containing:

LiveOS/ext3fs.img

4.
Code:
cd squashfs-root/LiveOS


If you wish you can check what the content file type is using command:
Code:
file ext3fs.img


Shows:
ext3fs.img: Linux rev 1.0 ext3 filesystem data, UUID=5fb93140-0986-451b-be2b-7be71b6afe4a (large files)

5. To extract its root filesystem contents, simply mount it as follows:
Code:
mkdir mymnt
mount -t ext3 ext3fs.img mymnt

Note that nowadays you don't usually need the -t ext3

Now, remove any existing firstrib_rootfs if you happened to have one... Then:
Code:
mkdir -p firstrib_rootfs
cp -af mymnt/* firstrib_rootfs
sync
umount mymnt


6. Now we are going to prepare that firstrib_rootfs for WeeDog initramfs use. so copy the following utilities into the LiveOS directory:

mount_chrootXXX.sh umount_chrootXXX.sh build_weedog_initramfsXXX.sh (using the actual script names).

7. Now use chroot to fetch new kernel/modules. For convenience I use firstrib's mount_chrootXXX.sh and umount_chrootXXX.sh utilities here:

If not already there, cd into LiveOS and run command:

Code:
./mount_chrootXXX.sh


Once in that chroot run commands:

Code:
xbps-install -Suy
xbps-install -y linux ncurses-base linux-firmware-network wifi-firmware


8. Whilst still in the chroot, remove the old kernel/modules combination. You can check what is installed with command:
Code:
xbps-query -l | grep linux

In my case I had to remove the following old kernel/modules combination:
Code:
xbps-remove linux4.18-4.18.17_1


You can't remove dracut and boot/initramfs* directly because linux package dependent on it. Probably could just remove the void initramfs, but in the hope of making the removal invisible to xbps database, I instead removed it with command:
Code:
n="`ls boot/initramfs*`"; rm boot/initramfs*; touch "$n"


You could prune the root filesystem further at this stage if you wish.

9. IMPORTANT! Set a password for root at this stage (don't know why but couldn't log in later if I didn't do that, even when trying what is supposed to be default Void root password, 'voidlinux'). That is, run the command:

Code:
passwd root


and give root a password...

10. Now exit the chroot and clean up its mounts with command:
Code:
./umount_chrootXXX.sh


11. That Void LXDE firstrib_rootfs is now ready for WeeDog initramfs creation via 'WeeDog-It' build command such as:
Code:
./build_weedog_initramfs05_sXXX.sh void "-comp lz4 -Xhc"


12. You can now copy the resultant vmlinuzXX (maybe renamed to simply vmlinuz), initramfs05.gz, and 01firstrib_rootfs.sfs to a directory you want to boot from, as usual, and boot using a grub entry such as:

Code:
title WeeDog Void LXDE rootfs
root (hd0,0)
kernel /weedogLXDE/vmlinuz bootfrom=/mnt/sda1/weedogLXDE
initrd /weedogLXDE/initramfs05.gz


and of course you can then use all the usual WeeDog flexible facilities/grub kernel line arguments and so on, such as:

optional usbwait=duration. Usually best left out since auto-seek works.
optional rdsh0, rdsh1, rdsh2, rdsh3, rdsh4 to force debug sh,
optional rdshN.plug files, which will be sourced by initramfs/init,
optional inram00.plug, which will be sourced by initramfs/init,
optional pre_switch_root.plug, which will be sourced by initramfs/init,
optional copy2ram, which copies all NNsfs, NNdirs, rdshN.plug to RAM,
optional changes=[option] where option can be:
RAM for no persistence, readonly for no writes, or /mnt/partition/dir
for dir location where upper_changes subdir will be stored.
optional altNN=path2dir for alternative location for NNsfs/dirs.

13. System will initially boot to a command line so:

Login as root (with your previously created password) when asked, and then run command:

Code:
lxdm


followed by again logging in as root to the default LXDE desktop.
You usually need to also give login credentials to shutdown/reboot from this I believe.

14. To connect to network. I didn't bother trying with ethernet (which is simpler) but simply connected by wifi straight away as follows:

Start an lxterminal from desktop Menu and enter command (note well use of >> i.e. append):

Code:
wpa_passphrase MYSSID MYPASSWORD >> /etc/wpa_supplicant/wpa_supplicant.conf


Then activated inbuilt dhcpcd which starts up wpa_supplicant automatically:

Code:
ln -s /etc/sv/dhcpcd /var/service
# That should auto-start dhcpcd and wpa_supplicant - check with ps aux

Then successfully tried:
Code:
ping google
# though dhcpcd needed time first to set up dns resolution (give it 5 or 10 seconds).

You can check your interface address configs with “ip address” command if you wish or need to.

NOTE that the above procedure can be pretty much used to WeeDog a Slackware live root filesystem too if you want. Only difference is that you use/move the original kernel/modules/firmware provided in Slackware live in your firstrib_rootfs and of course Slackware doesn't use xbps package manager nor runit, so network connection steps will be different.

I've added this to the User Contributed HowTos post list:

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

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: 3681

PostPosted: Sat 05 Oct 2019, 11:20    Post subject:  

Quote:
Here is a HowTo WeeDog an official LXDE graphical desktop Void Linux ‘live’

Nice!

_________________
( ͡° ͜ʖ ͡°) :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: 3681

PostPosted: Sat 05 Oct 2019, 11:32    Post subject:  

Question: I know you can store/mount/run ext2/3/4 file filesystems stored on ntfs formatted partition, and believe you can also store/mount/use sfs's in a similar manner. When you source a script either with source <script> or . <script> it reads/interprets (runs) that textual content as though its part of the same script. Does that work equally if the script (text file) is on a ntfs partition? i.e. main script is running in ram or from ext3, but where the sourced file resides on a ntfs partition.

I haven't used Windows for years and loaded gparted in anticipation of creating a ntfs partition to try that out, but my installation/version doesn't support formatting a partition to ntfs.

TIA

PS fundamentally here I have a ext3 formatted boot usb (with grub4dos installed) that also stores vmlinuz and initramfs but store my 01firstrib_rootfs.sfs and 02changes.sfs on hdd (ext3), along with a rdsh1.plug, and was wondering if those 01firstrib_rootsfs.sfs, 02changes.sfs and rdsh1.plug files were instead on ntfs formatted HDD would it still boot/run. I suspect so, but not 100% sure.

_________________
( ͡° ͜ʖ ͡°) :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: 1842
Location: not Bulgaria

PostPosted: Sat 05 Oct 2019, 12:33    Post subject:  

rufwoof wrote:
i.e. main script is running in ram or from ext3, but where the sourced file resides on a ntfs partition.
...
wondering if those 01firstrib_rootsfs.sfs, 02changes.sfs and rdsh1.plug files were instead on ntfs formatted HDD would it still boot/run. I suspect so, but not 100% sure.


Yes, you suspect correctly. That will be fine. You don't want symlinks between items on your ntfs partition, of course, ntfs doesn't support that, but no problem sourcing the scripts/plugins/sfs-files/img-files from a mounted ntfs partition.

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: 3681

PostPosted: Sat 05 Oct 2019, 12:34    Post subject:  

Thanks wiak.
_________________
( ͡° ͜ʖ ͡°) :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: 3681

PostPosted: Sat 05 Oct 2019, 12:51    Post subject:  

Here's the core part (snippet) of my /etc/rc.shutdown for saving (or not)
I'm just maintaining a single 02changes.sfs now, and whenever save is selected that is renamed to changes.sfs.bak (renaming it to 02changes.sfs.bak and it will get loaded into ram if copy2ram is used at the next bootup !!!). That renaming automatically revises its active loop, so after renaming it (mv) we have to use the new name when layering it with upper_changes i.e. so that all of the current 02changes.sfs content is layered beneath upper_changes content and where the new 02changes.sfs is created from that merged pair. I boot with changes=RAM, so upper_changes is mounted to /mnt/layers/RAM/upper_changes.
Code:
.
.
echo -n "Do you want to save changes y/n "                     
read -n1 n
echo     
if [ "$n" == "y" ]; then
    bootfrom=$(grep bootfrom /proc/cmdline | awk -F= '{print $2}' | awk '{print $1'})
    cd $bootfrom
    if [ -f 02changes.sfs ]; then
        if [ -f changes.sfs.bak ]; then
            rm changes.sfs.bak
        fi
        mv 02changes.sfs changes.sfs.bak
        # renaming the sfs on disk has losetup auto renamed as well so changes.sfs.bak now.
        CL=`losetup | grep changes.sfs.bak | awk '{print $1}'`
        mkdir /mnt/CL
        mkdir /mnt/TOP
        mount -t squashfs -o loop $CL /mnt/CL
        mount -t overlay overlay -o lowerdir=/mnt/layers/RAM/upper_changes:/mnt/CL /mnt/TOP
        sync
        mksquashfs /mnt/TOP 02changes.sfs -comp lz4 -Xhc
.
.

if 02changes.sfs doesn't already exits then it just runs mksquashfs against upper_changes alone to create the new 02changes.sfs.

_________________
( ͡° ͜ʖ ͡°) :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 45 of 49 [722 Posts]   Goto page: Previous 1, 2, 3, ..., 43, 44, 45, 46, 47, 48, 49 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.1682s ][ Queries: 13 (0.0367s) ][ GZIP on ]