Upgrade procedure (6.4 -> 6.5)

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Upgrade procedure (6.4 -> 6.5)

Consus-2
Hi,

I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
that /etc/networks and some other files (like malloc.conf.5) are still
present, although there is no use for them in the new release.

Is there a reason why these files are not listed in "FIles to remove"?
Is there a way to track them? It's not like something gonna break, but
old configuration files (and manual pages) lying around can make
someone's life harder during the debug session.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Markus Hennecke
Am 02.05.2019 um 09:52 schrieb Consus:
> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
> that /etc/networks and some other files (like malloc.conf.5) are still
> present, although there is no use for them in the new release.
>
> Is there a reason why these files are not listed in "FIles to remove"?
> Is there a way to track them? It's not like something gonna break, but
> old configuration files (and manual pages) lying around can make
> someone's life harder during the debug session.

Take a look at the sysutils/sysclean port.

Regards
Markus

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Consus-2
On 10:27 Thu 02 May, Markus Hennecke wrote:

> Am 02.05.2019 um 09:52 schrieb Consus:
> > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
> > that /etc/networks and some other files (like malloc.conf.5) are still
> > present, although there is no use for them in the new release.
> >
> > Is there a reason why these files are not listed in "FIles to remove"?
> > Is there a way to track them? It's not like something gonna break, but
> > old configuration files (and manual pages) lying around can make
> > someone's life harder during the debug session.
>
> Take a look at the sysutils/sysclean port.

That's pretty much how I discovered this. But I want to know the
"official" way. Maybe there is a reason why e.g. perl files are to be
removed, but man pages are not.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Stuart Henderson
On 2019-05-02, Consus <[hidden email]> wrote:

> On 10:27 Thu 02 May, Markus Hennecke wrote:
>> Am 02.05.2019 um 09:52 schrieb Consus:
>> > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
>> > that /etc/networks and some other files (like malloc.conf.5) are still
>> > present, although there is no use for them in the new release.
>> >
>> > Is there a reason why these files are not listed in "FIles to remove"?
>> > Is there a way to track them? It's not like something gonna break, but
>> > old configuration files (and manual pages) lying around can make
>> > someone's life harder during the debug session.
>>
>> Take a look at the sysutils/sysclean port.
>
> That's pretty much how I discovered this. But I want to know the
> "official" way. Maybe there is a reason why e.g. perl files are to be
> removed, but man pages are not.
>
>

The upgrade notes only list files which are likely to cause a problem if
they're left lying around.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

nothingness
In reply to this post by Consus-2

On 02/05/2019 11:02, Consus wrote:

> On 10:27 Thu 02 May, Markus Hennecke wrote:
>> Am 02.05.2019 um 09:52 schrieb Consus:
>>> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
>>> that /etc/networks and some other files (like malloc.conf.5) are still
>>> present, although there is no use for them in the new release.
>>>
>>> Is there a reason why these files are not listed in "FIles to remove"?
>>> Is there a way to track them? It's not like something gonna break, but
>>> old configuration files (and manual pages) lying around can make
>>> someone's life harder during the debug session.
>> Take a look at the sysutils/sysclean port.
> That's pretty much how I discovered this. But I want to know the
> "official" way. Maybe there is a reason why e.g. perl files are to be
> removed, but man pages are not.
>
I set up a script for sysclean:

cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done


sysclean65.txt is obtained by running sysclean -a >>sysclean65.txt . I
don't run that line in sysclean65.sh because the files have to be
reviewed to prevent deletion of any additional files you may have added,
like certs or scripts.

HTH

Noth

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Nick Holland
In reply to this post by Consus-2
On 5/2/19 1:52 AM, Consus wrote:

> Hi,
>
> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
> that /etc/networks and some other files (like malloc.conf.5) are still
> present, although there is no use for them in the new release.
>
> Is there a reason why these files are not listed in "FIles to remove"?
> Is there a way to track them? It's not like something gonna break, but
> old configuration files (and manual pages) lying around can make
> someone's life harder during the debug session.

There is no promise that an upgraded machine will be file-for-file
identical to a fresh install.  Here is the list of problems this might
cause you, as you can see, it's a long list and quite horrible:

* If you use the same hw for 20 years, you might run out of disk space?

Ok, not very long and not very horrible.

