USS "mounts" the filesystems before the "kernel" actually starts, so everything is available from the beginning. In Linux and most UNIX variants, there's a chicken-egg problem. To boot, you need the kernel image, and some files from /etc, /sbin, and /bin. If /etc is a separate filesystem, there's no place for inittab to be (yet), so you can't determine how to start up. Getting to /lib is another issue. It's perfectly possible in the Intel world to have your disk drivers as modules, so how do you read your disk if the device drivers are on it?
The usual solution is to create a "temporary" root filesystem, usually on a ramdisk, to get things going (using the BIOS disk access drivers), load required modules from that, then mount the "real" root filesystem over it at the appropriate time. The kernel lives in two places: /boot for the image, and /lib/modules for loadable modules. /boot can be separate, since that's where you actually BOOT from. During the initial startup, the kernel mounts the root fs (defined in zipl.conf) read only. Once that happens, /etc/inittab is read, /sbin/init kicks off (there's another directory that has to be in root), and everything else follows. The rc scripts actually do the module loading, and at some point the root fs is remounted rw. You can get some sense of this from following the startup messages. In VERY OLD versions of UNIX, the kernel image lived in /, along with /bin, /etc, and /lib. That was your basic startup set. (/sbin came later.) I didn't start seeing a separate /boot directory till Intel versions (Xenix, ix386, and SCO), although I think Solaris also has a separate /boot. That seemed to be mainly because older BIOS versions couldn't boot from a partition bigger than 1024 cylinders. As the disks got bigger, this became more of a problem. I'm on the fence about this whole issue. I've done it both ways, and I don't see what having a separate /boot buys you as long as you can boot the root fs. I like the IDEA of sharing the root fs between systems R/O, but I haven't seen a method that doesn't require a lot of effort and surgery on the startup process, and the risk of getting component versions seriously mixed up. What WOULD help is for someone to fix zipl so you can select the kernel you want via LOADPARM. > -----Original Message----- > From: Chet Norris [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 20, 2003 3:09 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] R/O Linux guest? > > > Mybe were talking RedHats to SuSe's or something. > I don't understand why /boot (the target of zipl) can be separated > from the load point (/) file structure and /etc can't be. USS > seemed to > make some sense in that the things that made the image unique could be > split away from the base code. ie. /etc, /var, /dev (and /tmp) > A kernel upgrade would modify /lib, /dev and /boot. To > roll out the > new kernel without applying it individually in each image I would have > to copy a new "/" file structure and a new /boot file structure and > then copy my original /etc back in over top of it. Right? > > --- "Post, Mark K" <[EMAIL PROTECTED]> wrote: > > /lib is, and must be, part of the root file system (unless you're > > willing to > > play the games that I am not). I'm not going to replace my entire > > root file > > system just to upgrade a kernel. So, no problem. > > > > Mark Post > > > > -----Original Message----- > > From: Hall, Ken (ECSS) [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, February 20, 2003 12:58 PM > > To: [EMAIL PROTECTED] > > Subject: Re: R/O Linux guest? > > > > > > What about /lib (and particularly /lib/modules)? You can't just > > switch > > kernels without having the corresponding modules available. > > > > Not to mention /var, and all of the RPM database stuff. > > > > Splitting off /boot seems to be mainly a relic from the days when > > Linux > > wouldn't boot if the root filesystem was bigger than 500mb. (or > > whatever) on > > Intel boxen. I haven't seen a good reason to do it > > for a long time. If it's too big, it's a waste of space, > and if it's > > too > > small, you can't keep the multiple kernels you want there. > > > > > -----Original Message----- > > > From: Post, Mark K [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, February 20, 2003 12:13 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [LINUX-390] R/O Linux guest? > > > > > > > > > Having /boot separate allows you to decide which volume you > > > want to IPL > > > from. It also allows you to have multiple IPL volumes > > > available. I also > > > have a /boot1, /boot2.4, etc. /root is root's home directory > > > and it forces > > > me to be careful with how much junk I put there. If it were > > > part of /, then > > > I could conceivably fill it up by being careless. > > > > > > In my particular case, /usr, /opt, are shared read-only with > > > other systems. > > > > > > I'm not sure what you mean by a kernel upgrade forcing me to > > replace > > > multiple minidisks. Most of the stuff that would need to be > > > upgraded along > > > with the kernel typically lives in /usr. > > > > > > Mark Post > > > > > > -----Original Message----- > > > From: Chet Norris [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, February 20, 2003 7:24 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: R/O Linux guest? > > > > > > > > > Per the below (03/12/02) response, what devices are Read-Only and > > > shared? It seems to me that only /usr and /usr/src could be. Then > > why > > > separate /root and /boot? I know you had a good reason, and I'm in > > the > > > process of re-mapping my file structures. Also, doesn't a kernel > > > upgrade force you to roll out multiple minidisk replacements? > > > Too bad we can't map it the same as USS with a separate /etc > > > per image. > > > > > > From Archives Date: Tue, 12 Mar 2002 18:38:59 -0800 > > > Mark Post wrote: > > > >/boot, /var and /tmp do _not_ have to be on the root file system. > > > >Mine aren't. Unless you play some games, /bin, /dev, /etc, /lib, > > > >and /sbin have to be part of the root file system. Anything else > > > >can be easily put on a different one. > > > >~ > df > > > >Filesystem 1k-blocks Used Available Use% > Mounted on > > > >/dev/dasdb1 52284 35868 13720 72% / > > > >/dev/dasdc1 1062992 388560 620436 39% /tmp > > > >/dev/dasdd1 1417324 1337424 7904 99% /usr > > > >/dev/dasde1 111572 50520 55296 48% /var > > > >/dev/dasdf1 104596 73036 26164 74% /opt > > > >/dev/dasdg1 10432 1756 8140 18% /boot > > > >/dev/dasdh1 52284 4936 44652 10% /root > > > >/dev/dasdi1 24384 12912 10216 56% /home > > > >/dev/dasdj1 921228 773876 100556 89% /usr/src > > > > > > Mark Post > > > > > > > > > > > > ===== > > > Chet Norris > > > Marriott International,Inc. > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > > http://mailplus.yahoo.com > > > > > > ===== > Chet Norris > Marriott International,Inc. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com >
