RC7 (STABLE) WeeDogLinux Arch 64 now released
@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
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
I have FirstRib running in a nested x-server using JWM
- Attachments
-
- Screenshot(33).png
- (98.95 KiB) Downloaded 945 times
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.rockedge wrote: I think there are 2 leafpad's. The FIrstRib version is in /bin and the host system is /usr/bin
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
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
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.
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.
Last edited by wiak on Thu 30 May 2019, 08:18, edited 3 times in total.
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
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
EDIT:
https://voidlinux.org/news/2017/12/adve ... iners.html
Last edited by wiak on Thu 30 May 2019, 08:06, edited 1 time in total.
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
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
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.rockedge wrote:so far the system is very fast and here is a shot with ROX installed and running
wiak
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
In build_firstroot script, I use the construct:
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
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
Code: Select all
cat << INSIDE_CHROOT | chroot firstrib_rootfs sh
...
...
INSIDECHROOT
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
Regarding Xauthority and xhost related matter, please also see my follow up post here:
http://www.murga-linux.com/puppy/viewto ... 307#963307
wiak
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Ah, thankyou AndresC2. It is because I accidentally used the bashism: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 : ]
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'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
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
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:
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
Code: Select all
&& mount --bind /tmp firstrib_rootfs/tmp
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
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
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:
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
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
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
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
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?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 : ]
P.S. sorry to side track this thread.
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].
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 : ]
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 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 : ]
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].
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
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
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.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?
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
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
How do you switch to root in tinycore?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
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].