Building your own kernel LQ wiki working thread

Originally Posted by jsbjsb001 Thoughts?

Yes. Add a summary section, just to relist the steps. Only concretely what you have to do.

It is a bit as I feared, it's a bit daunting, and this was something I struggled with as well, which is why I ended up with a summary of only listing the steps to do.

I tend to agree with Hazel in post #60 to be honest.

Originally Posted by zeebra Yes. Add a summary section, just to relist the steps. Only concretely what you have to do. It is a bit as I feared, it's a bit daunting, and this was something I struggled with as well, which is why I ended up with a summary of only listing the steps to do.

I fear doing that would just end up doing the exact opposite in all honesty. The titles of each section in the main body of the article already do that - you can just look at the table of contents at the top of the article to see a summary.

To follow on from Hazel's point in post #60; I didn't even read a book when I first started out with Linux. I just kept using it, poking around the system, trying stuff, and so on until I understood enough to at least be able to ask specific questions if I just couldn't work something out by myself. In relation to building the kernel; I tried at least 4 or 5 times before I finally got it to build. Admittedly it was due to LLVM/Clang that it failed to build for me the first 4 or 5 times, but other than a very brief guide I found online, I was pretty much on my own and had to try and figure out what the process was by myself. My point is: once I figured out the process (ie. get the required deps -> configure the build -> build the kernel -> install it, etc), it was much easier to "just be able to do it". So I really once again have to agree with Hazel's point here; it's a part of learning to have to figure it out. As rtmistler was saying earlier on, and I once again totally agree, if you're not willing to put the effort into reading the required material and putting in the effort, you're not ready to attempt such an effort in the first place. So I think the article shouldn't be attempting to "hold their hand", and I think anyone who is willing to do the required reading and willing to put in the required effort should be able to get something together through it. So I'm not sure failing the first time is such a bad thing - particularly if you keep trying until you get it together.

So I'm not in favor of a "summary" section, or adding anymore sections to the main body of the article to be perfectly honest - it's long enough already.

I've done my final edits. Mostly just minor grammatical ones, but I've rewritten (and greatly compressed) your paragraph on getting root access. Anyone who does not know how to use sudo shouldn't be building a kernel at all.

As far as I'm concerned, that's it :sigh_of_relief:. Now perhaps your doppelganger could actually use our instructions to build a kernel and see if they work.

Originally Posted by hazel ...Now perhaps your doppelganger could actually use our instructions to build a kernel and see if they work.

I wish I could give them the benefit of doubt, but it's very difficult. So I very much doubt they were even serious in begin with - why Jeremy hasn't deleted their account yet is beyond me... it really is.

I would recommend that the author(s) validate the wiki.

Not say back, "I already know how to do it, that's how/why I wrote the wiki."

Instead, start clean, follow what you've done step-by-step, and validate that the provided instruction has the intended result.

That's called testing.

Originally Posted by hazel So if you want to build your own kernel, why don't you go to the wiki article that we have so kindly created for you and follow the instructions? You can do really useful work here by testing our instructions to see if they are understandable to the naive user and if they actually result in a bootable kernel. And then report back to this thread.

Thank you so much. Where is it, I cannot see a link.

Isbjsb001 does not want to talk to me it seems. I don't know why the hostility. But maybe it will give hostility in return?

Originally Posted by jsbjsb002 I cannot see a link.

in post #10 of this thread

Originally Posted by rtmistler I would recommend that the author(s) validate the wiki. start clean, follow what you've done step-by-step, and validate that the provided instruction has the intended result. That's called testing.

Good idea. I'm at a bit of a loose end at the moment, so I could do a build on my LFS system and try using "make install" to install it as suggested by jsb. But I can't test out the GRUB part because I don't use GRUB. For me, making something bootable means adding it to elilo.conf.

Already found one thing! xconfig only works if you have the Qt libraries installed (KDE desktop). For gtk-based desktops, you need gconfig.

Originally Posted by hazel Good idea. I'm at a bit of a loose end at the moment, so I could do a build on my LFS system and try using "make install" to install it as suggested by jsb. But I can't test out the GRUB part because I don't use GRUB. For me, making something bootable means adding it to elilo.conf. Already found one thing! xconfig only works if you have the Qt libraries installed (KDE desktop). For gtk-based desktops, you need gconfig.

Well, I think perhaps the bootloader section should say "update your bootloader to boot with your new Kernel" and not be specific to Grub only. And perhaps mention bootloaders in general, before continuing into that Grub section which is there. It's fine to have a Grub section, because so many use Grub. But it seems ONLY grub is mentioned here, like no other bootloaders exist.

After doing the Kernel goto Grub.. Perhaps it should be, after doing the Kernel goto bootloader.

The tutorial looks good, the biggest issue will be getting the .config correct, which I think is a trial and error process. If one is trying to reduce the size of the kernel as much as possible. ie "I don't need x driver" but later on find out "maybe I should have included x driver for y reason". I think this will always be a problem for the first time one attempts to pare down a kernel. I don't know how you would address this issue. You may have and I just missed it.

I see one conflict in your tutorial:

want to avoid having to use an initrd image for booting

Under the grub section under tips and tricks

root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

the use of uuids on the linux line will require an initrd/initramfs, whereas root=/dev/xxxx or root=partuuid=xxxx on gpt disk, does not, and needs be stated.

Originally Posted by rtmistler I would recommend that the author(s) validate the wiki. ...

Don't mean to be a smartass or anything, but that's pretty much what I did when thinking about what sections to include - for the same reason you are talking about.

In any case, an extension of your suggestion would be; pretending you've never built a kernel yourself, and with only our article to go by; would you yourself get a bootable/working kernel if you done the steps the article says? As I'd think that would be really helpful if you could tell us if the article would be helpful to you in that situation.

Originally Posted by zeebra Well, I think perhaps the bootloader section should say "update your bootloader to boot with your new Kernel" and not be specific to Grub only. And perhaps mention bootloaders in general, before continuing into that Grub section which is there. It's fine to have a Grub section, because so many use Grub. But it seems ONLY grub is mentioned here, like no other bootloaders exist. After doing the Kernel goto Grub.. Perhaps it should be, after doing the Kernel goto bootloader.

The problem for me is that; like Hazel doesn't know GRUB; I don't know LILO nor ELILO... I've only ever used GRUB as far as I can remember. So I wouldn't be able to write about adding an entry to LILO's boot menu. To be clear: I know LILO and ELILO are bootloaders like GRUB is a bootloader (although from what I'm lead to believe, LILO is simpler than GRUB2). But in any case, it would be nice to have something in Tips and tricks about adding an entry to LILO's boot menu. But I'm not in favor of changing what Hazel already wrote for the "Making your new kernel bootable" section in the main body of the article though - any further tips should be put into the Tips and tricks section as extra sub-sections of, not in the main body of the article.

Originally Posted by colorpurple21859 The tutorial looks good, the biggest issue will be getting the .config correct, which I think is a trial and error process. If one is trying to reduce the size of the kernel as much as possible. ie "I don't need x driver" but later on find out "maybe I should have included x driver for y reason". I think this will always be a problem for the first time one attempts to pare down a kernel. I don't know how you would address this issue. You may have and I just missed it.

While I get what you're saying about the kernel config can be trial and error, not sure what you mean by "the x driver"?

I see one conflict in your tutorial: Under the grub section under tips and tricksthe use of uuids on the linux line will require an initrd/initramfs, whereas root=/dev/xxxx or root=partuuid=xxxx on gpt disk, does not, and needs be stated.

I never knew that myself. Why do you need an initrd if you use a UUID in GRUB's config?

Originally Posted by jsbjsb001 But in any case, it would be nice to have something in Tips and tricks about adding an entry to LILO's boot menu. But I'm not in favor of changing what Hazel already wrote for the "Making your new kernel bootable" section in the main body of the article though - any further tips should be put into the Tips and tricks section as extra sub-sections of, not in the main body of the article.

I could do that, But I'm chary of making the damn thing even longer than it is.

While I get what you're saying about the kernel config can be trial and error, not sure what you mean by "the x driver"?

He just means an unspecified driver. It's "X" as in "unknown", not as in "Xorg".

I never knew that myself. Why do you need an initrd if you use a UUID in GRUB's config?

I'm not sure you do actually. GRUB has built-in drivers for filesystems like ext4 and you tell it via the cfg file which driver to load before reading the rest of that menu stanza, so it should be able to read the UUID out of the superblock, shouldn't it?

Originally Posted by hazel I could do that, But I'm chary of making the damn thing even longer than it is.

It'll probably be ok as a sub-section (or in the existing section about adding an entry to the boot menu in Tips and tricks - although that section would need to be renamed as zeebra suggests in that case) in Tips and tricks. But I agree that there is a enough in the main body of the article, so I'm not in favor of making that any longer (or "simplifying" anything else in it for that matter).

He just means an unspecified driver. It's "X" as in "unknown", not as in "Xorg".

Yeah, that's what I thought they meant, "x" as in "Xorg". So it seems I misunderstood that bit.

I'm not sure you do actually. GRUB has built-in drivers for filesystems like ext4 and you tell it via the cfg file which driver to load before reading the rest of that menu stanza, so it should be able to read the UUID out of the superblock, shouldn't it?

I was thinking much the same thing myself.

Originally Posted by jsbjsb001 It'll probably be ok as a sub-section (or in the existing section about adding an entry to the boot menu in Tips and tricks - although that section would need to be renamed as zeebra suggests in that case) in Tips and tricks. But I agree that there is a enough in the main body of the article, so I'm not in favor of making that any longer (or "simplifying" anything else in it for that matter).

OK, done.

PS: Make install doesn't work for me. I get the following weird error:

sudo make install
sh ./arch/x86/boot/install.sh 5.10.3 arch/x86/boot/bzImage \
        System.map "/boot"
Fatal: open /boot/vmlinuz-generic-4.4.14: No such file or directory
arch/x86/boot/Makefile:160: recipe for target 'install' failed
make[1]: *** [install] Error 1
arch/x86/Makefile:275: recipe for target 'install' failed
make: *** [install] Error 2

Of course /boot/vmlinuz-generic-4.4.14 doesn't exist! It's a very old kernel version that I haven't used since God knows when. But why the install script was looking for it, I have no idea.

The need of an initrd has nothing to do with grub, grub understands uuids, otherwise the search function seen in grub menus using uuids wouldn't work. The kernel needs the initrd to understand the root=uuid=xxx option. when root=UUID=xxx is passed to the kernel to find the root filesystem. If I'm not mistaken would need an initrd with lilo if the root=UUID=xxx was added to the append line of the lilo.conf

I meant x as in unspecified driver, not xorg. I understand not wanting to make the wiki any longer then what it already is, just a thought as I was reading through it.