On 2018-07-01 at 18:43, David Wright wrote: > On Sun 01 Jul 2018 at 13:17:47 (-0700), Charlie Gibbs wrote: > >> I've been banging my head against the wall trying to compile >> OpenSSL clients on my Jessie laptop (see my recent posting titled >> "Can't link to OpenSSL on my laptop). I've decided to upgrade it >> to Stretch like my desktop machine, which compiles these programs >> successfully. However, "sudo apt-get dist-upgrade" shows the >> message: >> >> E: You don't have enough free space in /var/cache/apt/archives/. >> >> apt-get autoclean doesn't help; neither does apt-get clean. When >> I tried apt-get autoremove, the upgrade started, but at 99% >> completion it threw the message: >> >> Error writing to output file - write (28: No space left on device) >> >> Sure enough, / is full, with all the fun that that entails. > > It's worth knowing where the problem lies. I would type > > du -sh /[a-ln-z]*/ 2>/dev/null > > (I dodge m because /media has loads mounted under it; null avoids > permissions clutter if you do this as a user.) Is there a reason you don't add '-x' to that, to skip recursing into other filesystems? (Which would also avoid the need to omit /media.) >> Is Jessie's default partitioning insufficient for Stretch, or have >> I somehow filled up / with extraneous junk? Would I be better off >> backing up /home, wiping the disk (e.g. with cfdisk) and starting >> from scratch? (Probably - I should probably split /var into a >> separate partition anyway.) > > A separate /home is more useful as it allows a fresh installation of > the / partition that doesn't touch it. I generally do one partition each for /, /boot, /tmp, /home, and /var - and formerly also /usr, but I understand that that's not supported anymore. I sometimes also do one for /opt, depending on what I expect to do with the system. I've only filled up / once, on one system, so far as I recall - and it was in fact due to /var/cache/apt/archives. >> After this experience, I'm gun-shy about upgrading a system in >> place. > > Why? If you find the cause, you can fix it. Upgrades are careful > about preserving the system's integrity to run. Yep. I tend to dist-upgrade (against testing) about once a week, except when there's just been a release (and testing has come out of freeze), at which point I do it about once a day or so. I've rarely had problems, and when I have, it's generally been due to newly-introduced package bugs - which should all have been ironed out by the time a stable release is made, so you aren't likely to encounter any when dist-upgrading from one stable release to another. Even when a change resulting in (a behavior which you might see as being) a problem was retained for - or not noticed until after - the stable release, by the time you're dist-upgrading this late in the cycle, there will generally be things on the Web documenting the problem and one or more ways to address it. (Note that that's only for dist-upgrading against testing or stable! A dist-upgrade against sid is not something to run on a production machine, pretty much *ever*.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature