[HowTo] Repeat official building process

[alix_frolov]

Hey guys, sorry if i am not the first one to raise the question, but i really need the answer. I did use search... If you could point me to the complete FAQ covering the topic i will be really glad to read it.
My question is how to repeat the full procedure of a Debian kernel rebuilding. I cannot actually get a working kernel/installer.
I did:
1) Rebuilt kernel from linux-6.1.37-1 sources, by running consequently cd linux-6.1.37/; fakeroot debian/rules source; fakeroot debian/rules binary-arch. As a result i get a bunch of .deb packages, 3 of which are unsigned versions of amd64, cloud and RT
2) I install those 3 unsigned kernels, apt sourced linux-signed-amd64.dsc package with its dependencies, to generate signed kernels, buy running debuild -us -uc. As a result i get signed kernels and a couple dozens of .udebs
3) I use debian-installer sources and the .udebs from the previous step to get vmlinuz and initrd.gz compiled for installation CD. The ISO with these files is not bootable.
Some details of what i got. The unsigned kernel from step one work fine installed. The signed kernel refuses to boot, it cannot find the root FS. The installer made from the .udebs refuses to see any network interfaces and disks on the machine during the installation process.
Repeating 2nd and 3d steps with unsigned kernels from original Debian repo works fine for me, everything like a charm.
What and where i do wrong?

[sunrat]

As this is a support question and not an actual howto guide, moved to General Questions.

[lindi]

Are you trying to rebuild the kernel and also the installer? What's the actual problem you are trying to solve?

[alix_frolov]

Are you trying to rebuild the kernel and also the installer? What's the actual problem you are trying to solve?

Yes. i practically need to create full iso from the packages rebuilt with strace from the examined sources.
I am trying to create an installation iso with my custom kernel from scratch. No to add another custom kernel to it but have my own installed right away. Also, rebuilding packages is kind of necessary in the organization i work at.

[alix_frolov]

