Puppy Linux Discussion Forum

Seems we've now got to the root cause of the last aufs failure. /fs/aufs/i_op.c was the real problem. Although aufs6.6.4 hasn't been released, a patch has, & @peebee successfully made a 6.6.7 kernel. I compiled a 6.6.8 kernel & patch appears to be successful, as it boots fine & in brief testing runs ok.
stat.c & udba were pointers to the problem. It seems (at least for now) the process is: users find problems & specific errors, then a patch or workaround is released. Hopefully that is a only short-term scenario.

I also note that with the 6.6 kernels, if you run df, a mounted 'drive' of about 80kb appears: /sys/firmware/efi/efivars

ozsouth wrote: Fri Dec 29, 2023 1:04 am

Seems we've now got to the root cause of the last aufs failure. /fs/aufs/i_op.c was the real problem. Although aufs6.6.4 hasn't been released, a patch has, & @peebee successfully made a 6.6.7 kernel. I compiled a 6.6.8 kernel & patch appears to be successful, as it boots fine & in brief testing runs ok.
stat.c & udba were pointers to the problem. It seems (at least for now) the process is: users find problems & specific errors, then a patch or workaround is released. Hopefully that is a only short-term scenario.

I also note that with the 6.6 kernels, if you run df, a mounted 'drive' of about 80kb appears: /sys/firmware/efi/efivars

k6.6.4 temporary patch (#4206)
https://github.com/puppylinux-woof-CE/w ... f720f94c01

Thanks @peebee ! I made those 2 files myself (missed your github entry). Now you've confirmed my creations, I guess I can call my beta 6.6.8 kernel OK.

Seems to be more aufs trouble with the 6.7 kernel. As with 6.6.4, kernel commits seem to be breaking aufs more regularly. sfjro is unable to devote time to aufs now (he has the higher priorities of a job and a life - quite reasonable). Posted today on github:

Obviously aufs should follow the changes in mainline kernel.
Hopefully I'll return to aufs in a few months.

There have been no commits to aufs for 2 months now. Fortunately, kernel 6.1.x hasn't broken so far & sfjro provided an untested patch for 6.6.4+ which appears to work.

Thanks for that patch guys. I am just about to compile 6.6.11 kernel, for easyVoid.

@BarryK - I see there is an nfsd error that caused 6.6.12 to be released with a single fix.

Hi all!

First I would like to say thank you to sfjro for still keep maintaining and developing aufs sources for puppy linux huge kernels!
At second I recognized here: https://github.com/sfjro/aufs-standalone/issues/35 - so aufs sources have some problem with kernel 6.7 versions.
I fully understand the priorities described above and I hope that sfjro can continue to develop aufs.

So, I tried to compile this kernel source first: https://github.com/zen-kernel/zen-kerne ... 6.7.1-lqx1 with those aufs 6.7.y corrections but every way I've tried the compilation has been failed. After I gave up with aufs, I disabled it by kernel-kit and tried again with aufs disabled, but overlayfs enabled in menuconfig. Then compilation was successful.
So I released (currently via Google Drive) this kernel without aufs ability but overlayfs enabled. Edited initrd.gz to include UNIONFS="overlay" rather than "aufs" then repacked and tested new kernel and it works.

For tesing the above mentioned kernel compilation is available here for both standard-classic and symlinked puppy linux structures: https://drive.google.com/drive/folders/ ... w3lxdxI3AB

I hope I didn't choose the wrong topic for this writings and excuse me if I have grammatical mistakes in my expressions here!

nocsak wrote: Sun Jan 21, 2024 10:00 am

So I released (currently via Google Drive) this kernel without aufs ability but overlayfs enabled. Edited initrd.gz to include UNIONFS="overlay" rather than "aufs" then repacked and tested new kernel and it works.

Hi

I see graphics problems with 6.7.x and my Nvidia hardware....... https://gitlab.freedesktop.org/drm/nouveau/-/issues/310

You didn't need to edit initrd - overlayfs will be automatically used (in recent Pups) if aufs is not present.....

There is an experimental build of 6.7.x with aufs at: https://sourceforge.net/projects/lxpup/ ... ther/test/

Hello peebee!

Thanks for quick reply!

I will check out what yout wrote, both nouveau issue and your 6.7.1 kernel with aufs. I have a hybrid graphics notebook based on 9gen intel i5-9300H CPU, and it's IGP intel UHD 630 and with Nvidia GTX 1050Ti GPU with 4GB GDDR5. Earlier I worte about this VGA switching problem here: viewtopic.php?p=65130#p65130
So I using default nouveau and intel DRI_PRIME swtich instead of Nvidia driver and because I was not able to install on any way Nvidia native drivers to solve the main problem which is VGA-switching.

The only thing I can test is that I have a LED indicating on which GPU is currently used: Blue if intel, Red if Nvidia and I have a shell script based on ffplay and DRI_PRIME - I will check if the nouveau option has issues! But I did not recognized any problem of nouveau maybe another GPU family I have, or maybe because the VGA switching mechanism. The topic where I wrote about nvidia optimus, there are some links which are not alive already... so the kernel paramter was previously

pci=nommconf

and the kernel config to geenrally set it to disabled by searching to mmconfig and change value in kernel config to not set with hashtag at the beginning of line.

Anyway later I will write a feedback about this with picture under this line - in this comment:

OK I've tested my lqx1-k6.7.1 and your k6.7.1-lxpup64 kernel with DRI_PRIME both 0 (intel) and 1 (nouveau) and I haven't experienced any problem during the tests. I've cheked glxgears and a video playback with nouveau DRI_PRIME setup too without any problem on my dual graphics machine.

The above mentioned mmconfig at me is look like this:

#
# Bus options (PCI etc.)
#
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MMCONFIG is not set
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_ISA_BUS=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
# end of Bus options (PCI etc.)

and it is beacuse if enabled then dmesg has a lots of this section after boot:

[  148.004576] pcieport 0000:00:1d.6: AER: Corrected error received: 0000:03:00.0
[  148.004592] alx 0000:03:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
[  148.004593] alx 0000:03:00.0:   device [1969:10a1] error status/mask=00000080/00002000
[  148.004595] alx 0000:03:00.0:    [ 7] BadDLLP               
# 

aufs seems work well with your kernel so thanks for this too and here are the results of glxgears with that kernel too:

# DRI_PRIME=1 vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
16480 frames in 5.0 seconds = 3295.836 FPS
16463 frames in 5.0 seconds = 3292.510 FPS
16473 frames in 5.0 seconds = 3294.522 FPS
16500 frames in 5.0 seconds = 3299.821 FPS
^C
# DRI_PRIME=0 vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
46299 frames in 5.0 seconds = 9259.721 FPS
47978 frames in 5.0 seconds = 9595.455 FPS
47918 frames in 5.0 seconds = 9583.481 FPS
47966 frames in 5.0 seconds = 9593.161 FPS
^C

Here nouveau results are less values but they always were. (quicksetup says modesetting video driver is currently being used.) And during video playback no issues detected by me with nouveau option:

I'm not really sure but I think your issue with nouveau is GPU family specific maybe.

And here is a (unfortunately Hungarian lanuguage) video about how to make correct fdrv sfs. Maybe it helps too.

https://youtu.be/bpr49oTcWIw?si=2GmsPeFdLlymHptB

The heart of this video is copy-firmware.sh

And yes initrd.gz not has to be edited, it recognized the overlayfs only kernel and booted up well.

Thanks again, best wishes!

peebee wrote: Sun Jan 21, 2024 11:41 am

I see graphics problems with 6.7.x and my Nvidia hardware....... https://gitlab.freedesktop.org/drm/nouveau/-/issues/310

you can try some commands to check:

1. This command show all (DRM preferred) output resolution modes:

   Code: Select all

   cat /sys/class/drm/*/modes | uniq
   1280x1024
   1920x1440
   1600x1200
   1280x1024
   1152x864
   1024x768
   832x624
   800x600
   640x480
   720x400

2. This command show the (recognised) monitor specific infos:

   Code: Select all

   cat /s*/devi*/*/*/*/drm/*/*/edid | parse-edid
   Checksum Correct
   
   Section "Monitor"
       Identifier "hp 7550"
       ModelName "hp 7550"
       VendorName "HWP"
       # Monitor Manufactured week 47 of 2003
       # EDID version 1.3
       # Analog Display
       DisplaySize 320 240
       Gamma 2.80
       Option "DPMS" "true"
       Horizsync 30-86
       VertRefresh 50-140
       # Maximum pixel clock is 180MHz
       #Not giving standard mode: 640x480, 85Hz
       #Not giving standard mode: 800x600, 85Hz
       #Not giving standard mode: 1024x768, 85Hz
       #Not giving standard mode: 1600x1200, 65Hz
       Modeline     "Mode 0" 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync 
   EndSection
   
   or
   
   cat `realpath /s*/c*/drm/*/edid` | parse-edid

   If Identifier and model name is incorrect , may u have cable problem too... (or plug n play not work properly...)
   (this may help kernel developers find the problem)

https://github.com/sfjro/aufs-standalon ... 1937853551

Here are aufs6.7 and aufs6.6.4.
Hopefully I'll start aufs6.x-rcN for linux-v6.8-rcN series in near
future.

J. R. Okajima

aufs 6.8 is released.

Oh dear. I have attempted to compile 5.15.157:

  CC      fs/aufs/loop.o
fs/aufs/loop.c: In function ‘au_test_loopback_overlap’:
fs/aufs/loop.c:36:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   36 |         struct super_block *h_sb;
      |         ^~~~~~
  CC      fs/aufs/hnotify.o
  CC      fs/aufs/hfsnotify.o
fs/aufs/hfsnotify.c: In function ‘au_hfsn_init_br’:
fs/aufs/hfsnotify.c:241:17: error: too few arguments to function ‘fsnotify_alloc_group’
  241 |         group = fsnotify_alloc_group(&au_hfsn_ops);
      |                 ^~~~~~~~~~~~~~~~~~~~
In file included from ./include/linux/fsnotify.h:15,
                 from fs/aufs/inode.h:28,
                 from fs/aufs/aufs.h:49,
                 from fs/aufs/hfsnotify.c:23:
./include/linux/fsnotify_backend.h:598:31: note: declared here
  598 | extern struct fsnotify_group *fsnotify_alloc_group(
      |                               ^~~~~~~~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:289: fs/aufs/hfsnotify.o] Error 1

The last in the 5.15 series that I compiled, successfully, was 5.15.149.

I guess I will have to report this to sfjro at github.
No I won't. Just read back on page 4, sfjro won't be providing any more support for 5.15.x

@BarryK - yes, 5.15.150 failed for me. I made overlay-only 5.15.155, so definitely an aufs problem, which sfjro said he won't fix for 5.x. Best hope is that some of the Porteus boffins, who found the 6.6.4 fix (which was then ratified by sfjro). For aufs, 5.15.147 & 148 are the last I successfully built. This is pretty annoying, as many folk with the rtl8821ce wireless chip have found 6.x 's inbuilt rtw88 hangs their system.
I guess 5.10.x is still a goer. (Last I made was 5.10.208).

I figured it out. Looked at the aufs 6.8, and saw what to do, to fix the 5.15.157 kernel.
Patch attached, with a real .gz
You need to apply this after the aufs patches applied to the kernel.

I did a rerun of kernel-kit on Github Actions (uses gcc (Debian 10.2.1-6) 10.2.1 20210110) and 5.15.157 built with no issues:
https://github.com/puppylinux-woof-CE/w ... 8682520810
https://github.com/puppylinux-woof-CE/w ... el-kit.yml

@BarryK - which version of gcc were you using? I've recently seen evidence that anomaly checking is being tightened up in gcc > 12.....

@peebee - I used gcc 11.2 (s15pup64-231209) with my 5.15.150 failure, which was then ok to make 5.15.148 usrmerge kernel. I mostly use 10.2 (ScPup64_20.01), for compatibility with oldish pups.

I have gcc 11.4.0, compiling in EasyOS 5.7.
And the aufs "5.15.41" patch, that I got in 20220530.

BarryK wrote: Sun Apr 28, 2024 1:00 pm

I figured it out. Looked at the aufs 6.8, and saw what to do, to fix the 5.15.157 kernel.
Patch attached, with a real .gz
You need to apply this after the aufs patches applied to the kernel.

This is OT, but bad news about the 5.15.157 kernel:

viewtopic.php?p=118453#p118453

I examined the kernel changelog, lots of amdgpu changes around April 5, so right now I'm compiling 5.15.153 which was released March 27.
Will test that on my AMD laptop.

Hi all, Hi BarryK!

I follow with interest your amdgpu problem...
Some years ago you helped me around my nvidia hybrid graphics notebook's dmesg problem which had indicated many errors, and after you helped me with your EasyOS kernel config, then I rolled forward that line which caused the main problem:
CONFIG_PCI_MMCONFIG to be commented out as not set.

Since I've found lqx and zen patched kernels on github, then I compiled zen and lqx1 patched kernels with kernel-kit, and with some of tricks to prepare and to be able to compile them. I do not know what kind/type/model of amdgpu you have, but please consider my recommendation about these huge kernels and their kernel configs if they may help you - may solve your amdgpu problem. I'm using with them an RX550 EVO 4GB GDDR5 Phoenix radeon card, which is working well with them in solo in my desktop computer. I don't know it will help anyway or not, but give it a try and if you will have success, then you can test your target kernel version with that configs.

You may need to convert them to usrmerged or to non-usrmerged to fit your testing OS structure! But after opening the sfs-es, you will see you need to or not.

If the problem still persists, then I agree with your conviction - it is a kernel problem. Anyway you try those kernels or not, you can open them to read kernel config.

Best wishes!

...EDIT...

Oh, sorry I've just found: https://bkhome.org/news/202405/kernel-5 ... d-gpu.html

Then, need to try and determine what patch in the .150 kernel has caused the problem. Might contact the kernel developers first.

Note, my black-screen problem does not affect all AMD GPUs. Forum member 'gcav' reported his "AMD Ryzen Mobile 3700U" is OK

Well, excuse me that I wrote here, I switch to the right topic after this post and I'll be patient about the news of BarryK.

Yes, I isolated which kernel caused the problem. I also found which commit.

I have sent emails to some kernel developers, including the guy who's commit has caused the problem.
That was a week ago, no one has replied. I will post to my blog about it soon.

I can create a patch to fix it, but I really think the guy who caused the problem should fix it. I'll wait a bit longer.

o News
- aufs6.9 is released

J. R. Okajima

Sunday 2 June:

o News
- now aufs6.x-rcN branch is for linux-v6.10-rc1

J. R. Okajima

FYI: https://github.com/sfjro/aufs-standalone/issues/39
For now, I have to revert the this commit when I build my 6.1 kernel.

The 6.1 kernel seems to be building OK on Github:
https://github.com/puppylinux-woof-CE/w ... 9326384816

peebee wrote: Fri Jun 07, 2024 2:25 pm

The 6.1 kernel seems to be building OK on Github:
https://github.com/puppylinux-woof-CE/w ... 9326384816

It's not the build process @peebee. The kernel could lock up hard, requiring manual power down.

Fortunately, thanks to Junjiro-san's hard work, as he has done faithfully non-stop for more than 15 years, it has finally been fixed https://github.com/sfjro/aufs-standalon ... 2185386404

So started rebuilding all your kernels, gentlemen!

o News
- When linux-v6.10 is released, aufs6.1--aufs6.5 will get the end of
life and will not be supported. aufs6.6 will become my new development
base.
- according to www.kernel.org, linux-v6.8 got marked as EOL.
aufs6.8 simply follows it.

J. R. Okajima

- When linux-v6.10 is released, aufs6.1--aufs6.5 will get the end of life and will not be supported.

That will be only 11 months after pre-6.1 was dropped. Seems the aufs field is narrowing. Upkeep must be becoming a real burden.

The 5.10 aufs patches no longer work after 5.10.220.......... removed from Woof-CE Kernel-kit
https://github.com/sfjro/aufs-standalone/issues/41

What causes these problems with aufs?
It's just a layering system right?
I don't understand why it is necessary to move to overlayfs. (or whatever else)

Is it the changes in hardware architecture that has caused aufs to fall behind?
Or software changes that require the shift?

greengeek wrote: Thu Jul 04, 2024 8:21 am

What causes these problems with aufs?
It's just a layering system right?
I don't understand why it is necessary to move to overlayfs. (or whatever else)

Is it the changes in hardware architecture that has caused aufs to fall behind?
Or software changes that require the shift?

Maybe it just has one main developer and it requires building patched kernels wheras overlayfs is kernel team official. What particular extra abilities of aufs makes it so valuable to you? It does have an extra ability, but I can't say it is missed much at all in my general distro usage patterns, and I love being able to use pretty much any upstream kernels since always include overlay support. If aufs becoming flakey unreliable and not well supported it is not worth too much effort.