pUPnGO - 6Mb ISO - Basic Building Block Puplet

A home for all kinds of Puppy related projects
Message
Author
wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#841 Post by wanderer »

thanks goingnuts
i appreciate you taking the time
fantastic project
a real advance

wanderer

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

#842 Post by goingnuts »

Thanks. Although I gave up a 2013 version a snapshot of current state of the core pupngo - with kernel from P216 - and holding 4 Original Puppy versions (P216, P300, P413 and Wary5.3) as sfs-extensions to run after boot can be downloaded here [download removed 20140117]. Note that iso size is approx. 350 Mb and that this is an old kernel. Used on a modern pc you might lack driver support for some of your hardware.
After boot use command "firstboot" - choose "Configure now" to set network/keybord/time - an ethernet connection is most likely to work (wireless can not be configured here). After that choose "Install programs from bootcd" to choose which version of Puppy to load. Exit and run xwin (note for wary run startx). If you don't do things that block the appended sfs for umount (like running xorgwizard) - you should be able to exit to prompt and run otf_sfs_loader.sh and unload the Puppy-sfs currently loaded. After that run "firstboot" again to load a different Puppy version. This is just a quick compilation and none of the different versions loads of applications has been tested. So expect bugs and nonfunctional applications. One could even think of loading several Puppy versions at the same time - just to see what happens...
Last edited by goingnuts on Fri 17 Jan 2014, 15:18, edited 1 time in total.

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#843 Post by Ted Dog »

ever think about this as a highly functional boot loader? with KEXEC patch you could launch other linux isos Instead of adding sfs support like you are. Also care to help me port this to ARM? :shock:

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

#844 Post by goingnuts »

Ted Dog: I would like to help but have no ARM knowledge, hardware or what else is needed.

A question was asked if P412 support ext4.
* Seems that it should be partly supported by loading module ext4dev (modprobe ext4dev) - but not handled in initrd so no boot from ext4.
* Need e2fsprogs-1.41.or later to create ext4 (need update of /etc/mke2fs.conf to work).
* To create

Code: Select all

mke2fs -T ext4dev /dev/sdc9
.
* need ext4 capable version of guess_fstype
* Need patch of /sbin/pup_event_frontend_d - add ext4 2 places in code to have deskdrive icon shown.
* Need util-linux-2.19 or later - to mount

Code: Select all

mount -t ext4dev /dev/sdc9 /mnt/sdc9
but even then mount fails. dmesg says
EXT4-fs: sdc9: Filesystem with huge files cannot be mounted read-write without CONFIG_LSF
Kernel must be compiled with "Support for Large Single Files"

So might be possible to get ext4dev working but need kernel recompile, initrd modifications and other upgrades.

Added: P431 should have a better chance - seems that ext4 support is build in kernel. But included mount-FULL version seems too old (util-linux 2.13-pre7) - but has mkfs.ext4 and guess_fstype is also allright - although I have not tested P431 in respect to create & mount an ext4 partition.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#845 Post by technosaurus »

@TD - I would recommend starting with one of the aboriginal linux toolchains and building from source. ... We really need to get the core tools onto github.

@goingnuts - would you be able to push your toolchain to github or possibly a fossil repo on goingnuts.dk?

I would really like to set up the build as a combo of busybox/toybox multicall build with ffmpeg's license white/blacklist options added on... so that if needed we could build a permissive license only build. X+hazewm+st+tcl/tk instead of X+jwm+rxvt+gtkdialog ... but this is in part because I would like to support BSD in addition to Linux (still doing research) ... this means using $CC instead of hardcoding gcc as well as weaning ourselves from using GNUisms, but I have most of that under control already
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#846 Post by Ted Dog »

FatdogARM will serve as build environment with distibuted compiles with Fatdog64. Aboriginal Linux is too baren to be comfortable to use. Yes please setup a git so others can build upon this effort.
I like how plop linux did its own boot loader. Wish a puppy like plop loader existed. This project would be perfect fit... :wink:

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#847 Post by technosaurus »

