how to build myself a next Quirky starting out with the kernel like Quirky 5.4.91?
perhaps per example with the stuff of the next Quirky 6...
How to build a ALL-IN-KERNEL-Quirky with a different kernel?
How to build a ALL-IN-KERNEL-Quirky with a different kernel?
Last edited by slackfan on Fri 07 Mar 2014, 21:23, edited 1 time in total.
was that the one where it had the inirtd attached to end of kernel so you basically had only one file needed to boot into a puppylinux?
I recall that and I think it is a setting in the wolf build system still. Any one else remember? it was a cool idea, If we could also wrap the sfs file into the inird attached to end of kernel like fatdog does in inird. Then we would only need 1 files to boot from. And if we named it bootx32.efi or 64 then we could make it easy to boot in UEFI... no loader needed
I recall that and I think it is a setting in the wolf build system still. Any one else remember? it was a cool idea, If we could also wrap the sfs file into the inird attached to end of kernel like fatdog does in inird. Then we would only need 1 files to boot from. And if we named it bootx32.efi or 64 then we could make it easy to boot in UEFI... no loader needed
exact
but the most import thing:
if you have a big collection of SFS like the collection from RSH for his modular systems, you can put all your puplets in the same directory (or directly in / if you want, in this case the SFS also to be there)
and as I did observe in Quirky 5.4.91 grub needs only to invoque the kernel and nothing more so it would be possible to use EASILY the Grub2 command line to start from nothing in grub.cgf and make the use of the PC from cold start very difficult for someone not really very well informed on such details (if you have no drive in it as it is is easy in my PC, I only have a CD ready build in but removable and used as USB drive, you can remove it, don't permit bootable USB stick in BIOS and interchange grub.cfg manually : nothing to do anymore to start the PC without command line entry ! the kernel name is in this case as important as a password! and knowledge on Grub2 command line system!)
but the most import thing:
if you have a big collection of SFS like the collection from RSH for his modular systems, you can put all your puplets in the same directory (or directly in / if you want, in this case the SFS also to be there)
and as I did observe in Quirky 5.4.91 grub needs only to invoque the kernel and nothing more so it would be possible to use EASILY the Grub2 command line to start from nothing in grub.cgf and make the use of the PC from cold start very difficult for someone not really very well informed on such details (if you have no drive in it as it is is easy in my PC, I only have a CD ready build in but removable and used as USB drive, you can remove it, don't permit bootable USB stick in BIOS and interchange grub.cfg manually : nothing to do anymore to start the PC without command line entry ! the kernel name is in this case as important as a password! and knowledge on Grub2 command line system!)
Notwithstanding a GRUB4DOS or GRUB2 boot the ISO on the CD. ISO is the only single file that would be needed.
And following the work being done by @GreenGeek (aka @Ted Dog), persistence-personalization would be acquired by native ISO at boot.
Just another approach to boot a single file. If this kind of approach is used, the authors for distros would have the freedom to generate any boot structures they feel comfortable with into an ISO. Then via some standard BootManager(BM) steps, that ISO (or any individual ISO) could be booted. This allows the freedom on ISO containing single humongous kernel or humongous initrd or adrv or zdrv or ... to be employed as a develop sees fit, while all anyone would need is point the boot manager at the ISO and the system would emerge. Nothing would need changing in the ISO and persistence-personalization would continue to work as it does, today.
Biggest problem, in today's PUPs is having some agreed to BM that make this simple for distro developer use and deploy.
How many are aware of @MikeB's KVM Launcher which allow any user to point it at an ISO, and that PUP will emerge on your desktop? And, the booted ISO will save your personalization-persistence as you go. Might want to have a look at it for one version of ISO booting.
Hope this helps
And following the work being done by @GreenGeek (aka @Ted Dog), persistence-personalization would be acquired by native ISO at boot.
Just another approach to boot a single file. If this kind of approach is used, the authors for distros would have the freedom to generate any boot structures they feel comfortable with into an ISO. Then via some standard BootManager(BM) steps, that ISO (or any individual ISO) could be booted. This allows the freedom on ISO containing single humongous kernel or humongous initrd or adrv or zdrv or ... to be employed as a develop sees fit, while all anyone would need is point the boot manager at the ISO and the system would emerge. Nothing would need changing in the ISO and persistence-personalization would continue to work as it does, today.
Biggest problem, in today's PUPs is having some agreed to BM that make this simple for distro developer use and deploy.
How many are aware of @MikeB's KVM Launcher which allow any user to point it at an ISO, and that PUP will emerge on your desktop? And, the booted ISO will save your personalization-persistence as you go. Might want to have a look at it for one version of ISO booting.
Hope this helps