Still another try. This time I edited the autoinstallscript to remove sdb and built a new autoinstall script. I even checked to make sure no references to sdb. When SC runs on the client I again see errors for sdb and there is a /proc/partitions entry for it. So how did it get mounted? I also did a grep for sdb in /etc and found an entry in smartd.conf, which apparantly is some sort of disk monitoring daemon. Could that be somehow involved? -mark
Mark Seger wrote: > OK, one more thing I thought of on the way to the dump - yeah, I live > in the country - I forgot the verbose switch so I ran it again and > checked the output. However it also occurred to me that there should > be options to get more details for diagnostic puposes AND there really > needs to be a way to save errors like those disk ones on sdb I > mentioned. If anyone want I can send off a screen shot. > > Anyhow, running with --verbose I spotted SC trying to examine sdb and > from the code it looks like this is because sdb is in > /proc/partitions. How did that get there? Must be some table that > controls this but I don't know what. It's not in /etc/fstab or > /etc/mtab. My thought is if I could stop SC from probing sdb maybe it > will be able to write out a good boot loader. Might there be some LVM > structure that defines it as part of a volume set - as I said before I > thought I had disabled sdb/sdc when I installed the system (though > their partition tables also have the lvm flag set and I don't know > where that come from unless it was a previous installation?)... > > -mark > > Mark Seger wrote: > >> ok, I think the deal is that when systemconfigurator calls >> grub-install IT tries to probe the various drives and it turn craps >> out with a bunch of sdb errors. The reason I say this is because I >> tried to manually run "grub-install /dev/sda" and it worked - gave me >> a bunch of errors I don't understand on fd0, but I'm not going to >> worry about those for now. Anyhow I rebooted but things still >> crapped out with a 'non-system disk or disk error' so I'm guessing >> things still aren't quite cofngured right. sigh... >> >> another debugging question - and this may be FAQ worthy - is there a >> way to capture the output of these commands when they die? I tried >> doing a systemconfiguratior --runboot >xxx 2>&1 and still got the >> errors on my console and not in the log file. Even if there is a way >> to make this work, part 2 of the FAQ might also talk about how to >> copy the log back to the image server using rsync. Another FAQ that >> would also be useful is a discussion of how to use the console to >> 'chroot /a' and manually execute the commands the autoinstallscript >> is running and possibly even inserting exit statements into the >> script so you can break out at various points of the process. I'm >> not even sure this is the best way to do things but that's the way >> I've been doing it. When things work well, they really work well, >> but when something goes wrong it's not real clear how to proceed >> unless you've been there before... >> >> I also remember Andrea telling me some dump command to run to verify >> the boot record was properly written. This too might be FAQ worthy. >> Feels like there is the need for a whole section of troubleshooting >> tips and tricks. >> >> -mark >> >> Mark Seger wrote: >> >>> Time to ramble a bit... >>> >>> I've been having major problems trying to get an installation to >>> work on an operton with 3 sda disks using LVM, and thanks to Andrea >>> it looks like sdb went bad! I was able to edit my autoinstallscript >>> to change all occurances of sdb to sdc and remove all the sdc's and >>> so I can now build/format the partitions and lay down an image. My >>> first point/question is it would sure be nice if there were more >>> checking for device integrity in the autoinstall script. This stuff >>> is so solid (and I mean that as a compliment), whenever something >>> goes wrong I assume it's me. So when I saw a lot of sdb errors I >>> figured I must have screwed up retrieving the image and/or building >>> the autoinstall script. A couple of checks might have save me and >>> andrea a lot of time tracking this down. >>> >>> So, now I'm able to image the system, but systemconfigurator now >>> craps out with errors on sdb and I'm guessing there must be a file >>> somewhere that says to do something with that disk. I looked at >>> /etc/mtab and /proc/partitions and there are no references to sdb. >>> Is there somewhere else I should look? Might I screwed up my >>> autoinstall script - I don't think so. Is there an easy way to just >>> edit my autoinstallscript.conf file to change sdb to sdc - this uses >>> LVM and things are a little more complicated. Clearly this is a >>> non-standard situation and it's probably not critical I solve it as >>> I can just swap some drives when I get into the office on monday, >>> but it would be nice to be able to confirm I can to an end-to-end >>> installation with 3.7.4 on an opteron with scsi disks. >>> >>> As an aside, I tried to get the remote console monitoring stuff >>> working and it didn't work. Since there's no documentation on any >>> of this I couldn't verify I was doing it correctly. 8-( I also >>> discovered the console log in /tmp, but it doesn't contain all the >>> error messages. Is there not an easy way to capture them? I'm also >>> a little puzzled about what gets logged an how since I see the rsycn >>> request, the run_post_install, but nothing from systemconfigurator - >>> specifically the error messages. >>> >>> -mark >>> >>> >>> >>> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sisuite-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
