RC7 (STABLE) WeeDogLinux Arch 64 now released

[wiak]

So, just briefly. To extract the firstrib_rootfs firmware and modules and put them into an sfs for auto-loading, what I do is this:

Code: Select all

mkdir -p firstrib_firmware_modules/usr/lib
# mv firstrib_rootfs/usr/lib/modules firstrib_firmware_modules/usr/lib/modules # probably not move modules - see NOTE at foot
mv firstrib_rootfs/usr/lib/firmware firstrib_firmware_modules/usr/lib/firmware

Then I prune the firmware down to next to nothing (which saves tons); could also prune the modules at that stage, and then, I make the sfs with command:

Code: Select all

mksquashfs firstrib_firmware_modules/ 00firstrib_firmware_modules.sfs -noappend -comp xz -b 524288 -Xdict-size 524288 -Xbcj x86

Then I rename firstrib_rootfs to 01firstrib_rootfs and boot the system with that uncompressed 01firstrib_rootfs (instead of 01firstrib_rootfs.sfs) to see if all works. Then I can make a new 01firstrib_rootfs.sfs out of that when it does (much smaller since no firmware and modules taken out of it).

NOTE: In practice, I'd probably modify the above to just put /usr/lib/firmware into 00firstrib_firmware_modules.sfs because modules for Void Linux need to be built into the initramfs and the build_weedog_initramfs05 script needs these modules to be in firstrib_rootfs so best to leave them there... But the above idea should work fine with /usr/lib/firmware

wiak

[seaside]

In my experience, it seems there is a wait of usb device recognition anywhere from one-half second to twenty or more. Instead of having a "usbwait=15", what about a "variable speed" usb device loader....

Here's a modification to the "build_weedog_initramfs" "init" file I've started to use.

On the boot kernel line put "usbwait=0"

Upon boot, a test loop is then entered and checked in .5 second intervals until the "/mnt/${bootpartition}" is mounted.

Changes to "init" -

Code: Select all

#Find below line and comment it out 
# mkdir -p /mnt/${bootpartition} && mount /dev/${bootpartition} /mnt/${bootpartition}

#add this -

mkdir -p /mnt/${bootpartition}

if [ $usbwait -eq 0 ] ; then
echo -e "\e[33mCurrently seeking $bootpartition for slow devices. Please wait patiently...\e[0m"  >/dev/console
while ! mount /dev/${bootpartition} /mnt/${bootpartition} 2>/dev/null; do  sleep .5; done
else 
mount /dev/${bootpartition} /mnt/${bootpartition}
fi

echo -e "\e[32mYes.found and mounted $bootpartition .. now continuing boot process.....\e[0m" >/dev/console

You can put an actual sleep amount or "0" for "variable".

So far, I've just used "usbwait=0" and it's working nicely..

Cheers,
s

[wiak]

In my experience, it seems there is a wait of usb device recognition anywhere from one-half second to twenty or more. Instead of having a "usbwait=15", what about a "variable speed" usb device loader....