You are trying to solve a non-problem.  And sometimes, 'specially on an
upgraded machine, it's great to see how things WERE when the machine was
set up.  If you really care, go ahead, delete stuff.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Consus-2
In reply to this post by Stuart Henderson
On 09:42 Thu 02 May, Stuart Henderson wrote:
> The upgrade notes only list files which are likely to cause a problem
> if they're left lying around.

Oh, okay.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Stephen Gregoratto
In reply to this post by nothingness
On 2019-05-02 11:46, Noth wrote:
> I set up a script for sysclean:
>
> cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done

Nitpick, but this could be shortened to:

  xargs rm -rf < sysclean??.txt

Just tested this on my server, so it should work fine.
--
Stephen Gregoratto
PGP: 3FC6 3D0E 2801 C348 1C44 2D34 A80C 0F8E 8BAB EC8B

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Ingo Schwarze
In reply to this post by Nick Holland
Hi Nick,

Nick Holland wrote on Thu, May 02, 2019 at 08:04:32AM -0400:

> There is no promise that an upgraded machine will be file-for-file
> identical to a fresh install.  Here is the list of problems this might
> cause you, as you can see, it's a long list and quite horrible:
>
> * If you use the same hw for 20 years, you might run out of disk space?
>
> Ok, not very long and not very horrible.
>
> You are trying to solve a non-problem.  And sometimes, 'specially on an
> upgraded machine, it's great to see how things WERE when the machine was
> set up.  If you really care, go ahead, delete stuff.

There is (at least) one slight issue that doesn't have an official
solution yet: manual pages.

It might be a good idea to do

  # rm -rf /usr/share/man/* /usr/X11R6/man/*

immediately before an upgrade.

If you don't do that, man(1) might serve you stale manual pages
afterwards that were removed from the sets, containing information
that no longer applies.

All the same, so far, we don't officially recommend it, and even i
usually forget about it when doing upgrades.

Should that be automated?  Or are there risks of downsides or side
effects?  I'm not sure.  Either way, it's hardly a very serious
problem, it's merely slightly annoying.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Chris Cappuccio
Ingo Schwarze [[hidden email]] wrote:
>
> It might be a good idea to do
>
>   # rm -rf /usr/share/man/* /usr/X11R6/man/*
>
> immediately before an upgrade.
>

I go one step further, and rm -rf /usr/include /usr/share /usr/X11R6
before a new snapshot is applied. This is a bit overkill but it's easier
than trying to remember what subdirectories to include during any
given release transition.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Ingo Schwarze
Hi Chris,

Chris Cappuccio wrote on Thu, May 02, 2019 at 12:08:07PM -0700:
> Ingo Schwarze [[hidden email]] wrote:

>> It might be a good idea to do
>>
>>   # rm -rf /usr/share/man/* /usr/X11R6/man/*
>>
>> immediately before an upgrade.

> I go one step further, and rm -rf /usr/include /usr/share /usr/X11R6
> before a new snapshot is applied. This is a bit overkill

That may well be adequate for your personal needs, though we certainly
can't make that the default.  In particular, you are deleting
/usr/X11R6/lib/ which means that many installed packages stop
working, and also private programs that you may have compiled from
source.

Sure, you should run "pkg_add -u" anyway, and also recompile whatever
you compiled by hand.  All the same, for the average user, the
expectation is that doing an upgrade will usually *not* result in
programs linked against old libraries being broken - except, of
course, in the case of major flag days described in upgrade*.html
and current.html.

Yours,
  Ingo

> but it's easier than trying to remember what subdirectories to
> include during any given release transition.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Gonzalo L. Rodriguez-2
In reply to this post by nothingness
On Thu, 02 May 2019 at 11:46:20 +0200, Noth wrote:

>
> On 02/05/2019 11:02, Consus wrote:
> > On 10:27 Thu 02 May, Markus Hennecke wrote:
> > > Am 02.05.2019 um 09:52 schrieb Consus:
> > > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
> > > > that /etc/networks and some other files (like malloc.conf.5) are still
> > > > present, although there is no use for them in the new release.
> > > >
> > > > Is there a reason why these files are not listed in "FIles to remove"?
> > > > Is there a way to track them? It's not like something gonna break, but
> > > > old configuration files (and manual pages) lying around can make
> > > > someone's life harder during the debug session.
> > > Take a look at the sysutils/sysclean port.
> > That's pretty much how I discovered this. But I want to know the
> > "official" way. Maybe there is a reason why e.g. perl files are to be
> > removed, but man pages are not.
> >
> I set up a script for sysclean:
>
> cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done

You probably want some /etc/sysclean.ignore bits before that

> sysclean65.txt is obtained by running sysclean -a >>sysclean65.txt . I don't
> run that line in sysclean65.sh because the files have to be reviewed to
> prevent deletion of any additional files you may have added, like certs or
> scripts.
>
> HTH
>
> Noth
>


--

                - gonzalo

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Consus-2
In reply to this post by Ingo Schwarze
On 15:08 Thu 02 May, Ingo Schwarze wrote:

> Hi Nick,
>
> Nick Holland wrote on Thu, May 02, 2019 at 08:04:32AM -0400:
>
> > There is no promise that an upgraded machine will be file-for-file
> > identical to a fresh install.  Here is the list of problems this might
> > cause you, as you can see, it's a long list and quite horrible:
> >
> > * If you use the same hw for 20 years, you might run out of disk space?
> >
> > Ok, not very long and not very horrible.
> >
> > You are trying to solve a non-problem.  And sometimes, 'specially on an
> > upgraded machine, it's great to see how things WERE when the machine was
> > set up.  If you really care, go ahead, delete stuff.
>
> There is (at least) one slight issue that doesn't have an official
> solution yet: manual pages.
>
> It might be a good idea to do
>
>   # rm -rf /usr/share/man/* /usr/X11R6/man/*
>
> immediately before an upgrade.
>
> If you don't do that, man(1) might serve you stale manual pages
> afterwards that were removed from the sets, containing information
> that no longer applies.
>
> All the same, so far, we don't officially recommend it, and even i
> usually forget about it when doing upgrades.
>
> Should that be automated?  Or are there risks of downsides or side
> effects?  I'm not sure.  Either way, it's hardly a very serious
> problem, it's merely slightly annoying.
>
> Yours,
>   Ingo

Maybe it's a good idea to note this on the upgrade page? Something like
"the upgrade procedure may leave some files behing; you can manually
clean them up using sysclean package"?

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Steve Williams-16
In reply to this post by Stephen Gregoratto
On 02/05/2019 6:23 a.m., Stephen Gregoratto wrote:
> On 2019-05-02 11:46, Noth wrote:
>> I set up a script for sysclean:
>>
>> cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
> Nitpick, but this could be shortened to:
>
>    xargs rm -rf < sysclean??.txt
>
> Just tested this on my server, so it should work fine.

If there are filenames with spaces in them, I think that command won't
work as expected.

Cheers,
Steve Williams

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

nothingness
In reply to this post by Gonzalo L. Rodriguez-2

On 03/05/2019 10:48, Gonzalo L. Rodriguez wrote:

> On Thu, 02 May 2019 at 11:46:20 +0200, Noth wrote:
>> On 02/05/2019 11:02, Consus wrote:
>>> On 10:27 Thu 02 May, Markus Hennecke wrote:
>>>> Am 02.05.2019 um 09:52 schrieb Consus:
>>>>> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
>>>>> that /etc/networks and some other files (like malloc.conf.5) are still
>>>>> present, although there is no use for them in the new release.
>>>>>
>>>>> Is there a reason why these files are not listed in "FIles to remove"?
>>>>> Is there a way to track them? It's not like something gonna break, but
>>>>> old configuration files (and manual pages) lying around can make
>>>>> someone's life harder during the debug session.
>>>> Take a look at the sysutils/sysclean port.
>>> That's pretty much how I discovered this. But I want to know the
>>> "official" way. Maybe there is a reason why e.g. perl files are to be
>>> removed, but man pages are not.
>>>
>> I set up a script for sysclean:
>>
>> cat sysclean65.txt | while read line ; do rm -rf "${line}" ; done
> You probably want some /etc/sysclean.ignore bits before that
Agreed, thanks for the suggestion. Hadn't read the manpage properly,
just for a change. With that you can just pipe sysclean's output to a
delete script...

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

snikolov
In reply to this post by Nick Holland
On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland <[hidden email]> wrote:

>On 5/2/19 1:52 AM, Consus wrote:
>> Hi,
>>
>> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
>> that /etc/networks and some other files (like malloc.conf.5) are
>still
>> present, although there is no use for them in the new release.
>>
>> Is there a reason why these files are not listed in "FIles to
>remove"?
>> Is there a way to track them? It's not like something gonna break,
>but
>> old configuration files (and manual pages) lying around can make
>> someone's life harder during the debug session.
>
>There is no promise that an upgraded machine will be file-for-file
>identical to a fresh install.  Here is the list of problems this might
>cause you, as you can see, it's a long list and quite horrible:
>
>* If you use the same hw for 20 years, you might run out of disk space?
>
>Ok, not very long and not very horrible.
>
>You are trying to solve a non-problem.  And sometimes, 'specially on an
>upgraded machine, it's great to see how things WERE when the machine
>was
>set up.  If you really care, go ahead, delete stuff.
>
>Nick.

Hi All,

As I linux guy (my experience in openBSD can be easily measured in days) I can share the view  of less experienced user that was planing  to upgrade from 6.4 to 6.5 and that eneded with a full reinstall.

I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to 6.5  and thus it seemed that booting from the 6.5 DVD will do the trick.
Sadly the installer never checked the avalable space , but just started to do it's stuff until reporting that not enough space is available.

Why did the installer allow installation despite the available space is low ( even windows checks available space :) )???

Why should the end-user delete old unnecessary/problematic files ? Usually we do have package management system to take care of that (or at least to rename those files in case we really need them).

For me, system upgrade is a very complicated  and  error prone procedure.

P.S.: No offence here, just sharing my thoughts.

Best Regards,
Strahil Nikolov

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Predrag Punosevac-2
In reply to this post by Consus-2
Strahil Nikolov wrote:

>
> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland <[hidden email]> \
> wrote:
> > On 5/2/19 1:52 AM, Consus wrote:
> > > Hi,
> > >
> > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
> > > that /etc/networks and some other files (like malloc.conf.5) are
> > still
> > > present, although there is no use for them in the new release.
> > >
> > > Is there a reason why these files are not listed in "FIles to
> > remove"?
> > > Is there a way to track them? It's not like something gonna break,
> > but
> > > old configuration files (and manual pages) lying around can make
> > > someone's life harder during the debug session.
> >
> > There is no promise that an upgraded machine will be file-for-file
> > identical to a fresh install.  Here is the list of problems this might
> > cause you, as you can see, it's a long list and quite horrible:
> >
> > * If you use the same hw for 20 years, you might run out of disk space?
> >
> > Ok, not very long and not very horrible.
> >
> > You are trying to solve a non-problem.  And sometimes, 'specially on an
> > upgraded machine, it's great to see how things WERE when the machine
> > was
> > set up.  If you really care, go ahead, delete stuff.
> >
> > Nick.
>
> Hi All,
>
> As I linux guy (my experience in openBSD can be easily measured in days)
> I can share the view  of less experienced user that was planing  to
> upgrade from 6.4 to 6.5 and that eneded with a full reinstall.
>

I just upgraded 18 servers running mission critical network
infrastructure and services for a research group of 150 people.
Everything went without a glitch. Some of the servers have been
continuously upgraded since OpenBSD 5.4. That is a solid 5 years which
is a typical lifespan of a production server.

Just as a comparison, I am still afraid to upgrade dozen or so file
servers and jail hosts running FreeBSD 11.2 to 12.0 in-spite of root on
the ZFS mirror and beadm. I typically wait at least year and a half
after initial release of Red Hat to do fresh re-installation of our
computing nodes. Red Hat as you know doesn't support upgrade between the
major releases. Ubuntu (deep learning guys love that crap) upgrade from
16.04 to 18.04 should not be attempted on the production server. On the
top of it network stack on Ubuntu 18.04 is completely broken (at lease
running as Xen DomU. I was too afraid to try on our AWS instances).


> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to 6.5
> and thus it seemed that booting from the 6.5 DVD will do the trick.
> Sadly the installer never checked the avalable space , but just started
> to do it's stuff until reporting that not enough space is available.
>
> Why did the installer allow installation despite the available space is
> low ( even windows checks available space :) )???
>
> Why should the end-user delete old unnecessary/problematic files ?


Because Theo's misplaced his crystal ball and without it, it's
impossible for him to tell which of your files are old and unnecessary
and which once are your local modifications and important data files.


