Re: Corel/Debian Linux Installer
goswin.brederlow@student.uni-tuebingen.de wrote:
> > / -- small, 32-64MB, mounted readonly, 0% reserve
> I have 24 MB used on my Alpha with an usual amount of software
> installed. Maybe 32 MB is a bit short, but normaly its enough. 64Mb is
I think I've always used 32MB, and have run into problems a couple times.
The reason I do though, is because I compile my own kernel, and do so a
lot. /boot and /lib is in / on my system, and I've run out of space
because of that. I also have /tmp in /, and don't know if 32 is enough.
I seem to use very little /tmp space; it seemed like 64MB for / including
/tmp would suffice.
> /etc CAN'T be a seperate partition. /etc/fstab would not be available
> to mount /etc.
Yes and no. You can have /etc/fstab in / that tells you how to mount
/etc, but there would be some interesting side effects with other
filesystems that may need working on. My concerns were more about
/etc/mtab~ and then with some files in /dev that syslog creates. I know
Solaris changes the permissions of /dev/console and /dev/audio based on
the user who logs in, so /dev would have to be its own fs, unless devfs
was used. / just seems to be a tricky filesystem in general. I don't
think it's worth the effort to try to make it readonly if it is kept
small.
As an aside - yesterday I tried booting Solaris 7 without the /usr
partition and it did not work _at_all_. /usr/sbin couldn't be found and
essentially nothing worked. Solaris has some good stuff, but it obviously
also has a lot of flaws remaining. Now I have to reinstall the OS in
order to restore the /usr partition. P-I-T-A. If I had a working /, I
wouldn't have to go through this mess, would I?
> > /usr -- dependent on packages selected, readonly, 2% reserve
> > /var -- dependent on packages selected, read-write, 5% reserve
> 32 MB for var are normaly fine. squid, mail, printing needs more.
I use 64MB for /var. On machines that I apt-get daily, this is fine. On
my home machine (behind a 16k (if I'm lucky) modem), this is overkill.
As another aside - apt-get aborts if there is not enough free space in
/var. I can symlink around this, but it would be good if it were
possible, for apt-get to upgrade subsystems in chunks. That is to say, if
the space required is too small, update all the dependent packages first,
then update the packages that depend on those -- or something similar
along those lines -- rather than just abort.
For "special" installations, such as a mail or news or cache proxy server,
no default will ever suffice. Those are essentially lost causes.
However, as I mentioned before, if the .deb could give "hints" about
"additional" space, some semblance of future use could be given. This
certainly does not eliminate any problems - experts may still be needed -
but if nothing else, dpkg could popup a notice from the package maintainer
(*before* installation - *before* partitioning) saying something like,
"squid's cache can grow very large. If you are using squid for a small
network or larger, it may be a good idea to create a RAID partition for
/var/squid", or whatever. Rather than just assume that only an expert is
going to install such-and-such pacakge, give some warnings.
Now, these warnings could be especially annoying, so it might be good if
an "installation class" is selected, that certain messages be supressed.
For instance, if someone told the installer that this is going to be an
enduser workstation, and they install sendmail, it could suppress the
message about creating a large mail spool.
These are just ideas, of course. I believe that the installation could be
made easier, both for experts and for end users. The goal, I suppose, is
to make it easy for the newbie, but there's no reason not to make it easy
for the expert as well. A lot of people may want to install Debian for
its stability, and may have a lot of Unix/Linux experience, but not be an
expert in every aspect of the system. Maybe they decide they want a
Debian news server, but have never installed news before. They may have
never installed Debian before either, and not realize that Debian puts a
lot of stuff in /var. I think Debian is the only dist that has a
/var/www. All the others I think use /usr/share. Whether I'm correct in
this or not is immaterial - the fact is that Debian tends to be very
different from RedHat, SuSe, Slackware, etc. And there really is no easy
transition. Debian does do a lot of stuff The Right Way, but people, even
experts, aren't accustomed to this. I think that there's just a little
too much "ex post facto" learning. You essentially have to install Debian
a couple times to figure out how it works before you finish a successful
installation.
I don't know, but it just seems that it could be easier. And preselecting
packages is a good first step. I think it would also make it the first
dist to do it that way (even though Solaris already does it like that -
and people rave about the Solaris install, both personally that I know and
experience, and that I've read in the press). It seems obvious to me that
this is The Right Thing, technical issues aside (the Solaris install, for
instance, does not work if you have less than 32MB RAM). If the technical
stuff is insurmountable, that's all well and fine. But I think I have a
hard time believing it. If the consensus is that this is a bad idea, feel
free not to do it - but I think that it would be a bad decision
personally.
> /tmp is pretty important and most people forget to create a partition
> for it.
I don't like /tmp as its own partition. If you make it too big, it's a
waste of space (like all other partitioning schemes). If it's too small,
you're really screwed. I have a 32MB / partition, including /tmp, and
have had very, very few problems. /tmp is not used a lot for large files
in my experience. But when the issue arises, it is easier (and less
painful) to make /tmp a symlink into /var/tmp (which is typically larger
than /) than to orphan a too-small partition. I just don't see the
advantage of /tmp as its own partition, excepting the case that a
swapfs/tempfs exists - where /tmp is essentially a ramdisk that grows as
large as swap and autocleans after boot (it's all in ram anyway). Solaris
does this, and it is a good thing, except that it seems to me that if you
fill /tmp, you also fill swap, which is not good. I would like to see
Linux support this with a maximal size, or percentage, or reserve, or
something of that nature to ensure that filling /tmp doesn't bring down
the system.
However, since I brought it up, maybe creating a ramdisk for /tmp is not a
bad idea.
> /var/squid, /var/spool should be partitions too, /var/cache as well
> and so on indefinitly.
>
> The perfect partition scheme must be fit to the specific situation and
> useage. Maybe a tool to resize ext2 partitions would be a good
> solution to the problem.
I agree - nothing is going to be perfect. And Debian already packages the
ext2 resize tool. This is more a hack than a solution though. No
solution is perfect, but I think that a less than ideal starting point is
better than a hidden starting point.
> Nobody I know has / readonly or /usr readonly. Running potato and its
At home I have /usr mounted readonly. I tried mount / readonly but that
was a huge mistake. It is good to do this when you are developing device
drivers. It is also good from me because I installed some tool to tune
the system (PCI bus?) that simply rebooted my computer when it ran from
/etc/init.d. That sucked. turn on, reboot, fsck, reboot, repeat
> > And on another aside, I think that /usr/share/doc is a good idea; this
> > isn't binary data and can safely be exported/remote mounted.
>
> So can a lot of other stuff as well and /usr/doc is good for
> historical reasons.
Yeah - I don't know the history behind the decision - but /usr/share seems
to be a reaonalbe place, assuming that /usr/share is exported/mounted.
/usr/doc could easily be a symlink, so it seems like there are easy
workarounds, but I'm not dedicated either layout.
And since I'm writing, one more idea that I had a long time ago - binary
installation. I haven't thought this out too much, but I used to work in
a distributed environment where /usr/local was shared, and started to be
shared across multiple architectures (32bit & 64bit SPARC). This worked
mostly fine, as long as I compiled stuff for 32bit Solaris 2.3, the oldest
version. Compatibility started to become a problem as time progressed,
though, and it seems to make more sense to me to install things in
/export/arch/os/partition, then symlink /partition into /export/arch/os as
needed. This would make exporting things easier, but at the same time not
interfere with normal operation. It also makes life _very_ easy with the
automounter. That may be too unusual a circumstance to even try to deal
with though, so I just wanted to throw that out in case anyone else may
use it.
> > And then configure while installing in the background, like OpenLinux.
> > That is very slick.
>
> We are working on that. :)
Cool. =)
All the best,
Christopher
Reply to: