Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 17 Apr 2014, 20:26
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
pUPnGO - 6Mb ISO - Basic Building Block Puplet
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 57 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 55, 56, 57, 58 Next
Author Message
wanderer

Joined: 20 Oct 2007
Posts: 212

PostPosted: Sun 22 Dec 2013, 15:04    Post subject:  

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

wanderer
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 777

PostPosted: Mon 23 Dec 2013, 06:24    Post subject:  

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, 11:18; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
Ted Dog


Joined: 13 Sep 2005
Posts: 2051
Location: Heart of Texas

PostPosted: Mon 23 Dec 2013, 14:07    Post subject:  

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? Shocked
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 777

PostPosted: Mon 23 Dec 2013, 15:52    Post subject:  

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:
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:
mount -t ext4dev /dev/sdc9 /mnt/sdc9


but even then mount fails. dmesg says
Quote:
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.
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Mon 23 Dec 2013, 20:15    Post subject:  

@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

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ted Dog


Joined: 13 Sep 2005
Posts: 2051
Location: Heart of Texas

PostPosted: Mon 23 Dec 2013, 20:26    Post subject:  

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
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Mon 23 Dec 2013, 22:30    Post subject:  

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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 1875
Location: The Blue Marble

PostPosted: Mon 23 Dec 2013, 22:50    Post subject:  

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, Slacko and Puppeee user. Puppy user since 2.13
Back to top
View user's profile Send private message 
Ted Dog


Joined: 13 Sep 2005
Posts: 2051
Location: Heart of Texas

PostPosted: Mon 23 Dec 2013, 23:22    Post subject:  

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.. Rolling Eyes
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 1875
Location: The Blue Marble

PostPosted: Mon 23 Dec 2013, 23:36    Post subject:  

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.

Quote:
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 Laughing )

Quote:
The grub EFI loader for Fatdog64 takes 7M and does nothing else special.. Rolling Eyes
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 Shocked It may work with pupngo, whose size is a lot smaller.
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13
Back to top
View user's profile Send private message 
Ted Dog


Joined: 13 Sep 2005
Posts: 2051
Location: Heart of Texas

PostPosted: Mon 23 Dec 2013, 23:44    Post subject:  

doesn't the EFI already used a KEXEC patched shim kernel to boot GRUB with Fatdog64?
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Tue 24 Dec 2013, 00:23    Post subject:  

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/binaries/cross-compiler-armv7l.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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Ted Dog


Joined: 13 Sep 2005
Posts: 2051
Location: Heart of Texas

PostPosted: Tue 24 Dec 2013, 00:41    Post subject:  

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.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 1875
Location: The Blue Marble

PostPosted: Tue 24 Dec 2013, 00:48    Post subject:  

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/binaries/cross-compiler-armv7l.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).

Quote:
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 ...)

Quote:
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.

Quote:
... 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

Quote:
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" Sad
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13
Back to top
View user's profile Send private message 
Ted Dog


Joined: 13 Sep 2005
Posts: 2051
Location: Heart of Texas

PostPosted: Tue 24 Dec 2013, 01:22    Post subject:  

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.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 57 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 55, 56, 57, 58 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1195s ][ Queries: 12 (0.0148s) ][ GZIP on ]