pUPnGO - 6Mb ISO - Basic Building Block Puplet
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...
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.
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.
* 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
but even then mount fails. dmesg says
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.
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
Kernel must be compiled with "Support for Large Single Files"EXT4-fs: sdc9: Filesystem with huge files cannot be mounted read-write without CONFIG_LSF
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.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
@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
@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].
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...
I like how plop linux did its own boot loader. Wish a puppy like plop loader existed. This project would be perfect fit...
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.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...
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].
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.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.
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]
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..
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..
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.Ted Dog wrote:No support. no replies, even to a fellow Texan is just plan rude.
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 )If PLoP linux can add booting in situations not available using more common used loaders then Why can't puppy benefit from same techniques?
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 It may work with pupngo, whose size is a lot smaller.The grub EFI loader for Fatdog64 takes 7M and does nothing else special..
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]
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
http://landley.net/aboriginal/downloads ... 7l.tar.bz2jamesbond wrote:Aboriginal is stuck with gcc 4.2.2 which doesn't support ARMv7; but it did get me started.
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].
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.
I have been looking into how windows8 uses flashdrives for recovery and do see some similarities between setups.
No. The boot process under EFI for Fatdog64 is as follows:Ted Dog wrote:doesn't the EFI already used a KEXEC patched shim kernel to boot GRUB with Fatdog64?
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.
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).technosaurus wrote:http://landley.net/aboriginal/downloads ... 7l.tar.bz2jamesbond wrote:Aboriginal is stuck with gcc 4.2.2 which doesn't support ARMv7; but it did get me started.
Which makes it more difficult by an order or magnitude (unless you already know what you're doing ...)IIRC it is possible to configure it to use later versions of gcc; however later versions have a lot more external dependencies.
+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.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
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).... but there is no _real_ limitation on kernel size AFAIK as long as the monolithic part fits into the EFI partition.
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.EFITed Dog wrote:yep EFI for windows 8 are around 300M so not your grandpa's BIOS limitations.
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"I do not see BK heading to EFI unless I'm missing something.
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]
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.
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.
I will try but may take a while. Meanwhile below is the packages used to populate initrd:technosaurus wrote:...
@goingnuts - would you be able to push your toolchain to github or possibly a fossil repo on goingnuts.dk?
...
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
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
Apart from that the kernel+modules and initrd+core-sfs file-skeleton including all the scripts.
They were here but seems to have vanished. I got the source (2.2Mb) if you need it.
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.
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