The kernel has the ability to include the initrd when built, have you considered adding such a beast?

+ easy install, fast boot, simple tracking, easier version control
- kernel may need to be rebuilt if the initrd is modified

Perhaps only do it if configured to do so?

I've done it once before with an lzma'd kernel with fairly impressive results, but I was working with an "extreme" minimal kernel and everything (including X) as a single static multicall binary in the initrd (a real painful learning experience btw)_________________Web Programming - Pet Packaging 100 & 101

I'm lost my interest in Saluki. While the nice "static or not static" conversation goes on in the Saluki front, the real hard work is done on the 5.3 and Wary fronts, by people who work more and talk less.

I wanted a kernel build script and wrote one. That's how I work. Enough talking and planning of a project without any product so far ... it's time to bring features to the table and that's what 01micko and the 5.3 guys do, unlike Saluki. I decided to join this effort.

So if you ask me - no, I won't help with Saluki's kernel ... well, at least I won't do it actively. However, this can be a kernel if the Saluki team wants it._________________My homepageMy GitHub profile

Being hard coded to 2.6.32 isn't a bad thing just a restrictive thing.

You could easy adjust to use any sauce you want.. with special cases for the LTS branches.

I just compiled 2.6.37.6 basically following your script manually. It may need a break at the configuration part where "make gconfig" (or whatever config option) could be run to configure the source. (hehe.. make xconfig is nice.. but needs qt :0 )

I reckon the kernel version could be passed as a commandline param.. that would nullify your little read at the start! (no param, no start)

As for patches.. well aufs gets the right version from git anyway, printk.c patch is basic arithmetic.. the stumbling block would be the aufs-allow-sfs.patch.. however the version for 2.6.32 seemed to work perfectly for 2.6.37.6. (I haven't tested outside of the full install as yet, so that's tentative ). Where does that patch come from anyway??? Is it a BK orig?

The vortex patch is machine specific and not needed for a main puppy kernel and probably (though I didn't test) wont work in newer kernels anyways. Perhaps a simple test there.

Ah.. then the config.. that would be daunting for a kernel noob (such as myself) .. so maybe a pause in the script so a config option could be run? Maybe based on a latish default DOTconfig? That way all the normal puppystuff is there.... and new stuff is tagged as (NEW) with a default recommendation (if using the commandline). The GUI version is super easy.. a dot (like a radiobutton) for module or a check for builtin. Just food for thought . Even just stop the script instead of erroring to alert the user that a valid DOTconfig is needed. It can be restarted just fine._________________Woof Mailing List | keep the faith |

I hand-crafted the aufs-allow-sfs.patch patch to be generic - the two lines it replaces are common to all Aufs branches, so it should work on any 2.x version, until the two lines it replaces are gone from Aufs.

The BFS patch and the vortex patch are Barry's. However, the bfs_cpufreq_tweaks patch is something I had to backport from later kernels, because Con Kolivas doesn't make one for 2.6.32.x.

Finally, regarding the .config - the defaults are really stupid in many cases, so it's impossible to make a .config generator. And the patches are suitable for a certain kernel version - you'll have to download patches that suit your kernel version manually, no matter what, that's why I don't add a command-line argument for the kernel version. Well, that's how I see it._________________My homepageMy GitHub profile

There are two reasons why my patch is better (IMHO):
- If the lines Barry's patch relies on are gone in a future Aufs version, a new patch is needed. Mine relies only on two lines, which persist through the Aufs history.
- Two structs are allocated on the stack and the function returns 0 without using them ... so why allocate them? GCC won't compile the code after the "return 0" and the structs won't be allocated with my patch._________________My homepageMy GitHub profile

I'm currently doing a test build of a new version of the script. I already mentioned it in Barry's blog and the spup thread.

It's a Python script which generates a Bash build script. It has the ability to deblob the kernel with the Linux-libre scripts and has many improvements.

Also, it's much tidier because I replaced some strings. For example, instead of using "linux_kernel-$kernel_version-$suffix" in many places, I created a variable which stores this string, so many lines of code are shorter and clearer.

Moreover, there's a small bonus ... it patches the kernel with a patch which adds a 224-color Puppy Linux logo. People who use framebuffer consoles with enough colors should see it

I already built a 5.2.5 with a previous version, but it wasn't Linux-libre. The logo appeared and it worked nicely, just like the 2.6.32.40 built by the script.

Here's the output of the latest development version (Linux-libre 2.6.32.41 with BFS):

Features:
- A Python script which generates a kernel build script, more dynamic, more programmable.
- Support for Linux-libre deblobbing for free software lovers
- Support for firmware removal
- Patches the kernel for compatibility with all bug-fix releases of the same stable release (e.g all 2.6.32.x kernels are named "2.6.32")
- Automatically reduces the number of consoles and the kernel verbosity, to save memory and additional gray hair
- Automatically patches the kernel with a Puppy Linux logo
- Builds kernel headers and sources packages
- Strips kernel modules to reduce size
- Better!

How to use it?
- Create a directory named after the kernel branch you use (e.g 2.6.35 for 2.6.35.13) and a configuration file named DOTconfig-$kernel_version. See the 2.6.32 example.
- Run create_kit.sh and put the desired kernel version and download mirror.
- ROX will open in the output directory. Take all files from there to your desired build location and run build.sh.

Simple as A-B-C. For Linux 2.6.32.x you can skip the first step, because the kit already has the patches and the configuration file. I want to add another kernel to the kit - the more kernels I add, the easier things get. This mechanism allows Puppy kernel guys to build multiple kernel versions and track down changes.

The deblobbing needs some testing - the latest deblob-2.6.32 script broke 2.6.32.41 for some reason. It was some syntax error in a driver which got stripped by it. Also, the package creation part needs testing because so far it failed again and again as I added the more advanced features. However, an initial build of this kit produced a really solid kernel.

Here's the build script (the latest one, using it right now - it's a traditional, non-libre build with firmware) produced by it: