[sf-lug] boot is full
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Sun Jun 29 03:40:49 PDT 2014
So, regarding boot is full:
http://linuxmafia.com/pipermail/sf-lug/2014q2/010471.html
et. seq.
Did you ever get that resolved?
And yes, ~88M is relatively small for boot. Especially also since it's
typically relatively difficult to make /boot larger.
I typically do around 200 to 256 MiB for /boot:
$ df -k /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 233191 23142 197608 11% /boot
$ 2>>/dev/null sudo sfdisk -uS -l /dev/sda | fgrep -e Start -e 'sda1 '
Device Boot Start End #sectors Id System
/dev/sda1 * 2048 499711 497664 83 Linux
$ echo '497664/2/1024' | bc -l
243.00000000000000000000
$
So - I have 243 MiB for my /boot partition
But what's eating most all your space in /boot anyway? 88 MiB isn't
huge, but it may be enough to squeak by okay for you. I'm only using
something closer to 23 MiB.
What do these show you?
# du -x /boot | sort -bnr
(and probably don't post this next one directly to list, likely a bit
long):
# find /boot -xdev -exec ls -sd \{\} \; | sort -bnr
The first of those two commands gives you, for everything
in and beneath /boot on that same filesystem, total recursive space used
for each directory, and then sorted numerically, largest first. The
second command is somewhat similar, except it shows the individual size
(physical storage blocks) of everything. Probably doesn't apply in this
scenario, but good to look at both df and du, and see if their numbers
are reasonably consistent for the filesystem - if not you may have
something significantly more unusual going on (e.g. unlinked open files,
overmounts, filesystem corruption). E.g.:
# du -xs /boot && df -k /boot
23142 /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 233191 23142 197608 11% /boot
Note that in the above our used block counts precisely match - which is
what we'd typically expect and hope for on a /boot filesystem.
... /lost+found was mentioned, if there are contents of that directory
that you're sure you don't need, you can remove the contents - but best
not to remove /lost+found itself. /lost+found is used for recovery by,
e.g. fsck. If one needs to recover, e.g. with fsck, and the /lost+found
directory isn't present at the root of the filesystem (at least for many
types, such as ext[234]), fsck may not be able to recover files for you.
Also, when the filesystem is created (again for filesystems that use
/lost+found for recovery), the /lost+found directory is also created of
suitable size to be able to recover a fairly large number of files. So
if one were to get rid of that directory, and recreate it with mkdir, it
wouldn't be as large, and one could potentially end up not being able to
recover all the files that might need recovery.
From your earlier listing:
drwx------ 2 root root 12288 Feb 27 14:00 lost+found
That's why it's sized that "large" - not all that huge, but generally
ample for more common recovery scenarios. Let's see, for my /boot, we
have:
$ ls -dls /boot/lost+found
12 drwxr-xr-x 2 root root 12288 Dec 18 2011 /boot/lost+found
So your /lost+found (at least as of time of that listing) is likely
precisely the correct size it should be.
[hmmmm, WTF caused my lost+found to be world readable/"executable" on my
/boot filesystem? ... that shouldn't be the case! - one to correct and
note for the logs - and the mtime (and ctime) correlate to when I did
fresh install from CD ... which I know, because that's noted in my log]
Encryption :-) ... that's a good reason to have a separate /boot,
gives the reasonable compromise between being able to boot directly from
the drive, while allowing everything else on the drive, except for /boot
itself (and wee bit of MBR and partition data) to be fully and quite
securely encrypted. But I gather from what I read that ZaReason set
that up for you? Did they encrypt swap?
I noticed from your earlier:
christian at laptop:/boot$ df -h > /home/christian/Desktop/list2.txt
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sda3_crypt 212G 104G 98G 52% /
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 791M 884K 790M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 224K 3.9G 1% /run/shm
/dev/sda1 88M 79M 2.3M 98% /boot
/home/christian/.Private 212G 104G 98G 52% /home/christian
That presumably (guessing by name), that sda3 is encrypted, we see sda1
is /boot, so I'm guessing sda2 is swap. If one is going to encrypt
everything on the drive - or everything except /boot, then it's
generally best to also encrypt swap ... though there may be some
tradeoffs there if one uses or wants to use hibernate / suspend to disk.
If, as I'm guessing, sda2 is swap, and sda1 is at start of drive, with
sda2 swap right after it, easiest way to grow sda1 a bit may simply be
to shrink swap a bit. Swap is most likely comparatively large, and can
be reduced a bit in size easily enough. Note however that reducing size
of (presumed) swap partition sda2 may have implications for hibernate /
suspend to disk. Other than that, not a big deal, as one can add
additional swap even from a regular file on filesystem, so one could add
swap there - but if that's added from, e.g. your encrypted root (/)
filesystem, that part of swap couldn't be used for hibernate / suspend
to disk (I'm guestimating a bit on the hibernate / suspend to disk - I
really haven't mucked about with it on Linux ... yet).
So, if my guesses are right, procedure would go about like this:
deactivate swap (swapoff)
delete sda2 swap partition
grow sda1 /boot partition (I'd recommend up to 200 to 256 MiB total size)
grow /boot filesystem
create new sda2 swap partition (will be slightly smaller than before)
initialize sda2 as swap (mkswap)
reactivate swap (swapon)
If you still need/want sda2 as swap and as large as it was before, then
(again presuming I'm guessing correctly on your layout) it gets more
complex, as - again if I'm guessing right - you've got sda3 right after
that, and it's encrypted. It's easier to change the boundary of the end
of a partition, harder to change the start of a partition - particularly
if it contains data such as filesystem - and we can apply that doubly so
for encrypted data. If that's the case, and also guessing/presuming
that sda3 uses space out to the end of the drive, we'd need to boot from
recovery media (e.g. Ubuntu DVD). There do exist tools for moving and
shrinking filesystems and partitions. Not sure if there are tools for
doing that a bit lower-level with relatively arbitrary (e.g. encrypted)
data. Anyway, procedure on that would go approximately as follows,
after booted from recovery media:
activate the encrypted partition
shrink the filesystem on the encrypted partition
not 100% sure of order of next 2 steps, or if the first step is needed:
reconfigure the encryption to be suitably reduced in size (if needed)
deactivate the encrypted partition
shuffle data - if there's tool that will move the data, from start of
partition, to end of the encrypted filesystem after shrinking, and
shuffle those blocks to realign so they'll start where you want to
change the partition start to, then you could use such a tool.
Alternative approach would be to copy all that data to something else
(probably not a bad idea in any case, as an error could lose all that
data).
change partition - redo the sda3 partition to where the encrypted data
has been shrunk and relocated.
That's it. ;-) Yeah, not as easy as it sounds - if it even sounds easy
at all.
This is also one of many reasons, especially also as drives get quite
large - and even more so hard drives, why I don't create some single
giant partition for most or all of the data. Of course for systems with
>> 4 drives, I'd probably alter that somewhere between the 2nd and 5th
drive, but for at least the first one (e.g. typical laptop or desktop),
at least for my own stuff, I do something quite like this, e.g. my
personal laptop:
$ 2>>/dev/null sudo sfdisk -uS -l /dev/sda
Disk /dev/sda: 19457 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/sda1 * 2048 499711 497664 83 Linux
/dev/sda2 501758 312565759 312064002 5 Extended
/dev/sda3 0 - 0 0 Empty
/dev/sda4 0 - 0 0 Empty
/dev/sda5 501760 39507967 39006208 83 Linux
/dev/sda6 39510016 78516223 39006208 83 Linux
/dev/sda7 78518272 117524479 39006208 83 Linux
/dev/sda8 117526528 156532735 39006208 83 Linux
/dev/sda9 156534784 195540991 39006208 83 Linux
/dev/sda10 195543040 234549247 39006208 83 Linux
/dev/sda11 234551296 273557503 39006208 83 Linux
/dev/sda12 273559552 312565759 39006208 83 Linux
$ sudo blkid /dev/sda[13-9] /dev/sda1[0-9]
/dev/sda1: LABEL="boot" UUID="75422ae5-1f6d-4e9f-81c5-81a696cef155"
TYPE="ext2"
/dev/sda5: UUID="bf4825d7-79ff-4943-8dbc-95f68b842233" TYPE="crypto_LUKS"
/dev/sda6: UUID="2e9d3b36-2060-45e0-951f-5601e3ef611f" TYPE="crypto_LUKS"
/dev/sda7: UUID="aa3c4c3d-a2ee-4907-a332-c4b2b4c442fe" TYPE="crypto_LUKS"
/dev/sda8: UUID="5df0783f-b2a2-4f10-8a78-54b38871693e" TYPE="crypto_LUKS"
/dev/sda9: UUID="114dec40-ceb9-47d9-90da-f4d33b3a711c" TYPE="crypto_LUKS"
/dev/sda10: UUID="8cef158d-133c-4da2-b9c6-33f1751e7946" TYPE="crypto_LUKS"
/dev/sda11: UUID="9c720fa5-fdb3-44fa-9d24-d23a919b5077" TYPE="crypto_LUKS"
/dev/sda12: UUID="fdcf1d48-a0d8-4a03-942b-18b2d3a2b50a" TYPE="crypto_LUKS"
So, I've got a partition for /boot, and after that, the remaining space
is carved up nice and evenly into 8 equal sized partitions (I'd
recommend somewhere between 4 and 8). So, let's say, for sake of
argument, some day, my /boot is no longer large enough - like I've got
some "must have" kernel or whatever, that just takes up quite a bit more
space in /boot. Or maybe I want to install some other totally different
operating system on it's own partition. Well, on top of the encryption,
I've got LVM, so I can migrate stuff live. So long as I've got
sufficient free space, I can migrate data off of, e.g. sda5, deactivate
or remove the encryption stuff from there, change the partitioning as
appropriate, leaving the existing sda6 through sda12 as they are, and
continue from there with whatever I needed or wanted to do. No major
disruptions. Not the simplest of setups, but it dang well does for me
what I want it to do, and leaves me the flexibility I desire.
Similarly, I don't do swap as one big chunk, e.g.:
$ swapon -s
Filename Type Size Used
Priority
/dev/mapper/tigger-swap1 partition 1048572 74028 -1
/dev/mapper/tigger-swap2 partition 1048572 0 -2
/dev/mapper/tigger-swap3 partition 1048572 0 -3
/dev/mapper/tigger-swap4 partition 1048572 0 -4
/dev/mapper/tigger-swap5 partition 1048572 0 -5
/dev/mapper/tigger-swap6 partition 1048572 0 -6
/dev/mapper/tigger-swap7 partition 1048572 0 -7
/dev/mapper/tigger-swap8 partition 1048572 0 -8
That makes it relatively easy to add/drop/move swap if/when I wish to do
so (note that that may not be compatible with hibernate / suspend to
disk).
Other random bits ... :-) ...
unmount /boot, remount it temporarily elsewhere, and copy all that to
/boot? No, that won't work for an encrypted root (/) ... unless you
want to boot off of some other device. /boot cannot be encrypted.
and quite excellent advice from Rick Moen:
"One of the bits of advice I give to new Linux users, which some even
listen to, is to keep track of major admin decisions you make in
building and administering your box, e.g., in a composition book or on a
legal pad that you devote to that purpose. Partitioning would be one of
the things worth taking notes about."
As for myself and most of the systems I deal with, I've evolved that
process a fair bit, but it's still quite excellent advice for new users.
I even remember once-upon-a-time, some Unix Vendors would ship with
their systems, a hardcopy binder log book for one to use, trying to
encourage such a practice. For my own first personal computer(s) I also
quite did that. Though such hardcopy has advantages (e.g. don't need
another computer to read it), it also has some disadvantages, notably
harder to search and replicate/copy. So, I go with simple format text
file, and it gets quite regularly backed up - including off-site backups.
That way, if, e.g. building catches fire and computer destroyed, there's
still off-site copy of that log data. And the soft-copy is much more
easily searched than hardcopy. Alas, the first hundred or so pages of
my system log is hardcopy ... not convenient to search or copy.
And some of the systems I deal with (even including sf-lug) even have
most of that particular log data publicly available - for the curious or
whatever, e.g.:
http://www.sf-lug.org/log.txt
http://www.archive.balug.org/log.txt
And in case you think all the lines in there about
purging/removing/adding/upgrading packages are difficult to maintain
and put in there, no, not at all - I've a script which post-processes
the output of such operations from apt-get or aptitude, turning such
into a more concise and more easily human readable form. It also comes
in dang handy when, "Gee, this isn't working ... but it *was* working
back around such-and-such time. Hmmm, what got changed since around
then?". Having that level of log detail often makes determining what
change caused the issue *much* easier.
By default, Debian now also has /var/log/dpkg.log files, which can also
be quite useful for that type of package change information.
More information about the sf-lug
mailing list