kernel compiling in woof-ce

Message

stemsee · #501 Post by **stemsee** » Sun 29 Apr 2018, 08:13

k4.16.2?

Dry Falls · #502 Post by **Dry Falls** » Sun 29 Apr 2018, 08:21

Peebee used k4.16.2 but I haven't tried it. k4.16.1 worked for me whether I used his configuration or my own. The problem started with k4.16.3, which I tested inside and out and just plain can't get to work. k4.16.5 is behaving the same.

peebee · #503 Post by **peebee** » Sun 29 Apr 2018, 08:39

Dry Falls wrote:Peebee used k4.16.2 but I haven't tried it. k4.16.1 worked for me whether I used his configuration or my own. The problem started with k4.16.3, which I tested inside and out and just plain can't get to work. k4.16.5 is behaving the same.

4.16.5 ok for me.....

Dry Falls · #504 Post by **Dry Falls** » Sun 29 Apr 2018, 21:41

Thanks Peebee. Just downloaded 18.04 with B3 delia and it ships with k4.15.15 (very nice, by the way). Put in Stemsee's k4.16.5 and as you observed, runs well, as it does in Lighthouse --except powerdown which has the same 'lockup' (for lack of a better word) issue. If you compiled a k4.16.5-lxpup64 for your trial, I'd sure like to see your .config file.

Of course, lxpup doesn't use full pulseaudio or consolekit2 so so won't experience the same 'other' issues. I'm going over your .xinitrd now to see if I can change the startup proceedure in JL64.

Again,
thanks!

df

peebee · #505 Post by **peebee** » Sun 29 Apr 2018, 22:21

Basically from Fatdog....remove -false.gz

Dry Falls · #506 Post by **Dry Falls** » Mon 30 Apr 2018, 02:58

Ok, Peebee. That fixed the console-keyboard issue and powerdown works correctly. Still the problem with dbus:

Code: Select all

dbus-daemon[7465]: Cannot setup inotify for '/usr/share/dbus-1/system.d'; error 'Permission denied'

Use alsa mixer which calls up retrovol icon tray and everything looks right.

There are umpteen new variables added building the kernel than your (or my) Dotconfig accommadates. My usuall practice is to accept all defaults. I hate to do it, but will have to track down the unusable features and start over if I'm to use this, and it would seem, any future kernels in JL64.

df

Dry Falls · #507 Post by **Dry Falls** » Tue 01 May 2018, 02:46

Recompiled k4.16.5. All working in both JL64 and lxpup64:

stemsee · #508 Post by **stemsee** » Sat 19 May 2018, 13:17

I got this working, and I have tested it out building x86_64 kernels, 4.16.8. All packages faithfully created. Sources with /lib/modules/(build,source) links; and /usr/include (headers). kernel-modules/lib/modules/ free from build and source links...finally!

aufs-util builds immediately after configuring kernel and creating headers package, recoded and working; when internet connection is likely to be alive.

stemsee · #509 Post by **stemsee** » Sat 19 May 2018, 13:30

If b, is entered at firmware download input then big firmware is downloaded and installed, likewise for s, cut-down firmware is added.

If no entry is made (carraige return) then firmware from the running system will be copied over.

stemsee · #510 Post by **stemsee** » Mon 04 Jun 2018, 11:45

This kernel package contains 4.16.13 - x86_64 sources and huge
Based on easy config.
https://drive.google.com/drive/folders/ ... AP9-sQ1Wre

rockedge · #511 Post by **rockedge** » Mon 04 Jun 2018, 23:11

I have compiled a 4.17 pae enabled kernel but I had to use the aufs=4.16 as the kernel-kit script could not find a version for 4.17

I am about to test it out with a 32bit Bionic build from woof-CE..just waiting for the ISO to finish writing...

peebee · #512 Post by **peebee** » Tue 05 Jun 2018, 08:25

rockedge wrote:I have compiled a 4.17 pae enabled kernel but I had to use the aufs=4.16 as the kernel-kit script could not find a version for 4.17

I am about to test it out with a 32bit Bionic build from woof-CE..just waiting for the ISO to finish writing...

