RC7 (STABLE) WeeDogLinux Arch 64 now released

[rufwoof]

my system with an internal HDD assigns the HDD always as /sda1 and the usb HDD I boot from is /sdb1...but if there is another usb drive attached then it is which usb device spools up quickest that gets assigned to sdb1 and not /sdc1. I try to use UUID which prevents the mix up in case of the 2 or more usb drives attached scenario

Booting fine from hdd frugal, but using the same setup on usb and no luck. Tried bootfrom=/dev/disk/by-label/usb3 (where the usb stick has been set to have a label of 'usb3'), but looks like udev isn't up/running by that time so it crashes.

[rufwoof]

rufwoof I really like your xlunch version! I have also played with just using jwm and xlunch and mc for the desktop.

Void of any tray etc. is nice. One quirk though is if you've chromium full screen (F11), stepping between tabs (ctrl-tab), add new tab (ctrl-t) ...etc. all works fine. But launching xlunch (bottom left hot corner) doesn't show. You have to activate skippy (top left corner) and then click on the xlunch window to see it. However that's only a issue if you want to stay in full screen chromium. Normal display (F11 to toggle off) and it all works fine. Alt-tab is also the other way to step between windows.

jwm is nicer that cwm as title bars for dragging smaller windows (galculator etc.) and resizing via the corners is better IMO than ctrl or alt + mouse type controls.

Once you get used to no tray and switching between full screens it does make other desktops look letter-box. Nice for mostly mouse/touchpad also, and with tilda terminal (cli) just a F1 press away and also full screened (with multiple tabs) its a great combination IMO. Some/many however seem to like zooming/restoring frames/windows (visible on the same screen at the same time).

As I mentioned before, skippy-xd and xlunch work very well under voidlinux, the best I've seen.

[rufwoof]

Despite moderate use, all running in ram/swap with chromium playing a youtube etc. the cpu temps are lower than on other systems running much the same. Around 66 deg versus 70 deg when moderate/heavy loaded.

Nice feature with the later tilda is they've adjusted it to start from 1 rather than 0. I used to tweak that manually as alt-1 for the first tab ...etc. is just more intuitive/natural

[rufwoof]

Attached is my most recent firstrib00.plug (a actual gzip'd version)

root password set to 'letmein'
user password set to 'invalid'

Also creates some scripts such as /usr/local/bin/weather and /usr/local/bin/temp that would probably need tweaking for your own hardware/desires.

You'll also need to change the NETWORK settings, for your own ssid/password if using wireless (or be extended/changed if you connect via hard wired/ethernet).

Pretty much configures for a comfortable 1366x768 laptop screen sized resolution.

Likely the last one I'll post as from here it will evolve to be much more specific for me version (ssh keys and encryption, data links etc.)

[wiak]

Question : what do you set the bootfrom kernel boot parameter to when booting from usb?

Frugal booting as I have been from hdd and /dev/sda1 is consistently /dev/sda1 when no usb's are also attached at bootup. But when a usb is plugged in at bootup then its a (kernel based) lottery as to whether the usb will be assigned to /dev/sda1 and the hdd assigned /dev/sdb1 or the other way around (usb assigned /dev/sdb1 and hdd assigned /dev/sda1).

I've never had an issue on my machines using what my system detects the usb sticks uuid, but I imagine there may be an issue (and clearly there is, from your report, on your setup somehow). But does your set up boot from the usb stick sometimes? Else it should if trying again reversing sda for sdb in bootfrom=value. It may be difficult to duplicate any issue since booting fine all the time here after using both build scripts and any combination of options.

title FirstRib
uuid beda5956-551f-429d-8f42-6d1fd1ad13ac
kernel /firstrib5/vmlinuz usbwait=12 bootfrom=/mnt/sdb1/firstrib5 changes=RAM copy2ram
initrd /firstrib5/initramfs04.gz

wiak

[rockedge]

thank you rufwoof for the opportunity to give your firstrib.plug a run!

I am about to give it a run, 32 bit and 64 bit.
I also am seeing low cpu temps and the computer overall is cooler somehow. much less noisy as the fans barely run.

I am very pleased with WeeDog's I have built and their overall performance. ZoneMinder runs very stable, with all the bells and whistles. Very low overall base loads there is plenty of room to run multiple cameras and it is a breeze to compile packages from source. WeeDog makes a lean and mean web server with Hiawatha as well.

I will at some point also begin to build WeeDog's more specific to their purpose. I see a great potential here with Void to build an OS that is really tuned for Home Automation of Smart Home and camera security systems. Especially designed to run on less powerful, older computers tailored to fit in 2-4 gigs of RAM single or dual core cpu's. But also some versions ready for really strong computers.

[wiak]

Thanks from me too for your firstrib00.plug rufwoof. Assuming WeeDog systems become at all popular, these plugins will become a major part of its ongoing development since WeeDog default build, when no plugin provided, will always just be a very basic commandline booted system. So the main work from now on, aside from not-particularly-important (but fun and potentially useful) alternative to Void flavours, will be in individual's plugin developments (and I'm no desktop installation/design/config expert whatsoever myself).

