now, to retart what I did on a non-patched environment: - patch autoinstall script to exit right before system configurator called - grub-install /dev/cciss/c0d0
note - /boot/grub/device.map contains (fd0) /dev/fd0 (hd0) /dev/cciss/c0d0
grub-install blows up because /etc/mtab is empty! if I "grep ext3 /proc/mounts > /etc/mtab" it then blows up because it can't find a device special file for /dev/cciss/disc0/part2 (that's my bootable partition). I've tried building links for /dev/cciss/disc0/part2 and /dev/cciss/disc0 to their counterparts of /dev/cciss/c0d0p2 and /dev/cciss/c0d0 but then grub-install blows up complaining it can't find an entry in device.map! I tried editing device.map to put in /dev/cciss/disco insteat of /dev/cciss/cod0 (now we're really hacking things up) and this time the line
tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'`
blows up complaining about in invalid reference to \1. A close look revealed that the disc0/part2 format is forcing the df output to 2 lines instead of 1! I tried adding the -P switch to df (which is a change to grub-install) but that didn't help either.
The bottom line is I tried a LOT of alternatives to make grub-install work by changing the environment and couldn't come up with a way to do it, so the only alternative I see if to supply a patch to grub-install or never be able to use that loader with cciss devices, unless of course someone else can come up with a workaround that allows one to use grub-install unaltered.
by the way, I should also remind everyone that if I use grub-install outside of this environment with /dev/cciss/c0d0 it works just fine, but in that envuironment there are no occurances of devices that look like /dev/cciss/disc0/part2
-mark
Message: 4 Date: Thu, 27 May 2004 07:20:43 -0600 From: dann frazier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Sisuite-users] trying to reach closure with grub and SmartArrays Reply-To: [EMAIL PROTECTED]
On Fri, May 21, 2004 at 01:39:30PM -0400, Mark Seger wrote:
what has me mystified is why for ide devices are the device special file names in /proc/mounts and for ccis devices they're not? is this something systeminager/systemconfigiurator is doing? should I even care?
my guess is its based on what we actually mount. for most devices (ide, scsi), we can mount by whatever name the system used. this is because both the devfs and non-devfs names exist at the same time.
with some devices - cciss, ida, rd, etc - it is not possible for both names to exist at the same time. see the comments above dev_to_devs() in Server.pm for an explanation. In this case, we actually mount by the devfs name, regardless of what the system uses normally. This probably caused the problem you're seeing, and is probably best fixed by providing a devfs_to_dev function to undo this mapping when in the chroot.
my fix to all this is to just remap device names into the same format as the device special files, both in systemconfigurator's lable() function and in grub-install as well. I admit the ideal situation would be to do it cleaner, but I think that would start with figuring out why /proc/mounts (and perhaps other files) aren't consistent.
maybe what we need is a "regen_mtab" function, that copies some stuff over from /proc/mounts, but knows when to do your translation. If both grub and sc get all their mount info from mtab, this sounds like a way we can do it w/o having to patch Grub itself.
I'd really like to just see this fixed and when I get a chance will post the changes I had to make to get this all to work.
I'm including the changes I had to make to grub-install, Grub.pm, and Label.pm.
Any change that requires modifications to grub-install aren't an option, since we don't maintain that file; so I won't apply this version of your patch.
Submitting patches is definitely the right approach - some comments on this one: - Please use functional names for subroutines - mjscvt() doesn't say what it does - Avoid whitespace only changes - I noticed a few chunks that did this [1] Whitespace changes usually end up causing patch conflicts, and otherwise make the patch for difficult to read. - it looks like your patch is backwards - lines beginning with '-' will be removed, lines beginning with '+' will be added. switch this around by putting files in the opposite order on the diff command line. I got confused when it looked like you were just deleting code. - leaving *some* debug in is ok, as long as you hide it in the default case. if ($debug), or if ($verbose).
Thanks Mark!
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Sisuite-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-users
