RC7 (STABLE) WeeDogLinux Arch 64 now released

A home for all kinds of Puppy related projects
Message
Author
User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#221 Post by rufwoof »

wiak wrote:You could also make 01firstrib_rootfs an empty directory, and use actual firstrib_rootfs renamed to upper_changes, but after some time rename upper_changes to say 50upper_changes (so it automatically gets used on next boot as one of the middle layers) and then the new auto-generated upper_changes will be small each time you want to keep it as a backup (or use later as say 51upper_changes and so on, though can always later merge them all together again).
The flexibility is great wiak :)

I've been messing around modifying the init script to instead use chroot of the main system, as that way I can exit-chroot back out of that (back into initrd). Also set it so it runs totally in ram, with the initram sfs inside initrd.

Pauses at a initrd shell at bootup (prior to the chroot), so you can tweak the 'save' area as desired. And later you can exit-chroot (I've compiled that myself) to copy/store the save area as desired for later reboots.

That's one hell of a void modules list, impressed how you managed to figure that all out!

void seem to change many things often, so installing one day, adding things another does involve syncing prior to adding (xbps-install -S) i.e. potentially a new kernel and other majors so the less in the base system the better IMO. Would be nice to have a stable/unchanging version as from personal experiences sooner or later a current 'snapshot' will fail or have issues that cause downtime. One of the risks of a continually and active rolling release. Could I guess create my own local repo snapshot (static void :)), perhaps even locally compiled, and refresh that periodically (perhaps 6 monthly).

Code: Select all

#!/bin/sh

###############################################
# /init (inside initrd)

# Based on original initramfs/init(04) by wiak 26 July 2019
# Simple chroot_root init with overlay filesystem set up.
# Copyright ; Licence MIT (aka X11 license)
# Rufwoof 2 Aug 2019
###############################################


_dmesg_quiet() {
	dmesg -n 1  # Show only emergency (panic) messages
}


_mount_proc_sys_dev() {
	# mount kernel required virtual filesystems and populate /dev
	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
}


_load_modules_for_void_linux() {
	# Modules need loaded by initramfs when using kernel from Void Linux
	for m in mbcache aufs exportfs ext4 fat vfat fuse isofs nls_cp437 \
         nls_iso8859-1 nls_utf8 reiserfs squashfs xfs libata ahci \
         libahci sata_sil24 pdc_adma sata_qstor sata_sx4 ata_piix \
         sata_mv sata_nv sata_promise sata_sil sata_sis sata_svw \
         sata_uli sata_via sata_vsc pata_ali pata_amd pata_artop \
         pata_atiixp pata_atp867x pata_cmd64x pata_cs5520 pata_cs5530 \
         pata_cs5535 pata_cs5536 pata_efar pata_hpt366 pata_hpt37x \
         pata_it8213 pata_it821x pata_jmicron pata_marvell pata_netcell \
         pata_ns87415 pata_oldpiix pata_pdc2027x pata_pdc202xx_old pata_rdc \
         pata_sc1200 pata_sch pata_serverworks pata_sil680 pata_sis \
         pata_triflex pata_via pata_isapnp pata_mpiix pata_ns87410 pata_opti \
         pata_rz1000 ata_generic loop cdrom hid hid_generic usbhid mptscsih \
         mptspi mptsas tifm_core cb710 mmc_block mmc_core sdhci sdhci-pci \
         wbsd tifm_sd cb710-mmc via-sdmmc vub300 sdhci-pltfm scsi_mod \
         scsi_transport_spi scsi_transport_sas sd_mod sr_mod usb-common \
         usbcore ehci-hcd ehci-pci ohci-hcd uhci-hcd xhci-hcd usb-storage xts
	do
		modprobe $m 2>/dev/null
	done
}


_usbwait() {
	# usbwait for slow devices
	echo "usbwait for slow devices. Please wait patiently..." >/dev/console
	usbwait=`egrep -o "usbwait=[^ ]+" /proc/cmdline | cut -d= -f2`  
	[ "$usbwait" ] && sleep $usbwait
}


_setup_chroot_folders() {
	mkdir /CHR
	cd /CHR
	mkdir merged upper_changes work lower
}


_mount_sfs() {
	mount /01firstrib_rootfs.sfs /CHR/lower
}


_load_modules_for_overlay() {
	# Load module to allow overlay filesystem functionality
	modprobe overlay && umount /usr/lib/modules 2>/dev/null  
	sync
}


