RC7 (STABLE) WeeDogLinux Arch 64 now released

[wiak]

Hi wiak

"running firstrib in a chroot or container"

for example rufwoof script

http://murga-linux.com/puppy/viewtopic. ... &start=540

from rufwoof script for example

change:

mount -o loop /initrd/mnt/dev_save/dpup/puppy_stretch_7.5.sfs /root/sfs

to

mount -o loop firstrib_rootfs.sfs /root/sfs

but you need this in tinycore or another distro

# unionfs_fuse
# libcap2-bin_2.25-1
# xserver-xephyr

you can try study rufwoof script

good bye.

Thanks, AndresC2, using containers such as rufwoof described and as used by BarryK in EasyOS, is a nice way to do things. The extra info on tinycore needs will prove very useful to those using that.

Cheers,

wiak

[wiak]

I can't backspace and if I resize the terminal window it pulls lots of prompts.

Finally... I've solved the issue with bash not working with backspace key in a small installation:

For backspace to work, bash needs /usr/share/terminfo, which is packaged as part of 'ncurses-base' (which has an install size of only 225kB). Oddly, though I came across others, on other Linux system installs, with similar bash backspace issues via google, nowhere did I find a working answer to the issue they raised. Ending up finding it myself by 'experiment' (I guess I should google again and provide the answer...):

i.e. To install bash with result that backspace key works correctly use:

Code: Select all

xbps-install -S bash ncurses-base

Alternatively, you might want the larger package of full ncurses anyway (install size of around 5 MB), which auto-install ncurses-base as a dependency, in which case you would:

Code: Select all

xbps-install -S bash ncurses

Of course, a larger install that uses the likes of base-system template/meta-package includes ncurses-base as a dependency anyway.

wiak

[wiak]

So just for some fun I downloaded latest dotpet of sc0ttman's pkg, untarred it, and merged the result into my pre-built firstrib_rootfs and ./mount_chroot.sh into that via my XenialDog64 host.

Using xbps-install I installed what seemed to be some of the major pkg dependencies: coreutils, sed, grep, findutils, wget. I had hoped pkg would work with busybox versions of these, but it had problems without the full versions (despite pkg advertised dependencies saying busybox wget and find okay, that didn't prove to be the case). When I first ran pkg --help it complained something about no repos, so I opened up BionicPup64 sfs and manually copied and pasted its /var/packages folder contents into firstrib_rootfs /root/.packages (a directory that came with the pkg installation). A symlink back to /var/packages approach would have been a bit better...

So on running pkg --help, pkg gave me its startup help screen (as shown on attached screenshot).

I also did a: pkg --update-sources

"pkg list-deps kodi" also worked, though it was a bit slow to report the dependencies.

I then got ambitious and tried installing frisbee (since I noticed it was in the current repo). pkg came back and said it was already built-in (as it is in BionicPup64 of course). I checked pkg script and noted it worked that out from /root/.packages/woof-installed-packages. So I cheated, and deleted the frisbee entry from that file, and once again tried: pkg add frisbee (actually ended up doing it twice so used pkg -f -g add frisbee command).

And pkg tried to do it's job and succeeded partially at least, as the second attached screenshot shows (despite Error on installation being indicated, frisbee binary, and various of its dependencies, was certainly now found on the system).

So could we build a Puppy via FirstRib and installed pkg (with pkg dependencies themselves installed using xbps)? Seems like it is possible... but I won't be doing it (my experiment was a very quick one just out of curiousity and I can't be bothered working harder on that since I have other priorities). Maybe interesting for someone to try though. Once pkg correctly set up xbps could be removed of course. I do wish pkg could have worked with busybox alone though, and I got the feeling pkg might unfortunately depend on a lot more underlying puppy core files than I dealt with, which would be a pity really. Nice if pkg could be made standalone capable, such as xbps - then it would be simple to build a FirstRib Puppy flavour. Nevertheless, the experiment suggested pkg was close to being capable of standalone (with say busybox) operation.

