Never seen it happen. And I've never seen /boot unmounted after boot, so there's no guarantee it can't happen, even with a separate /boot.
What I HAVE seen is someone get into my machine via a security hole in a server and issue rm -rf *. Having a protected kernel doesn't help if you have no filesystems to boot from. Have a good standalone restore procedure handy. I spoke to one of the Solaris guys here, and while I didn't follow everything he said (my Solaris experience is limited), I did gather that the kernel image is kept at the beginning of the root filesystem. On zLinux, I've found that the "install kernel" can be your friend. Stick a copy on a minidisk somewhere, and if your system won't boot, you can boot the install kernel from the reader, mount the real root, and survey the damage. > -----Original Message----- > From: Dwight Tuinstra [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 21, 2003 9:23 AM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] R/O Linux guest? > > > The main reason for running a separate /boot, AFAIK, is to minimize > the chance of damaging your boot files through a system or human > error. Once the machine is booted, /boot is unmounted. > > --Dwight Tuinstra > > On Fri, 21 Feb 2003, Hall, Ken (ECSS) wrote: > > | Nobody said you had to. Intel-based linux loaders allow > you to select a kernel configuration at boot time, so you can > keep multiple versions available. zipl doesn't let you do > this (yet), so you > | need a kludge to make two kernels available. > | > | My point was just that having a separate /boot doesn't buy > you much. The space saving is minimal. If you're running > two kernel versions they should be just that: Two separate > versions, with > | different image names, and different module directories. > Even if you're testing a new config of the same kernel > version, this can be done with the VERSION and EXTRAVERSION > variables in the kernel > | makefile (as long as you load the IBM OCO modules with > insmod -f, and the timer option matches). > | > | > -----Original Message----- > | > From: Post, Mark K [mailto:[EMAIL PROTECTED]] > | > Sent: Thursday, February 20, 2003 1:03 PM > | > To: [EMAIL PROTECTED] > | > Subject: Re: [LINUX-390] R/O Linux guest? > | > > | > > | > /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 > | > > > | > > > | > > | > > | >
