[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upgrading from very-old Debian



2017-11-29 14:45 GMT+08:00 Jan <jan@dwrox.net>:
>
>
> On 28.11.2017 17:58, The Wanderer wrote:
>>
>> On 2017-11-28 at 11:53, Patrick Bartek wrote:
>>
>>> On Tue, 28 Nov 2017 10:28:57 -0500 The Wanderer
>>> <wanderer@fastmail.fm> wrote:
>>>
>>>> I've run across someone who says her machine is running Debian
>>>> oldoldoldstable or maybe even oldoldoldoldstable, and who
>>>> consequently can't upgrade to newer Debian.
>>>>
>>>> I seem to recall that there *is* a way to do step-wise upgrades of
>>>> such old systems, i.e. upgrading from oldoldoldoldstable to
>>>> oldoldoldstable, then to oldoldstable, then to oldstable, then to
>>>> stable. However, I'm stumped as to how to actually get started on
>>>> doing that.
>>>>
>>>> The last few steps of this are straightforward; oldoldstable is
>>>> still available in the repos, as far as I'm aware. The first ones
>>>> are more of a problem; if I understand matters correctly, anything
>>>> prior to oldoldstable is removed from the live repos, although its
>>>> .deb files are still maintained on e.g. snapshot.debian.org. (Which
>>>> doesn't really suffice for the equivalent of a dist-upgrade,
>>>> because you'd have to manually download all the correct .debs by
>>>> hand and then install them with dpkg.)
>>>>
>>>> Is there in fact a way to manage the first steps of this stepwise
>>>> upgrade, from one aged-out-of-the-repos release to another?
>>>>
>>>> If so, any pointers to information on how to go about it?
>>>
>>>
>>> Save yourself time and lots of problems, back up your data and do a
>>> clean install of the current Debian release.
>>
>>
>> A: This isn't me, this is someone I encountered.
>>
>> B: That's not always a viable option, depending on the circumstances.
>> It's probably the easier option when it is viable, but that doesn't mean
>> it should be the only option considered, for cases when something else
>> may be more viable.
>>
>>> To do what you want requires dist-upgrading each release, in order,
>>> one-at-a-time, then troubleshooting each dist-upgrade once done with
>>> no guarantees it will work.
>>
>>
>> Yes, of course. That's established procedure, and it's entirely
>> reasonable to expect people to follow it. (Is there any reason it
>> shouldn't work, when it worked for people at the time when those
>> releases were made?)
>>
>>> Be sure to read and explicitly follow the dist-upgrade instructions
>>> in the Release Notes for each release. Many times there are special
>>> things that must be done. Just dist-upgrading from your current old
>>> install to Stretch, skipping all those inbetween is "not
>>> recommended," meaning it won't work.
>>
>>
>> Of course. That's exactly why accessible repositories containing those
>> older releases are needed; my question was about how / where to manage
>> those, and that was answered in the first reply.
>>
>
> As a friendly recommendation:
> If it was about me, I would encourage to backup the home directories as well
> as mail or similar, depending what other kind of services running under the
> particular system.
>
> Backup the data to an external usb drive or the whole source drive if you
> are keen on that, for example. Then do a "clean" install of a new system on
> the original drive. Otherwise you might run into issues, where you might
> miss out on an important package, if you snapshot upgrade one by one.
>
> Running such a old and obsolete system is not only a security risk, but also
> in other areas where improvements has been made, you miss out on a lot. This
> was not the question of course, but it simply doesn't make much sense to
> keep such an old operating system around which is not even actively
> supported by documentation or people likewise anymore.
>
> And it might not simply be worth the hassle to upgrade step by step,
> possible breaking something in the process and troubleshoot why one package
> depends on another or crippling other services, having obsolete folders or
> even configuration files and settings laying around, which are not needed
> anymore. As stated by other people here, it might and perhaps will, take
> much longer time to troubleshoot everything or simply end up to be
> impossible to do correctly.
>
> Better clean and start from scratch install with a known supported
> installation.
> Ensure just to backup mail(dirs), mail, .ssh, .config or similar folders in
> "home" (or better the whole home folders" or "var" or other locations which
> might contain data you need. Or "etc" for configuration settings - but "etc"
> content, might and will most likely have changed dramatically depending on
> what was installed previously.
>
> To backup the software list of what was installed on the system, I would use
> something like an "apt list | grep installed" and pipe the output into a
> file. But for "apt-get" this does not seem to be an option, so perhaps
> theres another way to get a list of installed packages using dpkg or such,
> I'm just not aware of that.
> This way, you can then, after some cleanup in an editor for example, pipe
> the output of listed installed packages into the new system apt/apt-get and
> reinstall as available in the repository everything that was installed
> earlier, most likely.
>
> Of course, after the home directories have been created accordingly using
> add user and copy and paste selectively from home to home of the backup
> media.
>
> Good luck!
>


I recommend doing P2V (creating a virtual machine straight from
physical machine) using VMware Converter so you can try upgrading
inside VMware Workstation or something similar.


Reply to: