RC7 (STABLE) WeeDogLinux Arch 64 now released

A home for all kinds of Puppy related projects
Message
Author
User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#46 Post by rockedge »

so far the system is very fast and here is a shot with ROX installed and running
Attachments
Screenshot(34).png
(107.38 KiB) Downloaded 861 times

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

#47 Post by wiak »

rockedge wrote: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
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#48 Post by 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
Posts: 76
Joined: Sun 09 Jul 2017, 02:12

#49 Post by 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
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#50 Post by wiak »

AndresC2 wrote: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
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#51 Post by 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
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#52 Post by 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

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#53 Post by 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
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#54 Post by s243a »

AndresC2 wrote: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. :oops:
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].

AndresC2
Posts: 76
Joined: Sun 09 Jul 2017, 02:12

#55 Post by 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
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#56 Post by s243a »

AndresC2 wrote: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.
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].

AndresC2
Posts: 76
Joined: Sun 09 Jul 2017, 02:12

#57 Post by 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
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#58 Post by wiak »

AndresC2 wrote: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
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#59 Post by 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
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#60 Post by s243a »

wanderer wrote: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?
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#61 Post by wanderer »

hi s243a

if you use emelfm
i open an xterm and
sudo emelfm
that will open emelfm as root in the root directory

if you use rox
the menu has 2 choices
open rox as user
open rox as root
that will open in the root directory

then any thing you do will be as root until you close the filemanager

wanderer

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

sharing /mnt/home between host system and the chroot system

#62 Post by wiak »

New versions (0.0.2) of mount_chroot.sh and umount_chroot.sh added to first post of thread for download.

These allow you to share a directory of your host linux system with the chroot firstrib_initramfs. By default these scripts result in the directory /mnt/home being shared. The code added to the mount script to do that is:

Code: Select all

mkdir -p firstrib_rootfs/mnt/home
mount --bind /mnt/home firstrib_rootfs/mnt/home
and the code added to umount_chroot.sh to clean that up at the end is simply:

Code: Select all

umount firstrib_rootfs/mnt/home
To prevent /mnt/home being shared you should comment out these lines in mount_chroot.sh (along with commenting out the related umount in umount_chroot.sh).

Alternatively, if you wish to share a different directory, alter the above mount and umount lines to reflect the directory you want to share (or add other similar lines to share other directories).

EDIT: Note that, by the way, you can actually ./mount-chroot.sh into an already built firstrib_rootfs and then build another firstrib_rootfs in there! I tried it, but be careful to start in an empty dir in firstrib of course or you could end up trying to overwrite your original firstrib_rootfs. Basically, you just run the same scripts: build_firstrib_rootfs...sh, mount-chroot.sh inside running firstrib chroot. When you exit that, you'll still be in firstrib and need to umount-chroot.sh. Then your final exit would take you back to host system prompt, where you would do your final umount-chroot.sh. Confused?!!! Don't worry about it - no good reason to build firstrib_rootfs inside firstrib itself anyway that I can think of... but it is instructive.

EDIT2: There is a Debian package called schroot that:
allows users to execute commands or interactive shells in different chroots. Any number of named chroots may be created, and access permissions given to each, including root access for normal users, on a per-user or per-group basis. Additionally, schroot can switch to a different user in the chroot, using PAM for authentication and authorisation. All operations are logged for security.
It seemingly can automate the mount bind sharings for you too. I haven't yet tried it though.

https://packages.debian.org/jessie/schroot
https://wiki.debian.org/RichardDarst/Schroot

EDIT3: Note that you can also make a recursive mount bind (so nested mounts also appear in the bind):

Code: Select all

mount --rbind /some/where /else/where
You can read more about various bind mechanisms here:

https://unix.stackexchange.com/question ... bind-mount

By the way, there is a reddit forum/area for Void Linux itself, here:

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

wiak

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

#63 Post by rockedge »

weekend update:

managed to build out the FirstRib into a 1 and 2 version which I can run simultaneously and both with there own X server in a nested Xnest with a export DISPLAY=:1 and export DISPLAY=:2 although I can still use the host X server with export DISPLAY=:0 to save on the xorg overhead.
I have JWM with ROX --pinboard going which is working nicely with a custom background.

