RC7 (STABLE) WeeDogLinux Arch 64 now released

[wiak]

I did do one run where .plug included installation of xorg, chromium ...etc. straight off, but that resulted in a .sfs file of nearly 1GB that wouldn't boot.

But this is odd. I have just attempted to repeat same installation (though I ran out of space during creation of 01firstrib_rootfs.sfs) and can confirm switch_root causing kernel panic (I used uncompressed 01firstrib_rootfs since I didn't have the sfs). I am looking into the issue at this exact moment.

wiak

[wiak]

@rufwoof: If I'm correct that test above that failed with large 01firstrib_rootfs.sfs was on a usb drive? Could you please confirm that?

The successful chromium test you did was on hard drive from what you write. I have found bug on similar test, but on usb stick boot only (all booted fine when same files on my hard drive instead) where my simple routine for removing modules to save memory has proved to be a bit too aggressive (I need to tell it not to remove module ehci_pci, which usb stick needs but is not being marked as in active use somehow - hence able to be removed). At the moment, simple workaround for me will be to have simple list of modules I definitely don't want moved (currently being that ehci_pic module, but there may be one or two other modules related to SD card booting I have to definitely force keep).

EDIT: testing my workaround/fix now.

wiak

[rockedge]

I am getting a kernel panic and have not yet built a successful system using model s100.

working on using the Void kernel with this build because up to now I have been using the Bionic kernels

[wiak]

I am getting a kernel panic and have not yet built a successful system using model s100.

working on using the Void kernel with this build because up to now I have been using the Bionic kernels

Is this with a usb connected drive of some sort? If so, which sort. Problem is probably the one I am addressing with bug-fix this very moment.

wiak

[rufwoof]

@rufwoof: If I'm correct that test above that failed with large 01firstrib_rootfs.sfs was on a usb drive? Could you please confirm that?

No. My hdd is pretty much empty so I've been using that as the test-bed (installed grub4dos to boot - where my otherwise usb based regular desktop boot usb isn't connected (BIOS set to boot usb before hdd)).

[wiak]

@rufwoof: If I'm correct that test above that failed with large 01firstrib_rootfs.sfs was on a usb drive? Could you please confirm that?

No. My hdd is pretty much empty so I've been using that as the test-bed (installed grub4dos to boot - where my otherwise usb based regular desktop boot usb isn't connected (BIOS set to boot usb before hdd)).

@rockedge and rufwoof:

Could you try with Revision s101, which I've just uploaded. It fixes the kernel panic issue on my machine - but that panic was only happening for usb boot on my machine - booting from my ata harddrive was fine. My test was with your (rufwoof) big chromium build all built at once into big 01firstrib_rootfs.

Even if that doesn't work on your machine, I've now included a modules_remove.plug plugin that can be altered to address alternative issues of this sort. Late here now though, so I have to go, but please send in feedback to see is all okay now, and if not, try and find out what driver/module your boot media needs and we can fix it from that info tomorrow.

EDIT: Even if issue on your machine is different than it was on mine, you may be able to sort it out with modules_remove.plug inbetween times anyway if you check how the relevant code used (extract below) works (note how I now, in Revision s101, prevent modules name-matching ehci, xhci and sdhci being removed - same could be done for any module regular expression match):

Code: Select all

if [ -s "\${mountfrom}"/modules_remove.plug ]; then  # source modules_remove plugin
	. "\${mountfrom}"/modules_remove.plug
