* glibc VETO for kernel version SUBLEVEL >= 255 @ 2021-09-26 7:23 Jari Ruusu 2021-09-26 7:28 ` Greg Kroah-Hartman 0 siblings, 1 reply; 10+ messages in thread From: Jari Ruusu @ 2021-09-26 7:23 UTC (permalink / raw) To: Greg Kroah-Hartman, Sasha Levin Cc: linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds Earlier this year there was some discussion about kernel version numbers after 4.9.255 and 4.4.255. Problem was 8-bit limitation for SUBLEVEL number in stable kernel versions. The fix was to freeze LINUX_VERSION_CODE number at x.x.255 and to continue incrementing SUBLEVEL number. Seems there are more more fallout from that decision. At least some versions of glibc do not play well with larger SUBLEVEL numbers. # uname -s -r -m Linux 4.9.283-QEMU armv6l # apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: [SNIP] Fetched 145 MB in 1min 57s (1244 kB/s) Reading changelogs... Done Preconfiguring packages ... (Reading database ... 39028 files and directories currently installed.) Preparing to unpack .../libc6-dbg_2.28-10+rpt2+rpi1_armhf.deb ... Unpacking libc6-dbg:armhf (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... Preparing to unpack .../libc6-dev_2.28-10+rpt2+rpi1_armhf.deb ... Unpacking libc6-dev:armhf (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... Preparing to unpack .../libc-dev-bin_2.28-10+rpt2+rpi1_armhf.deb ... Unpacking libc-dev-bin (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... Preparing to unpack .../linux-libc-dev_1%3a1.20210831-3~buster_armhf.deb ... Unpacking linux-libc-dev:armhf (1:1.20210831-3~buster) over (1:1.20210527-1) ... Preparing to unpack .../libc6_2.28-10+rpt2+rpi1_armhf.deb ... ERROR: Your kernel version indicates a revision number of 255 or greater. Glibc has a number of built in assumptions that this revision number is less than 255. If you\'ve built your own kernel, please make sure that any custom version numbers are appended to the upstream kernel number with a dash or some other delimiter. dpkg: error processing archive /var/cache/apt/archives/libc6_2.28-10+rpt2+rpi1_armhf.deb (--unpack): new libc6:armhf package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/libc6_2.28-10+rpt2+rpi1_armhf.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Above upgrade works normally if I edit top level Linux source Makefile to say "SUBLEVEL = 0" and re-compile new kernel. I am not pointing any fingers here, but it seems that either glibc code or stable kernel versioning is messed up. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 7:23 glibc VETO for kernel version SUBLEVEL >= 255 Jari Ruusu @ 2021-09-26 7:28 ` Greg Kroah-Hartman 2021-09-26 8:10 ` Salvatore Bonaccorso 0 siblings, 1 reply; 10+ messages in thread From: Greg Kroah-Hartman @ 2021-09-26 7:28 UTC (permalink / raw) To: Jari Ruusu Cc: Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds On Sun, Sep 26, 2021 at 07:23:33AM +0000, Jari Ruusu wrote: > Earlier this year there was some discussion about kernel version numbers > after 4.9.255 and 4.4.255. Problem was 8-bit limitation for SUBLEVEL > number in stable kernel versions. The fix was to freeze LINUX_VERSION_CODE > number at x.x.255 and to continue incrementing SUBLEVEL number. Seems > there are more more fallout from that decision. At least some versions of > glibc do not play well with larger SUBLEVEL numbers. > > > # uname -s -r -m > Linux 4.9.283-QEMU armv6l > # apt upgrade > Reading package lists... Done > Building dependency tree > Reading state information... Done > Calculating upgrade... Done > The following packages will be upgraded: > [SNIP] > Fetched 145 MB in 1min 57s (1244 kB/s) > Reading changelogs... Done > Preconfiguring packages ... > (Reading database ... 39028 files and directories currently installed.) > Preparing to unpack .../libc6-dbg_2.28-10+rpt2+rpi1_armhf.deb ... > Unpacking libc6-dbg:armhf (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > Preparing to unpack .../libc6-dev_2.28-10+rpt2+rpi1_armhf.deb ... > Unpacking libc6-dev:armhf (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > Preparing to unpack .../libc-dev-bin_2.28-10+rpt2+rpi1_armhf.deb ... > Unpacking libc-dev-bin (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > Preparing to unpack .../linux-libc-dev_1%3a1.20210831-3~buster_armhf.deb ... > Unpacking linux-libc-dev:armhf (1:1.20210831-3~buster) over (1:1.20210527-1) ... > Preparing to unpack .../libc6_2.28-10+rpt2+rpi1_armhf.deb ... > ERROR: Your kernel version indicates a revision number > of 255 or greater. Glibc has a number of built in > assumptions that this revision number is less than 255. > If you\'ve built your own kernel, please make sure that any > custom version numbers are appended to the upstream > kernel number with a dash or some other delimiter. > > dpkg: error processing archive /var/cache/apt/archives/libc6_2.28-10+rpt2+rpi1_armhf.deb (--unpack): > new libc6:armhf package pre-installation script subprocess returned error exit status 1 > Errors were encountered while processing: > /var/cache/apt/archives/libc6_2.28-10+rpt2+rpi1_armhf.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > Above upgrade works normally if I edit top level Linux source Makefile to > say "SUBLEVEL = 0" and re-compile new kernel. > > I am not pointing any fingers here, but it seems that either glibc code or > stable kernel versioning is messed up. Are you sure this isn't just a warning coming from a script that apt is running when trying to install glibc? Or is this from the glibc package itself? And what exactly is it testing? We fixed the build time detection of the kernel version here, so you should be able to build glibc properly. This is the first time we've seen this reported, are people using the newer kernels on systems that are not using glibc? thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 7:28 ` Greg Kroah-Hartman @ 2021-09-26 8:10 ` Salvatore Bonaccorso 2021-09-26 9:29 ` Greg Kroah-Hartman 0 siblings, 1 reply; 10+ messages in thread From: Salvatore Bonaccorso @ 2021-09-26 8:10 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Jari Ruusu, Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds, Aurelien Jarno Hi, On Sun, Sep 26, 2021 at 09:28:58AM +0200, Greg Kroah-Hartman wrote: > On Sun, Sep 26, 2021 at 07:23:33AM +0000, Jari Ruusu wrote: > > Earlier this year there was some discussion about kernel version numbers > > after 4.9.255 and 4.4.255. Problem was 8-bit limitation for SUBLEVEL > > number in stable kernel versions. The fix was to freeze LINUX_VERSION_CODE > > number at x.x.255 and to continue incrementing SUBLEVEL number. Seems > > there are more more fallout from that decision. At least some versions of > > glibc do not play well with larger SUBLEVEL numbers. > > > > > > # uname -s -r -m > > Linux 4.9.283-QEMU armv6l > > # apt upgrade > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > Calculating upgrade... Done > > The following packages will be upgraded: > > [SNIP] > > Fetched 145 MB in 1min 57s (1244 kB/s) > > Reading changelogs... Done > > Preconfiguring packages ... > > (Reading database ... 39028 files and directories currently installed.) > > Preparing to unpack .../libc6-dbg_2.28-10+rpt2+rpi1_armhf.deb ... > > Unpacking libc6-dbg:armhf (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > > Preparing to unpack .../libc6-dev_2.28-10+rpt2+rpi1_armhf.deb ... > > Unpacking libc6-dev:armhf (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > > Preparing to unpack .../libc-dev-bin_2.28-10+rpt2+rpi1_armhf.deb ... > > Unpacking libc-dev-bin (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > > Preparing to unpack .../linux-libc-dev_1%3a1.20210831-3~buster_armhf.deb ... > > Unpacking linux-libc-dev:armhf (1:1.20210831-3~buster) over (1:1.20210527-1) ... > > Preparing to unpack .../libc6_2.28-10+rpt2+rpi1_armhf.deb ... > > ERROR: Your kernel version indicates a revision number > > of 255 or greater. Glibc has a number of built in > > assumptions that this revision number is less than 255. > > If you\'ve built your own kernel, please make sure that any > > custom version numbers are appended to the upstream > > kernel number with a dash or some other delimiter. > > > > dpkg: error processing archive /var/cache/apt/archives/libc6_2.28-10+rpt2+rpi1_armhf.deb (--unpack): > > new libc6:armhf package pre-installation script subprocess returned error exit status 1 > > Errors were encountered while processing: > > /var/cache/apt/archives/libc6_2.28-10+rpt2+rpi1_armhf.deb > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > > > > > Above upgrade works normally if I edit top level Linux source Makefile to > > say "SUBLEVEL = 0" and re-compile new kernel. > > > > I am not pointing any fingers here, but it seems that either glibc code or > > stable kernel versioning is messed up. > > Are you sure this isn't just a warning coming from a script that apt is > running when trying to install glibc? Or is this from the glibc package > itself? > > And what exactly is it testing? We fixed the build time detection of > the kernel version here, so you should be able to build glibc properly. > > This is the first time we've seen this reported, are people using the > newer kernels on systems that are not using glibc? They are probably not using a problematic combination or a distribution kernel on those systems. Looking from the mentioned versions above this looks like a version derived from Debian buster. Recently prompted due to https://bugs.debian.org/987266 the check was removed in the postinst script of libc in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987266 . Regards, Salvatore ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 8:10 ` Salvatore Bonaccorso @ 2021-09-26 9:29 ` Greg Kroah-Hartman 2021-09-26 10:58 ` Jari Ruusu 0 siblings, 1 reply; 10+ messages in thread From: Greg Kroah-Hartman @ 2021-09-26 9:29 UTC (permalink / raw) To: Salvatore Bonaccorso Cc: Jari Ruusu, Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds, Aurelien Jarno On Sun, Sep 26, 2021 at 10:10:53AM +0200, Salvatore Bonaccorso wrote: > Hi, > > On Sun, Sep 26, 2021 at 09:28:58AM +0200, Greg Kroah-Hartman wrote: > > On Sun, Sep 26, 2021 at 07:23:33AM +0000, Jari Ruusu wrote: > > > Earlier this year there was some discussion about kernel version numbers > > > after 4.9.255 and 4.4.255. Problem was 8-bit limitation for SUBLEVEL > > > number in stable kernel versions. The fix was to freeze LINUX_VERSION_CODE > > > number at x.x.255 and to continue incrementing SUBLEVEL number. Seems > > > there are more more fallout from that decision. At least some versions of > > > glibc do not play well with larger SUBLEVEL numbers. > > > > > > > > > # uname -s -r -m > > > Linux 4.9.283-QEMU armv6l > > > # apt upgrade > > > Reading package lists... Done > > > Building dependency tree > > > Reading state information... Done > > > Calculating upgrade... Done > > > The following packages will be upgraded: > > > [SNIP] > > > Fetched 145 MB in 1min 57s (1244 kB/s) > > > Reading changelogs... Done > > > Preconfiguring packages ... > > > (Reading database ... 39028 files and directories currently installed.) > > > Preparing to unpack .../libc6-dbg_2.28-10+rpt2+rpi1_armhf.deb ... > > > Unpacking libc6-dbg:armhf (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > > > Preparing to unpack .../libc6-dev_2.28-10+rpt2+rpi1_armhf.deb ... > > > Unpacking libc6-dev:armhf (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > > > Preparing to unpack .../libc-dev-bin_2.28-10+rpt2+rpi1_armhf.deb ... > > > Unpacking libc-dev-bin (2.28-10+rpt2+rpi1) over (2.28-10+rpi1) ... > > > Preparing to unpack .../linux-libc-dev_1%3a1.20210831-3~buster_armhf.deb ... > > > Unpacking linux-libc-dev:armhf (1:1.20210831-3~buster) over (1:1.20210527-1) ... > > > Preparing to unpack .../libc6_2.28-10+rpt2+rpi1_armhf.deb ... > > > ERROR: Your kernel version indicates a revision number > > > of 255 or greater. Glibc has a number of built in > > > assumptions that this revision number is less than 255. > > > If you\'ve built your own kernel, please make sure that any > > > custom version numbers are appended to the upstream > > > kernel number with a dash or some other delimiter. > > > > > > dpkg: error processing archive /var/cache/apt/archives/libc6_2.28-10+rpt2+rpi1_armhf.deb (--unpack): > > > new libc6:armhf package pre-installation script subprocess returned error exit status 1 > > > Errors were encountered while processing: > > > /var/cache/apt/archives/libc6_2.28-10+rpt2+rpi1_armhf.deb > > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > > > > > > > > > Above upgrade works normally if I edit top level Linux source Makefile to > > > say "SUBLEVEL = 0" and re-compile new kernel. > > > > > > I am not pointing any fingers here, but it seems that either glibc code or > > > stable kernel versioning is messed up. > > > > Are you sure this isn't just a warning coming from a script that apt is > > running when trying to install glibc? Or is this from the glibc package > > itself? > > > > And what exactly is it testing? We fixed the build time detection of > > the kernel version here, so you should be able to build glibc properly. > > > > This is the first time we've seen this reported, are people using the > > newer kernels on systems that are not using glibc? > > They are probably not using a problematic combination or a > distribution kernel on those systems. Looking from the mentioned > versions above this looks like a version derived from Debian buster. > > Recently prompted due to https://bugs.debian.org/987266 the check was > removed in the postinst script of libc in Debian: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987266 . Wonderful, thanks for pointing this out! Jari, try asking whatever distro you are getting these rebuilt packages from to update their scripts and all should be good. thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 9:29 ` Greg Kroah-Hartman @ 2021-09-26 10:58 ` Jari Ruusu 2021-09-26 11:24 ` Greg Kroah-Hartman 0 siblings, 1 reply; 10+ messages in thread From: Jari Ruusu @ 2021-09-26 10:58 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Salvatore Bonaccorso, Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds, Aurelien Jarno On Sunday, September 26th, 2021 at 12:29, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Sun, Sep 26, 2021 at 10:10:53AM +0200, Salvatore Bonaccorso wrote: > > Recently prompted due to https://bugs.debian.org/987266 the check was > > removed in the postinst script of libc in Debian: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987266 . > > Wonderful, thanks for pointing this out! > Jari, try asking whatever distro you are getting these rebuilt packages > from to update their scripts and all should be good. It is/was mostly self-inflicted pain, using Rasbian distro userland and self-compiled kernel.org kernel. Since that problem seems to be fixed in upstream glibc, that problem is not going to persist forever. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 10:58 ` Jari Ruusu @ 2021-09-26 11:24 ` Greg Kroah-Hartman 2021-09-26 11:31 ` Jari Ruusu 0 siblings, 1 reply; 10+ messages in thread From: Greg Kroah-Hartman @ 2021-09-26 11:24 UTC (permalink / raw) To: Jari Ruusu Cc: Salvatore Bonaccorso, Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds, Aurelien Jarno On Sun, Sep 26, 2021 at 10:58:59AM +0000, Jari Ruusu wrote: > On Sunday, September 26th, 2021 at 12:29, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Sun, Sep 26, 2021 at 10:10:53AM +0200, Salvatore Bonaccorso wrote: > > > Recently prompted due to https://bugs.debian.org/987266 the check was > > > removed in the postinst script of libc in Debian: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987266 . > > > > Wonderful, thanks for pointing this out! > > Jari, try asking whatever distro you are getting these rebuilt packages > > from to update their scripts and all should be good. > > It is/was mostly self-inflicted pain, using Rasbian distro userland and > self-compiled kernel.org kernel. Why use an older kernel tree on this device? Rasbian seems to be on 4.19.y at the least right now, is there something in those older kernel trees that you need? thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 11:24 ` Greg Kroah-Hartman @ 2021-09-26 11:31 ` Jari Ruusu 2021-09-26 11:39 ` Greg Kroah-Hartman 0 siblings, 1 reply; 10+ messages in thread From: Jari Ruusu @ 2021-09-26 11:31 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Salvatore Bonaccorso, Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds, Aurelien Jarno On Sunday, September 26th, 2021 at 14:24, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > Why use an older kernel tree on this device? Rasbian seems to be on > 4.19.y at the least right now, is there something in those older kernel > trees that you need? Due to circumstances, I need "smallest possible" kernel with all extra stripped out. 4.9.y kernels are smaller than newer ones. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 11:31 ` Jari Ruusu @ 2021-09-26 11:39 ` Greg Kroah-Hartman 2021-09-26 15:03 ` Willy Tarreau 2021-09-26 16:18 ` Jari Ruusu 0 siblings, 2 replies; 10+ messages in thread From: Greg Kroah-Hartman @ 2021-09-26 11:39 UTC (permalink / raw) To: Jari Ruusu Cc: Salvatore Bonaccorso, Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds, Aurelien Jarno On Sun, Sep 26, 2021 at 11:31:20AM +0000, Jari Ruusu wrote: > On Sunday, September 26th, 2021 at 14:24, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > Why use an older kernel tree on this device? Rasbian seems to be on > > 4.19.y at the least right now, is there something in those older kernel > > trees that you need? > > Due to circumstances, I need "smallest possible" kernel with all extra > stripped out. 4.9.y kernels are smaller than newer ones. Smaller by how much, and what portion grew? Are we building things into the kernel that previously was able to be compiled out? Or is there something new added after 4.9 that adds a huge memory increase? Figuring that out would be good as you only have 1 more year for 4.9.y to be alive, that's not going to last for forever... thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 11:39 ` Greg Kroah-Hartman @ 2021-09-26 15:03 ` Willy Tarreau 2021-09-26 16:18 ` Jari Ruusu 1 sibling, 0 replies; 10+ messages in thread From: Willy Tarreau @ 2021-09-26 15:03 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Jari Ruusu, Salvatore Bonaccorso, Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds, Aurelien Jarno On Sun, Sep 26, 2021 at 01:39:33PM +0200, Greg Kroah-Hartman wrote: > On Sun, Sep 26, 2021 at 11:31:20AM +0000, Jari Ruusu wrote: > > On Sunday, September 26th, 2021 at 14:24, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > Why use an older kernel tree on this device? Rasbian seems to be on > > > 4.19.y at the least right now, is there something in those older kernel > > > trees that you need? > > > > Due to circumstances, I need "smallest possible" kernel with all extra > > stripped out. 4.9.y kernels are smaller than newer ones. > > Smaller by how much, and what portion grew? Are we building things into > the kernel that previously was able to be compiled out? Or is there > something new added after 4.9 that adds a huge memory increase? > > Figuring that out would be good as you only have 1 more year for 4.9.y > to be alive, that's not going to last for forever... FWIW a situation I faced a few times was trying to put a modern kernel on a small NAND partition of an older device. Nowadays kernels are really big. I don't have numbers here but for example I never managed to make a 5.10 fit into the 4 MB partition of an old armv5 device where its 3.4 had plenty of room. And there isn't a single thing to disable, it looks more like a systemic growth, probably due to all the stuff we now have to improve large systems performance and harden everything. Willy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: glibc VETO for kernel version SUBLEVEL >= 255 2021-09-26 11:39 ` Greg Kroah-Hartman 2021-09-26 15:03 ` Willy Tarreau @ 2021-09-26 16:18 ` Jari Ruusu 1 sibling, 0 replies; 10+ messages in thread From: Jari Ruusu @ 2021-09-26 16:18 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Salvatore Bonaccorso, Sasha Levin, linux-kernel, stable, Jiri Slaby, Mauro Carvalho Chehab, Linus Torvalds, Aurelien Jarno On Sunday, September 26th, 2021 at 14:39, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Sun, Sep 26, 2021 at 11:31:20AM +0000, Jari Ruusu wrote: > > Due to circumstances, I need "smallest possible" kernel with all extra > > stripped out. 4.9.y kernels are smaller than newer ones. > > Smaller by how much, and what portion grew? Are we building things into > the kernel that previously was able to be compiled out? Or is there > something new added after 4.9 that adds a huge memory increase? Byte sizes of different kernels for my laptop. Everything needed built-in, except for wifi modules. Same compiler, roughly same kernel configs: 6906816 vmlinuz-4.9.284 7603200 vmlinuz-4.19.208 8306752 vmlinuz-5.10.69 > Figuring that out would be good as you only have 1 more year for 4.9.y > to be alive, that's not going to last for forever... I will deal with that when 4.9.y updates run dry, or when Raspbian userland starts requiring newer kernel. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-09-26 16:19 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-26 7:23 glibc VETO for kernel version SUBLEVEL >= 255 Jari Ruusu 2021-09-26 7:28 ` Greg Kroah-Hartman 2021-09-26 8:10 ` Salvatore Bonaccorso 2021-09-26 9:29 ` Greg Kroah-Hartman 2021-09-26 10:58 ` Jari Ruusu 2021-09-26 11:24 ` Greg Kroah-Hartman 2021-09-26 11:31 ` Jari Ruusu 2021-09-26 11:39 ` Greg Kroah-Hartman 2021-09-26 15:03 ` Willy Tarreau 2021-09-26 16:18 ` Jari Ruusu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).