[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New 64bit Installation. Root partition too small--what to do?



> It's actually /lib/modules that takes up the space, and of course this
> has to be under / for booting. I have a server in this position, which
> had an adequately-sized / and separate /usr and /var when installed.
> 350MB used to be more than enough for a / which didn't contain /home, 
> /usr or /var. I don't normally keep more than one previous kernel
> around, but there have been occasions where I have wanted to. I
> understand now that a separate /usr is a no-no, unless I want to add
> even more complication to grub2 (see below), so sizing / won't be an
> issue in future. 

Might be interesting if there were a utility/script to remove from 
/lib/modules everything not used on the current system. Only a tiny minority 
of the modules are actually needed. There was once a time when space was at a 
premium and economy was a valued programming virtue. (One can always re-
install the whole linux-image if changing the system.)
> 
> > > 
> > > 
> > >
> > > My system drives are partitioned as follows.  I don't need to save
> > > core dumps in swap, so it is smaller than RAM.  I tried running
> > >
> > > without swap, but my machines crashed under heavy RAM loads:
> > > 
> > >         primary #1 - 0.5 GB bootable ext4 /boot
> > >         primary #2 - 0.5 GB random encrypted swap
> > >         primary #3 - 8.0 GB encrypted ext4 /
> > > 
> > > 
> > >
> > > My bulk data fits on one encrypted ext4 drive, which is in one
> > > machine and is shared via Samba. 
> > > * * * * *
> > This is very good and sound advice, actually. Problem is, I tried
> > selecting manual partitioning on the install and saw no interface to
> > actually do it. (If I set up partitions beforehand, will the
> > installation simply respect them?)
> 
> Yes, either way will work, you need to get the hang of the drive
> allocation part of the installer, which isn't quite intuitive enough.
> Basically, it shows you the existing partitions and you have the option
> to allocate mount points, delete them, make new ones etc. If you're
> familiar with (*)fdisk or parted, make the partitions with it and then
> allocate the mount points in the installer.
OK, the UI of the installer is problematic. I knew what I wanted to do but 
could not find a way to do it. If it will respect fdisk or parted partitions, 
well ... the next time.
> 
> > 
> >
> > Question: How do I tell grub about new /, new /boot, etc.?? Seems to
> > be mostly automatic with little documentation. Or do I go back to
> > lilo which I at least know how to configure :-)?

> If you're mucking about with an existing system and need to update the
> existing grub installation, it's a bit harder. I find that quite
> unpleasant, I don't get on at all well with grub2. It used to be
> trivial with the mature LiLo, before the days of initrd, udev etc.
Might see about a return to lilo if it is still on the repos.

The issue of a separate /usr or not was raised in posts here. Conventional 
wisdom was always that it is better and the installer does that.

My older 1-terra drive has bad blocks. I can partition around them and use it 
but one a disk has begun to ... well, maybe best to junk it. I have an older 
80g IDE will just keeps going and going. / can go there is I cannot achieve 
any other alternative.


Reply to: