re: non-chroot'd - /etc/mtabMessage: 1 Date: Thu, 20 May 2004 10:09:12 -0600 From: dann frazier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Sisuite-users] Re: found bug in Server.pm Reply-To: [EMAIL PROTECTED]
On Thu, May 20, 2004 at 09:17:29AM -0400, Mark Seger wrote:
Thinking about this some more AND trying to move this forward with a solid recommendation. My original thought had been to patch SystemComfigurator, but what if SC is called outside of the SystemImager context? Architecturally, since SystemImager is the source of the problem SystsemImager should be responsible for fixing it.
Makes sense.
Furthermore, since this problem only exists during the execution of the autoinstall script until the system reboots, ANY code thay may be added to that script that uses 'df', be it SystemImager future enhancements or unsuspecting slobs like me, won't have a clue what's happening.
Therefore I recommend the following:
- BIG comment in autoinstall script that /etc/mtab is empty and commands that depend on it like 'df' will fail.
- add some code that rebuilds /etc/mtab, later on in the script (and I'm not sure where the best place is to do this, but perhaps right after the rsync calls), put in a line of code also with a BIG comments, that tests for a zero length mtab and if found recreates it. As to how to recreate it, since we're only worried about available file systems perhaps "grep ext /proc/mounts> /etc/mtab" wil be sufficient.
Well, ext2 & ext3 are only two of the filesystems we support. It would be better to ignore the filesystems you know aren't necessary, since that is a static list.
What happens if /proc/filesystems uses devfs names, but your chroot uses the standard /dev/ names (like on a redhat system)?
Does it make more sense to copy systemimager's /etc/mtab into the chroot? In
theory, this has been maintained by our calls to mount & umount during the install.
(e.g. - cp /etc/mtab /a/etc/mtab before calling systemconfigurator).
I like it and decided to try it out. I just tried loading a system with an 'exit' in the autoinstall script right before the call to systemconfigurator. alas, /etc/mtab only contains a single entry and the entry is:
/dev/ram0 / ext2 rw 0 0
so I guess that can't be done. on the other hand, what if Server.pm doesn't truncate /etc/mtab? then in the autoinstall script first thing you could copy it to /tmp, truncate it (I'm still not sure what it might break, but perhaps its filesystem creation stuff in the beginning) and then restore it from the copy in /tmp. This also assures the reader of the script knows exactly what's going on.
-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
