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