_mount_overlay() {
	# Combine the overlays with result in /CHR/merged
	mount -t overlay -o lowerdir=/CHR/lower,upperdir=/CHR/upper_changes,workdir=/CHR/work overlay /CHR/merged
}


_move_mounts() {
	mount -o move /sys /CHR/merged/sys
	mount -o move /dev /CHR/merged/dev
	mount -o move /proc /CHR/merged/proc
}


_cleanup_modules() {
	# Remove unused modules to save memory
	modprobe -r `lsmod | cut -d' ' -f1` 2>/dev/null  
}


_sub_void() {
	echo "You are now in init ramdisk - sub void level"
	echo "when done making tweaks exit this shell to continue booting void"
	setsid cttyhack /bin/sh	
}


_chroot() {
	exec chroot /CHR/merged /sbin/init
}

###############################################

_dmesg_quiet
_mount_proc_sys_dev
_load_modules_for_void_linux
_usbwait
_setup_chroot_folders
_mount_sfs
_load_modules_for_overlay
_mount_overlay
_move_mounts
_cleanup_modules
_sub_void
_chroot
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#222 Post by wiak »

rufwoof wrote: The flexibility is great wiak :)

I've been messing around modifying the init script to instead use chroot of the main system, as that way I can exit-chroot back out of that (back into initrd). Also set it so it runs totally in ram, with the initram sfs inside initrd.

