aufs future

[nocsak]

Yes, thank you, I was afraid of that.
Okay, anyway I can now see clearly the cause of the problem.

Best wishes!

[jamesbond]

@peebee @ozsouth You can build 5.10.x again.

Apply the given patch to aufs5.10.140, and apply aufs to the kernel as usual.

xscreenshot-20240820T233408.png (24.18 KiB) Viewed 2329 times

[peebee]

Many thanks @jamesbond - 5.10.x has been restored to Github kernel-kit with your patch:
https://github.com/puppylinux-woof-CE/w ... el-kit.yml

[nocsak]

Wow! Thank you @jamesbond !

I needed to hang the build.sh process at aufs patching by giving a false argument in that for loop which is for apply default aufs patches, then build.sh asked me to Ctrl+C or hit enter to continue. Then manually applied your's from another terminal and the 5.10.224 compilation Done with success!

Code: Select all

Compressing the log
------------------
Output files:
- output/huge-5.10.224-dpupbw64.tar.bz2
  (kernel tarball: vmlinuz, modules.sfs - used in the woof process)
  you can use this to replace vmlinuz and zdrv.sfs from the current wce puppy install..

- output/kernel_sources-5.10.224-dpupbw64.sfs
  (you can use this to compile new kernel modules - load or install first..)
------------------
Done!
# ldd --version
ldd Debian GLIBC 2.40-1
Copyright (C) 2022 Free Software Foundation, Inc.
Ez egy szabad szoftver, lásd a forrást a másolási feltételekért. NINCS
garancia, még az ADOTT CÉLRE VALÓ ELADHATÓSÁGRA VAGY MEGFELELŐSÉGRE SEM.
Írta: Roland McGrath és Ulrich Drepper.
# gcc --version
gcc (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# 

Now I will make my complete bz2 package with kernel sources and may upload next to my other kernel compilations.
Thank you to all!

[ozsouth]

@jamesbond - thanks! Will do a compile a bit later. LATER - success!

[ozsouth]

On the off chance anyone's interested, aufs broke again after 5.4.257. Overlayfs-only worked on 5.4.281, but needs minimum gcc 11.2 (after 5.4.257). I don't intend to pursue that line further.

Also, the .224.diff patch allowed me to make a 5.10.222 kernel (I renamed patch & apply script ref as .220), as that's where 5.10 broke this time.

[peebee]

o news
- linux-v6.11 is released and aufs6.11 follows.

J. R. Okajima

[peebee]

o news
- - new aufs6.6.54 and aufs6.10.13 and aufs6.11.2 branches are released

[ozsouth]

new aufs6.6.54 and aufs6.10.13 and aufs6.11.2 branches are released

I really feel for sfjro. Never any warning when big backports break aufs.
Overnight shipwrecks. He's had to quickly adjust 3 trees this time.
I prefer to wait a fortnight after release to make aufs kernels now.

[jamesbond]

new aufs6.6.54 and aufs6.10.13 and aufs6.11.2 branches are released

I really feel for sfjro. Never any warning when big backports break aufs.
Overnight shipwrecks. He's had to quickly adjust 3 trees this time.
I prefer to wait a fortnight after release to make aufs kernels now.

The premise of "stable" kernel is that updates should only be about bug fixes, not new features (especially API-breaking features). Apparently many are forgetting that now

I get it, on long running LTS series (those whose minor version numbers go beyond 100+ like 6.1 and 5.10 etc) this may not always be possible, depending on the fixes (which may depend on newer features, so to apply the fixes one really have to import the new API-breaking features as well); but breaking an already EOL-ed series like 6.10.13? It is as if they're doing it on purpose ...

[nocsak]

Hi all!

I'm glad to read there are new aufs branches released! Some day earlier I tried to compile both k6.11.2-zen1 patched and original k6.11.2 versions but at aufs patching process during kernel-kit building at the beginning stopped by an error message - some patches couldn't be applied to aufs. I've just hit enter, then the compilation was done, but I don't know why fails the aufs patching at start. Is this happening at me only, or others also recognised this problem? Or do I need to ignore and hit enter only?

Thanks in advance for answer!

---EDIT---

OK! I've missed I require to specify aufsv=6.11.2
then everything seems fine, sorry!

[ozsouth]

Many branches updated 3 days ago, including 6.6.54, 6.10.13, 6.11.2. 6.6.44 added 2 weeks ago & further updated 3 days ago. Seems that now, is best to wait a month after kernel release, as 6.6.53 I made 2 weeks ago is now questionable, even though it tested fine then.

LATER: Since the recent changes, I am having trouble compiling some older 6.6 & 6.10 kernels with aufs enabled (4 consecutive fails). Am trying ones after change (6.6.55+). Fortunately overlayfs-only is unaffected.

[peebee]

There is a problem with both aufs-6.6.54 and aufs-6.11.2 .......... reported:
https://github.com/sfjro/aufs-standalon ... 2450827504

[ozsouth]

I finally managed to make a 6.1.112 aufs kernel - a branch not updated in the last few weeks. I've tried 6.6, 6.9 & 6.10 - many diffierent configs & kernel kits, all failed. Wasted days on it. As overlay 6.6 & 6.9 kernels worked, is definitely an aufs issue.
Sadly, this set of mass updates couldn't have turned out worse if AI was responsible. Due to outside factors (beyond our aufs man's control), this is becoming untenable.

