"initrd" with command line parameters
in [Slackware]
|
From: Helmut Hullen on 16 Apr 2008 07:13 Hallo alle miteinander, I need some possibility to boot a machine via "initrd" and telling "initrd" another "root device" than the pre-installed device in the "initrd". Background: I make kernels and initrds for other machines, for unknown machines (with P-ATA, S-ATA, SCSI, Compaq-Array, ...). When I run "mkinitrd", the script takes the root device from my machine (which doesn't fit everywhere - it's /dev/hda6), or I tell the skript to take another root device (p.e. "/dev/cciss/c0d0p1"), which doesn't fit everywhere. The template contents of the initrd is packed in /usr/share/mkinitrd/initrd-tree.tar.gz Is there any way to let the "init" script look for parameters on the command line? If there is a way: what is to be changed in "lilo.conf"? Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: +Alan Hicks+ on 17 Apr 2008 15:35 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2008-04-16, Helmut Hullen <helmut(a)hullen.de> wrote: > I need some possibility to boot a machine via "initrd" and telling > "initrd" another "root device" than the pre-installed device in the > "initrd". > > Background: I make kernels and initrds for other machines, for unknown > machines (with P-ATA, S-ATA, SCSI, Compaq-Array, ...). > > When I run "mkinitrd", the script takes the root device from my machine > (which doesn't fit everywhere - it's /dev/hda6), or I tell the skript to > take another root device (p.e. "/dev/cciss/c0d0p1"), which doesn't fit > everywhere. > > Is there any way to let the "init" script look for parameters on the > command line? Yes, but it won't be simple. The initrd mounts the proc filesystem at /proc (inside the initrd's / basically) and you could grab a kernel commandline option from /proc/cmdline, but that only gets you half-way. The initrd's init grabs the root device and the root filesystem from the /rootdev and /rootfs files respectively. You will have to over-ride this in init to use whatever partition and filesystem you specified on the kernel's commandline. Specifying those commandline arguments in lilo.conf is fairly trivial; they are just "append=" lines in each image statement. I hope that helps. It's a very interesting problem, and I don't think anyone who has worked on mkinitrd has considered it before. Please let us know how it turns out for you, or if you run into any other problems. Could you explain why it is necessary to make these initrds on a computer they will not be run on? If it's a big problem for more than a handful of people, I might look into submitting a patch for mkinitrd to handle this when the next -current opens up. - -- It is better to hear the rebuke of the wise, Than for a man to hear the song of fools. Ecclesiastes 7:5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkgHppgACgkQrZS6hX/gvjpXvwCgsdW15FO9KhucjeJmOVzJhHmG E5wAoN1kwzPQXhHgAJtCZNBmkNElusPX =BZqh -----END PGP SIGNATURE-----
From: Helmut Hullen on 17 Apr 2008 17:01 Hallo, +Alan, Du meintest am 17.04.08: >> Is there any way to let the "init" script look for parameters on the >> command line? > Yes, but it won't be simple. > The initrd mounts the proc filesystem at /proc (inside the initrd's / > basically) and you could grab a kernel commandline option from > /proc/cmdline, but that only gets you half-way. > The initrd's init grabs the root device and the root filesystem from > the /rootdev and /rootfs files respectively. You will have to > over-ride this in init to use whatever partition and filesystem you > specified on the kernel's commandline. > Specifying those commandline arguments in lilo.conf is fairly > trivial; they are just "append=" lines in each image statement. http://jootamam.net/howto-initramfs-image.htm shows a way to import command line parameters - I'll try. Frank Paulsen has send me the link. And Frank Boehm has tried http://www.baldar.de/pub/eeePC/initrd-tree-xl.tgz for the ASUS EEE. > I hope that helps. It's a very interesting problem, and I don't > think anyone who has worked on mkinitrd has considered it before. Look for "Process command line options" in the first mentioned page - maybe that paragraph is all Patrick might add to the actual "init" script in "/usr/share/mkinitrd/initrd-tree.tar.gz". > Please let us know how it turns out for you, or if you run into any > other problems. Could you explain why it is necessary to make these > initrds on a computer they will not be run on? Look at http://arktur.de/download.php (end of the page) The installation CD is used in many schools, it's used from colleagues with no skills in linux. They don't like to install a new server instead of porting only the disks (or the backups) from an old server to a new server. Without an initrd perhaps they must run rdev bzImage </dev/newmachine> But with an initrd they must run "mkinitrd" on the new machine, but the old disk won't boot. I make the "general purpose" kernel with the "general purpose" initrd for these school servers (p.e. without sound, without video4linux - a pure server doesn't need them). And the initrd has to fit for P-ATA, for S-ATA, for SCSI, for Compaq CCISS etc. > If it's a big problem for more than a handful of people, I might look > into submitting a patch for mkinitrd to handle this when the next - > current opens up. Sounds good. A colleague and I try since 2 weeks to transfer and run the contents of an IDE disk to a Compaq Proliant ("/dev/cciss/c0d0px"). Copying the data is simple. Changing the initrd.gz without a second machine is nearly impossible, and the only necessary change is "rootdev", from "/dev/hda1" to "/dev/cciss/c0d0p1". Please excuse my gerlish ...
From: Helmut Hullen on 17 Apr 2008 17:16 Hallo, +Alan, Du meintest am 17.04.08: > The initrd mounts the proc filesystem at /proc (inside the initrd's / > basically) and you could grab a kernel commandline option from > /proc/cmdline, but that only gets you half-way. Just an idea: may it be possible for the "init" script to look for an "initrd.conf" file and overwrite the hard coded parameters? For testing I work with many kernels, I sort them per /boot/<kernel>-<ext> p.e. /boot/2.6.24.3-ODS/.config System.map bzImage initrd.gz And then a nice place would be in this special directory, next to the wanted kernel and the wanted initrd. Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: Joseph Rosevear on 19 Apr 2008 06:38
Helmut Hullen <helmut(a)hullen.de> wrote: > Hallo alle miteinander, > I need some possibility to boot a machine via "initrd" and telling > "initrd" another "root device" than the pre-installed device in the > "initrd". > Background: I make kernels and initrds for other machines, for unknown > machines (with P-ATA, S-ATA, SCSI, Compaq-Array, ...). > When I run "mkinitrd", the script takes the root device from my machine > (which doesn't fit everywhere - it's /dev/hda6), or I tell the skript to > take another root device (p.e. "/dev/cciss/c0d0p1"), which doesn't fit > everywhere. > The template contents of the initrd is packed in > /usr/share/mkinitrd/initrd-tree.tar.gz > Is there any way to let the "init" script look for parameters on the > command line? > If there is a way: what is to be changed in "lilo.conf"? > Viele Gruesse > Helmut > "Ubuntu" - an African word, meaning "Slackware is too hard for me". Hallo Helmut, I have a solution that I use that I think would meet your needs. As Alan said, it is not simple. It is like Frank's method, but you do not recompile busybox. I do it by making a boot disk (Joe's Boot Disk) which is a CD. This method also uses grub. This works well and is able to do what you said. You can put the disk into a machine and boot. It lets you pick a kernel from the kernels that are on the CD. And it let's you specify boot parameters (for example, "vga=791"). Then it uses the initrd.gz which is on the CD. The initrd.gz has a modified init script and other changes. Script init prompts you for partition name (for example, "/dev/sda4") and file system type (for example, "ext3"). I have two scripts that I use to make boot disks. The first script makes the initrd.gz file. The second uses the initrd.gz file to make a grub boot CD (Joe's Boot Disk). Both scripts are called "prep". Here is a prep script that makes initrd.gz (on my computer it has this path /opt/SAM/config/resurect/ramdisks/080418aa/prep): vvv #!/bin/sh # prep, by Joe Rosevear # This makes a new initrd.gz file. Run this as root from the dir that # contains this. Note that this script puts files and dirs in # initrd-tree before making initrd.gz. # The way it puts them there uses "follow" and "asis" dirs. These # refer to what they do to symbolic links. Either can have files that # are meant to be copied "as is", but only "asis" should have symbolic # links that are to be preserved as links. Links that are to be # followed should go in "follow". # Remake current rm -R ../current mkdir ../current # Make a starter initrd-tree in current. # The accompanying initrd.gz will be overwritten later. mkinitrd -s ../current/initrd-tree -o initrd.gz # add prep to current cp -pi prep ../current # copy and follow links when copying mv follow initrd-tree -i cp -RLp initrd-tree ../current mv initrd-tree follow -i # copy and copy links "as is" mv asis initrd-tree -i cp -Rdp initrd-tree ../current mv initrd-tree asis -i # to avoid accidents remove prep's execute permission chmod ugo-x ../current/prep # put note in dir with pwd pwd > ../current/pwd.txt pushd ../current mkinitrd -s initrd-tree -o initrd.gz popd cp ../current/initrd-tree/initrd.gz . ^^^ To understand what this does you will need to see directories (dirs) follow and asis. I'll pause here to let you catch up. -Joe |