Porteus Kernel Builder

[Blaze]

neko, a new sof-firmware-2023.09.1-noarch-1.txz released.

[fulalas]

I'm failing to boot with the new kernel 6.6:

kernel panic - not syncing: Can't create rootfs


Is anyone experiencing the same thing?

EDIT: using Puppy kernel 6.6 works: https://archive.org/download/Puppy_Linu ... 64.tar.bz2

There's probably something wrong in our .config file

[beny]

hi fulalas,in my porteux current is ok but i have build it by myself the 6.6 version with the neko's tool

[fulalas]

@beny, do you mind uploading your vmlinuz and 000-kernel modules for version 6.6?

Thanks!

[beny]

hi,https://www.mediafire.com/folder/0crebw ... orteux-6.6

[fulalas]

Thanks a lot, but I still have the same error using your kernel.

It seems it's related to some specific hardware.

It's interesting that Puppy linux kernel works though.

[beny]

i have upgrade my system lately but all work fine:
CPU:
Info: 6-core model: AMD Ryzen 5 3500X bits: 64 type: MCP cache: L2: 3 MiB
Speed (MHz): avg: 2300 min/max: 2200/4120 cores: 1: 2200 2: 2200 3: 2200
4: 2200 5: 2800 6: 2200
Graphics:
Device-1: NVIDIA GK107 [GeForce GT 740] driver: nouveau v: kernel
Display: server: X.Org v: 21.1.9 with: Xwayland v: 23.2.2 driver: X:
loaded: modesetting unloaded: vesa dri: nouveau gpu: nouveau
resolution: 1920x1080~60Hz
API: EGL v: 1.5 drivers: nouveau,swrast
platforms: gbm,x11,surfaceless,device
API: OpenGL v: 4.3 vendor: mesa v: 23.2.1 renderer: NVE7
API: Vulkan v: 1.3.250 drivers: llvmpipe surfaces: xcb,xlib

[fulalas]

It's hard to believe and understand, but it seems we have been patching AUFS wrong, and that was causing this really odd error on some machines since kernel 6.6.x. The code that works for me is this:

For this to work please consider that:
1- the kernel is already downloaded and extracted
2- the script is at the extracted kernel folder at this point
3- AUFS standalone is already downloaded from git and extracted to ../aufs_sources

Code: Select all

for i in kbuild base standalone mmap; do
	patchfile=../aufs_sources/aufs${KERNELMAJORVERSION}-$i.patch
	patch -N -p1 < ${patchfile} > /dev/null 2>&1 || { echo "Failed to add AUFS patch 'aufs${KERNELMAJORVERSION}-$i.patch'."; exit 1; }
done
cp -r ../aufs_sources/{fs,Documentation} . || exit 1
cp ../aufs_sources/include/uapi/linux/aufs_type.h include/linux || cp ../aufs_sources/include/linux/aufs_type.h include/linux || exit 1
[ -d ../aufs_sources/include/uapi ] && cp -r ../aufs_sources/include/uapi/linux/aufs_type.h include/uapi/linux || exit 1

[Rava]

^
Can you make t more obvious what is different for how you did the AUFS patching compared to how it was doe normally?

Because rusty as I am when it comes to kernel patching I do not get what the issue was with the normal way of the AUFS patching.

(And if it is like you said, then it seems the patching should be altered… unless your way of patching creates errors for different hardware configurations… )

[beny]

hi fulalas, if you have a good patched 6.6 kernel source you can apply the kernel diff patch version to the base and mv to the next kernel version, and build it, if you like to do the task manually i have upgraded to the 6.6.1 with this method and seem that work.no need to apply aufs patch at all

[fulalas]

It seems the problem is more complicated than I was expecting. The discussion continues here: https://github.com/sfjro/aufs-standalone/issues/31

TL;DR: for now don't use the code I posted here.

[beny]

hi fulalas, if you don't have used the neko's 64bit config would share yours here,please so we can see the diff from the two version. and the aufs patch allowed are: kbuild,base, nmap and standalone if i remember well no other patch are needed,but....

[roadie]

Is the complete set of patches really needed to use aufs properly?

I apply only the base, kbuild, mmap, and loopback patches, and apply them in that order. I've never used the standalone patch and have had problems with the tmpfs-idr.patch in the past, so I don't use it. There are no issues booting and running with only those 4 patches so I have to wonder if the others are really needed. Running dmesg shows no errors and I've done it this way for years.

Modules can be activated and deactivated on the root system, files are removed on deactivation as they're supposed to be, and no glitches make themselves known with my machine running long hours every day. I'm no power user, though I doubt that would come into things, but problems don't pop up with this machine. Maybe the problems are machine specific.

I don't see what may be missing by not using all the patches in the sfjro set. I also use the sirlucjan aufs patch when it's available, it's just faster and easier to apply with the methods I use. I don't know if it includes standalone and the others, but the kernel almost always boots and runs fine. Any problems have come about from trying to apply an older patch to newer sources,.....in other words, me being a dummy.

[beny]

hi

Code: Select all

  
3. Configuration and Compilation
----------------------------------------
Make sure you have git-checkout'ed the correct branch.

