I guess I was able to take it further... I discovered a call in Grub.pm
to grub-install --recheck and commented it out. This time
systemconfigurator --runboot ran without errors, but...
I spotted another error in my autoinstall script, specifically:
/scripts/sandbox16.sh: /scripts/sandbox16.sh: 559: cannot create
/a/etc/systemconfig/hardware.1st: Directory nonexistent
followed by
Added SCSI device 0e11:b178 using module cciss to hardware.1st
Please press Enter to activate this console.
I'm guessing the script stopped because it hit my exit statement not
because of the error above. is there any way to trap this error and
quite upon hitting it? once again, this is something the novice user
has no way to deal with, but more important, since the script continued
running this is the type of message nobody is even going to see since
not everyone carefully watches messages scroll by.
From this point I did a 'chroot /a' and ran systemconfigurator --runboot
Did Imention before the message:
WARNING: Label SW-cciss/c0d0p2 not found anywhere on the system! at
/usr/lib/systemconfig/Boot/Grub.pm line 210
but that line number is wrong as I've inserted debugging code. The
actual line it's complaining about reads:
my $fstab = Boot::Label::fstab_struct("/etc/fstab"); in find_grub_root.
shouldn't there also be a check to make sure this function call
succeeded? [are you detecting a theme here to some of my comments? 8-)]
Anyhow, let me know what else I can do as I'm currently out of ideas...
-mark
Mark Seger wrote:
> I think I may have taken this as far as I can without a lot of more
> digging. I think this is going to require a 'team' effort, but here's
> what I did:
>
> - I installed my patched Label.pm
> - commented out the code in Grub.pm that deletes device.map
> - put an exit statement right before the call to systemimager
>
> at that point I ran "systemconfigurator --runboot", which if I
> understand correctly just deals with the boot loader and no networks,
> making it much easier to deal with debugging.
>
> anyhow, that generated a bunch of undefined messages and upcon
> completion the device.map file was messed up, which means someone is
> indeed messing with that file and my fear is it may be grub-install!
> the one neat thing is I can rsynh over fresh copies of both device.map
> and Grub.pm and so can insert debugging code! that done, I reran
> systemconfiguration redirecting the output to a file which I'm
> including below. The only thing is there were 2 messages that didn't
> get into my output file which I don't understand. I did
> systemconfigurator --runboot >/tmp/xxx 2>&1...
>
> The messages that didn't get captured were 2 copies of:
> "end_request: I/O error, dev fd0, sector 0"
>
> I inserted a print statement in device_map so I could see where it was
> called and then immediately printed out the device.map and you can see
> by then the damage has been done because it no longer contains its
> original values which were:
>
> (fd0) /dev/fd0
> (hd0) /dev/cciss/c0d0
> (hd1) /dev/cciss/c0d1
>
> And here's the output from my debugging session:
>
> C:\TEMP>type xxx
>
> Probing devices to guess BIOS drives. This may take a long time.
> /dev/cciss/c0d0p1 does not have any corresponding BIOS drive.
> WARNING: Label SW-cciss/c0d0p2 not found anywhere on the system! at
> /usr/lib/systemconfig/Boot/Grub.pm line 212
> DEVICE MAP CALLED!!!
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/systemconfig/Boot/Grub.pm line 160.
> Use of uninitialized value in substitution (s///) at
> /usr/lib/systemconfig/Boot/Grub.pm line 164.
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/systemconfig/Boot/Grub.pm line 240.
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/systemconfig/Boot/Grub.pm line 242.
> DEVICE MAP: (fd0) /dev/fd0 <<< this is where I print the
> contents of device.map
>
> GRUB: (fd0) REAL: /dev/fd0 <<< this is more debugging code, but
> really isn't necessary at this point
> Probing devices to guess BIOS drives. This may take a long time.
>
> so, the big question is does systemconfigurator call grub-install
> before if calls device_map? if so, my guess is it shouldn't!
>
> -mark
>
> Mark Seger wrote:
>
>> ok, I ran my tests and sad to say my memory seems to be correct.
>> here's what I did, and if you don't have the hardware you're just
>> going to have to take my word for it - btw, where are you located?
>>
>> anyhow, here's what I did:
>> - patched the autoinstall script to exit right after /etc/mtab was
>> created and before systemconfigurator is called
>> - execute the command as per device_map in Grub.pm
>> grub --batch --device-map=/boot/grub/device.map < /dev/null >
>> /dev/null
>>
>> This resulted in:
>> Probing devices...
>> end_request: I/O error, dev fd0, sector 0
>> cat /boot/grub/device.map
>> (fd0) /dev/fd0
>>
>> This is EXACTLY what I remember happening in the past.
>>
>> As I said in an earlier email, grub 0.93 is not capable of recreating
>> the device map file if cciss devices are involved. Now for the
>> second part of all this, and I guess I need to reimage again to
>> starte clealy but thanks to SI, that's pretty easy to do...
>>
>> If Grub.pm DOESN'T recreate the device map file, will the rest of
>> this work? I don't know, but now that I've gotten this far maybe
>> I'll give it a shot. But I have to run a few errands first...
>>
>> -mark
>>
>>
>> Erich Focht wrote:
>>
>>> Hi Mark,
>>>
>>> as Bernard mentioned, I'm maintaining the OSCAR variant of
>>> systemconfigurator, which is currently the only version which seems
>>> to be
>>> maintained at all.
>>>
>>> I've also looked at your patches and have a few concrete questions:
>>>
>>> in Grub.pm:
>>> + else {
>>> + $smartArrayFlag=1;
>>> + $file="/boot/grub/device.map";
>>> + verbose("using existing map file $file");
>>> + croak("$file doesn't contain required 'hd' entry for
>>> SmartArray devices") if `grep hd $file` eq '';
>>> + }
>>>
>>> Can you rely on the fact that the device.map file exists? I have the
>>> impression that it is created in the if branch above, so won't
>>> necessarilly be
>>> present.
>>>
>>> As you can see in function device_map, we are unconditionally creating
>>> /etc/mtab and the device.map. What exactly is the "new" device.map
>>> missing for
>>> your case? And where is the old device.map coming from? From your
>>> image? That
>>> doesn't exist on an OSCAR image because that one is freshly created
>>> from RPMs.
>>>
>>> Thanks,
>>> best regards,
>>> Erich
>>>
>>> On Friday 07 July 2006 19:24, Mark Seger wrote:
>>>
>>>
>>>> Here are my patches to make systemconfigurator work with version
>>>> 0.93 of grub install. I have no idea what the implications of
>>>> running this against the latest version of grub is, but the safest
>>>> thing might be to check the grub version and only execute the code
>>>> under those conditions.
>>>>
>>>> One should also note note that unless someone patches grub-install
>>>> (which isn't part of SystemConfigurator), these patches probably
>>>> won't do you any good. There are also patches to grub-install to
>>>> deal with an empty /etc/mtab, but I'm guessing that problem has
>>>> since been fixed in the newer version of SystemImager. It's also
>>>> possible some other patches may not be necessary since this were
>>>> also run in a SystemImager 3.2.0 environment but I do know I can't
>>>> install rhel3 using 3.7.3 unless I apply my patched versions of
>>>> Grub.pm. Label.pm and grub-install.
>>>>
>>>> I'll be happy to discuss the patches and the reasons for them if
>>>> anyone wants more details.
>>>>
>>>
>>>
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sisuite-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
