Easiest method to run shell script before mounting root fs

[Reiner Rottmann]

Hi,

I would like to create a seperate grub boot stanza that runs a maintenance shell script before mounting the root filesystem.

I have thought of the following possibilities:

Modify initrd:/init

- Needs to be recreated for new kernel releases.
- Easy to automate, though. I would create a diff file, create the initrd, unzip it, patch it and repackage it.
- Rather boring to develop with. If something fails or during first development one need to code, recreate initrd, reboot, see whether it works, code some more, make code persistent by mounting and copying another fs. boot os, recreate initrd... boring as I said...



Creating a small partition with another Linux installation.

- I do not want to have another partition on the system

Creating a filesystem image disk.img via dd. Then format it with ext3, install a base Linux system to the image and somehow boot it with grub/extlinux

- I like this idea but I think that it is not as easy to boot a disk image. I know that one may boot floppy and cd images but they seem to be ro only.

What would you suggest? What do you think is the easiest way?

[Matti_Kurkela · Accepted solution]

Before the root filesystem is mounted, there is not much you can do.

You cannot modify the contents of any filesystem, because they haven't been mounted yet.

You cannot persistently modify the contents of initrd, because not all the tools required to rebuild initrd are within initrd. And to write a new initrd, you would have to mount at least /boot.

Normally you cannot use the network, because you don't have network driver modules nor the configuration files that would tell you the IP network parameters. If you produce any logs or other result files, you must pass them on to the root file system when it's mounted, or your result files will be lost.

Modification of RAID1 mirror sets does not seem very productive either: if you plan to do something destructive, you cannot go forward with the boot. If your operation is non-destructive, why not do it after the root filesystem is mounted, but still in read-only mode? (= at the very beginning of regular non-initrd-based boot sequence)

What kind of tasks do you plan to run in this way? There might be alternate ways to accomplish essentially the same thing.

Yes, debugging any early-boot environment will be tricky. Whether you develop a custom initrd or a custom filesystem/image, you'll have to reboot a lot to see if it really works. This is exactly why most distributions keep the initrd environment as simple as possible.

MK

[Reiner Rottmann]

I would like to transport a root fs to SAN by creating a boot stanza and booting that once.

This could be possible with lvm snapshots and copying it to the SAN lun but I would like to copy the contents without the server running.

As I need to automate the procedure I currently tend to modify an initrd to call the necessary steps.

[Lucifer Megacruel]

Hi Reiner,

I would go with method (1) .

"- Needs to be recreated for new kernel releases. " I do not think this is really required , you can specify the kernel to be be loaded using kernel and the intial ramdisk using initrd parameter in grub. You may look at the grub documentation.

About method (2)

It is easy to do this , grub can load .img files as long as it fits into the ramdisk :). So doing it this way is same as method (1) itself.

--Lucifer

[dirk dierickx]

this;

Modify initrd:/init

- Needs to be recreated for new kernel releases.
- Easy to automate, though. I would create a diff file, create the initrd, unzip it, patch it and repackage it.
- Rather boring to develop with. If something fails or during first development one need to code, recreate initrd, reboot, see whether it works, code some more, make code persistent by mounting and copying another fs. boot os, recreate initrd... boring as I said...

what you should do is keep a kernel installed and not remove it when an update comes in. you create your own initrd, add it to grub and it can stay there forever. i would test this in a vm, like virtualbox and not on a physical machine to make testing/developing easier. there is hardly a limit to what you can do with an initrd image.

[Matti_Kurkela]

If you really want to modify initrd, you should see which tool is used by your distribution to create initrds, and see if it offers any way to plug in your customizations.

For example, the initramfs-tools package (which is the default package for initrd creation in Debian) allows you to drop in scripts in various sub-directories of /etc/initramfs-tools. These scripts, depending on where you put them, can automatically act on either the initrd creation or the boot process. If your distribution of choice allows something similar, you could make a set of drop-in customizations: the system would automatically add them to any future initrd files.

But for your actual issue of migration to SAN... if you are already using LVM, I would suggest pvmove (or, with care, LVM-level disk mirroring functionality). If you don't have LVM, using "dd" when your root filesystem is read-only would certainly work, but if you're migrating to SAN, it would be a *really good idea* to start using LVM too.

If you have something like EMC Symmetrix or HP EVA, in about 3-5 years the pricing of the support agreements will typically make upgrading to a newer model a really attractive option. At that point, you may need to migrate your systems from one SAN to another... and then, having LVM will make things a *lot* easier.

But for initial migration of the root filesystem to SAN, you will still have to take several steps:

1.) Choose your boot LUN appropriately. Depending on your HBAs, you may have to make sure the boot LUN is LUN 0, or do something to specifically select which LUN to use for booting.

2.) If you use multipathing (and you should), make sure your initrd is configured to start your multipath solution before the root filesystem is mounted.
(By default, RHEL 5 and older don't do this unless the "mpath" boot option was used _when installing the OS_.)

Also make sure all the necessary HBA drivers are included in your initrd.

3.) Set up your boot LUN appropriately: for ordinary (non-EFI) PC hardware, create a traditional /boot partition and dedicate the rest of the disk to LVM.

4.) Copy the contents of the /boot filesystem to the new /boot partition on SAN.

5.) Install a bootloader to the LUN. Make sure you edit /boot/grub/device.map or otherwise convince the bootloader that the new boot LUN will eventually be (hd0) when the system will be booting from it.

At this point, you can test your system for SAN boot ability: if your system is configured to use LVM and initrd includes drivers for both SAN HBAs and local disk controllers, LVM might/should seamlessly detect your root VG still on the local disks and activate and mount it. With a non-LVM system, you might achieve pretty much the same thing by specifying the root filesystem by label or UUID instead of by explicit device name: the device name may change as you fiddle with scsi_hostadapter drivers and their loading order.

The essential things to verify are:
- the system boots from the correct LUN
- the bootloader successfully loads the kernel and initrd from the SAN LUN, not from the local disk

Anything else is gravy.

Testing this will typically require you to make changes to BIOS settings, so this step might be the trickiest to automate, depending on your hardware.

6.)
The next step would be migrating the actual root filesystem. For example, RHEL 5 executes /etc/sysconfig/readonly-root from early /etc/rc.sysinit while the root filesystem is still read-only. Normally the readonly-root file contains only environment variables, but it would also work nicely as a hook for your root filesystem migration script.

While the root filesystem is read-only, you might even use "dd" to copy it to the new location if it's a basic non-LVM filesystem.

After the root filesystem has been migrated, you may have to do something to make the system use the root filesystem from the new location, depending on various details.

If you used "dd" for copying a non-LVM root filesystem to SAN, you now have two copies of the root filesystem with identical labels and UUIDs, so you'll have to be specific.

If you added the new root LUN to already-existing root VG and then pvmove'd the root LV to the new LUN, you'll have to do nothing at this step: if the root filesystem was specified as "root=/dev/VolGroup00/LogVol01" in the bootloader configuration, it will be exactly the same after a pvmove-based migration.

MK