hi, I have some questions about the compilation process which I am not familiar with. #1 using ArchLinux PKGBUILD, I recompiled the LTS kernel with a slight change introduced in the block/blk-core.c file and two files were generated : linux-lts-6.1.15-1-x86_64.pkg.tar.zst and linux-lts-headers-6.1.15-1-x86_64.pkg.tar.zst. on the other hand, I had previously compiled packages that used linux-lts-headers-6.1.15-1-x86_64.pkg.tar.zst : do I have to recompile them after the change ? #2 my host kernel has been upgraded to 6.1.19-1-lts : how do I compile to 6.1.15-1-lts from 6.1.19-1-lts? regards, lacsaP.
On 3/20/23 05:27, lacsaP Patatetom wrote:
hi,
- When you change the source you must also bump pkgrel as the package is now different. - If you want to build your own version of an Arch package, you should not use same package name as the official Arch package - this will only lead to bad things. Change the package name to something else. - current kernel LTS is 6.1.20 so probably you should throw away 6.1.15 and use that anyway. best, gene
not renaming the package and modifying pkgrel can indeed lead me to confusion, but it's just personal compilation. ok : good practices you encourage ;-) version 6.1.20 has just been downloaded and will be soon in place but my question remains : how to target 6.1.15 when evolving under 6.x.y (or 6.1.z) ? virtual machine (this is what I use to get around the problem but it seems pretty heavy) ? "cross" compilation ? make parameters ? environment variables ? thank you for these precisions which unfortunately do not enlighten me much :-( regards, lacsaP. Le lun. 20 mars 2023 à 11:02, Genes Lists <lists@sapience.com> a écrit :
On 3/20/23 05:27, lacsaP Patatetom wrote:
hi,
- When you change the source you must also bump pkgrel as the package is now different.
- If you want to build your own version of an Arch package, you should not use same package name as the official Arch package - this will only lead to bad things. Change the package name to something else.
- current kernel LTS is 6.1.20 so probably you should throw away 6.1.15 and use that anyway.
best,
gene
On 3/20/23 06:44, lacsaP Patatetom wrote: Please don't top post on mailing lists. I don't understand what 'problem' you are speaking of. All you've asked is if you can install a kernel headers from a different build - the general answer is "no" - don't ever do that. I already explained if you want to compile kernel package that you hav emodified, bump pkgrel and compile it - it will create both kernel and kernel headers package - install and use them both. Cross compile?? Unless you're compiling on one architecture for another I don't understand the question. Since you're compiling a kernel for a VM your host and VM are presumably both x86-64. Honestly, my best advice to you is stop trying to build kernels.
On Mon, 20 Mar 2023 at 11:00, Genes Lists <lists@sapience.com> wrote:
On 3/20/23 06:44, lacsaP Patatetom wrote:
Please don't top post on mailing lists.
Honestly, my best advice to you is stop trying to build kernels.
Hmm the saying to give a person a fish feeds them for a day, teach them how to fish and you feed them for their lifetime comes to mind. Just saying "stop doing" what they want to be doing is in bad taste in my opinion.
Hi, I'm not sure if I understand what the OP tries to achieve. I install "linux" and "linux-rt-lts" from repositories, but build "linux-rt" myself. To keep different versions of "linux-rt 4.19, I add an extension, "cornflower", "pussytoes" or "securityink". I misuse pkgrel to inform me if CONFIG_HZ is 1000 or 300. $ pacman -Q linux{,-rt{-lts,,-cornflower,-pussytoes,-securityink}}|awk '{print $1"\t"$2}' linux 6.2.7.arch1-1 linux-rt-lts 5.15.96.61.realtime1-1 linux-rt 1:4.19.277_rt122-0.1000 linux-rt-cornflower 1:4.19.271_rt120-0.300 linux-rt-pussytoes 1:4.19.269_rt119-0.300 linux-rt-securityink 1:4.19.265_rt117-0.300 IOW we can not install 2 different "linux", but we can install "linux-foo" and "Linux-bar", if we don't want to follow the approach of some other distros, that don't name the kernels "vmlinuz-linux", but "vmlinuz-4.5.6-7", so by this approach there is the need to edit the bootloader config or to change links each time a kernel gets updated. Regards, Ralf
On 3/20/23 07:03, Andy Pieters wrote:
Sure on fish. But you deleted part of my comment where I provided some teaching information as well. So perhaps you mean, sure you taught them how to fish but you were too discouraging about their potential fishing ability. And good teachers are encouraging. Which would be fair.
Le lun. 20 mars 2023 à 12:00, Genes Lists <lists@sapience.com> a écrit :
On 3/20/23 06:44, lacsaP Patatetom wrote:
Please don't top post on mailing lists.
I use GMail and just click on "Respond to all" : is this the "top post" ? should I only answer you or not put you individually in the answer since you are in the list ?
I don't understand what 'problem' you are speaking of. All you've asked is if you can install a kernel headers from a different build - the general answer is "no" - don't ever do that.
I don't understand either : it makes me think of a dialogue of the deaf :-)
I already explained if you want to compile kernel package that you hav emodified, bump pkgrel and compile it - it will create both kernel and kernel headers package - install and use them both.
if I understand correctly, I can install my package linux-lts-perso-6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?
Cross compile?? Unless you're compiling on one architecture for another I don't understand the question. Since you're compiling a kernel for a VM your host and VM are presumably both x86-64.
I put cross in quotes to mean some analogy with this one (eg. cross-compilation: x86 > arm / me: 6.1.20 > 6.1.15)
Honestly, my best advice to you is stop trying to build kernels.
if I understand correctly, I can install my package linux-lts-perso-6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?
The kernel headers are used to compile out-of-tree kernel modules for that kernel. You should always install kernel and its companion headers file. While there may be cases where the headers are not actually changed and it may work - good policy is always install both kernel and its companion headers package. If you don't compile out of tree kernel modules then you may not even need to install headers. Hope that is clear.
On Mon, 2023-03-20 at 12:27 +0100, lacsaP Patatetom wrote:
if I understand correctly, I can install my package linux-lts-perso- 6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?
I still don't know if I understand you and https://www.google.com/search?q=translate doesn't help. You can install core/linux-lts 6.1.20-1 core/linux-lts-docs 6.1.20-1 core/linux-lts-headers 6.1.20-1 and also your linux-lts-perso 6.1.15-2 linux-lts-perso-docs 6.1.15-2 linux-lts-perso-headers 6.1.15-2 neither the version, nor the pkgrel matter. You can run one or the other kernel and you can build modules for what ever kernel you like, see https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modul... . You (usually) can use a binary such as /usr/bin/vim with one or the other kernel, but you might need to build modules to use something like virtualbox. In your case something like systemd or xorg is irrelevant, but something like this might depend closer on kernel versions, than vim does. Regards, Ralf
it's clear yes, thanks for these explanations/clarifications. Le lun. 20 mars 2023 à 12:42, Genes Lists <lists@sapience.com> a écrit :
if I understand correctly, I can install my package linux-lts-perso-6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?
The kernel headers are used to compile out-of-tree kernel modules for that kernel. You should always install kernel and its companion headers file. While there may be cases where the headers are not actually changed and it may work - good policy is always install both kernel and its companion headers package. If you don't compile out of tree kernel modules then you may not even need to install headers.
Hope that is clear.
On Mon, 2023-03-20 at 07:42 -0400, Genes Lists wrote:
The kernel headers are used to compile out-of-tree kernel modules for that kernel. You should always install kernel and its companion headers file. While there may be cases where the headers are not actually changed and it may work - good policy is always install both kernel and its companion headers package. If you don't compile out of tree kernel modules then you may not even need to install headers.
I don't know if that's what the OP is asking for. There's no need to compile e.g. vim or bash against a new kernel version. But there is the need to compile e.g. virtualbox kernel modules against a new kernel version.
thank you for your feedback Ralf which is in line with Genes' explanations. the application that could fall into the mentioned category and that I am paying attention to is lvm, but previous tests show that this is not the case (the lvm2 package provided by ArchLinux behaves as expected with the recompiled modified kernel). regards, lacsaP. Le lun. 20 mars 2023 à 12:49, Ralf Mardorf <ralf-mardorf@riseup.net> a écrit :
On Mon, 2023-03-20 at 12:27 +0100, lacsaP Patatetom wrote:
if I understand correctly, I can install my package linux-lts-perso- 6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?
I still don't know if I understand you and https://www.google.com/search?q=translate doesn't help.
You can install
core/linux-lts 6.1.20-1 core/linux-lts-docs 6.1.20-1 core/linux-lts-headers 6.1.20-1
and also your
linux-lts-perso 6.1.15-2 linux-lts-perso-docs 6.1.15-2 linux-lts-perso-headers 6.1.15-2
neither the version, nor the pkgrel matter. You can run one or the other kernel and you can build modules for what ever kernel you like, see
https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modul... .
You (usually) can use a binary such as /usr/bin/vim with one or the other kernel, but you might need to build modules to use something like virtualbox.
In your case something like systemd or xorg is irrelevant, but something like this might depend closer on kernel versions, than vim does.
Regards, Ralf
lvm is a good one , bpftrace and other tools that might rely on kernel hooks , or something specific module or statically compiled feature , but as Ralf said , the vast majority of user land applications can be used interchangeably with different kernels . On Mon, 20 Mar 2023 at 11:59, lacsaP Patatetom <patatetom@gmail.com> wrote:
thank you for your feedback Ralf which is in line with Genes' explanations.
the application that could fall into the mentioned category and that I am paying attention to is lvm, but previous tests show that this is not the case (the lvm2 package provided by ArchLinux behaves as expected with the recompiled modified kernel).
regards, lacsaP.
Le lun. 20 mars 2023 à 12:49, Ralf Mardorf <ralf-mardorf@riseup.net> a écrit :
On Mon, 2023-03-20 at 12:27 +0100, lacsaP Patatetom wrote:
if I understand correctly, I can install my package linux-lts-perso- 6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?
I still don't know if I understand you and https://www.google.com/search?q=translate doesn't help.
You can install
core/linux-lts 6.1.20-1 core/linux-lts-docs 6.1.20-1 core/linux-lts-headers 6.1.20-1
and also your
linux-lts-perso 6.1.15-2 linux-lts-perso-docs 6.1.15-2 linux-lts-perso-headers 6.1.15-2
neither the version, nor the pkgrel matter. You can run one or the other kernel and you can build modules for what ever kernel you like, see
https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modul... .
You (usually) can use a binary such as /usr/bin/vim with one or the other kernel, but you might need to build modules to use something like virtualbox.
In your case something like systemd or xorg is irrelevant, but something like this might depend closer on kernel versions, than vim does.
Regards, Ralf
hi everybody, if point #1 is now relatively clear to me (eg. out of tree kernel modules need to recompile, otherwise it should work with few exceptions), point #2 is still pending. so I rephrase my question hoping to find an answer ;-) my development workstation is running 6.1.20-1-lts and I made linux-lts-ro-6.1.15-1-x86_64.pkg.tar.zst and linux-lts-ro-headers-6.1.15-1-x86_64.pkg.tar.zst packages on it : if now I want to compile on this development workstation applications to run on another workstation which is running 6.1.15-1-lts-ro, what should I do so that the compilation takes this specificity into account ? I saw that there was the gcc ‘--enable-kernel=version’ option : is it the solution ? if yes, how to introduce it during the traditional "./configure && make" ? regards, lacsaP. Le lun. 20 mars 2023 à 13:19, Jeronimo Garcia <garciaj.uk@gmail.com> a écrit :
lvm is a good one , bpftrace and other tools that might rely on kernel hooks , or something specific module or statically compiled feature , but as Ralf said , the vast majority of user land applications can be used interchangeably with different kernels .
On Mon, 20 Mar 2023 at 11:59, lacsaP Patatetom <patatetom@gmail.com> wrote:
thank you for your feedback Ralf which is in line with Genes' explanations.
the application that could fall into the mentioned category and that I am paying attention to is lvm, but previous tests show that this is not the case (the lvm2 package provided by ArchLinux behaves as expected with the recompiled modified kernel).
regards, lacsaP.
Le lun. 20 mars 2023 à 12:49, Ralf Mardorf <ralf-mardorf@riseup.net> a écrit :
On Mon, 2023-03-20 at 12:27 +0100, lacsaP Patatetom wrote:
if I understand correctly, I can install my package linux-lts-perso- 6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?
I still don't know if I understand you and https://www.google.com/search?q=translate doesn't help.
You can install
core/linux-lts 6.1.20-1 core/linux-lts-docs 6.1.20-1 core/linux-lts-headers 6.1.20-1
and also your
linux-lts-perso 6.1.15-2 linux-lts-perso-docs 6.1.15-2 linux-lts-perso-headers 6.1.15-2
neither the version, nor the pkgrel matter. You can run one or the other kernel and you can build modules for what ever kernel you like, see
https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modul... .
You (usually) can use a binary such as /usr/bin/vim with one or the other kernel, but you might need to build modules to use something like virtualbox.
In your case something like systemd or xorg is irrelevant, but something like this might depend closer on kernel versions, than vim does.
Regards, Ralf
On 3/21/23 04:26, lacsaP Patatetom wrote:
hi everybody,
my development workstation is running 6.1.20-1-lts and I made linux-lts-ro-6.1.15-1-x86_64.pkg.tar.zst and linux-lts-ro-headers-6.1.15-1-x86_64.pkg.tar.zst packages on it : if now I want to compile on this development workstation applications to run on another workstation which is running 6.1.15-1-lts-ro, what should I do so that the compilation takes this specificity into account ?
Unless you are compiling kernel modules the answer is nothing. The kernel team takes great pains to ensure that user space will continue to work. Most of the kernel interface of the kernel with user space is mediated by libraries such as glibc. You do need to be sure that your user-space environment is consistent between the compiling host and the application target. For example that the target machines run same version of glibc etc. So short answer - if only difference between your compile machine and target application machine is kernel - there is nothing special you need to do. Good luck.
again thank you for explanations/clarifications. have a good day, regards, lacsaP. Le mar. 21 mars 2023 à 11:16, Genes Lists <lists@sapience.com> a écrit :
On 3/21/23 04:26, lacsaP Patatetom wrote:
hi everybody,
my development workstation is running 6.1.20-1-lts and I made linux-lts-ro-6.1.15-1-x86_64.pkg.tar.zst and linux-lts-ro-headers-6.1.15-1-x86_64.pkg.tar.zst packages on it : if now I want to compile on this development workstation applications to run on another workstation which is running 6.1.15-1-lts-ro, what should I do so that the compilation takes this specificity into account ?
Unless you are compiling kernel modules the answer is nothing. The kernel team takes great pains to ensure that user space will continue to work. Most of the kernel interface of the kernel with user space is mediated by libraries such as glibc.
You do need to be sure that your user-space environment is consistent between the compiling host and the application target. For example that the target machines run same version of glibc etc.
So short answer - if only difference between your compile machine and target application machine is kernel - there is nothing special you need to do.
Good luck.
participants (5)
-
Andy Pieters
-
Genes Lists
-
Jeronimo Garcia
-
lacsaP Patatetom
-
Ralf Mardorf