On May 4, 2019 10:11:07 AM GMT+03:00, Nick Holland 
<n...@holland-consulting.net> wrote:
>On 5/3/19 2:32 PM, Strahil Nikolov wrote:
>> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
>> <n...@holland-consulting.net> 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

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 

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.

>feel free to send in a patch.  Test on two or three different
>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 

>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
>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 
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
>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 

>> 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
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
>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

Reply via email to