else
	# Remove unused modules to save memory
	modprobe -r \`lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci'\` 2>/dev/null  # keep ehci,xhci,sdhci
fi

To be honest, rufwoof, it doesn't make sense to me that smaller build booted on your machine, but bigger build didn't (unless you were also using copy2ram with the smaller build, since that would not run into any modules removed issue) - if it were a module issue, would occur for small or big firstrib_rootfs booting. On my machine, module ehci_pci was being removed on s100 revision - not allowing that to be removed fixed the usb boot for me (as I said boot from hd with your big firstrib00.plug build worked fine anyway).

Note that revision s101 is hot off the press and only given one brief test by myself thus far. But I'm releasing ultra-early since the quick test worked as my theory imagined it would... it may indeed need some further tweaks for some systems. I'm pretty sure it will be a similar module removed issue though.

EDIT2: If worst comes to the worst you can just comment out that whole block of code though and your system should boot since all modules will remain loaded. But uses more RAM that way. Actually Porteus boot in DebianDog does that; there are far more media driver modules loaded by DD Porteus boot than need to be (as lsmod shows). Puppy kernel, on the otherhand, has majority of these media drivers built permanently into the kernel (hence such issues don't occur) - official Void Linux kernel is pretty light in terms of few drivers directly built into it - so a bit harder to handle, but potentially lighter in use.

Alternatively, once plugin code fixed will be able to just use an empty plugin (or simply a # comment line in that with no actual code otherwise), then modules will not be removed at all so at least booting should fthen always work.

EDIT3: Sorry, in my haste I forgot I had moved "mount from" mountpoint after the overlay merge, so modules_remove plugin won't work yet, though the else code above should work for USB devices anyway. I'll fix the plugin code later today.

wiak

[rockedge]

yes I will test s101 revision....I can't get past the kernel panic with the s100. I'm going with the Void kernel on this series of tests

[wiak]

yes I will test s101 revision....I can't get past the kernel panic with the s100. I'm going with the Void kernel on this series of tests

If you run into further problems, I'll need more info regarding media you are booting from to help work out what is going on. Also, please remember to start from blank directory in major bug tests just in case something in folder (and old upper_changes or whatever contains something causing any issues).

Despite bugs sometimes not seeming logical, there are sometimes race conditions involved that throw all logic out the window (though sleep insertions often then 'fix' the issue), or sometimes it can just be a matter of order of loading/unloading to fix. The biggest problem is when all works fine on the developer's own hardware - but not on someone elses - I can only test my own system; then system/devices-uses information becomes paramount in the bug search (followed by copious googling and probably lots of luck).

wiak

[rockedge]

I start fresh every time I build one to avoid problems and mix ups

I am booting from a HDD connected via USB
just got back home so I'll start the tests soon...

where is s101 located for download?
I cloned the project from github but I don't think I see s101

[wiak]

where is s101 located for download?

It is already available in first post of thread rockedge. I uploaded it last night after a quick test of my own. I haven't uploaded to github, though I should, but I was waiting for tests (I'm not using git during actual development at the moment).

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

I imagine it may work for you since you are indeed connecting via usb.

wiak

[wiak]

Sorry, in my haste I forgot I had moved "mount from" mountpoint after the overlay merge, so modules_remove plugin won't work yet, though the else code above should work for USB devices anyway. I'll fix the plugin code later today.

I'll be looking into this module remove issue more thoroughly over the coming week, but in the meantime should be able to address most issues via plugin 'fix' (once that plugin code is fixed...)


wiak

[wiak]

build_firstrib_initramfs04_s102.sh uploaded to first post of this thread.

Changes:

****NEW (in Revision 1.0.2):

The trim modules code in the initramfs/init (i.e. modprobe -r etc...) now force keeps ehci, xhci, and sdhci modules to ensure boot ability of usb-connected devices (i.e. previously could get kernel panic on kernel unable to switch_root to /sbin/init).

Can now externally change that trim modules code section via plugin modules_remove.plug. If empty file of that name put in /mnt/bootpartition/bootdir, the modules will not be trimmed at all. Alternatively, any code placed in that plugin will be used instead of the default initramfs/init modules trim code (allowing easy fix of any such issues). That is:

/mnt/bootpartition/bootdir/modules_remove.plug should now be sourced if it exists as a regular file. If you simply create modules_remove.plug as an empty file then initramfs/init will not attempt to auto-remove modules that are not in use - that may prove helpful for systems that fail to switch_root because they cannot find /sbin/init

Alternatively, /mnt/bootpartition/bootdir/modules_remove.plug can be used to provide alternative modules remove code inside initramfs04/init - that will allow on-boot modifications to that part of the code without having to decompress the initramfs04 first.

This code really all needs tested on variety of different hardware. I only have a couple of different computer models to test it on, which over the next week I shall do as thoroughly as I can.

However, external testing will speed up the process of finding universal fix if current build initramfs04 script produces initramfs04.gz that fails on some hardware; such failures could be addressed via specially tailored modules_remove.plug once I know about them and can ascertain what being-removed-module needs to instead be kept.

Anyway, please let me know details of any tests results. If reports of failure, please also find out exact details of the boot media device involved so we can track down any missing module requirements.

wiak

[rockedge]

completed install of s101 successfully to a usb connected HDD
53 megs initramfs.gz
boots to void-login and so far have not tried the /rc.local trick with startx
connects to network and detects the wlan eth0 and lo and with ip link set eth0 up and ip link set lo up then udhcpc -i eth0

using Void kernel and here is the firstrib00.plug

Code: Select all

xbps-install -y base-minimal mc
xbps-install -y ncurses-base linux4.19 linux-firmware-network wifi-firmware shadow
pwconv # set up passwd system
grpconv
echo -e "root\nroot" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root" 
# you can add as many valid commandlines as you want in here
xbps-install -y xorg jwm rox bash xterm lxterminal geany adwaita-icon-theme

I would like to test if the firstrib00.plug can run the commands to rename the symlink /bin/sh from dash to bash and uncomment the en_US.UTF-8 UTF-8 in the /etc/default/glibc-locales and run

Code: Select all

xbps-reconfigure -f glibc-locales

[rockedge]

I just started to work on s101..... now I will try s102...it takes me a few minutes to set up the systems! I will test s102 next. with those changes added to firstrib00.plug

then again it only takes minutes to run the scripts and have a working system and with a few more minutes it is quite easy to modify the OS into many desktop forms and shapes and how complex or simple as one desires.

[rockedge]

Successful build of s102 32 bit is completed and booted.

running from a usb HDD using 55 megs of RAM and the initramfs.gz is 53 megs

DELL INSPIRON E1505 dual core 2gigs RAM

firstrib00.plug

Code: Select all

xbps-install -y base-minimal mc
xbps-install -y ncurses-base linux4.19 linux-firmware-network wifi-firmware shadow
pwconv # set up passwd system
grpconv
echo -e "root\nroot" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root"
# you can add as many valid commandlines as you want in here
xbps-install -y xorg jwm rox bash xterm lxterminal geany adwaita-icon-theme squashfs-tools

changed the /usr/bin/sh symlink from dash to bash


modified /etc/X11/xinit/xinitrc to this version (Note only the bottom lines have changed) ->

Code: Select all

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then







    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then







    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

jwm &
rox -p default &
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login

then ran the script to build the initramfs.gz

all of it took under 15 minutes to finsh

_

[wiak]

Great to hear s012 revision release is working on your system rockedge. Just want to check: is that with kernel=void?

wiak

[rockedge]

yes it is with kernel=void

[rufwoof]

Code: Select all

./build_firstrib_rootfs_x86_64_008.sh;./build_firstrib_initramfs04_s102.sh kernel=void

with firstrib00.plug content of

Code: Select all

xbps-install -y linux4.19 base-system shadow xorg xinit xbitmaps terminus-font squashfs-tools alsa-utils pulseaudio pavucontrol jwm chromium tilda mtpaint mc galculator

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

# set root to use /bin/bash
usermod --shell /bin/bash root

# Network (wireless where ifconfig shows my device as wlp2s0)
echo "network={" >>/etc/wpa_supplicant/wpa_supplicant.conf
echo "  ssid=\"VM123456-2G\"" >>/etc/wpa_supplicant/wpa_supplicant.conf
echo "  psk=\"abcd1234\"" >>/etc/wpa_supplicant/wpa_supplicant.conf
echo "}" >>/etc/wpa_supplicant/wpa_supplicant.conf

# Prepare a /root/connect script we can run to network connect
echo "wpa_supplicant -i wlp2s0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B" >/root/connect
echo "dhcpcd" >>/root/connect
echo "pulseaudio --start" >>/root/connect
chmod +x /root/connect
loadkeys uk
# So tilda continually runs
echo "#!/bin/sh" >/root/tilda.sh
echo "while :;do" >>/root/tilda.sh
echo "   tilda" >>/root/tilda.sh
echo "done" >>/root/tilda.sh
chmod +x /root/tilda.sh
echo "FONT=ter-i28b" >>/etc/rc.conf
echo "TIMEZONE=\"Europe/London\"" >>/etc/rc.conf
echo "KEYMAP=\"uk\"" >>/etc/rc.conf
echo "/root/tilda.sh &" >/root/.xinitrc
echo "setxkbmap -layout gb" >>/root/.xinitrc
echo "pavucontrol &" >>/root/.xinitrc
echo "chromium --no-sandbox &" >>/root/.xinitrc
echo "exec jwm" >>/root/.xinitrc
# Set dpi
echo "Xft.dpi: 144" >/root/.Xdefaults
ln -s /root/.Xdefaults /root/.Xresources
# Set locale
sed -i 's/#en_GB.UTF-8 UTF-8/en_GB.UTF-8 UTF-8/' /etc/default/libc-locales
xbps-reconfigure -f glibc-locales
# Change jwm tray clock to show date as well as time
sed -i 's/<Clock format="%H:%M">/<Clock format="%a %d %b %H:%M">/' /etc/system.jwmrc
# Add a MENU label to jwm tray
sed -i 's/TrayButton icon="jwm-blue"/TrayButton label="MENU" icon="jwm-blue"/' /etc/system.jwmrc

# Stop scroll wheel on jwm root window from scrolling through desktops
sed -i 's/<\/JWM>/<RootMenu onroot="4"\/>\
<RootMenu onroot="5"\/>\
<\/JWM>/' /etc/system.jwmrc

# Get Steven Blacks /etc/hosts file (form of ad-block)
rm /etc/hosts;wget -O /etc/hosts https://github.com/StevenBlack/hosts/blob/master/hosts?raw=true

I did change build_firstrib_initramfs04_s102.sh to add -comp lz4 to the mksquashfs line (faster compression, but larger filesize)

8m46s build time
01firstrib_rootfs.sfs 1.1GB filesize
initramfs04.gz 68MB filesize
vmlinuz-4.19.66_1 7MB filesize

Installed to HDD, booted using grub4dos with menu.lst entry of

title FirstRib (Void Linux Flavour)
root (hd0,0)
kernel /VOID/vmlinuz-4.19.66_1 bootfrom=/mnt/sda1/VOID
initrd /VOID/initramfs04.gz

Booting and running fine.

[wiak]

Thanks rockedge and rufwoof. Useful reports.

I successfully tried build using rufwoof's firstrib00.plug onto usb flash stick, and on 4GB laptop, booted that entirely into RAM (using kernel-line options changes=RAM copy2ram) followed by umount /mnt/sdb1 (i.e. unmounted and then removed usb flash stick); grub4dos menu.lst:

Code: Select all

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

# where uuid was for my usb flash stick per command blkid report

wiak

[rufwoof]

...and on 4GB laptop, booted that entirely into RAM (using kernel-line options changes=RAM copy2ram)...

I hadn't realised it was that easy to run in ram, thanks. Currently booted using HDD based copies of the vmlinuz, initrd and main sfs, also on a 4GB laptop.

Added libreoffice to the xbps-install line of my firstrib00.plug. With the build...initramfs script mksquashfs line extended to use lz4 compression (-comp lz4) that build in 15 minutes. But creates a near 2GB sfs filesize that wont boot entirely in ram on a 4GB ram system. Dropping the menu.lst copy2ram parameter however to leave just changes=RAM and it boots/runs fine, with all changes being lost on shutdown or reboot - which is the way I like it to run (reboot the exact same clean/pristine system each/every time). Obviously in the case of a usb based boot you wouldn't be able to umount/unplug the usb, so potentially the mbr/bootloader/vmlinuz ..etc. are open to be modified by a cracker, but its relatively easy to run a crude/simple intrusion detection test at each bootup to validate their integrity - something like http://murga-linux.com/puppy/viewtopic. ... 56#1021156