Pauses at a initrd shell at bootup (prior to the chroot), so you can tweak the 'save' area as desired. And later you can exit-chroot (I've compiled that myself) to copy/store the save area as desired for later reboots.

That's one hell of a void modules list, impressed how you managed to figure that all out!

Hi rufwoof

I do similar when I'm debugging. For example, I insert debug calls to /bin/sh just prior to the overlay being mounted or the switch_root. That's my usual procedure when I get the dreaded kernel panic during boot or the overlay not merging the way I intended it to!

I did consider putting the various init stages into small functions but I decided for now against that in the release version since the script is so short and easy to just read as a single page, but that is perhaps a matter of general preference.

Actually, for my own uses, I normally also prefer to reorganize scripts like that into function parts, especially for very large complex scripts (indeed long time back, whilst implementing SD booting for DebianDog Porteus boot, I re-organised DebianDog's frugal install scripts (by I think sunburst - Terry - or maybe Fred) into functions rather than the one long script it was. However, I hope to keep the init version used in my main build initramfs script as short/simple code as possible so, for now at least, keeping functions out of it.

Having said that, I absolutely encourage users to modify all these scripts for their own purposes: there is so much functionality that can be added (or taken away) depending on needs and preferences. Indeed I intending making init generation an optional "plugin" (as I have done for build rootfs contents (firstrib00.plug) and for modules processing code in build initramfs script. I also intended adding similar optional plugin for the init script build too a couple of revisions ago but became distracted simply trying to get everything working... I will add that to next release (just a simple if plugin available use it line of code else if not supplied script will use the 'simple' one internally provided). That way we can collect various people's init versions as an active flexible ever-being-developed resource (if okay with you, I'll include your modified init as the first optional init plugin). I'm hoping some will eventually also provide their firstrib00.plug creations which document/automate how there rootfs was built so can easily be duplicated.

EDIT: Of course you can also use the already provided modify_initramfs scripts (e.g. modify_initramfs_gz.sh) to uncompress existing initramfs04.gz and then place your own init inside before allowing the modify script to continue and rebuild the initramfs04.gz. That's something I also use a lot when debugging/creating new revisions.

By the way, you can restrict Void packages from being updated:

https://www.reddit.com/r/voidlinux/comm ... g_updated/

wiak

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#223 Post by rufwoof »

In fatdog there are kernel boot parameters of early-shell and late-shell included as standard, so to drop to a cli you just add one of those in interactively as you boot (menu.lst) and you'll be dropped to shell at the relevant/associated point.

Yeah showing too many functions I know, but the mount_proc_sys_dev, usbwait, dmesg move_mounts, cleanup_modules and even the mount_overlay and setup_chroot_folders functions could more generally be in a common 'include' (sourced) file of 'useful collections of functions' (. functions.sh) rather than being coded in the script. Having many short snippets of code/script within the single functions.sh file helps avoid having to dig around to re-do the same code elsewhere at a later date. I'm even tending to do that with my calendar/diary nowadays. Keep it all in a single text file so portable, easily searched, easy to 'postpone' (cut/paste) current days events to a later date. Just archive older history periodically by cutting that out of the current and append it to the historic archive file. Lots of things in the same file/folder makes for quicker/easier searching. And if kept on a server (encrypted) then that transfers the responsibility of backups/restores.

Somewhat the same for word processing. I used to use Libre quite a bit, but nowadays I tend to just use a text editor to focus upon the text rather than the layout, and then later return to focus upon the layout not the words (format/layout) which often I can still do in a text editor (add html tags). Display/print to pdf and done.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#224 Post by wiak »

rufwoof wrote:In fatdog there are kernel boot parameters of early-shell and late-shell included as standard, so to drop to a cli you just add one of those in interactively as you boot (menu.lst) and you'll be dropped to shell at the relevant/associated point.
That's a good idea. I do process boot params in the initramfs/init so could easily add that.

The big modules list, by the way, is from DD's Porteus boot initrd, so no thoughts required on my part. I knew about it because of adding SD support to that long time back.

wiak

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#225 Post by rufwoof »

Added a wrapper script ... so a one click start to finish build.

512MB final size using high compression. That's with /var/cache/xbps content being cleared.

xbps installing ...

linux4.19
linux-firmware-network
wifi-firmware
openssh
xorg
linux-firmware
tilda (instead of xterm)
util-linux
alsa-utils
pulseaudio
pavucontrol
ncurses-base
xinit
xf86-video-amdgpu
jwm
chromium

... so massive amounts of firmware (portable), accounts for around 300MB of that 512MB I guess.

Actually builds in minutes, but with the high compression that extends it out to a 30 minute build time.

I've tweaked my init script to also do a basic build/activation of sound, network connection etc. (very few changes actually needed).

All booted from usb, runs in ram, disconnect usb once booted. void linux kernel and packages are great.

Image

Great job wiak. Thanks.

EDIT: 8m 30s built time if use -comp lz4 (770MB filesize, that boots ok on my 4GB with no swap hardware).

Using lz4 -Xhc (slower to compress, no impact upon decompress) 700MB filesize.

Stripping out all /usr/share/locales ...except for en and en_GB and lz4 -Xhc = 670MB
Last edited by rufwoof on Sat 03 Aug 2019, 23:27, edited 3 times in total.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

build_firstrib_initramfs04_004.sh (Revision 0.0.4) uploaded

#226 Post by wiak »

build_firstrib_initramfs04_004.sh (i.e. Revision 0.0.4) uploaded to first post of this thread:

http://www.murga-linux.com/puppy/viewto ... 56#1028956

Changes:

Code: Select all

if any of rdsh0 and/or rdsh1 rdsh2 rdsh3 are specified on grub linux/kernel line the init looks for file 
/mnt/bootpartition/bootdirectory/rdshN.plug
and sources that if not empty. Otherwise it runs busybox job control shell at rdshN code position in initramfs/init script.
You should view the contents of build_firstrib_initramfs04_004.sh to see the four positions in the initramfs/init code where a plugin can be sourced (or a busybox job control debug shell started).

wiak

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#227 Post by rockedge »

hello.. I only had the one time experience that after I ran the scripts...with no modifications, that after I booted, xbps-install was completely missing. I deleted everything and started fresh with build_firstrib_initramfs04_s003.sh. Which works nicely and booted cleanly.

on a system built with build_firstrib_initramfs01_ver008pre.sh All the computers network devices including wlan was found and I could immediately connect to the network.

I am about to run the latest version and attempt some experiments.

I have ZoneMInder, Hiawatha 10.9, mariaDB,PHP 7.3.7 running fully functional, on both a 32 and 64 bit versions. They start without xorg running and come in at 17 megs. With Xorg, ZM and LHMP running and 3 cameras configured no motion detection enabled, RAM usage is around 750 megs. With no Xorg running WeeDog is running ZM in 175 megs of RAM. Also these builds use the Puppy Linux Bionic kernels.

I am going to go ahead and use the build_firstrib_initramfs04_s004.sh to construct an OS and will continue to experiment. Also want to use the Void kernel with a ZM setup to check the performance.

over all fantastic results....very stable very responsive cool CPU temps in all the working variants so far

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#228 Post by rufwoof »

rockedge wrote:over all fantastic results....very stable very responsive cool CPU temps in all the working variants so far
Ditto. For me the temperatures are comparable, as is glxgears (to get glxgears however its not mesa-utils but mesa-demos (xbps-install mesa-demos ... then run glxgears). The repos are great, for instance under Fatdog tilda is a old version, not so with Void.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#229 Post by wiak »

rufwoof wrote:massive amounts of firmware (portable), accounts for around 300MB of that 512MB I guess.
Yes, that's the main reason why, currently, the hard drive storage used by the system is comparatively large [also Void leaves many/most of its libs unstripped], which is fine by me. For those who want to create a small iso, it will of course be nice to provide a script that strips things down to say Puppy size. That won't be hard to do, I've already experimented doing so with the large number of modules Void by default provides.

I don't have a refined script for that purpose yet, but the method is simple enough, even in bash. A method that works is to use find command on say BionicPup /lib/firmware to generate a recursive txt listing of all the (relatively small amount of) firmware provided there (find command output redirected to say text file Bionic_firmwarelist). Then do the same to generate a similar list for what Void provides in its /usr/lib/firmware (say to Void_firmwarelist). Finally you cut out only the equivalent firmware of BionicPup from what Void offers; in bash the comm utility is excellent for that. Note that comm requires the input files, Void_firmwarelist and Bionic_firmwarelist to be sorted (i.e. using sort) before the comparison:

Code: Select all

comm -23 /tmp/firstrib/sorted_Void_firmwarelist /tmp/firstrib/sorted_Bionic_firmwarelist | xargs rm -rf
https://linux.die.net/man/1/comm

The same algorithm useful for lots of similar purposes (e.g. I originally used it for pruning modules whilst building a much smaller initramfs04).

Here was me generating all_modules list of Void /usr/lib/modules:

Code: Select all

cd ../VoidFull/usr/lib/modules/* && find . | sort>/tmp/firstrib/all_modules
Of course you have to be careful using a script contructed with xargs rm -rf ... but it worked fine for me and safe enough (as long as you get the script correct... or include some protection code) since only used as a one-off prune job.

@rockedge: Once things settle down I hope you could consider working on a firstrib00.plug and/or any extra addon sfs to get your Zoneminder configuration/compile published (or even a final iso). It sounds really good.

wiak
Last edited by wiak on Sun 04 Aug 2019, 01:21, edited 1 time in total.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#230 Post by rufwoof »

Boots/runs on the wide range of kit I've tried so far, so not really bothered about the main system having all that firmware. Fine with me also. Modestly longer usb based bootup time isn't really a concern for me.
Attachments
s.png
(27.12 KiB) Downloaded 753 times
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#231 Post by rockedge »

noticed after I modified /etc/rc.local

Code: Select all

# Default rc.local for void; add your custom commands here.
#
# This is run by runit in stage 2 before the services are executed
# (see /etc/runit/2).
/root/my-applications/start_net
startx
at boot WeeDog will put the machine into a desktop, jwm and rox -p default which all starts.
the system is running with out being logged in! whoami reports "root" and I can do everything and setup the desktop and add icons. When I click on rox "home" rox opens in /...reboot and they are there and all works.
I have an xterm terminal start with from /ect/X11/init/initrc that when I use exit will shut down the Xorg server and return to the command line AND the void-linux logon prompt.

Now I use "root" and the correct password and once on the system use startx and xorg starts right up but in now a different desktop. rox-filer opens up in /root all rhe previous setup is gone. So I can set this destop up just fine.

Then reboot -f the system and restart it......the system repeats the first step above and starts in the first desktop I configured and rox-filer opens /...everything is there.....I exit then void-login again, use startx .....the 2nd "root" desktop comes up also still completely configured and rox-filer now starts in /root......

kind of cool actually....it's like the commands in /etc/rc.local circumvents the login procedure.........

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#232 Post by rufwoof »

From wiak's script comments ...
# The switch_root runs /sbin/init on real rootfilesystem, which actually (ultimately) symlinks to busybox (sysv)init and executes it as PID 1. That busybox init reads file /etc/inittab, which configures init to run boot startup script, which is currently configured to be: /etc/rc.d/rc.sysinit. Should runit-void later be installed, /sbin/init should instead be symlinked to /usr/bin/runit-init, in which case /etc/rc.d/rc.sysinit will not be used.
runit is neat ..
http://www.troubleshooters.com/linux/vo ... .htm#runit
when you hear systemd enthusiasts remarking how systemd frees them from all these gruesome init scripts, remember they're talking about the first-seen-in-1983 sysvinit system, not the 2004-invented runit system. It's like a 20 year old runner bragging that he beat a 75 year old man: The systemd enthusiasts should stop doing this because it really makes them look bad.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#233 Post by wiak »

rockedge wrote:noticed after I modified /etc/rc.local
...

kind of cool actually....it's like the commands in /etc/rc.local circumvents the login procedure.........
Hmmm... Just wondering if your system has runit installed rockedge or is it using busybox init which through inittab runs rc.sysinit? The reason I'm asking is that I noticed a while back that in rc.sysinit I had put running rc.local script what seemed to me to be too early (prior to udev being run). I meant to change that but forgot about it till I just read your post.

However, if your system is using runit then rc.sysinit isn't being used anyway... so whatever effect you are observing presumably is to do with the way void runit is starting things. I'm not quite sure what you are describing but it sounds a bit weird - I would have imagined login/passwd would have always been requested. ??? Anyway, it may or may not be a small bug that will need addressed.

@rufwoof: Yes, once I read how to use it... I have to say runit is great.

wiak

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#234 Post by rockedge »

the root user ends up having 2 separate desktops!

I automated starting JWM and ROX by adding those lines to /etc/rc.local
the system boots perfectly starts both and I am in a desktop that belongs to "root". Everything functions. And no login required.

now I exit the desktop, shutdown xorg and return to the shell...which now is
"void-login:", which I now login as root using the password I have set earlier.
Then I restart xorg with "startx" and now I am in a completely different desktop. rox -p default starts and I have a "home" folder icon...I click this now and rox-filer opens up in /root........the first desktop that starts at the first boot will open "/"......

so there is 2 different desktops both belong to "root". the first only appears at the first system start with the automated start of xorg via startx in /etc/rc.local. If I exit out of it I now must login at the shell prompt...which after a startx presents and entirely different desktop...also belonging to root.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#235 Post by wiak »

rockedge wrote:the root user ends up having 2 separate desktops!

I automated starting JWM and ROX by adding those lines to /etc/rc.local
the system boots perfectly starts both and I am in a desktop that belongs to "root". Everything functions. And no login required.

now I exit the desktop, shutdown xorg and return to the shell...which now is
"void-login:", which I now login as root using the password I have set earlier.
Is that with runit installed rockedge?

Oh, I think I understand. First time up you are starting X via rc.local, second time you drop to login shell, which starts X via "startx", which involves a different desktop. Yes, that's interesting! EDIT: On second thoughts, no I don't know what is going on there!

wiak

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#236 Post by rockedge »

Oh, I think I understand. First time up you are starting X via rc.local, second time you drop to login shell, which starts X via "startx", which involves a different desktop.
Yes, exactly. You can try it by adding "startx" to /etc/rc.local, then reboot....do something then exit X and you will come to the void-login: shell. Then login as "root" and use startx again

I just repeated it on a brand new 64 bit version

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#237 Post by wiak »

Hi rockedge,

I don't have X installed on my WeeDog at the moment since just working on lower down init matters.

I note startx script header says:

Code: Select all

#!/bin/sh

#
# This is just a sample implementation of a slightly less primitive
# interface than xinit. It looks for user .xinitrc and .xserverrc
# files, then system xinitrc and xserverrc files, else lets xinit choose
# its default. The system xinitrc should probably do things like check
# for .Xresources files and merge them in, start up a window manager,
# and pop a clock and several xterms.
I imagine that when you actually login as root, startx will find a .xinitrc file in /root, which will contain code to set things up in a certain way, whereas when you just startx from rc.local, bypassing login, then you are not in /root directory and startx does not find any ./xinitrc file, so things will be set up differently. But as I say, I can't check that just now, so just a guess really. It is interesting that doing startx from rc.local allows you to bypass login; that wouldn't be the usual method of doing so (usually done when agetty starting with "-a/--autologin root" option).

wiak

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#238 Post by wiak »

I don't want to add much more to initramfs04/init since I want to keep it simple and as unbloated as possible.

However, I am currently working on providing a [EDIT] 'changes' in RAM only mode, which is no-persistence mode (but can, if wished, usefully use previous upper_changes directory, by simply renaming that to NNupper_changes, for example 90upper_changes as one of the read-only middle layers. Note that I am not myself interested in a copy2ram mode (sfs copying to RAM), which simply uses too much RAM with little end-benefit in my opinion; Linux does a pretty good job of caching anyway...

At the same time, I'm also implementing a read-only mode, in which the merged overlay result is entirely read-only (so cannot be written to) - that mode is good for making remasters.

And also a mode that allows the upper_changes directory to be stored anywhere (rather than default /mnt/bootpartition/bootdir).

The additional code for these particular alternatives is very simple and if no new mode is specified on grub linux/kernel line then default current /mnt/bootpartition/bootdir/upper_changes will continue to be used.

As far as any more complex possible modes are concerned, which generally would require a substantial amount of additional code, these I feel should only be made available (if at all) as plugins to the relatively straightforward to understand Firstrib initramfs04/init provided. For example, using grub kernel line option rdsh1, results in initramfs/init searching for plugin rdsh1.plug and, if found, sources that plugin code quite early in the provided initramfs/init and effectively thus allows plugging in additional init code of any desired complexity/functionality without having to uncompress and then edit the initramfs cpio archive (though that is also easy to do with modify_initramfs_gz.sh utility of course).

That follows my original design aim/philosophy of what FirstRib is all about. It was intended to be a very flexible user-modifiable build system, designed on purpose as a couple of short simple shell scripts. It is not intended to provide an all-singing/all-dancing desktop user system as its default out-of-the-box build (and is thus very unlike the Puppy woof-CE build system). But I believe that, with FirstRib build system, you do not need to be some kind of Linux guru to relatively easily build a system of whatever complexity you desire; rather, FirstRib WeeDog leverages the power provided by Void Linux native package manager xbps, and not just its repositories (and thus, without user-effort, provides full access to all Void Linux system components/configuration including runit)

One plugin possibility, however:

In terms of flexibility, low-resource-usage, speed and efficiency, I have longterm/years been somewhat a fan of the way tinycore linux saves changes on shutdown via its .filetool.lst and .xfiletool.lst lists, which simply instruct the system what to archive in a tar.gz archive (which then gets untarred on reboot). That is an alternative to merging overlays (which often requires dealing with overlayfs whiteouts and so on) and I may eventually try to implement that tinycore linux mechanism in a plugin for the initramfs, though generally speaking I don't really need that extra myself.

I'm actually planning to soon move to WeeDog as my main desktop system; not because I will have built up a version for my own use that is polished up to the standard of say the XenialDog system I generally use (by fredx181), but because I really like xbps package manager and Void system with runit generally. I already feel I've personally learned/benefited a lot from it so using it daily will certainly strengthen my familiarity with it. Also, owing to the simple KISS nature of FirstRib WeeDog, and thanks to Void Linux rolling release system, I'm confident now that I can keep my WeeDog system updated (whatever shape it takes), without having to rely on the often unlikely iso-upgrades of other distro builds by their developer/creators. No reason iso's couldn't be built however, or simple scripts written for such purpose - I may or may not do any of that, but I think others are more likely to produce more polished WeeDog versions than I will anyway!

wiak
Last edited by wiak on Wed 07 Aug 2019, 21:44, edited 2 times in total.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#239 Post by rufwoof »

wiak wrote:However, I am currently working on providing a run in RAM only mode, which is no-persistence mode (but can, if wished, usefully use previous upper_changes directory, by simply renaming that to NNupper_changes, for example 90upper_changes as one of the read-only middle layers. Note that I am not myself interested in a copy2ram mode (sfs copying to RAM), which simply uses too much RAM with little end-benefit in my opinion
Physical isolation (boot from usb, unplug usb once booted) is a great feature IMO. On my 4GB ram laptop, using the wrapper build script I mentioned in a earlier post - so its a single click action to build (vmlinuz/kernel, system with X, chrome, pulseaudio ..etc.) when using lz4 compression is around a 8 minute build time. A quick build time to the latest clean kernel and OS (rolling Void releases) is another great feature. I have seen some issues however, for instance running gparted complains about gparted.bin already being loaded (looks like the script does a grep for gparted and finds a 'grep gparted' return and bombs out; Run gpartedbin directly and it starts up OK). Seeing rockedge's posts got me wondering if perhaps two versions of the system were running concurrently, one via runit and another via init.
Last edited by rufwoof on Tue 06 Aug 2019, 16:51, edited 2 times in total.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#240 Post by rockedge »

the scripts are showing amazing potential! there is so much room for choice. The ability to make the OS as simple or as fully featured as one needs or wants is well thought out.

I will share some plugin files and perhaps a script to install zoneminder...
I really would like to create a Void package for it......
At least I think that's the case, seeing rockedge's posts got me wondering if perhaps two versions of the system were running concurrently, one via runit and another via init).
I believe this may be the case!


_

Post Reply