[Duprate]

Good morning! My problems with AUFS ended in 2020, when I started compiling the kernel only with OVERLAYFS and I'm happy! It was like taking a weight off my shoulders ...

[BarryK]

There is a problem with both aufs-6.6.54 and aufs-6.11.2 .......... reported:
https://github.com/sfjro/aufs-standalon ... 2450827504

EasyOS Scarthgap 6.4.1 has kernel 6.6.58, Daedalus 6.4.1 has 6.6.54
Scarthgap 6.4 has kernel 6.6.56 if I recall correctly.

They use aufs and the kernels compiled without any problem. Also aufs works perfectly.

I haven't ventured to 6.6.59 yet!
After seeing peebee's report on github, I will hold off updating!

[ozsouth]

@BarryK - the mass update was 5 days ago. I successfully made 6.6.53 aufs 2 weeks ago, but now (last few days) everything fails (6.1 is ok). If you made your kernels a week or more ago, you wouldn't have had a problem.

[peebee]

The aufs 6.6 & 6.11 updates have been released:
https://github.com/sfjro/aufs-standalone/branches

Github kernel kit 6.6 now builds ok:
https://github.com/puppylinux-woof-CE/w ... 1622768817

[peebee]

o news
- linux-v6.12 is released and aufs6.12 follows.
The aufs sources codes are not changed since last aufs6.x-rcN branch
release.

J. R. Okajima

[BarryK]

I found that the aufs patch for the 6.6.63 kernel failed. It has been reported:

https://github.com/sfjro/aufs-standalone/issues/48

I examined the changelog, and determined that the 6.6.61 kernel is OK.
Confirmed yes, "6.6.54" aufs patch applies ok to 6.6.61 kernel.
And it works, running it now.

sfjro must be getting very frustrated.

[peebee]

The 6.12.y series has officially been designated, LTS. i.e., Long Term Service Kernel.

https://www.kernel.org/category/releases.html

aufs-6.12 has been released

The Github kernel-kit builds now need to be updated to include 6.12 - done

[peebee]

https://github.com/puppylinux-woof-CE/w ... el-kit.yml

kernel-kit #256

Artifacts (include firmware etc.)
Produced during runtime
Name Size
kernel-kit-output-5.10.x-x86
272 MB
kernel-kit-output-5.10.x-x86_64
284 MB
kernel-kit-output-5.15.x-x86
291 MB
kernel-kit-output-5.15.x-x86_64
304 MB
kernel-kit-output-6.1.x-x86
312 MB
kernel-kit-output-6.1.x-x86_64
299 MB
kernel-kit-output-6.12.x-x86
378 MB
kernel-kit-output-6.12.x-x86_64
365 MB
kernel-kit-output-6.6.x-x86
324 MB
kernel-kit-output-6.6.x-x86_64
313 MB
kernel-kit-output-usrmerge-5.10.x-x86
272 MB
kernel-kit-output-usrmerge-5.10.x-x86_64
284 MB
kernel-kit-output-usrmerge-5.15.x-x86
291 MB
kernel-kit-output-usrmerge-5.15.x-x86_64
304 MB
kernel-kit-output-usrmerge-6.1.x-x86
312 MB
kernel-kit-output-usrmerge-6.1.x-x86_64
299 MB
kernel-kit-output-usrmerge-6.12.x-x86
378 MB
kernel-kit-output-usrmerge-6.12.x-x86_64
365 MB
kernel-kit-output-usrmerge-6.6.x-x86
324 MB
kernel-kit-output-usrmerge-6.6.x-x86_64
313 MB

[Marv]

Quick test of 6.12.2 in the 241201 build of VoidPup64 (previously run sucessfully with the stock 6.6.63 kernel and with the 6.12.1 kernel). Library structure adjusted to match that which void uses (no lib64). Currently running using AUFS in my ydrv only, non-savefile frugal install to SSD on the Fujitsu S761 2nd gen i5 laptop. Not a test of 'firmware fallback' as my Atheros wifi cards don't require any firmware and I have no other or new hardware that does but...

Clean boot, clean dmesg, excellent idle resource use, no FPS test as I don't have glxgears in this install but 'snappy' in daily use. My nemesis on this hardware, lidsuspend, working fine also. Just that and the LTS for 12 makes it of interest to me.

I'll run the appropriate 6.12.2 kernels in LxPupSc64 and NoblePup64 a little later.

Posting from the VoidPup64 install using the current Brave run-as-spot from a shared portable.

Thanks,

[Jasper]

@Marv

Thank you for your consistency in giving feedback on kernel updates

Where can I get the kernel 6.12.1 ?

I had to manually my Mesa for VoidPup64.

[Marv]

The kernel is a artifact of @peebees' latest run at the link he provides two posts up. Log in to github and download the flavour you want. Extract once to get the kernel sources etc. and a secondary tarball with the kernel modules SFS and vmlinux. Extract from it to get them. My download had the usrmerged flavour and I manually adjust libraries in the kernel modules sfs to match the pups I'm using it in to keep my downloads to one. I don't use the fdrv, a function of my hardware.