RC7 (STABLE) WeeDogLinux Arch 64 now released

[rockedge]

@s243a

I think you are correct. The X server is probably running with components from both the host and the chroot'ed file system.
But without the Xorg stuff installed in FirstRib leafpad wouldn't run.

I used in the FirstRib shell -> export DISPLAY=:0.0
then in the host -> xhost +

back in the FirstRib terminal then started /bin/leafpad and then using the menu File->Open looked around......leafpad could not see the host system's files

[rockedge]

I have FirstRib running in a nested x-server using JWM

[wiak]

I think there are 2 leafpad's. The FIrstRib version is in /bin and the host system is /usr/bin

Yes that is correct. You only need to install leafpad and its dependencies though (including some fonts or menus won't show up correctly). There are a lot of X-related dependencies, including whole gtk+ needed by leafpad. Once chroot is entered that acts like a jail of course so leafpad will indeed not see files outside of firstrib_rootfs.

As for backspace key and bash... If, starting from scratch build you install base-system, which is pretty much the whole of void Linux commandline-related stuff you should find backspace then working in bash.

xbps-install -Su base-system

So need to find out why. Not easy... Maybe the file /etc/login.defs is read by bash. That file in base-system contains definition of backspace key as a code. I'm in bed cos of flu so haven't tried simply making copy of that in basic firstrib, might be more needed anyway.

wiak

[wiak]

Nested X server nice. Rufwoof also posted about that and also pflask somewhere.

EDIT, about pflask, here:

http://murga-linux.com/puppy/viewtopic. ... 78#1025478

But see my post immediately below regarding Void Linux's own lightweight container system implementation.

[wiak]

Void Linux does provide its own lightweight container system - I think I posted link about that earlier or search void wiki/docs. As far as nesting X goes there is older xnest and also xephyr.

EDIT:
https://voidlinux.org/news/2017/12/adve ... iners.html

[rockedge]

so far the system is very fast and here is a shot with ROX installed and running

[wiak]

so far the system is very fast and here is a shot with ROX installed and running

Very nice. I must try this with something like tinycore or Slitaz. I like the idea of running one of these very small distros but with the full power of Void Linux available easily and conveniently via FirstRib.

wiak

[wiak]

In build_firstroot script, I use the construct:

Code: Select all

cat << INSIDE_CHROOT | chroot firstrib_rootfs sh
...
...
INSIDECHROOT

to execute commands inside the chroot from my buildscript.

I came across that method at third post down here:

https://askubuntu.com/questions/551195/ ... oot-how-to

However, I have now remembered fredx181 suggesting how to run commands from menu of host via a shell script, which would be useful here, and after searching for that, discover it is the exact same method he was suggesting.

Anyway, here is a modified example of what fredx181 wrote for starting, say leafpad, from host system via this shell script, which you just need to make executable. You could even create a desktop file for it in the host system's /usr/share/applications directory. Note this assumes you have installed leafpad (and necessary X libs that requires) in your firstrib_rootfs installation. Note that sometimes it may also be necessary to allow the chroot apps access to the host Xserver as rockedge has recently been doing:

per fredx181's suggestion: http://www.murga-linux.com/puppy/viewto ... 304#963304

Code: Select all

#!/bin/sh
# firstrib_leafpad.sh, run firstrib leafpad in chroot and exit when finished using it

mount --bind /proc firstrib_rootfs/proc
mount --bind /tmp firstrib_rootfs/tmp
mount --bind /dev firstrib_rootfs/dev
mount --bind /sys firstrib_rootfs/sys
mount -t devpts devpts firstrib_rootfs/dev/pts
cp /etc/resolv.conf firstrib_rootfs/etc/resolv.conf

cat << EOF | chroot firstrib_rootfs sh
export LC_ALL=C

##### start doing stuff here #####
leafpad # run program, can be any, if installed in firstrib_rootfs
# do some more
##### end of doing stuff #####

EOF

umount firstrib_rootfs/tmp
umount firstrib_rootfs/proc
umount firstrib_rootfs/dev/pts
umount firstrib_rootfs/dev
umount firstrib_rootfs/sys 

Using the above technique, (which will work with commandline apps too) you don't need to bother using mount_chroot.sh and umount.chroot.sh since setting up mounts and cleaning them at the end is being done within the above script anyway. As I said, you can even arrange using this technique for firstrib_rootfs apps to be run straight from host system menu.

Regarding Xauthority and xhost related matter, please also see my follow up post here:

http://www.murga-linux.com/puppy/viewto ... 307#963307

wiak

[AndresC2]

hola wiak and wanderer

you need install BASH in tinycore from appbrowser

and change in your script

!#/bin/sh for

!#/bin/bash

only test in /root folder and run fine.

suerte : ]

[wiak]

hola wiak and wanderer

you need install BASH in tinycore from appbrowser

and change in your script

!#/bin/sh for

!#/bin/bash

only test in /root folder and run fine.

suerte : ]

Ah, thankyou AndresC2. It is because I accidentally used the bashism:

Code: Select all

mkdir -p firstrib_rootfs/{boot/kernel,dev/pts,etc/{skel,xbps.d},home/void,media,mnt,opt,proc,root,run,sys,tmp,usr/{bin,include,lib/{firmware,modules},lib32,libexec,local/{bin,include,lib,sbin,share},share/xbps.d,source},var/log}

I've fixed that in version 0.0.3 and it runs fine in tinycore now (wanderer should be pleased) without installing bash or changing !#/bin/sh.

I'll upload version 0.0.3 in a little while, once I've double checked it. Instead of manually creating /etc/group and /etc/passwd I'm now installing base-files, which is only a couple of hundred kilobytes but sets up lots of txt config files. Also, manually creating these files creates other problems when loading other void linux templates.

wiak

[wiak]

Note: I'm also about to upload new versions of mount_chroot.sh and umount_chroot.sh at same time I upload build_firstrib version 0.0.3. Only change is that I'm also making a bind mount of /tmp of host. I had forgotten that I discovered previously in my "The debootstrapDebian within Puppy project" that that is required for some distribution host systems in order to access their X DISPLAY. That is, addition:

Code: Select all

&& mount --bind /tmp firstrib_rootfs/tmp

The decription of why I needed that (sometimes) is here:

http://www.murga-linux.com/puppy/viewto ... 307#963307

Basically, the relevant X lock files are often/always? stored by the host system in its /tmp and the chroot system needs access to these for .Xauthority to work (or the insecure xhost+ come to that I think). Binding /tmp may not always be required but probably more general purpose - you can always take out that mount --bind /tmp... statement if problems were to arise (which I doubt).

wiak

[wiak]

FirstRib version 0.0.3 uploaded to first post of this thread (all scripts updated, including mount_chroot.sh and umount_chroot.sh).

See my previous two posts for details of changes. Basically:

I fixed a bashism (using {} with mkdir) so script will now work with host systems that do not have bash installed.

Included void linux base-files selection (only a couple of hundred kilobytes but more effectively sets up the likes of /etc/passwd and /etc/group).

Simplified the code very slightly (I had a couple of stupid bits in the original at a time I wasn't familiar enough with xbps package manager usage).

I've only really tested the x86_64 bit version since changes are the same. But please let me know if I made any mistake updating the i686 version (I'll also test it later to be sure).

@wanderer: should work in tinycore linux now (without bash needing installed). Open a terminal in tinycore and enter:

Code: Select all

sudo su

That makes you root user. Then proceed as usual to build_firstrib_rootfs-xxx.sh (using appropriate script version for 32bit or 64bit install). Worked in my test on tinycore linux 64bit system anyway. If you get as far as installing Xapps there may be some tricks required for the case of tinycore X display - I remember having problems with that, but sorted them out in my Debiandebootstrap for Puppy project, so solutions are documented there.

