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