Aboriginal Linux as a Puppy Pet and Puppy

A home for all kinds of Puppy related projects
Message
Author
scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

Aboriginal Linux as a Puppy Pet and Puppy

#1 Post by scsijon »

I have created a pet that allows you to play with a busybox based aboriginal linux under puppy.

It was built with the i486 in mind and should have it's dev 'bits' already there.

It uses chroot so you don't need qemu, etc.

It installs in it's own directory under /root and starts with a script so you can play with it and see it's workings and have access to anything you build in it.

It should be found at http://www.lamiaworks.com.au/puppy/abor ... 130612.pet and is about 31meg in size and a hash of 2a21a278d28618199036dd47c70636f9.

To use it:-

drop out of your desktop to a # prompt (using a console is not suitable as you can have serious corruption);
type on on the # prompt> ./aboriginal
and you should be in it
to exit it press <ctrl>d
and you should see the word exit and a new # prompt, you should be able to start your desktop again.

Have fun.
Last edited by scsijon on Mon 01 Jul 2013, 02:46, edited 1 time in total.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#2 Post by goingnuts »

This is HOT! :D Just played a little with it:
After chroot I
* compiled & installed libz
* compiled & installed tinyXlib
* compiled & installed tiny-Xvesa
* compiled & installed m4-1.4.12
* compiled & installed dvd+rw-tools-7.0 (to check c+ build)

Then exited from the chroot.

Then populated aboriginal-filesystem-i486/dev and run the below before another chroot:

Code: Select all

if [ ! -c aboriginal-filesystem-i486/dev/null ]; then
	mknod -m 666 aboriginal-filesystem-i486/dev/null c 1 3
fi

#getting net access
cd aboriginal-filesystem-i486
mount -t proc proc proc/
cd ..

cp -af /etc/resolv.conf aboriginal-filesystem-i486/etc/resolv.conf 

#shell...
[ ! -f aboriginal-filesystem-i486/etc/profile ] && cp -af /etc/profile aboriginal-filesystem-i486/etc/profile
[ ! -f aboriginal-filesystem-i486/root/.bashrc ] && cp -af /root/.bashrc aboriginal-filesystem-i486/root/.bashrc

mount -t devpts devpts aboriginal-filesystem-i486/dev/pts
mount -t tmpfs shm aboriginal-filesystem-i486/dev/shm
mount -t proc proc aboriginal-filesystem-i486/proc
mount -t sysfs sysfs aboriginal-filesystem-i486/sys
After chroot I was able to start Xvesa. Will do further testing to get jwm & rxvt running too.

Is it possible for you to post a "recipe" for your build of the pet?
Anyway thanks a lot for doing this pet!

PANZERKOPF
Posts: 282
Joined: Wed 16 Dec 2009, 21:38
Location: Earth

#3 Post by PANZERKOPF »

goingnuts wrote:This is HOT!
Yes, this is really HOT :)
They have images for many targets: x86, arm, PowerPC etc.
http://landley.net/aboriginal/downloads/

Thanks scsijon!
SUUM CUIQUE.

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

building aboriginal

#4 Post by scsijon »

All I did was download their build script http://landley.net/aboriginal/downloads ... .3.tar.bz2, followed their instructions on how to build, created my 'aboriginal' starting script and put it all together into a pet using my version of Petmaker (2.2).

You could of used their pre-built versions if you wanted and add all sorts of things but different kernels=different results.

it's built for kernel 3.8.x.

Go herehttp://landley.net/aboriginal/screenshots/ to see the best descriptions of their versions and bases. Don't use the links on this page as most don't work properly as they were the old ones, http://landley.net/aboriginal/downloads/ do.

Have fun
Last edited by scsijon on Tue 25 Jun 2013, 00:30, edited 4 times in total.

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#5 Post by scsijon »

@goingnuts, ?do you want to build a single package with those you built and maybe well start a puppy aboriginal for those that want a minimalist system to play with.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#6 Post by goingnuts »

