On Friday 13 July 2007, Aaron Konstam wrote: >On Fri, 2007-07-13 at 01:10 -0400, Tom Diehl wrote: >> On Wed, 11 Jul 2007, Aaron Konstam wrote: >> > On Wed, 2007-07-11 at 01:16 -0400, Tom Diehl wrote: >> >> Hi, >> >> >> >> I need to know if anyone has the magic incantation to get mkinitrd to >> >> build a proper initrd from either rescue mode or the live cd. I need to >> >> put a drive into another box that has a different disk controller in >> >> it. >> >> >> >> If I boot into rescue mode and setup a chroot, when I run mkinitrd I >> >> get an error that says "error opening /sys/block: No such file or >> >> directory. >> > >> > Do you have a /sys directory on your installation. It is one of those >> > pseudo directories like /proc. If not mkdir /sys might be worth doing. >> >> Actually I tried mounting both /proc and /sys inside the chroot. They >> mounted OK and the errors went away but the mkinitrd still produced an >> initrd that would not boot. :-( >> >> I finally ended up cheating. I fired up the Live cd and mounted all of the >> system partitions. Then, I setup a chroot and did an rpm -e kernel* >> >> I then rebooted into Anaconda and told it to upgrade the system to F7. >> Since the machine was already an F7 box it simply reinstalled a kernel and >> updated the initrd. When I rebooted the machines came up normally. :-))))) >> >> I realize this is kind of a convoluted way to get the machines going again >> but it worked. >> >> I would still like to know how to rebuild the initrd but so far no one >> knows. It must be some super secret incantation. I suppose if I understood >> python I could read the anaconda src and see how they do it but alas I do >> not speak python. :-( >> >> For the record, there were 2 machines involved in this, one was F7 and the >> other was Centos 5. I used the procedure above to recover both of them >> without reinstalling. >> >> Hope this info helps someone else. > >At the risk of causing ire, running mkinitrd is rather straightforward >and is described adequately in the man page. I have done it many times. >Maybe if you posted the mkinitrd line you executed we could help >further. > I don't know as that should cause any ire, Aaron. I think whats messing with him may be that he is trying to over-write an existing one, and that's something I personally have never tried. Why? Because I long ago wrote me a script to do all this, and at the time I considered that I might want to revert to the older version with a live session grub edit, the end result being that my script first touches all those files to make sure they exist, rm's the .old versions, then mv's the originals to .old versions. The actual line(s) that generates the initrd in my script is: echo now making a new initrd.$VER.img && \ touch initrd-$VER.img && \ rm -f initrd-$VER.img && \ mkinitrd -f initrd-$VER.img $VER && \ echo and copying it to /boot/initrd-$VER.img && \ touch /boot/initrd-$VER.img.old && \ rm -f /boot/initrd-$VER.img.old && \ touch /boot/initrd-$VER.img \ mv /boot/initrd-$VER.img /boot/initrd-$VER.img.old \ cp initrd-$VER.img /boot/initrd-$VER.img && \ Where $VER is set at the top of the script to match that of the Makefile, and the script is cd'd to $VER. I also use the \ rather liberally throughout my script such that if there is an error at anyplace in the whole procedure from the make bzImage stage on, it exits properly leaving the error message still visible in that shells screen. I can do a 'time ./makeit' in that screen, go away and do other things, having only to edit my grub.conf and reboot if the compile succeeds. My script is a kludge, it's probably butt ugly to some, but it has now built and installed every kernel I've run since the early 2.4 days, probably 200+ successfull runs now, with no surprises like the Makefiles have more than occasionally contained. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I hope something GOOD came in the mail today so I have a REASON to live!!