wiak

[rufwoof]

title FirstRib
uuid beda5956-551f-429d-8f42-6d1fd1ad13ac
kernel /firstrib5/vmlinuz usbwait=12 bootfrom=/mnt/sdb1/firstrib5 changes=RAM copy2ram
initrd /firstrib5/initramfs04.gz

Thanks wiak

usb3 stick, with grub4dos installed

/VOID folder ... content
bash-5.0# pwd
/mnt/usb/VOID
bash-5.0# ls
01firstrib_rootfs.sfs initramfs04.gz vmlinuz-4.19.67_1
bash-5.0#


menu.lst content

bash-5.0# cat menu.lst
# menu.lst
color white/blue black/cyan white/black cyan/black
#splashimage=/splash.xpm
timeout 15
default 0

###################################
title Void
#find --set-root /usb3.txt
uuid 4ea3148b-9309-42d6-972b-d2723a459c98
kernel /VOID/vmlinuz-4.19.67_1 usbwait=12 bootfrom=/mnt/sda1/VOID changes=ram copy2ram rdsh3
initrd /VOID/initramfs04.gz
###################################


Boots and exits to rd shell (#3) and shows

mount : mounting /dev/ram on /mnt/ram failed: No such file or directory
bootfrom is /mnt/sda1/VOID
mountfrom is /mnt/layers/RAM
lower is 01
upper_work is upperdir=ram/upper_changes,workdir=ram/work,xino=off
mount: mounting overlay_result on merged failed: No such file or directory
mount: mounting /mnt/ram on merged/mnt/ram failed: Invalid argument

Running cat /proc/cmdline indicates ...

usbwait=12 bootfrom=/mnt/sda1/VOID changes=ram copy2ram rdsh3

On exit from the rd shell it crashes.

No matter, not a necessity for me, and a long day with too much tipple/drink. Fresh eyes another day will likely reveal a stupid oversight somewhere

[wiak]

Boots and exits to rd shell (#3) and shows

mount : mounting /dev/ram on /mnt/ram failed: No such file or directory
bootfrom is /mnt/sda1/VOID
mountfrom is /mnt/layers/RAM
lower is 01
upper_work is upperdir=ram/upper_changes,workdir=ram/work,xino=off
mount: mounting overlay_result on merged failed: No such file or directory
mount: mounting /mnt/ram on merged/mnt/ram failed: Invalid argument

EDIT: odd thing is I don't use any folder called /mnt/ram. RAM layer gets mounted to /mnt/layers/RAM (which after the mount overlay should be seen at merged/mnt/layers/RAM).

Yes, it will crash since the overlay to merged isn't working according to the above. I've seen these kind of messages - one reason can simply be that overlay module not being found and loaded. Since booting from hard drive okay, it must be already be there in your firstrib_rootfs/usr/lib/modules, so that can't be the issue. So it does look like some part isn't being found and mounted ... hmmm... tricky without having the same setup and hardware.

Does lsmod look okay (at that rdsh3 break point)?

I'd put rdsh0 rdsh1 rdsh2 rdsh3 all on the menu.list kernel line and then boot and at each stage check lsmod output, and also mount command output, and even df -h output, to see if can figure out what isn't being seen/mounted when needed. The set command run on its own should show bootfrom content (since that gets exported by these newer kernels), though your /proc/cmdline looks fine anyway.

My machine doesn't have usb3, so maybe it could be a module load issue (some other module needing loading in the long list) that I don't know about. If the modprobe -r command is stripping out something, that can be suppressed simply by making a blank file called modules_remove.plug in the bootfrom location (i.e. next to vmlinuz etc).

The rdsh1 shell break is the one that comes just prior to the overlay being mounted (so everything that mount overlay line needs has to be ready and correct at that point - mounts/overlay module etc). rdsh2 break comes immediately after the mount overlay should have worked (but clearly didn't or /mnt/layers/merged would hold the overlay result).

Time will tell I'm sure, especially if we get sufficient testers who are using different hardware - I'll try your firstrib00.plug build on my partners machine (which is pretty new so must have usb3 I guess - though I don't know anything about booting from new machines that boot with UEFI etc - my own machines are all old so I've never bothered looking into that.

I may put the WeeDog Debuntu flavour aside for the moment, since that was just my curiousity in action (tho nice to know I have working scripts for later publishing that). I really want to finish zram additions/capabilities and sort out any existing issues with what we have.

wiak

[rufwoof]

Seems to be due to the changes=ram boot parameter, without that it boots OK. Suspecting its the mount -o mode=1777,nosuid,nodev,size=xxx tweak combined with a borderline size of my build (chromium, libreoffice etc.). Currently I've cpio extracted and changed init to exclude the size=xxx and I'm reforming the sfs using xz compression to see if that squeezes in. Suspecting some form of boundary/buffer overrun that is avoided when hdd frugal booted but that gets hit when booted via usb3. But that's just a guess. If so, perhaps using zram and suchlike could be inclined to potentially introduce difficult to identify/resolve issues (something to be wary of).

[wiak]

Seems to be due to the changes=ram boot parameter, without that it boots OK. Suspecting its the mount -o mode=1777,nosuid,nodev,size=xxx tweak combined with a borderline size of my build (chromium, libreoffice etc.). Currently I've cpio extracted and changed init to exclude the size=xxx and I'm reforming the sfs using xz compression to see if that squeezes in. Suspecting some form of boundary/buffer overrun that is avoided when hdd frugal booted but that gets hit when booted via usb3. But that's just a guess. If so, perhaps using zram and suchlike could be inclined to potentially introduce difficult to identify/resolve issues (something to be wary of).

Yes, could be. There are so many things that can have unexpected effects. There are certainly limiting factors with the likes of copy2ram, and for simplicity the (default) scripts purposively include no complex logic bound checkings of any sort (though users are encouraged to tweak these accordingly). The zram additions will increase the possibilities of such issues for sure, but, then again, these additions will all be no more than optional (and sometimes such additions may actually help with issues). We make what we can of it.

On the otherhand, sometimes the reason for a bug is straighforward and staring us in the face but takes us a while to see and understand it.

wiak

[wiak]

You can surely imagine, that I've had many a kernel panic or failing to boot generally situation whilst working on the initram script. And not easy to debug when things simply crashing out as they do... However, thus far, I've always found fix or workaround (and often it was simpler than I imagined - something simple I just overlooked). It is not easy always, but certainly not rocket-science - all pretty simply stuff really, once I get over the pain of kernel crashes and the frustrations of trying to get things to boot as I hoped (in theory) they should! Buffer/cache/fs-size issues - minor matters to fix really - the difficulty being pinning down what is really causing the problem in the first case. Admittedly, all going well on my machine so hard to fix anything not yet needing fixed. But once I experiment more and build bigger systems on it no doubt I will find some issues that need resolved - but I have the attitude taught to me in my younger days when I was an electronics development engineer - my boss said to me "of course you can fix it, you are an engineer" and I agree with that mantra.

wiak

[wiak]

Seems to be due to the changes=ram boot parameter, without that it boots OK. Suspecting its the mount -o mode=1777,nosuid,nodev,size=xxx tweak combined with a borderline size of my build (chromium, libreoffice etc.)

But I still wonder if the issue could be to do with usb3, were it not for your comment here. The list of modules I included in the initramfs was taken from my old XenialDog set, and that's pretty old so some relevant device modules may well be missing for newer hardware (no problem for me with my old junk!). That would be a trivial issue to address really (I don't mean send me new junk... well come to think of it...). Will sort it out eventually. I'll see what latest official Porteus itself is using, or if they are using mainly builtin drivers for booting, I'll check Debian/live/Linux_live_kit (never looked at that project as yet - didn't want my own creative attempts influenced...!) initrd as a starter.

Come to think of it, checking out official Void initramfs would be even better, but I have a feeling they may do it in more sophisticated way; simple loading a whole pile of possible modules in a big loop is pretty crude way of doing it I'd say so maybe aim to change that later (but how - I don't want early udev but maybe for the best...).

Okay, looking at Linux Live Kit. Wish I hadn't bothered... hurting my brain. I'm too lazy to read other peoples complex code and can't see where modules get loaded. Maybe later or somewhere else that just has a simple loop list. List in BionicDog should be newer than XenialDog - I'll see if anything likely missing to cos issue in its initrd if I official Void/Porteus/DebianLive/Kit is too tiring for my brain (which is very tired just now anyway.

By the way, I never remember the cpio commands so use firstrib's modify_initramfs_XXX.sh scripts to unpack/repack/convert_gz2xz etc... initramfs utilities as I when I need to (or sometimes steal the cpio commands out of them...). Quick and easy. Void Linux own initramfs on its live cd uses different method - I worked it out and recorded method somewhere in my disorganised cherrytree notes...

wiak

[wiak]

Ah, I see Fred has had module load problems with usb3 too and seems to have found extended modules to load list from Live Kit?

http://murga-linux.com/puppy/viewtopic. ... 189#998189

Will save me time to just use the latest from DebianDogs then (though I'd still find it useful/informative to know where the list came from but had issues/arguments on a DD thread recently so prefer my peace and quiet - except about Puppy and woof-CE which I'm happy to argue about) - size of list doesn't matter really since can always remove unneeded at switch_root time.

I should probably download some latest live install images from Debian (debian live 10.0.0?) [or use a less brute-force method of loading initial modules].

I'll come back to this later after checking up more generally about modules usb3 likely to need (thought it was xhci though). Busy working on new build rootfs script.

wiak

[rufwoof]

By the way, I never remember the cpio commands

I mentally associate to remember it as I need to "id" to view it, and semi loudly exclaim "oh new cpio" to close it. With that create a folder beneath where the initrd cpio is ...etc.

mkdir i
cd i
cat ../initrd | cpio -id

and to create a new cpio (from within the i folder)
find . | cpio -o -H newc >../initrd.new

However many/most of the later pups tend to take care of all of that with a single click nowadays.

[wiak]

By the way, I never remember the cpio commands

I mentally associate to remember it as I need to "id" to view it, and semi loudly exclaim "oh new cpio" to close it. With that create a folder beneath where the initrd cpio is ...etc.

mkdir i
cd i
cat ../initrd | cpio -id

and to create a new cpio (from within the i folder)
find . | cpio -o -H newc >../initrd.new

However many/most of the later pups tend to take care of all of that with a single click nowadays.

Hmmm... you do realise don't you, rufwoof, that I created utility scripts (the modify_xxx ones I referred to) that automate all of that stuff at commandline whilst I'm doing dev work?. The scripts are all attached to second post of this thread at following link. I use them all the time during development of build initramfs:

http://murga-linux.com/puppy/viewtopic. ... 57#1028957

e.g. modify_initramfs_gz.sh or modifiy_initramfs_xz.sh or modify_initramfs_gz2xz.sh and so on.

You do occasionally come across an initrd initramfs that is packed by a different method though.

[wiak]

Regarding modules that I may have missed out from modprobe loop in initramfs/init, most of the ones I see in the extended list I see Fred tried don't seem relevant. The only one that looks possible, that I should maybe include is module uas:

https://en.wikipedia.org/wiki/USB_Attached_SCSI

Code: Select all

USB Attached SCSI (UAS) or USB Attached SCSI Protocol (UASP) is a computer protocol used to move data to and from USB storage devices such as hard drives (HDDs), solid-state drives (SSDs), and thumb drives. UAS depends on the USB protocol, and uses the standard SCSI command set. Use of UAS generally provides faster transfers compared to the older USB Mass Storage Bulk-Only Transport (BOT) drivers.

UAS was introduced as part of the USB 3.0 standard

Hopefully adding that one to init (in build_firstrib_initramfs04_s102.sh would fix your boot problem if actually usb3 related.

i.e. on line 108 at the end, change:

xhci-hcd usb-storage xts;

to

xhci-hcd usb-storage xts uas;

I don't know - haven't tested. But looking up modules.dep list, yes, I think that module may be necessary in which case I also need to change the line 251 in build initramfs script:

from:

modprobe -r \`lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci'\` 2>/dev/null # keep ehci,xhci,sdhci

to

modprobe -r \`lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas'\` 2>/dev/null # keep ehci,xhci,sdhci,uas

No harm in that change anyway, so I'll do that for next release.

EDIT: maybe...: https://github.com/gnubee-git/GnuBee_Docs/issues/98

wiak

[rufwoof]

Mac OS X Exposé/Compiz Scale style X Desktop Environment with ncurses TUI (text user interface) menu system/Midnight Commander file manager.

Installation

firstrib00.plug.tar.gz

Download the above firstrib00.plug.tar.gz into the same folder as wiaks scripts

Once dowloaded, extract it using

Code: Select all

tar xvf firstrib00.plug.tar.gz

and edit the first few lines of firstrib00.plug to specify the root and user passwords you prefer, and edit it to specify your wireless ssid and password.

Rebuild the tar using

Code: Select all

rm firstrib00.plug.tar.gz
tar czvf firstrib00.plug.tar.gz firstrib00.plug plugins/

and then run wiak's scripts

Code: Select all

./build_firstrib_rootfs_102.sh void current amd64 firstrib00.plug.tar.gz
./build_weedog_initramfs05_s201.sh void "-comp lz4 -Xhc"

When finished you'll have a vmlinuz, initramfs and 01firstrib_rootfs.sfs (main sfs) ready to add to your bootloader.

My menu.lst entry looks like ...

Code: Select all

title FirstRib (Void Linux Flavour)
   root (hd0,0)
   kernel /VOID/vmlinuz-4.19.68_1 bootfrom=/mnt/sda1/VOID usbwait=8 changes=RAM

Boot that and login as root using password 'root' (unless you changed it (as above)). Then run 'startx' to start the graphical desktop.

Recommended boot method, usb used to boot (MBR, bootloader such as grub4dos, vmlinuz stored on USB), main sfs stored on HDD. That way the usb can be unplugged after booting to physically isolate the MBR/bootloader/kernel.


Desktop Environment

Window Selection

Hot corners style desktop (bottom left for skippy-xd to select open windows, top left for xlunch - program launcher), and with tilda terminal F1 show/hide toggle (I like to mouse over the terminal window and press F11 on first bootup to set it to full screen).


Program Launcher

To view current open programs mouse into the bottom left corner or use the win + spacebar key combination. Mouse into top left corner (or alt + spacebar) shows available programs. For both skippy and xlunch windows clicking on the background closes the window without further action, or use the arrow keys (or click) to launch a specific window/program. mc does involve a learning curve, but well worth it as its common and works great for the likes of when you're remotely logged into other boxes/servers.


Browser

Even though logged in as root, starting chromium will run that under userid user, so you get the full sandbox protections.

If you must run chromium as root then do so from the command line using chromium --no-sandbox ... but as that indicates that runs without any of the chromium sandbox protections.

As tilda terminal supports clickable url links I keep all my bookmarks in a text file so its easily edited and pressing F1 to show tilda, and then selecting my url tab reveals all of my bookmarks ready to click. Tilda also supports the common cut/paste keys (right click in a tilda window to see all of its options).


Text User Interface (TUI)

Tilda terminal (F1 toggles show/hide) supports multiple tabs (ctrl shift t ... to add a tab). There is however a ncurses (text user interface (tui)) menu to further help simplify using terminal/cli. Running the command tt (for tab title) and a label/name i.e. tt hello - sets the tab title to hello (or whatever you prefer). Run the command 'tui' inside tilda to launch the ncurses menu.


(clickable thumbnail of tilda
terminal screenshot)

Starting mc within a tilda window (ctrl-shift t to add another tab, or right mouse click context (that also shows other commands such as cut/paste etc.)) and the right pane (that you can 'tab' to) shows a range of scripts, such as for shutdown, reboot, setting up and using encrypted folders ...etc.). You can use the mouse in mc when its running under X. Most common file extensions are already set, for instance .txt files will open the file in geany, .html files will open Chrome, mp4 will launch vlc ...etc.


Suspend

I don't like my laptop automatically suspending when the lid is closed so none of that is activated. Sometimes I carry the laptop around with the lid closed whilst its still working, other times I might want to suspend it whilst the lid is open to save the battery. So I just use the zzz command as/when I want to suspend the session. For instance alt space and typing zzz and then pressing enter will suspend the laptop. Press Enter to resume/restore from suspension.


Volume

For volume up/down the keys are ctrl up-arrow/control down-arrow. Or leave alsamixer open in a tilda window and F1 (to show tilda) and select/use that to adjust sound levels (or use the programs own volume control(s)). Personally I just tend to use the ctrl-arrows choice.


Persistence

Run the command save.sh to save changes. Each save creates a additional sfs file that is loaded at boot layered on top of the main sfs. When the number of save sfs files reaches 5 however you should run the merge-changes.sh script (open mc and tab to the right pane, and then scroll down to the merge-changes.sh file and press Enter, or just run merge-changes.sh from a command line). That combines all of the multiple save sfs files into a single save sfs file and avoids exceeding the number of permitted/available loop devices.


Development/Admin

Wireless ssid details are stored in /etc/wpa_supplicant/wpa_supplicant.conf, edit that file as desired. Haven't tried it, but I believe that when multiple entries are included then it automatically activates the one with the strongest signal strength.

[wiak]

The attached firstrib00.plug builds a pretty comprehensive voidlinux setup.

Excellent. Thankyou rufwoof.

I'll be collecting submitter's firstrib00.plug creations as a library of available builds once I have time to organise that.

I'll also endeavour to make sure that the new version of build_firstrib_rootfs I'm working on will be compatible (should be), and if not, I'll inform you and any other firstrib00.plug submitters of any difference that may result in an issue.

wiak

[westwest]

Well, this is not quite a desktop, but a simple experiment, modifying rufwoof's script for firstrib00.plug
to build a firstrib without X11 (for simplicity's sake?), using tmux as a window manager.

I've easily found CLI and TUI packages to perform most daily OS functions, except of course playing video files.
Therefore, running the optional script "installX" will then enable vlc to be run "on the fly" in its own tty
with command "xinit vlc $* -- :2".

Code: Select all

xbps-install -y linux4.19 ncurses-base base-system linux-firmware-network shadow mc htop terminus-font tmux udevil tlp htop cmus bashmount gptfdisk squashfs-tools w3m rtorrent alsa-utils gptfdisk

# Root password
pwconv
grpconv
echo -e "root\nroot" | passwd >/dev/null 2>&1

# Network
echo "network={" >>/etc/wpa_supplicant/wpa_supplicant.conf
echo "ssid=\"SOMEAVAILABLE_SSID\"" >>/etc/wpa_supplicant/wpa_supplicant.conf
echo "key_mgmt=NONE" >>/etc/wpa_supplicant/wpa_supplicant.conf	# for connecting to open wifi network  
echo "}" >>/etc/wpa_supplicant/wpa_supplicant.conf

# Prepare a /root/connect script we can run to network connect
echo "wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B" >>/root/connect
echo "dhcpcd" >>/root/connect
chmod +x /root/connect

# Basic tmux config file
echo "unbind C-b" >>/root/.tmux.conf
echo "set -g prefix C-a" >>/root/.tmux.conf	# changes prefix keybinding to Ctrl-a
echo "set -g base-index 1" >>/root/.tmux.conf
echo "set -g pane-base-index 1" >>/root/.tmux.conf     # starts windows from 1 instead of 0
echo "bind-key r source-file ~/.tmux.conf \; display-message \"Config Reloaded!\"" >>/root/.tmux.conf	# sets prefix-r to load config file in-session

# Prepare a /installX script to enable running VLC in X with command "xinit vlc $* -- :2"
echo "xbps-install -y xorg vlc xterm" >>/root/installX
sed -i 's/geteuid/getppid/' /usr/bin/vlc
#echo "echo \"tilda &\" >>/root/.xinitrc" >>/root/installX
#echo "echo \"compton &\" >>/root/.xinitrc" >>/root/installX
#echo "echo \"exec openbox\" >>/root/.xinitrc" >>/root/installX
chmod +x /root/installX

# Some console variables loaded on boot
echo "FONT=ter-118n" >>/etc/rc.conf
echo "HARDWARECLOCK=\"UTC\"" >>/etc/rc.conf
echo "TIMEZONE=\"America/Montreal\"" >>/etc/rc.conf
echo "KEYMAP=\"us\"" >>/etc/rc.conf
echo "exec echo 0 > /sys/class/backlight/acpi_video0/brightness" >>/etc/rc.local
sed -i 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/default/libc-locales
xbps-reconfigure -f glibc-locales
usermod --shell /bin/bash root 

[code]
[/color]

Without deleting any files in /var/cache/xbps, it creates a 01firstrib_rootfs.sfs of ~500mb,
which loads up at boot in literally no time at all on my 10-years-ago laptop. Memory usage on prompt is about 44mb, and
the system is very stable (no loss of keyboard settings after "sleep" for example).

As a side note, i've noticed that on the first boot after renaming the "upper_changes" directory to "50upper_changes"
(from puppy, not from inside firstrib), directory "50upper_changes" was completely ignored.
Subsequent boots loaded both directories just fine. Perhaps a fluke?

Thanks!