[kwlug-disc] Disk longevity ...

[Bob Jonkman]

On 2022-02-16 01:36, Chris Frey wrote:
 > Thanks Bob!
 >
 > My specific interest was how you did the upgrade.  Say for example 
you  had a root LV named /dev/mapper/volumegroup-debian10 and you were 
upgrading to debian11. Would you create a new LV and copy 
volumegroup-debian10 into it as a backup, then upgrade in-place to 
debian11? Or would you install something fresh on a brand new LV?

The second option, install a fresh OS on one of the spare LVs. The 
reason I do this is to start with a clean installation, when I don't 
necessarily trust all the software already installed -- something is 
obsolete, forgotten, no longer needed, didn't uninstall cleanly, or 
something just doesn't work quite right. A fresh OS and newly installed 
applications eliminate problems. With old / obsolete stuff still 
installed you can never be sure that a problem isn't caused by something 
apparently unrelated to the software you're troublshooting.


On 2022-02-16 13:21, Khalid Baheyeldin wrote:
 > That approach will work great for many applications.
 > However it can be problematic for others.

Yes, that's very true, especially for database schema updates.

I don't make these "replacement upgrades" every time, but definitely if 
there are problems, or the upgrade leaps over several OS versions, eg. 
Ubuntu 2012LTS to Ubuntu 2018LTS, or even from one distro to another, 
eg. Ubuntu to Debian.

But if everything has been hunky-dunky since the previous upgrade then 
performing a regular upgrade is much faster and easier.

--Bob.


On 2022-02-16 13:21, Khalid Baheyeldin wrote:
 > Bob,
 >
 > That approach will work great for many applications.
 > However it can be problematic for others.
 >
 > An example is when an application does an upgrade from an old
 > version to the new version that changes the data structure that is
 > stored. For example, MySQL does that frequently between one
 > version to the next. Firefox is another case, where ~ version 93
 > and over are not compatible with the data that is on version 91
 > which is the ESR.
 >
 > So it would be a one way street (from lower version to a higher
 > version) for some applications, and you cannot go back once
 > the newer version has started and messed with the data structure.



On 2022-02-16 01:36, Chris Frey wrote:
> Thanks Bob!
> 
> My specific interest was how you did the upgrade.  Say for example you
> had a root LV named /dev/mapper/volumegroup-debian10 and you were upgrading
> to debian11.
> 
> Would you create a new LV and copy volumegroup-debian10 into it as a backup,
> then upgrade in-place to debian11?   Or would you install something
> fresh on a brand new LV?
> 
> The first I can kinda figure.  The second is a new tactic to me and I
> want to understand it. :-)
> 
> - Chris
> 
> 
> On Wed, Feb 16, 2022 at 01:08:36AM -0500, Bob Jonkman wrote:
>> On current OSes the LVM stuff seems to be installed as part of the base
>> operating system; I can see LVs with lsblk and I can just mount the LVs as
>> either /dev/mapper/volumegroup-lvname or /dev/volumegroup/lvname  For some
>> reason I almost always use the /dev/mapper/volumegroup-lvname syntax...
>>
>> On older versions of Debian or Ubuntu (2012?) it might be necessary to
>> install the lvm2 package. But I've found that the package installation makes
>> sure all the needed OS components are in place, and then the LVs are
>> available with the above syntax. There' no extra effort for the SysAdmin.
>>
>> Older GRUB couldn't boot directly from LVs, but for the last five years or
>> so GRUB recognizes LVM, so I no longer create a separate /boot partition
>> outside the LVs. The only time I create a separate /boot partition now is
>> for encrypted drives.
>>
>> --Bob.
>>
>>
>> On 2022-02-15 19:04, Chris Frey wrote:
>>> On Tue, Feb 15, 2022 at 05:57:49PM -0500, Bob Jonkman wrote:
>>>> When I set up new servers I create a few extra LVs each 15 GB in size for
>>>> "spare" and "backupOS" which I use for a clean install of a new OS, install
>>>> the packages (with dpkg --set-selections), and then point the new fstab to
>>>> the old LVs for /home, /srv, /opt, /var/lib/mysql or /var/lib/postgresql,
>>>> and /usr/local, and copy the necessary config files from the former root
>>>> LV's /etc (yes, salt or ansible would be useful here).
>>>
>>> What do you use to get the new LVs started?  Do you run the usual
>>> installer and just tell it the new LVs to use?
>>>
>>> Thanks,
>>> - Chris