You are not logged in.
Pages: 1
Something is just not clicking in my little head. I have been trying to build a custom kernel and have been unsuccessful.
I've read the custom kernel wiki entries, both with and without ABS. I've read the kernel build HOW-TO, and multiple other kernel compile guides.
I decided tonight to try what I thought should be the simplest custom kernel - adding an additonal option to the stock Arch config and recompiling.
So, I wanted to add support for squashfs.
1. I got the 2.6.15 source from kernel.org
2. I patched it with squashfs3.0-patch
3. I copied over the .config file from /usr/src/linux-2.6.15-ARCH
4. I did make menuconfig and added squashfs to the kernel
5. Then I make clean and make bzImage
Shouldn't this give me the stock kernel + squashfs or am I missing some additional patches?
Doing it like this I figured I could skip remaking the modules and initrd becuase the existing ones would still work - I didn't add or subtract modules (squashfs went into the kernel) so the initrd and /lib/modules shouldn't need to be updated right?
I copied over the new kernel image, edited grub menu and rebooted. The kernel loads but fails with:
mount: Mounting /dev/root on /new_root failed: no such device or address plus some additional error messages, and then I'm left at the BusyBox prompt.
I've searched and found others with identical errors after a kernel upgrade but none of the fixes they did worked or were not really applicable. Trying the initrd26-full.img doesn't help either.
So then I just started trying stuff like rebuilding the initrd with kernel_version= option, making and installing the modules again, renaming the modules subdirs to match my kernel name - basically just getting more and more confused as I went on.
What is the relationship between the file names used in /boot and the dir names in /lib/modules? I mean, you can call your kernel image anything you want right? Same for the initrd image also correct? How does this affect the name of the dir in /lib/modules? Not at all?
Like I said, I'm just *not getting it*, so I'm not really sure about the questions I'm asking.
I want to do this without ABS first because I feel like I'll understand the process better.
Offline
why don't you just install archck? it has squashfs patches and a whole lot of other useful things. Its in extra just do pacman -S kernel26archck
Offline
why don't you just install archck? it has squashfs patches and a whole lot of other useful things. Its in extra just do pacman -S kernel26archck
Because that wouldn't teach me anything
Offline
My advice would be to check on what version you're using currently. If you're using an installation which was before .7.1 you may still be using DevFS instead of Udev. The reason you may see something like that is because it's pointing to the incorrect device node. I'll put it this way
DevFS: Your hard drive partition looks something like this:
/dev/discs/disc#/part#
Udev: Your hard drive partition looks something like this:
/dev/hdx#
So, what you may need to do is identify what the new node is within the /dev/ folder. Whenever I get an error like that, I realized that I've done something along those lines. Once you figure out what the correct node is, you need to make the changes appropriatly within grub's menu.lst. Hopefully this is what you're looking to do. Oh, also, you may need to use a LiveCD to get access to the hard disk (this is what I usually need to do).
Offline
I count 12 patches to kernel26 in /var/abs/kernels/kernel26 for the latest 2.6.15 arch pkgbuild.
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Thanks for the replies.
@dswain - I'm using the most current Arch as it is, so it's not a Devfs issue.
I count 12 patches to kernel26 in /var/abs/kernels/kernel26 for the latest 2.6.15 arch pkgbuild.
So I guess my methodology is not wrong, just that my kernel source didn't exactly match the stock kernel? I kind of suspected that might be part of the problem.
So if I get the stock kernel source, or the vanilla kernel source and make sure to apply all the same patches, then I should be able to:
- copy the stock config
- make 1 change (say squashfs not as a module)
- compile
- move the bzimage into /boot using whatever name I want
- add a grub entry and point to the same initrd as the stock kernel
Yes?
Offline
A few weeks back, the squashfs was available as a module in the 2.6.15 kernel AFAIK.
I haven't located it at present and haven't any further info as to where it went or how to implement installing a new module in a kernel release with any dependencies it may require.
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
- copy the stock config
- make 1 change (say squashfs not as a module)
- compile
- move the bzimage into /boot using whatever name I want
- add a grub entry and point to the same initrd as the stock kernel
I've been using an unpatched vanilla kernel for some time now (atm I'm in an archck kernel, but only since yesterday), worked fine. Did you copy over the System.map file to /boot?
Offline
In building my custom kernels, I transfer all elements of the /var/abs/kernels/kernel26 file, make my changes to the config file and pkgbuild and then run makepkg. If custom kernel is desired, pkgbuild is modified, otherwise (no custom desired)it is not modified and the change affects all kernel26 related boots(vmlinuz26).
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
sodface wrote:- copy the stock config
- make 1 change (say squashfs not as a module)
- compile
- move the bzimage into /boot using whatever name I want
- add a grub entry and point to the same initrd as the stock kernelI've been using an unpatched vanilla kernel for some time now (atm I'm in an archck kernel, but only since yesterday), worked fine. Did you copy over the System.map file to /boot?
Yes, I copied the System.map file. Do you use an initrd with your vanilla kernels or do you include everything you need in the kernel itself? I'm pretty sure that my problems stem from something I'm doing wrong in regard to the initrd as opposed to something I'm doing wrong during the kernel build, save for patch level perhaps.
I printed out the mkinitrd script this afternoon and went over it pretty good to get a feel for how the initrd creation process works. I'm going to start over and try again.
I'm doing it this way as a learning exercise. I feel I can learn more about how a linux system boots, or at least how a 2.6.x Arch system boots, as opposed to building with ABS or using an archck kernel. Squashfs was just something I picked as an addition, not because I need it specifically.
Offline
In building my custom kernels, I transfer all elements of the /var/abs/kernels/kernel26 file, make my changes to the config file and pkgbuild and then run makepkg. If custom kernel is desired, pkgbuild is modified, otherwise (no custom desired)it is not modified and the change affects all kernel26 related boots(vmlinuz26).
I will investigate this, thanks for the info.
Offline
The stock config builds a kernel that needs initrd, so if you just add squashfs, you'll need it too.
Incidentally, the 2.6.16 kernel will be moving to current sometime soon, and it has just 4 patches, so you could simplify your build a little, AND be ahead of the posse - well, some of the posse, anyway .......;)
Offline
In building my custom kernels, I transfer all elements of the /var/abs/kernels/kernel26 file, make my changes to the config file and pkgbuild and then run makepkg. If custom kernel is desired, pkgbuild is modified, otherwise (no custom desired)it is not modified and the change affects all kernel26 related boots(vmlinuz26).
I got this method to work.
One thing though, any change in the config will fail the md5 check so editing PKGBUILD is always necessary? (remove md5sums or regenerate them?)
Offline
The stock config builds a kernel that needs initrd, so if you just add squashfs, you'll need it too.
Incidentally, the 2.6.16 kernel will be moving to current sometime soon, and it has just 4 patches, so you could simplify your build a little, AND be ahead of the posse - well, some of the posse, anyway .......;)
Using the method lilsirecho described worked good for the current Arch kernel but I haven't seen a way to get ABS to include Testing in the ABS tree. Or maybe I'm just missing the obvious. There is not an option for it in /etc/abs.conf either. Is this because Testing isn't really a separate CVS branch but just Current with a Testing tag?
Offline
Yeah, that's right. Judd has put the procedure in the wiki here.
Offline
Your conclusion regarding the MD5 sums is correct..I forgot that detail and I am old enuff to blame it on alzheimers
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Pages: 1