Yes, I did actually consider doing pretty much exactly that early on (except I just planned to the increment time idea, not having fixed as an alternative at all), but at that time was keeping the build script very simple and with as few lines as reasonably possible so just adopted a user manual entry for usbwait. However, the script has inevitably increased (a bit...) in size and complexity (whilst still being relatively short, simple to read, modify and understand, so yes, putting that auto-usbwait mechanism in place would probably be fine (and I like the implementation). I'm soon to upload new version because of small 'bug' I mentioned in my post above, so might try that in the latest and see if it works out to everyone's satisfaction.

wiak

[rockedge]

the overall size is not a concern of high priority at this time. Performance although is, and good low CPU loads and temps with actually quite low RAM usage is what I am experiencing.

The ISO I threw together is mainly for experimentation and gaining some knowledge. Running the scripts from a host system like Puppy Linux Bionic which is a great system for this kind of work, is the best way to start a build of WeeDog. Using a plug that is already tested or just modifying one for personal preference because it is easy to do.

But there is the case that someone does not have a host system to start up, and needs some basic system to boot to be the host system. In this case the ISO would be handy, especially since WeeDog can run those scripts very well and why not have a WeeDog that can be host to creating another WeeDog.

I would like to see Grub4Dos run in WeeDog. I am playing around with it, so far no luck.

I am seeing that even if the size of WeeDog is in my case without ZoneMinder and LHMP is as an ISO 1151 megs large but it will run in only 71 megs of RAM after startx activated the X server desktop.

_

[wiak]

I'm not sue what you mean about getting grub4dos to run in WeeDog rockedge. I use grub4dos to boot when making weedog USB bootable.

By the way, seaside, I came across a kernel command line parameter some time ago, rootwait, which sounded relevant but I forgot to look into it. I'm off to sleep now but maybe worth investigating its purpose. Probably I'll set things to not wait indefinitely though, but rather to have a give up timeout in case device faulty.

quai

[rufwoof]

Under voidlinux you can install and use grub bootloader. When managed manually its quite similar except the menu system is under the /boot folder. Syntax is similar/familiar.

[rockedge]

Hello wiak,

I was referring to being able to run Grub4Dos in WeeDog. Would be easy to set up a virtual hdd in VirtualBox for example when running in RAM from a booted CD or ISO. I should get a command line solution working for a simple installer mechanism.

I use Puppy Bionic to do most of the work setting up boot partitions and creating them. But it would be easier if the booted WeeDog could run the Grub4Dos programs, and would be nice to have on board.

[rockedge]

hello rufwoof,
I did install grub but have yet to use it correctly on the VirtualBox virtual HDD

I have to figure out what I am not doing right! Why I suddenly missed starting Grub4Dos.....

[AndresC2]

Hi Wiak

sorry for late post no internet in home

you are right i do not have too much memory ram for such task

anyway i build a script for merge changes in ram with 01-filesystem.squashfs in debian buster:

mkdir -vp /tmp/merge
unionfs-fuse -o nonempty -o allow_root -o cow /run/live/overlay/rw=RW:/run/live/rootfs/01-filesystem.squashfs=RO /tmp/merge

mksquashfs /tmp/merge /lib/live/mount/medium/Buster/live/01-filesystemNEW.squashfs

umount /tmp/merge

work fine for me.

is possible the same in WeeDog?

In debian the 01-filesystem.squashfs is mount in this path:/run/live/rootfs/01-filesystem.squashfs

but where is in weedog?

i try

mkdir -vp /tmp/merge
mkdir -vp /tmp/weedog

mount -o loop /mnt/sdb1/WeeDog/01weedog.sfs /tmp/weedog
unionfs-fuse -o nonempty -o allow_root -o cow /mnt/layers/RAM/upper_changes/rw=RW:/tmp/weedog=RO /tmp/merge

No work it said device or loop0 is busy.

another thing a script in boot like this:

if [ -f /mnt/sdb1/WeeDog/01weedogNEW.sfs ]; then
mv 01weedog.sfs 01weedogOLD.sfs
mv 01weedogNEW 01weedog.sfs
fi

thanks.

EDIT:

Wiak i did it

dpkg-deb -x linux-image-4.19.0-5-686 linux

mkdir -p modules-4.19.0-5-686

cd modules-4.19.0-5-686

mkdir -p usr/lib
ln -s usr/lib lib

cp linux/usr/lib/modules modules-4.19.0-5-686/usr/lib

mksquashfs modules-4.19.0-5-686 02modules-4.19.0-5-686.sfs

i have 01weedog.sfs only 62 mb

02modules-4.19.0-5-686.sfs only 51mb

initramfs05.gz only 51mb

reboot ........

Nice run very fine

this is cool in my case beacause when mksquashfs weedog+modules my cpu overhead but

this way compress much fast not overhead at all.

then merge /mnt/layers/RAM/upper_changes with 01weedog is much easy now.

[rufwoof]

I was looking to build a bespoke kernel with all modules statically inbuilt within the kernel and initrd also integral, so could all be booted with just vmlinuz alone. Compiled a 5.2.18 kernel with localyesconfig, with CONFIG_INITRAMFS_SOURCE set to point to a config file containing

Code: Select all

dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
nod /dev/loop0 644 0 0 b 7 0
dir /bin 755 1000 1000
slink /bin/sh busybox 777 0 0
file /bin/busybox /sbin/busybox 755 0 0
dir /proc 755 0 0
dir /sys 755 0 0
dir /mnt 755 0 0
file /init /mnt/sda1/KERNEL/init.sh 755 0 0

where that init.sh file contains just

Code: Select all

mount -t proc -o nodev,noexec,nosuid proc /proc
mount -t sysfs -o nodev,noexec,nosuid sysfs /sys
mount -t devtmpfs -o mode=0755 none /dev
/bin/sh

... 12MB in size bzImage (vmlinuz) , but didn't boot

[seaside]

By the way, seaside, I came across a kernel command line parameter some time ago, rootwait, which sounded relevant but I forgot to look into it. I'm off to sleep now but maybe worth investigating its purpose. Probably I'll set things to not wait indefinitely though, but rather to have a give up timeout in case device faulty.

quai

wiak,

Good idea to have a timeout.

Perhaps,

Code: Select all

end=$((SECONDS+30)) #before loop
if [ $SECONDS -gt $end ] #then exit loop and abort

Cheers.
s
(I thought there was a "snooze" symbol at the end of your post )

[rufwoof]

Voidlinux cli wifi connecting ...

Code: Select all

Make sure wpa_supplicant is running.
ln -s /etc/sv/wpa_supplicant && sv start wpa_supplicant

Find your wireless interface
ip link

Get connected
wpa_cli -i <wifi_interface>

scan
scan_results
add_network
set_network 0 ssid <mywifi>
set_network 0 psk <mywifipassword>
enable_network 0
save_config
quit

[wiak]

Perhaps,

Code: Select all

end=$((SECONDS+30)) #before loop
if [ $SECONDS -gt $end ] #then exit loop and abort

...
(I thought there was a "snooze" symbol at the end of your post )

Hello seaside,

Yes that would do for timeout (but env variable SECONDS doesn't get set under busybox sh does it?). There is also the 'timeout' command - I'm just out of bed so haven't tested any of this yet. Okay, now tried "SECONDS" and that works fine and makes sure the 30 is additional time, thanks. EDIT: no, SECONDS is indeed a bashism. I'll use something similar.
EDIT2: ok, done. Will upload new weedog script after some further testing.

As for the "snooze" symbol, that's cos was using android phone in bed just before sleeping and it autocorrected 'wiak' I believe...

[wiak]

EDIT:

Wiak i did it

dpkg-deb -x linux-image-4.19.0-5-686 linux

mkdir -p modules-4.19.0-5-686

cd modules-4.19.0-5-686

mkdir -p usr/lib
ln -s usr/lib lib

cp linux/usr/lib/modules modules-4.19.0-5-686/usr/lib

mksquashfs modules-4.19.0-5-686 02modules-4.19.0-5-686.sfs

i have 01weedog.sfs only 62 mb

02modules-4.19.0-5-686.sfs only 51mb

initramfs05.gz only 51mb

reboot ........

Nice run very fine

this is cool in my case beacause when mksquashfs weedog+modules my cpu overhead but

this way compress much fast not overhead at all.

then merge /mnt/layers/RAM/upper_changes with 01weedog is much easy now.

Hello AndresC2,

Sorry, I'm just out of bed but will try to digest later what you are writing about above and comment thereafter. I am out of touch with debian but perhaps what you are saying relates to Void too?

Anyway, glad what you've tried worked for you. Keep posting, it's good to know what you are up to and I'm interested in minimising whatever can be done for limited hardware. If things can be put into one of the rdsh plugin facilities that would be particularly interesting and good since don't want to break the core script initramfs/init code whilst it is more generally working fine.

Cheers

wiak

[wiak]

... 12MB in size bzImage (vmlinuz) , but didn't boot

Nice if it did

re: wifi connecting under Void. I'll try the recipe, thanks.

wiak

[wiak]

Fixed earlier notified tiny bug in build_weedog_initramfs05 script and whilst doing that took time to slightly modify a few things (including implementation of seaside recommendation). I'll be uploading it later, but because I've slightly reorganised the rdsh code, I want to do some more testing prior to version release/upload, so upload might be later today or tomorrow.

Nothing major.

wiak

[wiak]

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

http://www.murga-linux.com/puppy/viewto ... 24#1035524

CHANGES

# Revision 2.0.4 Date: 03 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.

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.

wiak

[rufwoof]

I've been looking at ways to implement storing the 01firstrib_rootfs.sfs along with 02changes.sfs and any plugins within a ext3 file filesystem that's potentially stored on a ntfs/fat partition, with vmlinuz and initramfs on a boot usb. Will have to grab the newer version now!

[seaside]

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

http://www.murga-linux.com/puppy/viewto ... 24#1035524

CHANGES

# Revision 2.0.4 Date: 03 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

Wiak,

Nice implementation - if no "usbwait" on the commandline, try to mount for 15 seconds, then abort. This will allow most usb devices time enough, and for the really slow ones an actual "usbwait=(above 15)" time is available. Other devices load immediately.

I think "snoozing" agrees with you....

Regards and thanks,
s

[rufwoof]

I had a rdsh1 kernel boot parameter specified as I have a rdsh1.plug that I want run at each boot (I do md5sum checks on the main and changes sfs files stored on hdd as a intrusion detection measure). I did a build with the new script and removed the rdsh1 kernel boot parameter (as it now auto-detects and runs .plug's) and to my surprise at bootup it stops at a cli asking to 'exit to continue' and when I run 'exit' only then is my rdsh1.plug sourced file actually run. I had expected it to just automatically run, without having to 'exit' from the initramfs cli. Yes if rdsh1 is specified as a kernel boot parameter only then would have expected that drop to shell behaviour. ??? My misunderstanding of the newer design perhaps ???

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: Select all

_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"