Yesterday i used as well the next sequence `export DEB_BUILD_PROFILES='pkg.linux.nokerneldbg pkg.linux.nokerneldbginfo'; export MAKEFLAGS=-j$(nproc); dpkg-buildpackage -b -nc -uc` (found here https://kernel-team.pages.debian.net/ke ... tasks.html ). Unfortunately no luck: the rebuilt signed kernel still shows "mdadm: no device listed in conf file was found' on a system where a second ago a vanila kernel worked fine

[lindi]

Are you trying to rebuild the kernel and also the installer? What's the actual problem you are trying to solve?

Yes. i practically need to create full iso from the packages rebuilt with strace from the examined sources.
I am trying to create an installation iso with my custom kernel from scratch. No to add another custom kernel to it but have my own installed right away. Also, rebuilding packages is kind of necessary in the organization i work at.

Rebuilding everything is likely going to be somewhat tricky. Can you explain bit more why you want to do this exactly so that we can think about what would be the most suitable solution?

[alix_frolov]

Are you trying to rebuild the kernel and also the installer? What's the actual problem you are trying to solve?

Yes. i practically need to create full iso from the packages rebuilt with strace from the examined sources.
I am trying to create an installation iso with my custom kernel from scratch. No to add another custom kernel to it but have my own installed right away. Also, rebuilding packages is kind of necessary in the organization i work at.

Rebuilding everything is likely going to be somewhat tricky. Can you explain bit more why you want to do this exactly so that we can think about what would be the most suitable solution?

I have already rebuilt everything we need. Alas, at the last moment i found out that package linux-signed-amd64 does not actually build kernels, rather uses installed in the building container kernels to rsync and sign precompiled modules from unsigned kernels (i had unsigned vanila kernes installed, not my own, during my first attempts). So the only thing i suppose i have left is the kernel+installer.
I need this because the system from the ISO i am building requires to be rebuild from the sources, which were approved by our security department officers. So i pretty much have no choice

[Aki]

[..] I need this because the system from the ISO i am building requires to be rebuild from the sources, which were approved by our security department officers. [..]

May I ask you:

• why do your security officers require package rebuild ?

• what other activities before/after the rebuild do security officers require to approve ?

[alix_frolov]

[..] I need this because the system from the ISO i am building requires to be rebuild from the sources, which were approved by our security department officers. [..]

May I ask you:

• why do your security officers require package rebuild ?

• what other activities before/after the rebuild do security officers require to approve ?

I have no idea, actually. Probably they have somehow scanned the source code for know vulnerabilities, and now ask to rebuild those .deb files to make sure they actually are build from the source code, and will check the building logs

[Aki]

Hello,

I have no idea, actually. Probably they have somehow scanned the source code for know vulnerabilities, and now ask to rebuild those .deb files to make sure they actually are build from the source code, and will check the building logs

Evasive answer (I mean not necessarily by you, but from your security officers, at least).

Strange.

Rebuilding a source code make sense only if someone doesn't trust the Debian build chain or, more probable, someone wants to modify something in the source code directly or indirectly (linking with modified libraries and shipping them).

[lindi]

Are you planning to sign the kernels with your own key and add that to every machine using secure boot in your organization?

[alix_frolov]

Are you planning to sign the kernels with your own key and add that to every machine using secure boot in your organization?

No definitely no secure boot, i have asked in advance. I said from the very beginning that i need to change the IMA options and several security options about emptying memory, nothing criminal as for me(if you need the exact list of options we are gonna change in the kernel config i can provide you with it).
I was thinking to use your source linux-signed-amd, with your keys. But if that is what concerns you (this option didn't occur in my head, makes sense), we probably may use our own CA to sign the kernel. It, probably, will take some more work but i understand your concerns now. Just i am gonna need a bit more pointers of how to replace the keys/

[alix_frolov]

Hello,

I have no idea, actually. Probably they have somehow scanned the source code for know vulnerabilities, and now ask to rebuild those .deb files to make sure they actually are build from the source code, and will check the building logs

Evasive answer (I mean not necessarily by you, but from your security officers, at least).

Strange.

Rebuilding a source code make sense only if someone doesn't trust the Debian build chain or, more probable, someone wants to modify something in the source code directly or indirectly (linking with modified libraries and shipping them).

The matter isn't trust or absence of such to the debian chain. And yes, you are right, the task is to have our own installation media, signed and rebuild internally (which i clearly indicated at the initial question), with our own customizations. So we are 100% certain of what we install upon our infrastructure. Does it sound strange or against Debian community rules?

[Aki]

Hello,

[..] the task is to have our own installation media, signed and rebuild internally (which i clearly indicated at the initial question), with our own customizations. So we are 100% certain of what we install upon our infrastructure. [..] Does it sound strange [..]

Just some personal thoughts.

Your topic is about " Repeat official building process", but you are not simply repeating the building process of official Debian packages: you are modifying them.

The strange thing is not that you are asking for support to rebuild modified Debian packages (kernel packages, but maybe others too; you started asking to rebuild the entire contents of a Debian-ISO with a Debian-installer; we don't even know what architecture)

May I ask you:

• why do your security officers require package rebuild ?

• what other activities before/after the rebuild do security officers require to approve ?

I have no idea, actually. Probably they have somehow scanned the source code for know vulnerabilities, and now ask to rebuild those .deb files to make sure they actually are build from the source code, and will check the building logs

It is strange that you have no idea what modifications are being made to the code you are rebuilding, and you don't know why they are required (apart from general security concerns).

In the end, it is strange that everything is requested/approved by some "security officers" and that they will evaluate rebuilt packages by checking the logs of the build process.

This lack of transparency seems a little suspicious to me.

[..] Does it [..] against Debian community rules?

As far I know, Debian community rules are not infringed in this topic (so far), but if you are planning building a derivative (or something like that) check here [1].

--
[1] https://wiki.debian.org/Derivatives/Guidelines

[alix_frolov]

Hello,

[..] the task is to have our own installation media, signed and rebuild internally (which i clearly indicated at the initial question), with our own customizations. So we are 100% certain of what we install upon our infrastructure. [..] Does it sound strange [..]

Just some personal thoughts.

Your topic is about " Repeat official building process", but you are not simply repeating the building process of official Debian packages: you are modifying them.

The strange thing is not that you are asking for support to rebuild modified Debian packages (kernel packages, but maybe others too; you started asking to rebuild the entire contents of a Debian-ISO with a Debian-installer; we don't even know what architecture)

May I ask you:

• why do your security officers require package rebuild ?

• what other activities before/after the rebuild do security officers require to approve ?

I have no idea, actually. Probably they have somehow scanned the source code for know vulnerabilities, and now ask to rebuild those .deb files to make sure they actually are build from the source code, and will check the building logs

It is strange that you have no idea what modifications are being made to the code you are rebuilding, and you don't know why they are required (apart from general security concerns).

In the end, it is strange that everything is requested/approved by some "security officers" and that they will evaluate rebuilt packages by checking the logs of the build process.

This lack of transparency seems a little suspicious to me.

[..] Does it [..] against Debian community rules?

As far I know, Debian community rules are not infringed in this topic (so far), but if you are planning building a derivative (or something like that) check here [1].

--
[1] https://wiki.debian.org/Derivatives/Guidelines

Maybe i did not make myself clear, it was purely unintentional. Sorry for that.
I did not realise that we would have to modify the rebuilding process, because we could not use your signature for a kernel with a different config and all the secure boot concerns, which now is clear.
We did most of job you mention in the Derivatives article(thanks you btw for the link, i forgot about something there). The installer package we are not inclined to change too, so keep everything as close to vanilla version as possible. Branding is done by a pressed file mostly, necessary files altered and the logos removed from the iso, we use automated text installer anyway.

The source code was not changed, everything i use is from a frozen repo of Debian 12.1(bookworm) + a few backports with closed vulnerabilities. The source codes underwent some testing, which, as i mention, i have no clue about, the job was done by an independent organisation and is mandatory. The changes introduced are only to kernel config file, which I add during building the unsigned kernel. The resulting package repo and building logs are also a subject for security expertise, in order to check that they are built from the source we had provided. I hope that clarifies why I have nothing to do with the security policies.

But back to my initial question.

Could you walk me through or point out the article about the process of signing kernel and building installer afterwards, if that is not to much to ask? What changes are necessary in signing process, probably, in linux-signed-amd64 for amd64 platforms? I do not expect much alternations there, probably just replace Debian keys, at least i hope it is so.

[donald]

Sounds like you are doing a blend for a specific environment more than anything really suspicious, but I'm not an expert in the field.

You should read the kernel building section of the kernel manual which I think has the steps you need to accomplish your inquiry, chapter 4 specifically. https://kernel-team.pages.debian.net/ke ... n-building

[alix_frolov]

Sounds like you are doing a blend for a specific environment more than anything really suspicious, but I'm not an expert in the field.

You should read the kernel building section of the kernel manual which I think has the steps you need to accomplish your inquiry, chapter 4 specifically. https://kernel-team.pages.debian.net/ke ... n-building

Thank you. I did it already. And the custom kernel gets installed by preseed in the post-install section. But i would like to get rid of having 2 kernels on the ISO(first one installed by default during installation, and the other later) it does not seem pretty. And this way does not allow me to rebuild the installer, which is the crucial part of the entire idea or rebuilding everything. That is why i started the topic, i could not find information about it at all, and fruitlessly had been trying to rebuild the installer and the signed kernel with the src. packages provided in off.repo.

[Linuxgaming1824]

I actually found original source documentation for Linux 1.0 recently and it inspired me to start building my own kernels following the original instructions linus gave for building it.

It's much easier building the regular kernel, and it's easy to manage alongside apt managing it's own debian kernels if your boot sector is big enough

in the original source documentation linus was very sincere in emphasizing that building the kernel should be a simple process and that less was more

[alix_frolov]

I actually found original source documentation for Linux 1.0 recently and it inspired me to start building my own kernels following the original instructions linus gave for building it.

It's much easier building the regular kernel, and it's easy to manage alongside apt managing it's own debian kernels if your boot sector is big enough

in the original source documentation linus was very sincere in emphasizing that building the kernel should be a simple process and that less was more

Building own kernel, based on already tested base is better, if you dont want to spend ages looking for the right balance doing it from scratch.
The idea is to follow debian building process as closely as possible, introducing only necessary alternations, exactly as it's said in the Derivatives link from above. That's much easier to maintain later, than having a vanilla kernel installed by the installer, and my custom kernel afterwards, then have ansible remove vanilla kernel. And repeating a Debian-like scenario of assembling ISO only seems like a natural way for most production scenarios, not looking for an easy way here, looking for less troublesome in consequences. But i cannot do it unless i got instructions of how to recreate process of signing up kernels (with my own keys) and rebuilding the installers from them, to get debian based systems meeting the requirements I have.

[alix_frolov]

@Aki @lindi
Sorry for bothering you, but it seems as if only you know for sure how to build correct unsigned kernels, sign them(not necessarily by Debian keys) creating correct udebs, and building functional vmlinuz аnd initrd based on the udebs. So as the result all those components function properly(the way it work with unsigned kernels from vanilla repo).
Could you share this information or is it not for disclosing? If latter (i had Debian mailing list as a last resort), I will stop asking about debian-installer, and get to explore Debian-live. I hope all its components might be rebuilt