FirstRib could be pretty useful in present chroot-only form since tinycore is so tiny... yet can host even full-installs of Void Linux via FirstRib running... and act as an X server for FirstRib Xapps.

wiak

[fredx181]

Hi wiak, I didn't test yet, but just want to say that your project looks very promising, keep up the good work!

Fred

[s243a]

hola wiak and wanderer

you need install BASH in tinycore from appbrowser

and change in your script

!#/bin/sh for

!#/bin/bash

only test in /root folder and run fine.

suerte : ]

I was looking at tinycore's package manager (appbrowser?). Anyway, I noticed that there was a line in it to check that you are not root. I'm wondering how this works, is there some suid mechanism to elevate privileges so that it can install packages in places where root permissions are required?

P.S. sorry to side track this thread.

[AndresC2]

hola s243a

sorry in wbar look for apps icon

and in terminal type:

tce-load

Usage: tce-load [ -i -w -wi -wo -wil -ic -wic -wicl]{s} extensions
-i Loads local extension
-w Download extension only
-wi Download and install extension
-wo Download and create an ondemand item
Adding -c to any -i option will force a one time copy to file system
Adding -l to any -i option indicates load only - do not update onboot or ondemand
Adding -s to any option will suppress OK message used by apps GUI

Example usage:
Load local extension:
tce-load -i /mnt/hda1/tce/optional/nano.tcz
Download into tce/optional directory, updates OnBoot and installs:
tce-load -w -i nano.tcz
Download only into tce/optional directory:
tce-load -w nano.tcz

suerte : ]

[s243a]

hola s243a

sorry in wbar look for apps icon

and in terminal type:

tce-load

Usage: tce-load [ -i -w -wi -wo -wil -ic -wic -wicl]{s} extensions
-i Loads local extension
-w Download extension only
-wi Download and install extension
-wo Download and create an ondemand item
Adding -c to any -i option will force a one time copy to file system
Adding -l to any -i option indicates load only - do not update onboot or ondemand
Adding -s to any option will suppress OK message used by apps GUI

Example usage:
Load local extension:
tce-load -i /mnt/hda1/tce/optional/nano.tcz
Download into tce/optional directory, updates OnBoot and installs:
tce-load -w -i nano.tcz
Download only into tce/optional directory:
tce-load -w nano.tcz

suerte : ]

Okay, so the actual installation happens OnBoot. I wonder how one might simulate this boot installation, if they are using tinycore in a chroot.

[AndresC2]

Hi s243a

maybe this help

The Core book gives a gentle introduction to Core, its concepts, and how it functions.

http://tinycorelinux.net/book.html

Hi wiak

Maybe is possible turn FirstRib in FirstRib.tcz and put it ondemand

but how merge with tinycore and save new apps?

good luck

[wiak]

Hi wiak
Maybe is possible turn FirstRib in FirstRib.tcz and put it ondemand
but how merge with tinycore and save new apps?

Hi AndresC2, assuming I understand your comment correctly: There is of course no problem for a tiny core linux user to make build_firstrib_rootfs script into a tcz; tiny core provides tools for that.

However, it should be understood that the resulting FirstRib (void flavour; others may come) results in an independent root filesystem, which can be used via a chroot in pretty much any host Linux system, even the smallest. 'Merging' apps installed into FirstLib with those of the host system is probably not a good idea because doing so would likely break the host systems package management database structure and also pollute the host system with incompatible libraries and so on. If the host happened to be tiny core linux then its own mechanism involves symlinking sfs files, so there would be additional complexities involved in any attempt to 'merge' anyway.

The root filesystem created by the build_firstrib_rootfs... script can be used in various ways. First, as done at the moment, it can be used to create a hybrid system (host Linux system plus running firstrib in a chroot or container of some sort, and perhaps using the likes of Xnest/Xephyr or the hosts own X system for firstrib Xapps display).