Ted Dog wrote:FatdogARM will serve as build environment with distibuted compiles with Fatdog64. Aboriginal Linux is too baren to be comfortable to use. Yes please setup a git so others can build upon this effort.
I like how plop linux did its own boot loader. Wish a puppy like plop loader existed. This project would be perfect fit... :wink:
You are missing my point. Aboriginal provides the minimum environment to bootstrap a system. Pupngo's utils only need this minimal environment to build and Rob provides a standardized environment for many different architectures that would act as a stage1. I am sure fatdog is more than plenty to build pupngo but we don't want more than enough. Aboriginal is specifically designed to have distributed builds across qemu using distcc, but more importantly it provides a standard set of tools across 16 different architectures capable of building a full Linux from Scratch build (which is more than what we need). Some of the Puppy developers (mostly the coder types) already work with Aboriginal's maintainer on toybox. If we use Rob's tools and update them as needed we will have the advantage that he has no problem setting us straight if we get off track or make something more complicated than it needs to be.

As bootloaders go I am not too concerned and would rather not use a bootloader at all if was possible (i.e. use EFI or coreboot bios instead to skip that unnecessary step) ... It really only matters that they can pass parameters to the kernel/init. Most users don't care what parameters are being passed, so the boot screen could be: Mom, Dad, Johnny, Janey, guest with configurable fg and bg color (or none at all on a single user system, just go straight to the default) Keep in mind that grub/syslinux/lilo/etc... are mostly x86. Other boot loaders support more architectures.

I'm not sure if I have made my vision clear enough. We should skip as much unnecessary commandline BS as possible before going to X and try not to use tools that are specific to one system/architecture.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#848 Post by jamesbond »

technosaurus wrote:Aboriginal provides the minimum environment to bootstrap a system. Pupngo's utils only need this minimal environment to build and Rob provides a standardized environment for many different architectures that would act as a stage1.
For whatever it is worth, I *did* use parts of Aboriginal (cross/native compilers) to bootstrap FatdogArm. It wasn't the easiest way to do things because Aboriginal is stuck with gcc 4.2.2 which doesn't support ARMv7; but it did get me started.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#849 Post by Ted Dog »

You both figured out how to get something useful out of aboriginal linux. I spent 6 months trying to do something useful but beyond what was supplied. I took away that it was just a self satisfaction exercise by its author. No support. no replies, even to a fellow Texan is just plan rude.
Use what you like but I was never a fan CLI only development. You are also answering to my intended use as a boot loader, but can't follow your reasons to rapidly discount this idea. If PLoP linux can add booting in situations not available using more common used loaders then Why can't puppy benefit from same techniques? The grub EFI loader for Fatdog64 takes 7M and does nothing else special.. :roll:

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#850 Post by jamesbond »

Ted Dog wrote:No support. no replies, even to a fellow Texan is just plan rude.
Hmm, that's surprising. Rob is quite active in some mailing lists, but I haven't interactive personally with him so I can't tell for sure.
If PLoP linux can add booting in situations not available using more common used loaders then Why can't puppy benefit from same techniques?
I think this idea has merit - but I'm only a visitor in this thread (what does a guy who shoots for multimegabytes distro doing in a forum discussing sub-10MB puppy anyway :lol: )
The grub EFI loader for Fatdog64 takes 7M and does nothing else special.. :roll:
It is to overcome Secure Boot and provides to menu for various boot options in case of boot problems. I think technosaurus point is to eliminate that 7MB altogether and has the EFI firmware load the kernel directly, without that 7M blobs ... thus no more boot menus. You can't do this with Fatdog - no sane EFI firmware will load a kernel whose size is 250MB :shock: It may work with pupngo, whose size is a lot smaller.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#851 Post by Ted Dog »

doesn't the EFI already used a KEXEC patched shim kernel to boot GRUB with Fatdog64?

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#852 Post by technosaurus »

jamesbond wrote:Aboriginal is stuck with gcc 4.2.2 which doesn't support ARMv7; but it did get me started.
http://landley.net/aboriginal/downloads ... 7l.tar.bz2
IIRC it is possible to configure it to use later versions of gcc; however later versions have a lot more external dependencies. One of the things that aboriginal's build does not take advantage of is the ability for binutils/gcc to do a single tree build where all the dependencies are in a single build directory (not surprising since this feature is barely documented at all). This uses newlibc in the tree and there is very little documentation on it - I was able to do it once just to satisfy my own curiosity, but I now wish it were the standard way because once it was set up everything went smoothly by a factor of N (where N is the number of dependencies). Just an FYI, most of the tools statically link against many of the same libraries, so our multicall binary method could reduce the size of the toolchain as much as 90%.

RE: EFI if you have followed Barry's recent quirky experimentation, he is almost to where I was about a year ago (I tried to send him a courtesy PM, but I am sure he had fun figuring it out on his own anyhow). Basically what you do is build a mostly modular kernel with EFI support and all the necessary modules to get to X built in (this is only about half a Mb) + whatever filesystems you plan to support. In the builtin kernel command line you add root=PARTUUID=<our-predetermined-UUID> and as part of the install use gdisk to set the GPT's global UUID for the installed partition to <our-predetermined-UUID> (There are other steps, but this is the important one). This bypasses the need for kexec-ing and should cut about half a second (or more) from the boot process.
... but there is no _real_ limitation on kernel size AFAIK as long as the monolithic part fits into the EFI partition.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#853 Post by Ted Dog »

yep EFI for windows 8 are around 300M so not your grandpa's BIOS limitations. I must have missed your boot work a year ago. Do you have links? I do not see BK heading to EFI unless I'm missing something. I haven't been following too closely Q6.01 work since I can't justified such a limited use of a flashdrive with cost.
I have been looking into how windows8 uses flashdrives for recovery and do see some similarities between setups.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#854 Post by jamesbond »

Ted Dog wrote:doesn't the EFI already used a KEXEC patched shim kernel to boot GRUB with Fatdog64?
No. The boot process under EFI for Fatdog64 is as follows:
EFI firmware --> mjg59's shim --> rEFInd --> grub2 --> Linux kernel

What technosaurus is aiming is:
EFI firmware --> Linux kernel

So what are the components used?
- mjg59's shim is needed for Secure boot
- rEFInd is the EFI bootmanager + boot loader
- grub2 is needed because rEFInd can't load kernel from ISO

There is a great overlap between rEFInd and grub2, but on ISO both are needed:
- rEFInd allows you to execute *other EFI binaries* (e.g. shell tool, etc) - useful for troubleshooting
- grub2 is needed because rEFInd can't load kernel directly from ISO

On normal frugal install, you don't need both, either rEFInd or grub2 will suffice.
technosaurus wrote:
jamesbond wrote:Aboriginal is stuck with gcc 4.2.2 which doesn't support ARMv7; but it did get me started.
http://landley.net/aboriginal/downloads ... 7l.tar.bz2
It wasn't there when I started FatdogArm; and if you look inside the binutils supports ARMv7 but the compiler is all armv6. I haven't tried it myself so I'm not sure whether it is working; but I've tested the armv7l-rootfs and it doesn't work (doesn't boot - kernel problem).
IIRC it is possible to configure it to use later versions of gcc; however later versions have a lot more external dependencies.
Which makes it more difficult by an order or magnitude (unless you already know what you're doing ...)
One of the things that aboriginal's build does not take advantage of is the ability for binutils/gcc to do a single tree build where all the dependencies are in a single build directory (not surprising since this feature is barely documented at all). This uses newlibc in the tree and there is very little documentation on it
+1 There is barely documentation about "how to build gcc properly". Most of the documentation deals with using gcc compiler assuming gcc is already available.
... but there is no _real_ limitation on kernel size AFAIK as long as the monolithic part fits into the EFI partition.
There is no real limitation but there is *practical* limitation, some EFI firmware refuses to load extremely large kernels (or crashes in the process of doing so). Using EFI firmware directly means no external initramfs; the initramfs has to be included in the kernel. In case of Fatdog with huge initramfs, binding it to the kernel makes over 250MB which probably isn't palatable for many EFI firmwares. Pupngo is in a much better situation to take advantage of this --- assuming that the boot never fails (there is no fallback plan in EFI other than using firmware-provided menu).
Ted Dog wrote:yep EFI for windows 8 are around 300M so not your grandpa's BIOS limitations.
I'm not talking about the size of the EFI partition. I'm talking about the size of the "boot application" to be loaded by EFI firmware (which I referred to as the "kernel" in the previous paragraphs). I don't have Win8 handy so I can't tell, but IIRC the size of this "boot application" is much less than 5MB. If you want to check, this would be the size of /EFI/BOOT/BOOTX64.EFI
I do not see BK heading to EFI unless I'm missing something.
Barry publicly denounced UEFI quite a while ago. I don't think his position has changed. For the better or worse, however, UEFI is the future - at least for the time being. I don't see many machines comes with "coreboot" :(
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#855 Post by Ted Dog »

Thanks for the layout of Fatdog64 boot sequence. mjg59 is the signed linux kernel with KEXEC patch that gets the process started. ideally a distro wide shim and intelegent loader to replace rEFInd grub setup. And provide a way of dropping all the boot loader wars on this forum. And providing a new way. I only discovered PLoP a few weeks ago and it solved a long time problem of booting CDs for machines that did not support it. Then it dawned on me with the right techniques a micro puppylinux would provide a better base than a two year old version of plops loader.
JamesBond your problem solving is inspiring, was not looking down on your methods just as a size reference, sorry bad place to post an emoticon.

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

#856 Post by goingnuts »

technosaurus wrote:...
@goingnuts - would you be able to push your toolchain to github or possibly a fossil repo on goingnuts.dk?
...
I will try but may take a while. Meanwhile below is the packages used to populate initrd:

Code: Select all

fileutils-4.1
disktype-9
e2fsprogs-1.40.2
elspci-1.0
findutils-4.1.20
fuse-2.6.0
guess_fstype_withext4_test1
util-linux-ng-2.17.2
busybox-20100217
ntfs-3g-2009.3.8
And the packages needed to make the core-pupngo sfs:

Code: Select all

setserial-2.17
syslinux-2.13 (or 4.00)
squashfs3.0
squashfs4.0
module-init-tools-3.3-pre11
ndiswrapper-2
sysfsutils-2.1.0
pcmciautils-014
puppyinputdetect-1.1i
hotplug2stdout-1.2.2
udev-124
psmisc-21.2
tar-1.15.1
dialog-1.1-20120706
dvd+rw-tools-7.0
wavplay-2.0
minimp3_source
dhcpcd-3.1.8
grub_0.97
wireless_tools.29
iptables-1.4.0
cdtool_2.1.8
diffutils-2.8.1
man-1.6e
wget-1.9.1
cdrkit-1.1.10
Most of them builds static with P412 glibc/uclibc - but some of them needs patching.
Apart from that the kernel+modules and initrd+core-sfs file-skeleton including all the scripts.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#857 Post by amigo »

I just saw a reference to dietxlib-0.04.tar.gz. I am unable to find a link to those sources. Any ideas?

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

#858 Post by goingnuts »

They were here but seems to have vanished. I got the source (2.2Mb) if you need it.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#859 Post by amigo »

Yes, please do make the source available somewhere -my email account is fine for that, even. You know how I collect oddities...

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

#860 Post by goingnuts »

amigo: Send to you by mail.
How about a simple spreadsheet - like The abs Spreadsheet? Builds to approx. 1Mb static linked bin with tinyxlib-4.8.0 & uclibc.
Attachments
snap0001.png
(55.17 KiB) Downloaded 1575 times

Post Reply