> Usually we do have package management system to take care of that (or at
> least to rename those files in case we really need them).
>
> For me, system upgrade is a very complicated  and  error prone
> procedure.
>

Just move on. Stick to what you know and feel comfortable working with.

Cheers,
Predrag

> P.S.: No offence here, just sharing my thoughts.
>
> Best Regards,
> Strahil Nikolov

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

Nick Holland
In reply to this post by snikolov
On 5/3/19 2:32 PM, Strahil Nikolov wrote:

> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
> <[hidden email]> wrote:
>> On 5/2/19 1:52 AM, Consus wrote:
>>> Hi,
>>>
>>> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I
>>> see that /etc/networks and some other files (like malloc.conf.5)
>>> are
>> still
>>> present, although there is no use for them in the new release.
>>>
>>> Is there a reason why these files are not listed in "FIles to
>> remove"?
>>> Is there a way to track them? It's not like something gonna
>>> break,
>> but
>>> old configuration files (and manual pages) lying around can make
>>> someone's life harder during the debug session.
>>
>> There is no promise that an upgraded machine will be file-for-file
>> identical to a fresh install.  Here is the list of problems this
>> might cause you, as you can see, it's a long list and quite
>> horrible:
>>
>> * If you use the same hw for 20 years, you might run out of disk
>> space?
>>
>> Ok, not very long and not very horrible.
>>
>> You are trying to solve a non-problem.  And sometimes, 'specially
>> on an upgraded machine, it's great to see how things WERE when the
>> machine was set up.  If you really care, go ahead, delete stuff.
>>
>> Nick.
>
> Hi All,
>
> As I linux guy (my experience in openBSD can be easily measured in
> days) I can share the view  of less experienced user that was planing
> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall.
>
> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
> 6.5  and thus it seemed that booting from the 6.5 DVD will do the
> trick. Sadly the installer never checked the avalable space , but
> just started to do it's stuff until reporting that not enough space
> is available.

The installer didn't check. Neither did you.  Let's blame the installer.

Ok, sure, might be nice, but when there are a snootload of different
platforms with radically different size binaries, it's not trivial.  But
feel free to send in a patch.  Test on two or three different platforms,
first, though, please.

And ... considering the number of times I've seen and heard about Linux
systems hose themselves with upgrades, I question your implication.
Major Linux upgrade?  Most people I know just say "Screw it.  Rebuild,
reload".  Linux might have the edge on incremental upgrades, but
eventually, you are going to need to move to the more current
release...and then OpenBSD starts looking REALLY GOOD.

10g disk?  When I first started working with OpenBSD, that was really
big.  But then, I had to manually partition the disk.  20 years later,
10G is tiny.  The installer auto-partioner is really intended for bigger
disks.   Yeah, you are in "Special Case" territory, which isn't a good
spot to be as a new user.

> Why did the installer allow installation despite the available space
> is low ( even windows checks available space :) )???

The average windows user doesn't know what the units of storage mean.

> Why should the end-user delete old unnecessary/problematic files ?

That's my question.  What's the big deal?  On a modern disk, just ignore
them.  They won't be a problem until long after your rotate out the hw.
 Problem is, you used a 2001 vintage size disk.  You should have rotated
that out around 2005.

And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G
disk.  I have my suspicions, and I suspect it would be entertaining to
watch...assuming it wasn't something you were dependent upon.

> Usually we do have package management system to take care of that (or
> at least to rename those files in case we really need them).

Yeah, you need to wait until Linux "package management" screws itself
into a knot for you.

> For me, system upgrade is a very complicated  and  error prone
> procedure.

OpenBSD has what I call a "Learning Curb".  You gotta lift your feet.
Not a lot, it's not hard, but you can't just shuffle along mindlessly
and expect to be carried to the next level without your engaging your brain

If you used Linux for a little bit and figured that OpenBSD is "just
like Linux, but different", yeah, no, you are going to be disappointed.
 Different beast.  From a management perspective, I'd say Linux and
Windows are much more alike than Linux and OpenBSD.  Linux is written
for and by those frustrated with Windows ("Reinventing Windows,
poorly").  OpenBSD is Unix.  It's probably the simplest Unix out there
to use and manage, but it's not Windows (or Linux).

Or...  Think of Linux (and windows) as the big cushy luxury car.  Easy
to drive, assuming you work within the anticipated parameters, but you
really have no idea what's going on under the hood.  "you aren't
supposed to".  That's the design goal, and it works pretty well...until
it doesn't.  OpenBSD is more like a semi-primative small car with tight
suspension and a stick-shift trans.  It's got antilock brakes, but for
the most part, it assumes you know what you are doing when you get
behind the wheel.  When it gets a little wonky, you pop the hood, look
around, see what's not right.  Grab a couple tools from the trunk
(included!) fix it, and be back on the road before the guy in the Luxury
car has figured out how to call for a tow truck.

Spend a little time learning OpenBSD, and you will find you can make it
do amazing things.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

nothingness

On 04/05/2019 07:07, Nick Holland wrote:

> On 5/3/19 2:32 PM, Strahil Nikolov wrote:
>> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
>> <[hidden email]> wrote:
>>> On 5/2/19 1:52 AM, Consus wrote:
>>>> Hi,
>>>>
>>>> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I
>>>> see that /etc/networks and some other files (like malloc.conf.5)
>>>> are
>>> still
>>>> present, although there is no use for them in the new release.
>>>>
>>>> Is there a reason why these files are not listed in "FIles to
>>> remove"?
>>>> Is there a way to track them? It's not like something gonna
>>>> break,
>>> but
>>>> old configuration files (and manual pages) lying around can make
>>>> someone's life harder during the debug session.
>>> There is no promise that an upgraded machine will be file-for-file
>>> identical to a fresh install.  Here is the list of problems this
>>> might cause you, as you can see, it's a long list and quite
>>> horrible:
>>>
>>> * If you use the same hw for 20 years, you might run out of disk
>>> space?
>>>
>>> Ok, not very long and not very horrible.
>>>
>>> You are trying to solve a non-problem.  And sometimes, 'specially
>>> on an upgraded machine, it's great to see how things WERE when the
>>> machine was set up.  If you really care, go ahead, delete stuff.
>>>
>>> Nick.
>> Hi All,
>>
>> As I linux guy (my experience in openBSD can be easily measured in
>> days) I can share the view  of less experienced user that was planing
>> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall.
>>
>> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
>> 6.5  and thus it seemed that booting from the 6.5 DVD will do the
>> trick. Sadly the installer never checked the avalable space , but
>> just started to do it's stuff until reporting that not enough space
>> is available.
> The installer didn't check. Neither did you.  Let's blame the installer.
>
> Ok, sure, might be nice, but when there are a snootload of different
> platforms with radically different size binaries, it's not trivial.  But
> feel free to send in a patch.  Test on two or three different platforms,
> first, though, please.
>
> And ... considering the number of times I've seen and heard about Linux
> systems hose themselves with upgrades, I question your implication.
> Major Linux upgrade?  Most people I know just say "Screw it.  Rebuild,
> reload".  Linux might have the edge on incremental upgrades, but
> eventually, you are going to need to move to the more current
> release...and then OpenBSD starts looking REALLY GOOD.
>
> 10g disk?  When I first started working with OpenBSD, that was really
> big.  But then, I had to manually partition the disk.  20 years later,
> 10G is tiny.  The installer auto-partioner is really intended for bigger
> disks.   Yeah, you are in "Special Case" territory, which isn't a good
> spot to be as a new user.
>
>> Why did the installer allow installation despite the available space
>> is low ( even windows checks available space :) )???
> The average windows user doesn't know what the units of storage mean.
>
>> Why should the end-user delete old unnecessary/problematic files ?
> That's my question.  What's the big deal?  On a modern disk, just ignore
> them.  They won't be a problem until long after your rotate out the hw.
>   Problem is, you used a 2001 vintage size disk.  You should have rotated
> that out around 2005.
>
> And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G
> disk.  I have my suspicions, and I suspect it would be entertaining to
> watch...assuming it wasn't something you were dependent upon.
>
>> Usually we do have package management system to take care of that (or
>> at least to rename those files in case we really need them).
> Yeah, you need to wait until Linux "package management" screws itself
> into a knot for you.
>
>> For me, system upgrade is a very complicated  and  error prone
>> procedure.
> OpenBSD has what I call a "Learning Curb".  You gotta lift your feet.
> Not a lot, it's not hard, but you can't just shuffle along mindlessly
> and expect to be carried to the next level without your engaging your brain
>
> If you used Linux for a little bit and figured that OpenBSD is "just
> like Linux, but different", yeah, no, you are going to be disappointed.
>   Different beast.  From a management perspective, I'd say Linux and
> Windows are much more alike than Linux and OpenBSD.  Linux is written
> for and by those frustrated with Windows ("Reinventing Windows,
> poorly").  OpenBSD is Unix.  It's probably the simplest Unix out there
> to use and manage, but it's not Windows (or Linux).
>
> Or...  Think of Linux (and windows) as the big cushy luxury car.  Easy
> to drive, assuming you work within the anticipated parameters, but you
> really have no idea what's going on under the hood.  "you aren't
> supposed to".  That's the design goal, and it works pretty well...until
> it doesn't.  OpenBSD is more like a semi-primative small car with tight
> suspension and a stick-shift trans.  It's got antilock brakes, but for
> the most part, it assumes you know what you are doing when you get
> behind the wheel.  When it gets a little wonky, you pop the hood, look
> around, see what's not right.  Grab a couple tools from the trunk
> (included!) fix it, and be back on the road before the guy in the Luxury
> car has figured out how to call for a tow truck.
>
> Spend a little time learning OpenBSD, and you will find you can make it
> do amazing things.
>
> Nick.
>
The issue raised really is with the installer. Since KARL was
introduced, 1300M for /usr (the default for 2.5-10G sized disks) isn't
quite enough. I've had "run out of disk space" problems with the
upgrader on 6.5 on a autopartitioned 15G SSD because of this. The
defaults in disklabel need to change so that /usr gets 2G and /usr/X11R6
is at 500M since that partition is never touched once installed and
doesn't require 1G of space. I'm not at all convinced /usr/obj &
/usr/src need partitions either if the computer isn't going to be used
to run -current.

Noth

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade procedure (6.4 -> 6.5)

snikolov
In reply to this post by Nick Holland
On May 4, 2019 10:11:07 AM GMT+03:00, Nick Holland <[hidden email]> wrote:

>On 5/3/19 2:32 PM, Strahil Nikolov wrote:
>> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
>> <[hidden email]> wrote:
>>> On 5/2/19 1:52 AM, Consus wrote:
>>>> Hi,
>>>>
>>>> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I
>>>> see that /etc/networks and some other files (like malloc.conf.5)
>>>> are
>>> still
>>>> present, although there is no use for them in the new release.
>>>>
>>>> Is there a reason why these files are not listed in "FIles to
>>> remove"?
>>>> Is there a way to track them? It's not like something gonna
>>>> break,
>>> but
>>>> old configuration files (and manual pages) lying around can make
>>>> someone's life harder during the debug session.
>>>
>>> There is no promise that an upgraded machine will be file-for-file
>>> identical to a fresh install.  Here is the list of problems this
>>> might cause you, as you can see, it's a long list and quite
>>> horrible:
>>>
>>> * If you use the same hw for 20 years, you might run out of disk
>>> space?
>>>
>>> Ok, not very long and not very horrible.
>>>
>>> You are trying to solve a non-problem.  And sometimes, 'specially
>>> on an upgraded machine, it's great to see how things WERE when the
>>> machine was set up.  If you really care, go ahead, delete stuff.
>>>
>>> Nick.
>>
>> Hi All,
>>
>> As I linux guy (my experience in openBSD can be easily measured in
>> days) I can share the view  of less experienced user that was planing
>> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall.
>>
>> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
>> 6.5  and thus it seemed that booting from the 6.5 DVD will do the
>> trick. Sadly the installer never checked the avalable space , but
>> just started to do it's stuff until reporting that not enough space
>> is available.
>
>The installer didn't check. Neither did you.  Let's blame the
>installer.

Well, O can't presict  how big are the new tars's size -yet the updater shoulddo that.
If my /usr is too small - it should make the calculation for me and refuse to update.

How do you estinate how much space do you need for the update ? Get the iso and extract each archive to predict that ?
Nah let's blame the newbie.

>Ok, sure, might be nice, but when there are a snootload of different
>platforms with radically different size binaries, it's not trivial.
Well, if it's done in linux , its doable in openBSD.

>But
>feel free to send in a patch.  Test on two or three different
>platforms,
>first, though, please.

I would, if I find some time... which is currently my most precious resource.

>And ... considering the number of times I've seen and heard about Linux
>systems hose themselves with upgrades, I question your implication.
>Major Linux upgrade?  Most people I know just say "Screw it.  Rebuild,
>reload".  Linux might have the edge on incremental upgrades, but
>eventually, you are going to need to move to the more current
>release...and then OpenBSD starts looking REALLY GOOD.

Maybe you haven't used RHEL or SUSE - they both support major upgrade (Red Hat released the tool for migration from 6 to 7. Check the release notes for RHEL 7.5)

>10g disk?  When I first started working with OpenBSD, that was really
>big.  But then, I had to manually partition the disk.  20 years later,
>10G is tiny.  The installer auto-partioner is really intended for
>bigger
>disks.   Yeah, you are in "Special Case" territory, which isn't a good
>spot to be as a new user.

If I'm so special, then where was the warning of the installer in the first place?
Just a short notice like 'You have a very small disk and upgrades might not be supported!' would be enough to keep my mouth shut.
Still, there was no such warning in the first place.

>> Why did the installer allow installation despite the available space
>> is low ( even windows checks available space :) )???
>
>The average windows user doesn't know what the units of storage mean.

Yet, we are not windows users :) Are we ?
openBSD is great, but it needs some improvement s and that's what I was trying to imply here, not to criticize.

>> Why should the end-user delete old unnecessary/problematic files ?
>
>That's my question.  What's the big deal?  On a modern disk, just
>ignore
>them.  They won't be a problem until long after your rotate out the hw.
>Problem is, you used a 2001 vintage size disk.  You should have rotated
>that out around 2005.
I saw that at least the man pages will be wrong if I keep them - and of course this will cause issues in the future.

>And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G
>disk.  I have my suspicions, and I suspect it would be entertaining to
>watch...assuming it wasn't something you were dependent upon.
I'm quite active in the CentOS forum and I can assure you that the tool that Red Hat use has no maintainers and thus it doesn't work.
The community will be happy if become a maintainer and start working on this one.

>> Usually we do have package management system to take care of that (or
>> at least to rename those files in case we really need them).
>
>Yeah, you need to wait until Linux "package management" screws itself
>into a knot for you.
I can assure you that rpm is quite a good package manager. If you had issues in the past - it was a bug in the SPEC file used for that package.
>> For me, system upgrade is a very complicated  and  error prone
>> procedure.
>
>OpenBSD has what I call a "Learning Curb".  You gotta lift your feet.
>Not a lot, it's not hard, but you can't just shuffle along mindlessly
>and expect to be carried to the next level without your engaging your
>brain
Well, I had some experience with AIX and it doesn't seem to require so much manual work.
>If you used Linux for a little bit and figured that OpenBSD is "just
>like Linux, but different", yeah, no, you are going to be disappointed.
> Different beast.  From a management perspective, I'd say Linux and
>Windows are much more alike than Linux and OpenBSD.  Linux is written
>for and by those frustrated with Windows ("Reinventing Windows,
>poorly").  OpenBSD is Unix.  It's probably the simplest Unix out there
>to use and manage, but it's not Windows (or Linux).
I know that openBSD is a different 'beer' but a good one.

>Or...  Think of Linux (and windows) as the big cushy luxury car.  Easy
>to drive, assuming you work within the anticipated parameters, but you
>really have no idea what's going on under the hood.  "you aren't
>supposed to".  That's the design goal, and it works pretty well...until
>it doesn't.  OpenBSD is more like a semi-primative small car with tight
>suspension and a stick-shift trans.  It's got antilock brakes, but for
>the most part, it assumes you know what you are doing when you get
>behind the wheel.  When it gets a little wonky, you pop the hood, look
>around, see what's not right.  Grab a couple tools from the trunk
>(included!) fix it, and be back on the road before the guy in the
>Luxury
>car has figured out how to call for a tow truck.
>
>Spend a little time learning OpenBSD, and you will find you can make it
>do amazing things.
I do , but it seems illogical the upgrade process is requiring so much manual effort. In our environment, if all 4000+ servers were openBSD, it would require eons to upgrade them all.
That's why I'm asking here as it seemed that I didn't do it the right way and seeked guidance in the mail list.

 In the end, it seems that I was right - the size of the disk is too small.

Best Regards,
Strahil Nikolov

12