I was thinking about something like that but ran into problems with jwm & rxvt. They wont compile (some pthread error) and I am kind of stuck for the moment...

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#7 Post by scsijon »

goingnuts wrote:I was thinking about something like that but ran into problems with jwm & rxvt. They wont compile (some pthread error) and I am kind of stuck for the moment...
You were using a 3.8.x kernel, wern't you.

?which errors with jwm, it may be a missing package or switch.

If you can build a package of what you already have added to the basic pet, I'll see if I or joewing can sort it out.

The current building package is attached, it does almost everything you need. EDIT: I've just found it builds with kernel 3.9.

I just modified it for a puppy environment.
Attachments
aboriginal-84bd3248fad8.tar.bz2
(193.78 KiB) Downloaded 495 times
Last edited by scsijon on Tue 25 Jun 2013, 23:31, edited 1 time in total.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#8 Post by goingnuts »

I could make a package of buildscripts + sources that would compile and install zlib + tinyx11 + tinyxvesa.

I did have to eliminate the toybox and replace it with a busybox 1.20.2 as toybox-cp wont do "cp -L -rf X11 /usr/include" (correctly) which is needed for tinyxlib. Alternative the aboriginal should be rebuild without toybox and a "full" busybox.

After that a package for populating /dev should be installed. And before Xvesa can run it needs fonts and other auxiliary files.

Then you can run Xvesa...

I could include a build script for rxvt (which works in other toolchains with musl/uclibc) and you could view the build errors.

But that is a huge package to make...so before doing so I have attached the build log for rxvt. It might give some ideas...my other uclibc toolchain configure with pty/tty type: GLIBC and my musl toolchain configures with pty/tty type: OPENPTY...
This toolchain configures with pty/tty type: STREAMS which seems to be a sort of last resort...
No idea why or if this is the problem - but I think it should be solved before creating a lot of packages.
Attachments
rxvt_build_log.txt.gz
(15.83 KiB) Downloaded 579 times

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#9 Post by scsijon »

downloaded your log, will have a look and see if anything obvious, but you may get a few 'odd' questions back.

and no' we want toybox in it as it has a lot of the switches missing from busybox commands that otherwise are requiring full commands to be included, I shall pass on your comment about 'cp' as this is the sort of thing they want to know to fix. It's also needed for the cross-compile versions.-DONE

Buildscripts, source (referances rather than the source itself) would be appreciated;

and agree, want to fix problems before a major building of packages run.

comment1:Building a new one for 3.9 in the background, no problems so far. They also seem to have a control on cpu useage somewhere, so that they are not overloading a working system, which is nice.

comment2:I want to have a look at their packaging script next to see if I can 'call' another pre-named script to add others into its build. It would make sense and I think I will sugest it to them.

regards

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#10 Post by goingnuts »

adding "UCLIBC_HAS_GETPT=y" to sources/baseconfig-uClibc solve the rxvt build... :)

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#11 Post by scsijon »

@goingnuts: it also seems there are a few expected include '.h' files missing, I have asked them what gives as we will need some of them such as a libc.h if we are going to build anything decent.

It's also nice to see you've progressed with your problem.

against "comment 2" in a previous post (above), I got a reply that they do have a way, it's called 'control-images, which seems like we do when we add an extra .sfs to the system, except they do it as drive attachments on the starting command line. I prefer our way, especially now we can load/unload on the fly. It's also nice that they are all squashfs so with a little renaming I can see what's inside. The static tools may be of interest to you as it has dropbear, strace and zlib in it, the latter two I thought would be in their basic system, I have no comment on dropbear as I haven't investigated it yet.

regards

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#12 Post by Ibidem »

scsijon wrote: against "comment 2" in a previous post (above), I got a reply that they do have a way, it's called 'control-images, which seems like we do when we add an extra .sfs to the system, except they do it as drive attachments on the starting command line. I prefer our way, especially now we can load/unload on the fly. It's also nice that they are all squashfs so with a little renaming I can see what's inside. The static tools may be of interest to you as it has dropbear, strace and zlib in it, the latter two I thought would be in their basic system, I have no comment on dropbear as I haven't investigated it yet.

