kernel compiling in woof-ce

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#511 Post by rockedge »

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...

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#512 Post by peebee »

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.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#513 Post by smokey01 »

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.

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#514 Post by rockedge »

I will also try a version with peebee's suggestion...meanwhile I have the finished pup running the 4.17 kernel
Attachments
bb1805k417.png
(55.65 KiB) Downloaded 733 times

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#515 Post by peebee »

ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#516 Post by rockedge »

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

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#517 Post by Sailor Enceladus »

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 »

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.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

#519 Post by mikeslr »

Hi All,
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 »

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!

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#521 Post by peebee »

Adding to stemsee's excellent explanation....

@gyro has a project which is progressing very successfully to replace aufs with overlayfs - http://www.murga-linux.com/puppy/viewtopic.php?t=110636 - as a fallback if the Japanese guy "Junjiro. R. Okajima" ever stops developing aufs - my kernels (and others) have overlayfs configured so they can be used with @gyro's experiments.....
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

stemsee

#522 Post by stemsee »

I have been testing this on BionicDog, the devx of which is empty in terms of kernel compiling deps, luckily the script installs fakeroot, kernel-package, headers, etc but, unlike previous debiandog, does not compile as make-kpkg not found!

Well, a few fixes in place but more to do! Good for building single package at a time.
Attachments
nubuild.sh.gz
nubuild script
(21.26 KiB) Downloaded 213 times

Dry Falls
Posts: 616
Joined: Tue 16 Dec 2014, 23:37
Location: Upper Columbia

#523 Post by Dry Falls »

does not compile as make-kpkg not found!
These newer scripts put the kernel headers in the kernel sources module. I miss having it in the kernel modules sfs. Put it there manually. Probably a good idea NOT to put it in devx, but why doesn't woofCE place it in the zdrive?

This new script continues with some errors (mostly typos) from the previous, although both work. Here are some changes I made you might be interested. Removed "carriage returns" (unwrapped lines) and fixed some tar options. Also removed a hyphen so that md5sum works on huge package. One tar still returns an error message during the aufs build:
Creating the Aufs sources tarball
tar: Cowardly refusing to create an empty archive
Try 'tar --help' or 'tar --usage' for more information.
Extracting the Aufs sources
and later
Failed to patch the aufs-util sources.
tar: ../aufs-util: Cannot open: Is a directory
tar: Error is not recoverable: exiting now
aufs-util is in dist
Attachments
diffing.txt.gz
real gz. click to unzip
(702 Bytes) Downloaded 190 times

stemsee

#524 Post by stemsee »

I will check out your scipt Dry Falls. The headers are supposed to go in the devx! I opted for the kernel-modules.sfs, against 01micko's advice, having no automatic way to put them in any given devx (wherever it resides on the hdd). So this time, I put them in the sources.sfs, in error, mixing up sources for devx!

Jamesbond had clarified that there are two types of header files, one of which is for development, those that are in the package with kernel sources. Probably should build their own headers.sfs package.

Dry Falls
Posts: 616
Joined: Tue 16 Dec 2014, 23:37
Location: Upper Columbia

#525 Post by Dry Falls »

stemsee wrote:The headers are supposed to go in the devx! I opted for the kernel-modules.sfs, against 01micko's advice, having no automatic way to put them in any given devx
My opinion: you were right in the first place. If in the zdrive or initrd, they take precedence during bootup (>switchroot) so you've got the right modules loaded no matter what is in the devx which loads later. (As you've discovered, you can use the devx from another distro to access some programs). If they are located in the devx, you will have to remaster that file for every kernel change. If they are in the kernel sources sfs, you will have to load it with the devx every time you want to compile. We're only talking 1 megabite (compressed) so there isn't really a "keep the size down" argument available. It's not just an issue of remastering the devx but eliminating all that bandwidth usage uploading the devx over and over for every kernel change. I appreciate that speculations on bandwidth/cloud usage are the only thing keeping wall street afloat (and therefore, the general economy), but that's their problem, not mine. When you think about it, all so-called security issues boil down to moving money. It's for the greater good (but never mine!)

df

stemsee

#526 Post by stemsee »

Sharing a folder with 4.17.4-x86_64 huge,sources,vmlinuz,kernel-modules.sfs, md5

https://drive.google.com/open?id=1qFWJC ... VZEY5PP9vY

stemsee

#527 Post by stemsee »

Corrected typos nubuild.sh
Attachments
nubuild.sh.gz
(21.56 KiB) Downloaded 438 times

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Fixed.

#528 Post by peebee »

Fixed - see below

Anybody managed to compile a 32-bit 4.14 series kernel after 4.14.56 using gcc-7.3.0 or later?

I get:

Code: Select all

ld: fs/aufs/xino.o: in function `au_xino_read':
xino.c:(.text+0xc49): undefined reference to `__divmoddi4'
ld: fs/aufs/xino.o: in function `au_xino_write':
xino.c:(.text+0xe6b): undefined reference to `__divmoddi4'
ld: fs/aufs/xino.o: in function `au_xino_do_set_br':
xino.c:(.text+0x18fd): undefined reference to `__divmoddi4'
ld: fs/aufs/xino.o: in function `au_xino_delete_inode':
xino.c:(.text+0x24bb): undefined reference to `__divmoddi4'
make: *** [Makefile:1016: vmlinux] Error 1
Error: failed to compile the kernel sources.
I was trying to build a 32-bit k4.14.67 with aufs-4.14.56+ when I first encountered this problem.

Thanks!
Last edited by peebee on Tue 04 Sep 2018, 05:35, edited 1 time in total.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
rockedge
Posts: 1864
Joined: Wed 11 Apr 2012, 13:32
Location: Connecticut, United States
Contact:

#529 Post by rockedge »

I am compiling 32 bit 4.14.67 with gcc 7.3.0 on a new Bionic 18.05 kernel 4.17.9 32 bit built with woof-CE

I will report when it finishes one way or another

build.conf

Code: Select all

kernel_ver=4.14.67

#x86_disable_pae=yes
x86_enable_pae=yes
#x86_set_i486=yes
x86_set_i686=yes

custom_suffix=

package_name_suffix=

##-----------------------------------------------------------------------

remove_sublevel=no

aufsv=4.14

LIBRE=0

### squashfs compression ###
## leave unset for the default of your mksquashfs binary
## run "mksquashfs --help" to find out options from compression
## for extra compression "-comp xz -Xbcj ia64" or "-comp xz -Xbcj x86" etc
## Consult the mksquashfs manual for more info.
## 'xz' / 'gzip' ..
COMP="-comp xz"

## Firmware tarballs repository
FW_URL=http://ftp.nluug.nl/ftp/pub/os/Linux/distr/puppylinux/firmware

## Kernel download mirrors
kernel_mirrors='https://www.kernel.org/pub/linux/kernel
ftp://ftp.ntu.edu.tw/linux/kernel
ftp://ftp.heanet.ie/pub/kernel.org/pub/linux/kernel
ftp://ftp.yandex.ru/pub/linux/kernel/
https://mirror.aarnet.edu.au/pub/ftp.kernel.org/linux/kernel
ftp://ftp.jaist.ac.jp/pub/Linux/kernel.org/linux/kernel
ftp://www.mirrorservice.org/pub/linux/kernel
ftp://ftp.be.debian.org/pub/linux/kernel'
Update
so far so good. 30 minutes into compiling

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#530 Post by peebee »

Sorry - should have reported - a patch has been found:
https://github.com/sfjro/aufs4-standalo ... aaf094c60f

There is an aufs branch 4.14.56+
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

Post Reply