You are not logged in.
Pages: 1
I have a tiny-itsy-bitsy feeling that each kernel I have installed must have its associated initrd images (auto=custom/full), am I right or not? It is my belief that modules (and thus images) might not be compatible between kernels.
If I'm right, is there a KISS method of making these files coexist? Shouldn't the initrd images include in their names the kernel for which they were built?
I am asking this because I want to have a close to painless transition and, when I upgrade kernels, I always keep a backup kernel installed. Sometime in the far future I might have 2 initrd kernels installed.
Thanks.
P.S. no, I haven't switched to initrd kernel yet - it's the middle of the school semester, holidays are coming => bad time for testing.
:: / my web presence
Offline
if you add the kernel version, you have to change your bootloader each time, that is a real horror. For your own purpose it's possible but not for all archers out there.
just use the mkinitrd command with kernel-version= then it's build for the kernel you specified and named after the kernel.
greetings
tpowa
Offline
Well... shouldn't the initrd image name contain AT LEAST the kernel package name (which doesn't change from one version to another)?
I haven't tested the initrd enabled kernel (see above reasons) but I have looked through the install functions. I've noticed
/sbin/mkinitrd auto
/sbin/mkinitrd full
Which initrd images are created when no parameters are given? (for which kernel)
:: / my web presence
Offline
mkinitrd wihtout anything will give you the options
Offline
you have to change your bootloader each time, that is a real horror.
A Real Horror?! :shock: A bit of exaggeration there, tpowa, surely.
Anyone who rolls their own kernels will be used to updating grub or lilo as required - and given Arch's target users, it shouldn't be a problem for anyone else either.
Actually, I'm waiting to see how you handle the inclusion of the full initrd image in the kernel package, as per phrakture's suggestion. If it makes sense to me, I'll try incorporating it into dibble's custom kernel PKGBUILD, which is what I use for all my kernel needs. If that works, I'll have uniquely-named kernels AND initrds - which is how all this relates to your original question, Ice.
Offline
Which initrd images are created when no parameters are given? (for which kernel)
Correction for the above question: ... when no kernel-version= is specified...
To be more precise: I understand the reason for not having a kernel-version stamped initrd image. We shouldn't have to update config files from one upgrade to another.
My question was more about how to have different kernel branches (no matter what version) on the same system (like kernel26, kernel26archck, kernel26mm, kernel26custom whatever). Under these circumstances, wouldn't it be more appropriate to tag the initrd images with... lets say.. "-ARCH"?
:: / my web presence
Offline
At last some common sense ;-)
Sooo why not tag each kernel version to avoid clashes
Mr Green
Offline
Hmm.. this might not have been my best day.
How about replacing
tag the initrd images with... lets say.. "-ARCH"
in my previous post with
append a package-name-specific suffix to the initrd images... like "-ARCH"/"-arch" and have "initrd26-full-arch.img" or something similar
:: / my web presence
Offline
why not adding this to other kernel and let the standard kernel as it is?
Offline
why not adding this to other kernel and let the standard kernel as it is?
Lets keep things easy for tpowa and make it difficult for everyone else.
Offline
Sorry ICEram :oops:
I moved stock kernel out of the way before loading test kernel, good job I did because testing kernel wipes over stock kernel :?
/me must stop ranting
Mr Green
Offline
I have 2 initrd kernels on my system with no troubles at all. When you use mkinitrd to build an image for you custom kernel you must specify kernel_version= for things to work right any way. When you run mkinitrd with kernel_version= it will tag the initrd image with whatever your specified as kernel_version=.
The way they wrote the mkinitrd script if you use auto of full it will determine the kernel version with this command.
grep "version" /boot/kconfig26 > /tmp/kernelversion
Since archck and ck and the others save their kconfig as kconfig26archck etc it will never build an initrd image for a custom kernel with auto or full so their initrd images should always be taged appropriately. Yes the auto and full commands can be misleading if read too quickly.
/sbin/mkinitrd <kernel_version> [options] Where <kernel_version> is one of: auto build for the installed Arch kernel full build with all possible modules kernel_version={version} use kernel version (no autodetect) <== Snip ==>
Auto builds for the installed stock ARCH kernel and full builds for the installed stock ARCH kernel ignoring mkinitrd.conf.
As my system sits right now, the stock kernel has initrd26.img and initrd26-full.img while my ck kernel has initrd-2.6.14-ck6-ARCH.img (archck doesn't using initrd yet so I'm not sure why I keep using them as an exmaple). This was the default behavior of the mkinitrd script. Yes I have to update grub every time I upgrade my ck kernel for the new initrd image, but because of the way I name my kernel I have to update it anyway so its kind of a moot point in my case. If I really wanted to automate it I could make the changes from the install script with sed anyway.
Which initrd images are created when no parameters are given? (for which kernel) Correction for the above question: ... when no kernel-version= is specified...
If you don't specify a kernel_version= and you don't use auto or full which build for the stock kernel then you will just get the usage message.
As we are all making suggestions for improvements I'll add my thoughs. It would be nice if there was a way to specify a kernel patch version on the command line. Then the mkinitrd script run with auto or full would look at kconfig26kernel_patch_version (eg kconfig26archck) to determine the installed kernel version and build the initrd image accordingly. The package maintainers could then change thier install scripts to call mkinitrd auto kernel_patch_version=patch_version and the proper image would be built accordingly. Then we could have initrd26.img for stock, initrd26archck.img for archck, etc.
Offline
Thank you all for the explanations... This brings me a bit closer to fully understanding the future initrd system under expected situations.
It's a bit weird though to have the stock kernel use non-suffixed initrd images...
:: / my web presence
Offline
Thank you all for the explanations... This brings me a bit closer to fully understanding the future initrd system under expected situations.
Future? initrd is already replaced by initramfs...
Offline
Wow :shock:
I have just set it up & its already out of date lol
Mr Green
Offline
Future? initrd is already replaced by initramfs...
It has? Well.. no problem. I don't have time to invest in this right now... so I can afford waiting. 10x for letting me know.
:: / my web presence
Offline
Pages: 1