I mentioned a tip (suggested some time back by fredx181) of running a firstrib app from the host by creating a special shell script on the host system that automatically chroots into firstrib and runs the app (and cleans up the bind mounts once you are finished).

http://www.murga-linux.com/puppy/viewto ... 15#1029315

A good idea would be to extend that technique with a little build script of its own that automatically creates a desktop icon on the host system everytime you add a new app to firstrib itself.

Implementing that would be easy: instead of mount-chroot into firstrib_rootfs and then installing app using xbps within there, create a script on the host that automates the firstrib installation of the wanted app. That host script could also then automatically create host desktop that will run/exec the special load script that will run the firstrib app by clicking icon on the host desktop (or menu).

The result would be an almost transparent hybrid system of the two (host plus firstrib void). Of course that build appload script could include an appbrowser and gui functionality. However, I recommend always writing FirstRib addons/modules in the form of commandline driven scripts, which each are as small and simple as possible, since that is one of the design goals to make FirstRib particularly easy to understand and modify. Gui functionality can always be added later to a well-written commandline script (if that script includes non-interactive usage).

Another use of FirstRib firstrib_rootfs is to use it to create an independently booting distribution. One method of doing that is to create a suitable initrd or an initramfs that ends up using firstrib_rootfs as the final running root filesystem after boot. You will no doubt be aware of the usual grub or grub2 procedure: first grub finds and loads the kernel (grub4dos and grub2 are quite sophisticated in their ability to find and load kernel from various media and filesystem formats). Then the kernel takes over - and the initramfs is loaded into RAM and the kernel looks for the program 'init' in the top directory (actual root or /) of that. That initramfs has to include a rootfs of its own that includes any firmware/modules that the kernel needs to operate the required system hardware.

Different initramfs modules can or could be created. The simplest could simply use firstrib_rootfs itself inside the initramfs with a suitable init, and what that init script contains will determine the functionality of the system. The very first initramfs I hope to soon publish a simple buildscript for will use that simplest method (which has limitations) and the first init will be amongst the least complex I can think of: it won't therefore do much other than have the ability to boot the system and run basic commands. Disadvantage of that simplest one is that it will load/run entirely/only in RAM and not include save persistence mechanisms, which will be the next step.

Implementing a more complex initramfs involves extending the init script to, for example, create overlayfs layers for reading and writing (save persistence). That can also be done in a very simple build script, though of course much more complex systems will indeed require much more complex init scripts (like I said, for firstrib I'm trying to avoid that, though nothing wrong with anyone using firstrib, or forking it, to create a complex system (that like traditional Puppy boot mechanisms would also of course be complex to understand...).

Anyway, first, pretty useless, initramfs will be coming soon, just to show how firstrib_rootfs can indeed be booted independently (but that simple version will not be able to connect to internet since that would require supplying, for example, firmware/modules for wifi and dhcp-related apps and configurations etc - how to do that will be modularly added later in my plans/dreams).

In my own eyes/point-of-view, the most useful use of FirstRib is not as an all-singing-all-dancing independently booting Linux distro. Rather, I find the hybrid system approach more attractive (especially with the addition of an auto appbrowser/appload/apprun functionality. Nice, because that can be used with any already polished Linux distro for added Void Linux functionality without any runtime overhead really (since just a chroot being done) - unlike running void linux from a virtual machine with the overhead that brings. Nevertheless, a major reason/point for FirstRib is to show how it is all done, in small easy scripts, for others to do as they like with them.

Anyway, back for me to work on first, pretty useless in practice, simplest initramfs/init. I've actually got it all working but now thinking/working on best way to present it to the forum in terms of a simple initramfs build script. So should appear reasonably soon for those interested in that.

wiak

[wanderer]

hi wiak and andreasC2 and everyone

just built wiaks new version in tinycore

it built fine

did it in the root directory as root

very cool

wanderer

[s243a]

hi wiak and andreasC2 and everyone

just built wiaks new version in tinycore

it built fine

did it in the root directory as root

very cool

wanderer

How do you switch to root in tinycore?