wiak

EDIT: Have since added petget (files takes from BionicDog64) so I could try "pkg repo-update". Basically just copied over the whole folder /usr/local/petget and then made a symlink ln -s /usr/local/petget /usr/bin/petget/petget. I'm not sure what difference having petget has (and would prefer anyway if pkg was not petget dependent in anyway). I think I needed to use xbps to install bash (with ncurses-base) for petget to work.

EDIT2: Also added dpkg-deb binary from BionicPup64 into /usr/bin and as a new test did:

Code: Select all

pkg add jsfutils

and that seems to have successfully installed. Trouble with Puppy building, however, is that it doesn't use its package manager for its complete build; first it simply downloads a rootfs-skeleton containing tons of files in a fixed directory structure - that's a bit of a pain IMO, but I guess I can try that and see if I can end up with some form of BionicPup64 root filesystem (after also getting selection of woof-CE rootfs-packages and other packages such as specified in DISTRO_PKGS_SPECS-ubuntu-bionic). I'm tempted to try - will think about it tomorrow... Main thing is, that if pkg and petget are now working correctly it should I feel now be possible to build a puppy based on FirstRib.

[wiak]

But no, it was an interesting experiment playing with sc0ttman's pkg, but I'd prefer to leave that now and get on with my plans for FirstRib void flavour rather than trying to script some kind of Puppy out of it, since Puppy rootfs would have to be reorganised and all made into dotpet form for pkg to install it all. But, yes, it's pretty clear to me that that could be done by extending my above post (and scripting it using build_firstrib_rootfs*.sh as the core of that). Hopefully above post is enough for someone else to try this if they so want.

My advice, therefore, to anyone wanting to re-design a Puppy build system would be to re-organise it such that a suitable commandline package manager (maybe pkg, albeit modified a bit to just depend on busybox and not need to also depend on petget for any functionality) would be able to fetch and install the complete system in modular form (such as is done with Void Linux; base-files, base-system, and so on). So if pkg could be made dependent only on busybox and the current rootfs-skeleton be done as some kind of base dotpet and other parts also packaged in dotpet form for pkg to fetch, then the build system becomes easy to script (as it is with FirstRib Void Linux flavour).

i.e. design should be organised into the form: busybox + native package manager

which is what FirstRib build system design is.

Then the rest of the build script simply uses the package manager to install the rest of the system and another simple build script builds the initramfs in similar fashion, for booting.

wiak

[s243a]

EDIT: Have since added petget (files takes from BionicDog64) so I could try "pkg repo-update". I'm not sure what difference having petget has (and would prefer anyway if pkg was not petget dependent in anyway). I think I needed to use xbps to install bash (with ncurses-base) for petget to work.

I think the only petget files that you need from pkg are:
/usr/local/petget/0setup
/usr/local/petget/debdb2pupdb
/usr/local/petget/find_cat

not count the files that you need in /root/.packages:
DISTRO_COMPAT_REPOS
DISTRO_PET_REPOS
DISTRO_PKGS_SPECS
PKGS_HOMEPAGES
PKGS_MANAGEMENT
Packages-devuan-ascii-contrib
Packages-devuan-ascii-main
Packages-devuan-ascii-non-free
Packages-puppy-ascii-official
Packages-puppy-common-official
Packages-puppy-noarch-official

The first group of files are to convert the compatible repo database into the puppy format. The latter group of files are to define which repos to use. I think it still might be slightly buggy though because I think that the name of some files in the repo might depend on three fields: name, version + update number; but this is just a wild guess. I haven't investigated it yet and I need to reproduce the error.

"pkg list-deps kodi" also worked, though it was a bit slow to report the dependencies.

I think that pkg is slow because it is searching multiple repos. That said I think if pkg used awk it might be faster than the combination of grep + cut.

[wiak]

EDIT: Have since added petget (files takes from BionicDog64) so I could try "pkg repo-update". I'm not sure what difference having petget has (and would prefer anyway if pkg was not petget dependent in anyway). I think I needed to use xbps to install bash (with ncurses-base) for petget to work.

I think the only petget files that you need from pkg are:
/usr/local/petget/0setup
/usr/local/petget/debdb2pupdb
/usr/local/petget/find_cat

Yes, that sounds right since pkg does the other petget-type functions itself. For the moment just using whole of /usr/local/petget though since not particularly large in size anyway.

find_cat is the ELF binary part of petget, which I presume is compiled code as a speed-up search component. I guess pkg itself uses that similarly though I have not studied pkg at all myself and have no idea how it does things.

wiak

[s243a]

EDIT: Have since added petget (files takes from BionicDog64) so I could try "pkg repo-update". I'm not sure what difference having petget has (and would prefer anyway if pkg was not petget dependent in anyway). I think I needed to use xbps to install bash (with ncurses-base) for petget to work.

I think the only petget files that you need from pkg are:
/usr/local/petget/0setup
/usr/local/petget/debdb2pupdb
/usr/local/petget/find_cat

Yes, that sounds right since pkg does the other petget-type functions itself. For the moment just using whole of /usr/local/petget though since not particularly large in size anyway.

find_cat is the ELF binary part of petget, which I presume is compiled code as a speed-up search component. I guess pkg itself uses that similarly though I have not studied pkg at all myself and have no idea how it does things.

wiak

correct. The source files can be found at:
/woof-CE/tree/master/initrd-progs/pkg/w_apps_static/w_apps

P.S. there might be a bug in the code that converts the files from debian format. I reported the issue in sc0ttman's pkg thread:
p=1029951#1029951

alternatively the bug might be in scottman's "pkg". As a final alternative, maybe I needed to copy more than these three files listed above???

[wiak]

I'm presumed 'pkg repo-update' performs some kind of sync of upstream repo contents to local, but if that was the case I'm surprised pkg list-deps kodi took so long if only then having to search through the deps locally. I suspect either the deps search routine could do with speeding up or the search isn't happening locally (it would be better if it was: apt update takes a while, and so does xbps-install -S, but thereafter searching, since local, is very quick, and Puppy pkg should do similar).

Any error in conversion from deb pkg format would certainly be a priority for a fix, wherever (pkg or petget) it is occuring.

plg itself is certainly a nice and promising piece of work; pity it inherits some petget design concepts though: having to set up the likes of DISTRO_PKGS_SPECS and similar seems overly complicated from the Puppy distro user/builder's point of view. Should just need to provide a simple list of packages wanted really, rather than having to tinker with such specially formatted files, which is far too complicated a process for most people to consider.

It's a pity, really, that Puppy itself, once carefully built, has such nice usability, from users point of view, but its build system woof-CE is so poor in that user-friendly/usability respect, and petget system so annoying/inefficient and flawed more generally. Really needs package management concept redesign and woof-CE needs binned since quicker to make a new design than continually hack away at that woof-CE mess IMO. Yes, it would take a lot of effort to read and understand all of how woof-CE works before being able to contribute to it, but why bother? It is like trying to master a language that no-one uses or would want to use. Throw it away and start afresh (though use it in the meantime since that's all there is - but too much time wasted on it - doesn't need 'guardians'... the opposite actually). It is ridiculous that a build system needs constant user-input (should be properly commandline driven, via commandline arguments - then various frontends could be easily produced for it using ncurses, dialog, yad, gtkdialog, whatever...).

wiak

[s243a]

My advice, therefore, to anyone wanting to re-design a Puppy build system would be to re-organise it such that a suitable commandline package manager (maybe pkg, albeit modified a bit to just depend on busybox and not need to also depend on petget for any functionality) would be able to fetch and install the complete system in modular form (such as is done with Void Linux; base-files, base-system, and so on).

It seems like the woof-CE team might agree with you here:

The ppm in the experimental branch probably needs some more testing and a few more fixes, i.... don't feel like doing that. And in fact it needs to be simplified even more.

It's basically a massive cleanup with some optimizations, one of the many massive cleanups in the history of woofce performed by yours truly.

https://github.com/puppylinux-woof-CE/w ... -499960217


mistfire is doing a lot of fixes to the puppy package manager on the github woof-CE repo under the name rizalmart see post:
http://www.murga-linux.com/puppy/viewto ... 33#1029733

[wiak]

Started new thread on creation of initramfs for FirstRib to allow it to be booted independently of any host Linux. The first, very simple, initramfs build script has now been uploaded with details here:

http://www.murga-linux.com/puppy/viewto ... 21#1030321

As explained there, this first initramfs isn't of much practical use. Rather it is uploaded to illustrate some general principles of initramfs construction.

With suitable vmlinuz kernel (that from BionicPup is highly recommended) it may, depending on your hardware, allow firstrib_rootfs to be booted independently (albeit without internet connectivity unless your firstrib_rootfs has been expanded to include network apps/configuration). Nor does this first initramfs provide save persistence, though next build script (already working but not yet uploaded) will provide that via overlayfs/chroot mechanism.

wiak

[rockedge]

good stuff!
I've been putting FirstRib through the paces on my set up...I am using a base-system with some frills and having good success.

I am following on the new thread and will begin to experiment with building a boot version following your work with developing a initramfs

[wiak]

NOTE WELL that the latest initramfs02.gz should automatically detect and load most modules (including for wifi and ethernet).

Also (optional), you can force the use of traditional interface name conventions, if you so wish (i.e. the likes of eth0, wlan0) by including (per rockedge's suggestion) the following grub kernel line parameter:

Code: Select all

net.ifnames=0

For example grub4dos menu.lst details, see post:

http://www.murga-linux.com/puppy/viewto ... 26#1031626

======================================================================


MANUALLY CONNECTING TO NETWORK:

Once you have new FirstRib-based WeeDog system booted to commandline you can easily connect to the Internet via ethernet or wifi as follows (of course you can simplify the procedure by using the relevant commands below in a simple script).

ETHERNET connection

Ethernet firmware should be auto-detected on boot.

Find out your ethernet_interface_name with command

Code: Select all

ip link

or for more detail

Code: Select all

ip address

All you need then is for system to get IP address via dhcp using command:

Code: Select all

udhcpc -i <ethernet_interface_name>

Should now be connected. Test with say: ping google.com
-------------------------

WIFI connection

On boot wifi device should be detected automatically. Then simply run the following commands (note well the use of >> for "append to"):

Code: Select all

wpa_passphrase <yourwifiSSID> <passwordKey> >> /etc/wpa_supplicant/wpa_supplicant.conf

(i.e. In the above you need to supply your wifi connection name and password)

Find out your wifi_interface_name with command

Code: Select all

ip link

or for more detail

Code: Select all

ip address

Then use wpa_supplicant to connect:

Code: Select all

wpa_supplicant -i <wifi_interface_name> -c /etc/wpa_supplicant/wpa_supplicant.conf -B

(the -B runs wpa_supplicant in the background).

Finally, you need IP address from dhcp. Get that with command:

Code: Select all

udhcpc -i <wifi_interface_name>

(or whatever your wifi interface name is).

Should now be connected. Test with say: ping google.com
------------------------------

wiak

[westwest]

Hello, firstrib built successfully within scpup64...

I've installed VLC, which cannot be run as root. What would be the steps to make this possible in firstrib?

Tried adding user:puppy, but i understand too little about permissions to make this work.
Same after installing sudo with xbps.

Any help appreciated, thank you.

[rockedge]

@westwest

open a terminal and type ->

Code: Select all

sed -i 's/geteuid/getppid/' /usr/bin/vlc

this only needs to be done once

then start VLC

[westwest]

Thanks, VLC now starts. I'm getting a message about missing i965 driver,
but that seems to have no effects on media playback.

Is it possible or advisable to mount more than one shared folder with mount_chroot? And does umount_chroot need to be adjusted accordingly?

[westwest]

Also, could it be possible in any way to run firstrib32 inside a 64bit distro?

[wiak]

Is it possible or advisable to mount more than one shared folder with mount_chroot?

Yes, it is fine. For example, I was using the following additions to mount_chroot.sh running firstrib_rootfs in BionicPup64 host system:

Code: Select all

mkdir -p firstrib_rootfs/varpackages
mount --bind /var/packages firstrib_rootfs/varpackages
mkdir -p firstrib_rootfs/oldroot
mount --bind /root firstrib_rootfs/oldroot

And does umount_chroot need to be adjusted accordingly?

Yes, after 'exit' from chroot. ./umount_choot.sh, for above extras, should contain:

Code: Select all

umount firstrib_rootfs/varpackages && umount firstrib_rootfs/oldroot

Also, could it be possible in any way to run firstrib32 inside a 64bit distro?

Yes, that's not a problem. To test, I build a firstrib_rootfs in BionicPup32 and then re-booted into BionicPup64 and ran that 32bit firstrib_rootfs build as usual with ./mount_chroot.sh.

What wouldn't work, would be to try and run a firstrib64 inside a 32bit host system since the binaries inside firstrib64 need 64bit host kernel.

wiak

[fredx181]

Is it possible or advisable to mount more than one shared folder with mount_chroot?

Another shared folder that can be added is /run/udev (to be able to run an X session in chroot), but it needs to be created in the chroot (see below, mkdir ...).
Works for me then running X in chroot, with working keyboard and mouse, found info here:
https://superuser.com/questions/688766/ ... ain-chroot

I have in mount_chroot.sh (in bold what I added):

# bind mount host virtual filesystes required for chroot into firstrib_rootfs to work on host system
mkdir -p firstrib_rootfs/run/udev
mount --bind /proc firstrib_rootfs/proc && mount --bind /sys firstrib_rootfs/sys && mount --bind /dev firstrib_rootfs/dev && mount -t devpts devpts firstrib_rootfs/dev/pts && mount --bind /tmp firstrib_rootfs/tmp && mount --bind /run/udev firstrib_rootfs/run/udev && cp /etc/resolv.conf firstrib_rootfs/etc/resolv.conf

Unmount firstrib_rootfs/run/udev when done or add to umount_chroot.sh:

Code: Select all

umount firstrib_rootfs/run/udev

The easiest to try is with twm window-manager since it's default in etc/X11/xinit/xinitrc
To install (e.g. also to make startx work)

Code: Select all

xbps-install coreutils file mc bash xorg-minimal twm xterm dejavu-fonts-ttf xclock xinit util-linux libEGL

(not sure if libEGL is required, for me it was (xserver error without it)
And run startx to get in twm. (type exit in the "login" terminal to leave the X session)

I expermented with openbox too and it worked (by replacing twm with openbox above) but it needs some editing of etc/X11/xinit//xinitrc in the chroot:
Last lines:

Code: Select all

#twm &
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
#exec xterm -geometry 80x66+0+0 -name login
exec openbox-session

I'm not sure if this all works on any OS, I tested only on Stretchdog.

When booting with initramfs.gz I tried also and could start X, but keyboard and mouse not working, can't figure out how to solve, maybe it's because /run is empty.

Fred

[wiak]

Is it possible or advisable to mount more than one shared folder with mount_chroot?

Another shared folder that can be added is /run/udev, but it needs to be created in the chroot.
Works for me then running X in chroot, with working keyboard and mouse, found info here:
https://superuser.com/questions/688766/ ... ain-chroot

Very good info Fred. Rockedge, in particular, will I'm sure find that very useful. I also see FirstRib run in a chroot on a host Linux system as an attractive add-on to very small core distros like tinycore since having xbps package manager and build utilities is useful for me.

NOTE: you should xbps-install -S ncurses-base
also so that backspace key works correctly with bash.

Getting X working in initramfs.gz included version will no doubt also get solved in time. This week for me though will continue with me finishing off a switch_root initramfs.gz version since that fits bigger rootfs better. As I said, then I also will be playing with trying to get X working and mouse/keyboard etc working.

EDIT: Via that link above that you posted Fred, I also came across Xpra (whichs "started as screen for X"), which also looks interesting (as of course are the discussed elsewhere: Xnest and Xephyr):

https://kb8ojh.net/elb/musings/tag/xpra
http://xpra.org/trac/wiki/About

There are certainly a lot of interesting schemes out there.

EDIT: I can confirm that X worked, as Fred described, with firstrib_rootfs mount_chroot.sh on BionicPup64 host system too.

wiak

[wiak]

When booting with initramfs.gz I tried also and could start X, but keyboard and mouse not working, can't figure out how to solve, maybe it's because /run is empty.

EDIT: Come to think of it, you'd really need to do the following using BionicPup (version you are using) if that was the zdrXX.sfs you planned to use with initramfs.gz since won't know what modules needed (or already in BionicPup vmlinuz) otherwise.

Aside from looking at modules loaded on host system with lsmod, it would probably be worth checking out host's udev rules then, since, for keyboard/mouse with X, I'm pretty sure initramfs.gz firstrib version will simply need correct modules loaded (which should load required firmware) for mouse/keyboard to work. I didn't check out udev last night but I was looking at some likely modules my host system loads, such as hid-generic.ko and usbhid.ko (modprobe usbhid, or modprobe hid-generic, would also load hid.ko according to modules.info or "modinfo hid-generic" or "modinfo usbhid" command). After all, I guess that's most of what udev does anyway (and triggers scripts etc). Probably more modules need loaded, depending on system hardware, maybe not... (psmouse.ko on old systems?), but like I say, I have just been reading about it - not as yet trying any of it out.

So, I suggest simply trying:

EDIT: the following no use for BionicPup64 since following modules available there. I suspect for that case, usbhid is already built into the kernel.

Code: Select all

modprobe hid-generic
modprobe usbhid

prior to startx

in the initramfs.gz independently booting FirstRib-based WeeDog.
_________

Though I'm pretty sure manual modprobe the relevant modules will get mouse/keyboard working prior to startng X, if you wish you can find a lot of udev-related info by running following command from a terminal on host Linux system:

Code: Select all

udevadm monitor

whilst, for example, plugging usb mouse (or keyboard) in and out, and then using command:

Code: Select all

udevadm info -a -n <name>

where <name> is what udevadm monitor revealed for mouse or keyboard (a long string) similar to what is decribed in following link:

http://granjow.net/udev-rules.html

EDIT: I tried above both by plugging in and unplugging out both usb mouse and usb keyboard. I noticed the keyboard also needed driver uhci_hcd but 'modinfo uhci_hcd' revealed no such module on my XenialDog64 system, so I guess it is built into the kernel. Otherwise I would have had to modprobe it too (or insmod it and all its dependency modules).

EDIT2: I'm don't really understand why this is, but when using BionicPup32, my wifi firmware gets loaded, but I noted that BionicPup32 disn't include it in /lib/firmware (so I presume built into kernel). However, firstrib WeeDog (i.e. with initramfs.gz) wouldn't load my wifi unless I included /lib/firmware/iwlwifi_firmware_for_my_system. Seems stuff built into kernel (if I'm correct) doesn't get seen after the chroot so has to be modprobed... That would mean modules usbhid.ko and hid-generic.ko and hid.ko modules would need to be available, and manually loaded (which they aren't in zdrv of the BionicPup64 I actually ended up using). As I say, I'm not sure about that but thinking it might be the problem (alas, I don't have these BionicPup64 modules to try).

Fred, how do you startx in initramfs version anyway? Mine just crashes out saying Display can't be found or something, so I guess some extra stuff is needed (graphics/xorg-servers for graphics card type etc?). I looked in /var/log/Xorg.0.log but it's too long since I ever mucked around with X and I can't remember any of it.

wiak