regards
dropbear is a small ssh mcb (server and client in one).

The command line part is because Aboriginal targets qemu, since it's a cross-compiling environment.
The sfs must be a drive or be on a drive for qemu to access it.
Also, Aboriginal is intended to be a minimal system (just enough to cross-compile), so clever scripts that don't serve that end aren't included.

OT, I may investigate the modinfo usage in eudev; I've sent modinfo patches adding multiple module support, plus -b and -k options.
toybox has lsmod, insmod, and modinfo, but not:
-compressed module support (especially in modinfo, which mmaps the module)
The theory as far as compressed ... support goes is that we have bzcat and xzcat (pending) and may have gzip sometime, so we'll use a function that detects the type of compression, spawns the decompressor, and reads the output of that.
-modprobe
I thought about the logic for this, but don't have anything more than vaguely C-ish pseudocode for the most important function, which is a recursive module loader...

Code: Select all

- modprobe
recursive insmod.
**char recursive_depload(char * modname, char ** options, dryrun) {
	if !dryrun && isloaded(modname) return NULL;
	if !dryrun (if check_blacklist(modname) return NULL;);
	array=recursive_depload(modname);
	if (array)
		orig_array=array;
		for mod in orig_array
			append(array,recursive_depload(mod));
	if !dryrun  {
		if (insmod(modname, options)) abort;
	} else 
		return array;
}
OPTIONS:
-a Loop through list, instead of treating rest of args as options.
-b Get blacklist (and options) from modprobe.conf / modprobe.d
-D dryrun
? depmod
-Needed for alias support, unless every modprobe reads all the aliases in every module. 

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#13 Post by goingnuts »

Adding

Code: Select all

CONFIG_CP=y
CONFIG_FEATURE_CP_LONG_OPTIONS=y"
to sources/baseconfig-busybox
get BB cp included but still final symlink of cp is to toybox. I cant see how to force BB-cp...so using a static cp from coreutils for now.

Change in download.sh of kernel ex:

Code: Select all

URL=ftp://kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.tar.bz2 \
SHA1=aa6187a1c212dd2d8bd906b023fcefdcf711f35e \
maybe_fork "download || dienow"
to change kernel (linux-2.6.25 wont build kernel but toolchain ok). Remove the kernel specific patches in sources/patches before building.

jwm can be build (jwm-2.0.1 & jwm-686) - although it has never been straight forward configuring and building it static.

The native-compiler-i486.tar.bz2 can after conversion to tar.gz be installed in pupngo and gives a decent starting point for a development environment. Tested build of zlib/tinyX11/rxvt after install and they are ok.

The potential of using Aboriginal Linux to build a puppy-derivative could be that different architectures would be addressed from start...
Attachments
snap0009.png
(168.54 KiB) Downloaded 1619 times

bark_bark_bark
Posts: 1885
Joined: Tue 05 Jun 2012, 12:17
Location: Wisconsin USA

#14 Post by bark_bark_bark »

I have tested this set of scripts to build a distro for the m68k arch, so i have a lightweight linux to run in ARAnyM.

The end result, these two files:

Code: Select all

./
./hda.sqf
./vmlinux
In the lilo section of my custom aranym config what do i put?

What I currently have:

Code: Select all

[LILO]
Kernel = vmlinux
Args = 
Ramdisk = 
....

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

'concept and initial testing working party'

#15 Post by scsijon »

i've had some quite comprehensive answers from the aboriginal linux group to my questions. If you've already joined their email group you should have seen both. However for the rest, I shall sort the questions and answers out and add them to this thread in the next few days.

Basically it seems it's not that hard to do what we want, we just need to know what to do in their system methodology.

And Rob Landley (barryk's equivalent) and his group seem to be happy for us to do so. I even got a 'yay!' from him.

So I'm going ahead and changing the Thread title slightly and starting to format a 'structural concept statement' for an Aboriginal Puppy that we may (hopefully) be able to have cross-compile without serious problems. I am not planning for it to be an application loaded Puppy as barry creates, with user type applications already included, but more as a 'basis to build on/from' puppy with application building ocurring after the 'core puppy' has been loaded.

I believe that I can call on goingnuts to help as he has shown in the past, as well as his work in the thread, a minimalist system leaning. I have the same!

I clearly admit that am not a programmer, but can work through an existing script and propose a change or help debug.

Do I have any other puppians willing to put up their hand at this stage to be included on at least, the 'concept and initial testing working party'?

I do admit i'd like for it to build within the woof2 framework, at least for now. Whether that can happen, I think, should be a fair part of the working party's initial task! Maybe we will eventually need to propose back to barryk changes that create a woof3.

regards
scsijon

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#16 Post by scsijon »

bark_bark_bark wrote:I have tested this set of scripts to build a distro for the m68k arch, so i have a lightweight linux to run in ARAnyM.

The end result, these two files:

Code: Select all

./
./hda.sqf
./vmlinux
In the lilo section of my custom aranym config what do i put?

What I currently have:

Code: Select all

[LILO]
Kernel = vmlinux
Args = 
Ramdisk = 
bark_bark_bark, I think you only need to put hda.sqf in the Args= line. and vmlinux should start it, alternately if that doesn't start it try Args=switch_root hda.sqf. Do you have any error messages that may help?
I don't use lilo anymore and haven't seen a M68K box for some time, my old mica was scrapped some years ago.

scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

#17 Post by scsijon »

@goingnuts, apparently there is a switch you can do in the aboriginal build line that works against toybox/busybox that allows you to tell the system which to use for common commands. When I find it again i'll add it in here.

Also, Rob sugests to download and look at the 'Linux From Scratch build control image', as it has a lot of what we seem to want, it's not small though and the download bandwith is slow, at least from here in australia.

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#18 Post by Ibidem »

scsijon wrote:@goingnuts, apparently there is a switch you can do in the aboriginal build line that works against toybox/busybox that allows you to tell the system which to use for common commands. When I find it again i'll add it in here.
That's BUSYBOX=1; it turns on busybox defconfig.

bark_bark_bark
Posts: 1885
Joined: Tue 05 Jun 2012, 12:17
Location: Wisconsin USA

#19 Post by bark_bark_bark »

scsijon wrote:
bark_bark_bark wrote:I have tested this set of scripts to build a distro for the m68k arch, so i have a lightweight linux to run in ARAnyM.

The end result, these two files:

Code: Select all

./
./hda.sqf
./vmlinux
In the lilo section of my custom aranym config what do i put?

What I currently have:

Code: Select all

[LILO]
Kernel = vmlinux
Args = 
Ramdisk = 
bark_bark_bark, I think you only need to put hda.sqf in the Args= line. and vmlinux should start it, alternately if that doesn't start it try Args=switch_root hda.sqf. Do you have any error messages that may help?
I don't use lilo anymore and haven't seen a M68K box for some time, my old mica was scrapped some years ago.
neither works, I looked in the terminal window for any info that aranym may spit out, but nothing useful.
....

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#20 Post by Ibidem »

bark_bark_bark wrote:I have tested this set of scripts to build a distro for the m68k arch, so i have a lightweight linux to run in ARAnyM.

The end result, these two files:

Code: Select all

./
./hda.sqf
./vmlinux
In the lilo section of my custom aranym config what do i put?

What I currently have:

Code: Select all

[LILO]
Kernel = vmlinux
Args = 
Ramdisk = 
This may be helpful...
http://wiki.aranym.org/afs/setup_linux
http://oreilly.com/linux/excerpts/97805 ... rence.html

The kernel has no idea what hda.sqf or anything else on the host filesystem is; it must be configured as a drive.

If hda.sqf is set up as a hard drive, I'd imagine you need:
kernel = vmlinux
args = root=/dev/hda

Though the device name is not for sure (I assume hda.sqf is a squash file)
You may need to specify rootfstype=squash (don't know the correct name!) as well.

Post Reply