| 1 |
On Thursday, 25 February 2021 15:42:38 GMT Grant Taylor wrote: |
| 2 |
> On 2/25/21 2:51 AM, Michael wrote: |
| 3 |
|
| 4 |
> > A reinstall in this context is not a wholesale replace. |
| 5 |
> |
| 6 |
> ~blink~ |
| 7 |
> |
| 8 |
> > It implies obtaining the latest Stage 3 archive from a mirror, |
| 9 |
> > but retaining part of your current installation. Your /home, /etc, |
| 10 |
> > /var/lib/portage/world, plus any databases e.g. in /var/lib/mysql/ |
| 11 |
> > and your kernel config will be retained from your existing system and |
| 12 |
> > will not be replaced. Back these up first along with any particular |
| 13 |
> > customizations you have made, before you untar Stage 3, so you can |
| 14 |
> > restore them. |
| 15 |
> |
| 16 |
> Ah. You seem to be talking about what I would call an "in place |
| 17 |
> upgrade" for Windows. As in stalling n over top of n-1 or n-2. That's |
| 18 |
> definitely less disruptive than I was thinking. I was thinking that |
| 19 |
> fdisk and / or mkfs would be involved. |
| 20 |
|
| 21 |
Yes, it is an "in place upgrade", but bottom up. You upgrade the filesystem |
| 22 |
to the latest OS image, then drop in your own existing settings/configuration |
| 23 |
and finally run a system/kernel update. |
| 24 |
|
| 25 |
Unless you want to change your partitions you won't need to use fdisk. |
| 26 |
|
| 27 |
mkfs is advisable, it will clear out any old cruft and address any changes to |
| 28 |
the default system directories - e.g. where $PORTDIR, $DISTDIR may be in the |
| 29 |
latest Stage 3. |
| 30 |
|
| 31 |
A quick diff between your backup of make.conf and repos.conf against the new |
| 32 |
Stage 3 archive contents will inform you of changes to default settings. |
| 33 |
|
| 34 |
|
| 35 |
> > Then rsync portage, update all your @world packages and build a new |
| 36 |
> > kernel (make oldconfig). Spend some time merging existing application |
| 37 |
> > config files with etc-update to make them compatible with the latest |
| 38 |
> > versions of these packages, reboot and hopefully that should be all |
| 39 |
> > there is to it. |
| 40 |
> |
| 41 |
> I may end up /needing/ to go that route. For the moment, I'm going to |
| 42 |
> try the incremental updates. |
| 43 |
> |
| 44 |
> > Yes, it would have been, but what is the benefit of updating multiple |
| 45 |
> > packages many times over, instead of doing it just once? |
| 46 |
> |
| 47 |
> In some ways, this is a learning experience. As in it's a proof of concept. |
| 48 |
|
| 49 |
Yes, nowt wrong with that and a sound reason to try it out. In this case, |
| 50 |
time spent and any problem solving would be an investment in learning. |
| 51 |
|
| 52 |
|
| 53 |
> The computer in question spends 2/3 of it's life doing nothing but |
| 54 |
> idling a few programs. So, it spending time compiling and producing |
| 55 |
> heat is not a bad thing in this case. Especially when there's 10" of |
| 56 |
> snow on the ground. ;-) |
| 57 |
|
| 58 |
Neil highlighted the use case of a server/system which can't afford |
| 59 |
interruptions. I'd still reinstall as explained above, but do it offline, |
| 60 |
test, backup, and then untar over the live filesystem to keep downtime to a |
| 61 |
minimum. |
Archives