With a new kernel version it is usually best to use the 4.x-rcN aufs branch until the specific branch for the new kernel becomes available.....I've done a 64-bit kernel-kit build in that way.

smokey01 · #513 Post by **smokey01** » Tue 05 Jun 2018, 10:28

rockedge wrote:I have compiled a 4.17 pae enabled kernel but I had to use the aufs=4.16 as the kernel-kit script could not find a version for 4.17

I am about to test it out with a 32bit Bionic build from woof-CE..just waiting for the ISO to finish writing...

I discovered the same problem and did the same as you.

Maybe next time I will try peebee's suggestion and use the 4.x-rcN aufs branch.

rockedge · #514 Post by **rockedge** » Wed 06 Jun 2018, 05:21

I will also try a version with peebee's suggestion...meanwhile I have the finished pup running the 4.17 kernel

peebee · #515 Post by **peebee** » Sun 10 Jun 2018, 22:13

Now available:
https://github.com/sfjro/aufs4-standalone/tree/aufs4.17

rockedge · #516 Post by **rockedge** » Mon 11 Jun 2018, 02:18

thanks peebee....I am compiling a kernel 4.17 in 2 slightly different versions as I type using this aufs

Sailor Enceladus · #517 Post by **Sailor Enceladus** » Tue 12 Jun 2018, 19:11

stemsee wrote:This kernel package contains 4.16.13 - x86_64 sources and huge
Based on easy config.
https://drive.google.com/drive/folders/ ... AP9-sQ1Wre

I tried compiling 4.14.49 in slacko64 with the easy config too and it's working. Thanks for the tip

https://www.mediafire.com/folder/6y6wbo ... 434mu7g3yk

stemsee · #518 Post by **stemsee** » Tue 12 Jun 2018, 21:18

Welcome Sailor Enceladus

I added some code to use the next aufs version down if latest not found ... so for 4.17 it will try 4.16 automatically.

Also with single . kernels 4.16 or 4.17 the kernel gets expanded to 4.17.0, got that sorted.

I also found two typos in the nubuild.sh script from my latest sukk download.

I compiled 4.17 and 4.17.1 no probs.

mikeslr · #519 Post by **mikeslr** » Tue 12 Jun 2018, 22:44

Hi All,

peebee wrote:Now available:
https://github.com/sfjro/aufs4-standalone/tree/aufs4.17

As someone who has put to use several of the kernel packages (vmlinuz & associated modules/drivers) but has limited knowledge of what's actually involved, it had been my impression that in compiling a kernel for use with Puppies, aufs was necessarily incorporated into the vmlinuz as part of the compile process initiated by the script. Of course, I may have gotten the foregoing assumption partly or entirely wrong.

Inherently, a more modular approach might be advantageous: an independent aufs --easier to compile and test-- which might be usable with (in?) other than one puppy vmlinuz, perhaps enabling the use of kernels published by Linux.org without having to 'start from scratch'. Does any of the foregoing make sense? And is that what peebee has done?

If so, could the aufs be used like other sfses --zdrv.sfs, fdrv.sfs-- or is the aufs still an intermediate component later to be combined into the vmlinuz?

mikesLr

stemsee · #520 Post by **stemsee** » Tue 12 Jun 2018, 23:05

The kernel sources are patched with patches from aufs sources. Then the kernel source is compiled with aufs capability. Aufs can be built as modules, but for most puppes it is built into the kernel at compile time, for booting purposes loading and layering the main.sfs and kernel-modules.sfs before performing a switchroot into the mounted layered filesystem. The aufs-utils are built from source and added to the kernel-modules.sfs.

Peebee has built the latest kernel 4.17, for which the aufs sources on github did not yet have a branch for. They are maintained by a Japanese person. Aufs has not been accepted into the mainline kernel by Torvalds (linux kernel king), but overlayfs has been accepted.

So Peebee compiled the 4.17 kernel using the aufs.x-rcN branch; while others used the 4.16 branch with the 4.17 kernel as there is not too much difference.

Using modules compiled with one kernel on another kernel is usually problematic, though there is some limited portability, but usually doesn't work!

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

kernel compiling in woof-ce