For aufs-linux tree,
- enable CONFIG_AUFS_FS.
- set other aufs configurations if necessary.
- for aufs5.13 and later
  Because aufs is not only an ordinary filesystem (callee of VFS), but
  also a caller of VFS functions for branch filesystems, subclassing of
  the internal locks for LOCKDEP is necessary. LOCKDEP is a debugging
  feature of linux kernel. If you enable CONFIG_LOCKDEP, then you will
  need to customize some LOCKDEP numbers. Here are what I use on my
  test environment.
	CONFIG_LOCKDEP_BITS=21
	CONFIG_LOCKDEP_CHAINS_BITS=21
	CONFIG_LOCKDEP_STACK_TRACE_BITS=24
  Also you will need to expand some constant values in LOCKDEP. Refer
  to lockdep-debug.patch in aufs-standalone.git.

For aufs-standalone tree,
There are several ways to build.

1.
- apply ./aufs6-kbuild.patch to your kernel source files.
- apply ./aufs6-base.patch too.
- apply ./aufs6-mmap.patch too.
- apply ./aufs6-standalone.patch too, if you have a plan to set
  CONFIG_AUFS_FS=m. otherwise you don't need ./aufs-standalone.patch.
- copy ./{Documentation,fs,include/uapi/linux/aufs_type.h} files to your
  kernel source tree. Never copy $PWD/include/uapi/linux/Kbuild.
- enable CONFIG_AUFS_FS, you can select either
  =m or =y.
- and build your kernel as usual.
- install the built kernel.
- install the header files too by "make headers_install" to the
  directory where you specify. By default, it is $PWD/usr.
  "make help" shows a brief note for headers_install.
- and reboot your system.

2.
- module only (CONFIG_AUFS_FS=m).
- apply ./aufs6-base.patch to your kernel source files.
- apply ./aufs6-mmap.patch too.
- apply ./aufs6-standalone.patch too.
- build your kernel, don't forget "make headers_install", and reboot.
- edit ./config.mk and set other aufs configurations if necessary.
  Note: You should read $PWD/fs/aufs/Kconfig carefully which describes
  every aufs configurations.
- build the module by simple "make".
- you can specify ${KDIR} make variable which points to your kernel
  source tree.
- install the files
  + run "make install" to install the aufs module, or copy the built
    $PWD/aufs.ko to /lib/modules/... and run depmod -a (or reboot simply).
  + run "make install_headers" (instead of headers_install) to install
    the modified aufs header file (you can specify DESTDIR which is
    available in aufs standalone version's Makefile only), or copy
    $PWD/usr/include/linux/aufs_type.h to /usr/include/linux or wherever
    you like manually. By default, the target directory is $PWD/usr.
- no need to apply aufs6-kbuild.patch, nor copying source files to your
  kernel source tree.

Note: The header file aufs_type.h is necessary to build aufs-util
      as well as "make headers_install" in the kernel source tree.
      headers_install is subject to be forgotten, but it is essentially
      necessary, not only for building aufs-util.
      You may not meet problems without headers_install in some older
      version though.

And then,
- read README in aufs-util, build and install it
- note that your distribution may contain an obsoleted version of
  aufs_type.h in /usr/include/linux or something. When you build aufs
  utilities, make sure that your compiler refers the correct aufs header
  file which is built by "make headers_install."
- if you want to use readdir(3) in userspace or pathconf(3) wrapper,
  then run "make install_ulib" too. And refer to the aufs manual in
  detail.

There several other patches in aufs-standalone.git. They are all
optional. When you meet some problems, they will help you.
- aufs6-loopback.patch
  Supports a nested loopback mount in a branch-fs. This patch is
  unnecessary until aufs produces a message like "you may want to try
  another patch for loopback file".
- vfs-ino.patch
  Modifies a system global kernel internal function get_next_ino() in
  order to stop assigning 0 for an inode-number. Not directly related to
  aufs, but recommended generally.
- tmpfs-idr.patch
  Keeps the tmpfs inode number as the lowest value. Effective to reduce
  the size of aufs XINO files for tmpfs branch. Also it prevents the
  duplication of inode number, which is important for backup tools and
  other utilities. When you find aufs XINO files for tmpfs branch
  growing too much, try this patch.
- lockdep-debug.patch
  Similar to some kernel configurations for LOCKDEP (see the top of
  this section), you will need expand some constants in LOCKDEP for
  aufs if you enable CONFIG_LOCKDEP.

                                                                                           

[roadie]

@ beny,

It seems that the standalone patch is needed only if aufs is built as a module. I include aufs in the kernel so I guess that's why it works. The tmpfs-idr patch seems to deal with xino files but I never have files in /mnt/live/memory/xino, which is where I would expect to find them. I'm still trying to understand what aufs-util is used for, I've never built it.

I apply the loopback patch because modules can't be activated on the live root system if it's not applied. I know nothing concerning the vfs-ino patch, or the lockdep patch, but lockdep seems to have something to do with kernel modules deadlocking.......I don't know what that involves. But, I get no errors without them so it works for me. I'll try different combinations the next time I compile a kernel. I'm not anywhere near a power user, maybe that's why I don't see errors as I'm not doing a pile of different things every day.

And, thanks for the tip on applying the kernel diff patch to sources, it worked great for me yesterday when I compiled the 6.6.1 kernel and used the 6.6.0 source.