On 05/14/2015 09:19 PM, Carlos E. R. wrote:
My point on this paragraph is that booting the previous kernel solves nothing, because the partition is full.
I don't want to sound like a cracked record but .... The concept of fixed provisioning with fdisk or similar at system initialization (aka install) time dates from the first half of the last century and was one of my major griped about successive generations of UNIX of all flavours. It was like that with V6 back in the late 1970s, progressed though with UNIX/86 from SCO and onwards. I was delighted when I met the Veritas manager on AIX, And even more delighted when that was re-implemented as LVM under Linux. While it is possible to put the /boot partition on LVM its not worth the hassle when things go wrong. However calculation for provisioning of /boot is pretty simple. You just figure that you are going to have at max N kernels and initrds. But the root partition is another matter. It can quite legitimately grow. Life was easier when /usr could be another partition but that time is past. However there is no reason you can't put /usr/share on a separate parition, along with other "root-ish" things like /opt, /local, /var, /srv and of course /tmp. There are good reasons to have some of them such as /tmp mounted "noexec,nodev". Others might be mounted "nosuid". It all helps reduce the security exposure, and that goes for the 'fat finger -- oops!' type of security gaff as well. Having file systems under LVM defers the issue of deciding how much space to allocate. All modern file systems can increase in size after the LVM logical volume (aka partition) has been increased. Some file systems can be shrunk as well if you over estimated. That's one reason I like ResiserFS. Not only can it increase and decrease in size, it can do so while mounted and in use on a running system! No need to drop down into rescue mode or single user mode and unmount everything! And yes I've met the case where my root file system has filled up and I needed to grow it. As it happened, this occurred with a BtrFS RootFS. BtrFS can grow. I don't believe it can shrink. Yes I had to go into rescue mode to do this, which is another strike against BtrFS and in favour of ReiserFS. In all my time ui=sing LVM I've only had 3 problems 1. Head crash, total disk loss 2. /boot on a LV but lost the MBR linkage .. Somehow... 3. Introduction of lvmetad daemon & 'switch' with no prior warning. Now I realise this is of no use to people who aren't using LVM and have fixed provisioning problems like the OP. But the real issue here is about planning and foresight. There has been a trend over the last decades to what might be termed "deferred design". Some of it is in the form of the separation of the presentation layer from the operational logic, which we've seen in web site design, though to be fair all to many commercial sites have not taken advantage of this. Many modern languages are about deferred design. Ruby is perhaps an extreme case of that with "Duck Typing", though it has a good historic precedent in the Bourne shell of old UNIX and even LISP. LVM is about deferring the final decision -- even revising the decision -- about file system space provisioning. And that goes for the ROOT partition as well. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org