Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora User (http://www.linux-archive.org/fedora-user/)
-   -   Changing initrd contents and grub (http://www.linux-archive.org/fedora-user/111948-changing-initrd-contents-grub.html)

Richard Michael 06-23-2008 03:35 PM

Changing initrd contents and grub
 
Hello list,

I've changed my RAID and LVM configuration and need to modify the
respective commands in the /init of my initrd.

I made those changes by decompressing and extracting the cpio archive,
editting the init script (add a couple lines for mdadm, changed the
activated volume group name), rebuilt a cpio archive (using the correct
"-c"/"-H newc" SVR4 format) and fed it back through gzip (max
compression), then I just moved aside the old initrd, replacing it with
my new one:

mkdir /boot/tmp
cd !$
gzip -dc ../initrd-<version> | cpio -id
vi init
find . -depth -print | cpio -oc | gzip -9 > ../initrd-<version>.new
cd ..
mv initrd-<version> initrd-<version>.orig
mv initrd-<version>.new initrd-<version>

The kernel now panics (paraphrase) "can't find /init".

It does not do this if I restore the original initrd.

I have not changed the name of the initrd, filenames match grub.conf and
grub's boot menu, etc. I have done this type of modification
successfully in the past, but only changing a single character in /init.

So, it appears the kernel is not using my use initrd. Perhaps it is not
prepared correctly (file magic for both new and old initrd files
suggests they are the same, however)? Is grub involved somehow?
Perhaps it can't find my new initrd?

/boot is on a raid1 partition, ext2fs. Grub knows about this, and the
system used to boot without problem.

Any advice?

Thanks,
Richard

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Phil Meyer 06-23-2008 04:39 PM

Changing initrd contents and grub
 
Richard Michael wrote:

Hello list,

I've changed my RAID and LVM configuration and need to modify the
respective commands in the /init of my initrd.

I made those changes by decompressing and extracting the cpio archive,
editting the init script (add a couple lines for mdadm, changed the
activated volume group name), rebuilt a cpio archive (using the correct
"-c"/"-H newc" SVR4 format) and fed it back through gzip (max
compression), then I just moved aside the old initrd, replacing it with
my new one:

mkdir /boot/tmp
cd !$
gzip -dc ../initrd-<version> | cpio -id
vi init
find . -depth -print | cpio -oc | gzip -9 > ../initrd-<version>.new
cd ..

mv initrd-<version> initrd-<version>.orig
mv initrd-<version>.new initrd-<version>

The kernel now panics (paraphrase) "can't find /init".

It does not do this if I restore the original initrd.

I have not changed the name of the initrd, filenames match grub.conf and
grub's boot menu, etc. I have done this type of modification
successfully in the past, but only changing a single character in /init.



Just a thought here, since I have also tried this several times with
limited success:


The whole point of mkinitrd is to avoid these 'by hand' operations.

After you make your changes, run mkinitrd to generate a new initrd. It
will pick up changes in /etc/modprobe.conf and /etc/fstab and try to do
the right thing. Besides that, mkinitrd will accept arguments that
allow additional drivers to be loaded, with arguments if needed, as well
as many other options.


I am pretty sure that a modern mkinitrd will make almost all need for
manual edits of an initrd image unnecessary.


Good luck!

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Richard Michael 06-23-2008 04:54 PM

Changing initrd contents and grub
 
On Mon, Jun 23, 2008 at 10:39:35AM -0600, Phil Meyer wrote:
> Richard Michael wrote:
>> Hello list,
>>
>> I've changed my RAID and LVM configuration and need to modify the
>> respective commands in the /init of my initrd.
>>
>> I made those changes by decompressing and extracting the cpio archive,
>> editting the init script (add a couple lines for mdadm, changed the
>> activated volume group name), rebuilt a cpio archive (using the correct
>> "-c"/"-H newc" SVR4 format) and fed it back through gzip (max
>> compression), then I just moved aside the old initrd, replacing it with
>> my new one:
>>
>> mkdir /boot/tmp
>> cd !$
>> gzip -dc ../initrd-<version> | cpio -id
>> vi init
>> find . -depth -print | cpio -oc | gzip -9 > ../initrd-<version>.new cd ..
>> mv initrd-<version> initrd-<version>.orig
>> mv initrd-<version>.new initrd-<version>
>>
>> The kernel now panics (paraphrase) "can't find /init".
>>
>> It does not do this if I restore the original initrd.
>>
>> I have not changed the name of the initrd, filenames match grub.conf and
>> grub's boot menu, etc. I have done this type of modification
>> successfully in the past, but only changing a single character in /init.
>>
>
> Just a thought here, since I have also tried this several times with
> limited success:
>
> The whole point of mkinitrd is to avoid these 'by hand' operations.
>
> After you make your changes, run mkinitrd to generate a new initrd. It
> will pick up changes in /etc/modprobe.conf and /etc/fstab and try to do the
> right thing. Besides that, mkinitrd will accept arguments that allow
> additional drivers to be loaded, with arguments if needed, as well as many
> other options.

I understand what you are saying, but I am of the opposite opinion.

I have a decent picture of what needs to change, and where to change it.
For example, those raid arrays which must be activated, and others not,
etc. What I obviously need is a more detailed understanding of the
kernel boot process, the BIOS and grub. (One problem here is
troubleshooting the kernel and boot is tricky when the output moves so
quickly on the screen!)

Automated tools often frustrate me because (a) I don't learn anything,
so I can't fix it when something goes wrong, and (b) something will go
wrong due to all the guesswork of an automated tool. As I say, I've
fixed problems with initrd's on other systems this way before. (In
fact, I had to change the uuid of an array that was being activated. If
I hadn't know anything about the contents of an initrd and how to modify
it, etc. it would have been quite hard to fix with mkinitrd because the
system wouldn't boot!)

In this situation, mkinitrd is hard to employ because the system is
booted from the Fedora DVD in rescue mode. I'm moving the entire system
to a new configuration (RAID1 on RAID5). This means I can't run
mkinitrd on *the* system to have it autoprobe, etc., etc. (chrooting
from a rescue image always seems broken because the /dev entries never
exist in the newly root tree). Moreover, I think nested RAID arrays
will really confuse any of the automated tools because that
configuration isn't (doesn't appear to be) supported (at least not at
install time).

Thanks though.

Regards,
Richard

> I am pretty sure that a modern mkinitrd will make almost all need for
> manual edits of an initrd image unnecessary.
>
> Good luck!
>
> --
> fedora-list mailing list
> fedora-list@redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Bruno Wolff III 06-23-2008 05:41 PM

Changing initrd contents and grub
 
On Mon, Jun 23, 2008 at 10:39:35 -0600,
Phil Meyer <pmeyer@themeyerfarm.com> wrote:
>
> I am pretty sure that a modern mkinitrd will make almost all need for
> manual edits of an initrd image unnecessary.

If there is a difference in the modules needed between the running kernel
and the kernel you want to generate there can be problems generating the
module list. I ran into this when I did a yum upgrade from FC6 to F9 and
wanted to do the whole process remotely.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list


All times are GMT. The time now is 02:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.