Also using FirstRib with no X server and using small scripts to start programs in the host that run in the chroot Void system.

All working very fast and on a FIrstRib installed firefox which I am typing this post from.

I used the latest scripts provided but I have not used the shared directory with the host which remains Bionic64-v8.

This method of running an almost complete OS in a chroot like this is much faster and feels lighter than doing similar with Void and VirtualBox.

really mostly experimental...... I am looking now at using this setup to attempt running zoneminder and a LAMP.
Attachments
Screenshot(38).png
(215.48 KiB) Downloaded 887 times

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

#64 Post by wiak »

rockedge wrote:weekend update:

managed to build out the FirstRib into a 1 and 2 version which I can run simultaneously and both with there own X server in a nested Xnest with a export DISPLAY=:1 and export DISPLAY=:2 although I can still use the host X server with export DISPLAY=:0 to save on the xorg overhead.
I have JWM with ROX --pinboard going which is working nicely with a custom background.

Also using FirstRib with no X server and using small scripts to start programs in the host that run in the chroot Void system.

All working very fast and on a FIrstRib installed firefox which I am typing this post from.
Hello rockedge,

What you describe sounds (and looks) excellent. Perhaps you could provide small simple setup scripts (or step by step howto) for achieving all that you describe. I'm sure that would be useful to others, and it would save me thinking too! I'm not quite sure what you mean by "using small scripts to start programs in the host that run in the chroot Void system". Could you supply an example (is it the small start app scripts fredx181 originally suggested that I mentioned in one of my posts above)?: EDIT: This one - http://www.murga-linux.com/puppy/viewto ... 15#1029315

I'll certainly include links, in first post of thread, to anyone's uploaded helper scripts.

At the moment, I'm personally still working on first initramfs buildscript to allow FirstRib to be booted independently with a suitable kernel. For the moment, I'm not using Void kernel, but instead chosen latest BionicPup kernel (either 32bit or 64bit). I've chosen that (after testing several different kernels) because I find that on my system at least, no modules/firmware needs to be loaded for FirstRib to be able to access my harddrive, usb, or SD card slot (and subsequently mount other partitions); i.e. the kernel has driver support already compiled in for these bits of hardware. Also, anyone with BionicPup system will easily be able to copy firmware/modules for a FirstRib bootable system using that kernel. I am however, including overlayfs module from BionicPup as I've going to use that in my initramfs to create layers for save persistence.

Though I haven't quite finished that part, FirstRib is booting fine with the BionicPup kernel and overlayfs working too. The initramfs buildscript is also very simple and small (a dozen lines of code or so, though that may increase a bit as I add save persistence functionality).

Of course, one important thing lacking in current simple bootable FirstRib system - no internet connection (in particular, no wifi) - that will require suitable firmware and some wifi-related void apps to be installed.

I may however, publish the pre-internet version soon anyway, since it shows the overall process of how initramfs boot works and the system is able to mount external filesystems. Then, after some further work, I'll see about getting wifi working (since xbps needs internet of course!).

Having said all that, I personally also think FirstRib is particularly useful as a chroot system as you describe Rockedge (where no initramfs is required and we just rely on what can be a tiny host system for booting and providing internet connectivity). I'm only planning to show how to boot it on its own for information purposes at this point in time anyway. It is indeed much lighter than using Virtual Box/Void Linux. There is almost no overhead at all in using a chroot - the FirstRib apps just use whatever CPU/RAM they need. So as it stands, FirstRib can be considered as being a Puppy (or other system) fully-Void-capable addon (and you can of course also make your own local repo in addition to having full access to Void's upstream repos).

By the way, I'm not around this weekend so will be a few days delay before I publish initial build_firstroot_initramfs.sh script, but should be ready for upload sometime next week.

wiak

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#65 Post by wanderer »

hi wiak

i am going to try to put your firstrib system
into s243a woof-next puppy (when it is ready)
and add my (very primitive) delta symlink system
and add fredx portable firefox system

this should be a very interesting experiment

and give the new puppy alternative build system
incredible flexibility

and thanks for making this system

its super cool

wanderer

Post Reply