login
Search
A chit-chat on a public mailing list isn't going to find this supposed bug. Why discuss it? Why not just keep prove it happened. Don't you see how tiring it is to discuss it when we've seen no evidence?
Yes, Theo. Though: How? This is what I tried to find out. I showed the list if files. Do you assume I tinkered with it? Why should I? pfctl wasn't working correctly. Without the help of the list, I wouldn't have been able to drill it down to some 70 files being of the previous version. It might be tiring, but what evidence do you want? Here, I want to solve a problem of files missing. Since I followed the Upgrade guide to the dot, rebooted to bsd.rd in the beginning, rebooted at the command prompt, we (I) need to find what went wrong. That's all. I don't even mind if the mistake was on my side, then I could learn. So, please, specify the evidence that you need. Uwe
The error message(s) you are suppressing (or maybe didn't see) About the only way you can get some files but not all files from a tarball is some fatal error in the extraction of the tarball. Any such error tends to give an error message. I don't think this list likes to play guessing games as to exactly what mistakes you have made or what evidence you are suppressing.
Oh, how beautiful! This is a sign of mutual trust. I documented everything from the first pfctl after reboot from upgrade not working, for what I am chided; and still, I am supposed to 'suppress evidence'. How nice of you! And if I present a serial log, I will have been suspected to have tempered with it? No, that seriously turns me off. I have given everything in detail that I came across, I have not been silent about any additional message, any unusual activity. I have stated a few times that I followed the upgrade procedure to the dot, I have confirmed that nothing unusual showed. Over. I might have made some mistake, yes. Even though these same boxes have been upgraded since 3.8, nevermind. I could at all times have made a mistake or overlooked something. But to start kind of asking for 'proof', that's what's ridiculous, to cite Theo. I am willing to give individuals unprivileged access to the boxes, I did this before, to look around. When you have a box that is relevant to your company, and you are responsible for it, and you noticed something unusual, why would you not want to come screaming to the list (like it did, my excuses), to look for help, but 'conveniently avoid' mentioning that serious error message during the upgrade? You need the box to be up and running, and adding this error message can only help; so why would you suppress it, maybe preventing efficient help to be offered? I fully agree that what I report sounds highly unlikely. But it is true, and by now I confirmed exactly the same having happened on that other box (i386), If I suppressed anything, why should I add to the improbability? Yes, it happened, and I applied the same method and have by now tar xzvphf-ed the 70+ sbin-files that were there and - identically to the previous amd64 - are from version 4.6. It is not excluded, as I wrote earlier, that the upgrade itself does everything 100% correct. Who knows, there can always be a rogue package. Not that I'm saying this has happened, but ...
On 3/06/2010, at 8:42 PM, Uwe Dippel wrote: [cut] <quote>everything in detail ... I have not been silent</unquote> I think that is the point that people are trying to make - you've sent so much to the list that it is hard to keep up. The people who can help may not want to wade through 20 emails to keep up with you. Take a deep breath. Take a 4.6 CD install on a spare clean machine and upgrade via the CD. Problem there? Yes/no. Start again with the 4.6 CD a CLEAN install, upgrade via your normal process to 4.7. Is the issue there? Yes/no. And then follow the other suggestions from minds wiser than mine. So far as you are aware, if you upgrade amd64 from a 4.6 CD to a 4.7 via your normal upgrade process, there are issues - correct? If so, I've got a spare amd64 box to try on, but to be honest I'm a bit intimated by the volume of mail you've sent - I'm losing the thread. HTH. Thanks.
OK, I've tried it and cannot reproduce what you see. I've never done an upgrade from bsd.rd before, so wanted to give it a go. Obviously something different with your set-up, or where you got the files from, or factor X - but as other people have said, they can't guess what. In short - the basic bsd.rd "follow these instructions" worked for me here. OK, I start with 4.6 amd64 (either 4.6 or just pre-4.6 release) uname -a OpenBSD dellamd64.home 4.6 GENERIC#0 amd64 But before I upgrade, what's /sbin/pfctl? $ ls -l /sbin/pfctl -r-xr-xr-x 1 root bin 492664 Dec 3 23:12 /sbin/pfctl $ md5 /sbin/pfctl MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7 http://openbsd.org/faq/upgrade47.html "One easy way to boot from the install kernel is to place the 4.7 version of bsd.rd in the root of your boot drive, then instruct the boot loader to boot using this new bsd.rd file. On amd64 and i386, you do this by entering "boot bsd.rd" at the initial boot> prompt." OK, I'll get the bsd.rd from the 4.7 release CD (but could have used FTP.) /usr/bin/su root mv /bsd.rd /bsd46.rd mount /dev/cd0a /mnt/ cp /mnt/4.7/amd64/bsd.rd /bsd.rd umount /mnt eject /dev/cd0a reboot ... boot > boot bsd.rd ... Welcome to the OpenBSD/amd64 4.7 installation program. ... I choose upgrade ... take defaults all the way until ... Location of sets? [What do I do here? I'll try http, and take the defaults. What did YOU do here?] bsd, bsd.rd, base47.tgz, misc47.tgz, comp47.tgz, man47.tgz, game47.tgz, xbase47.tgz xshare47.tgz, xfont47.tgz, xserv47.tgz ... all get to 100% no errors. ... rest of install, reboot ... $ uname -a OpenBSD dellamd64.home 4.7 GENERIC#112 amd64 $ ls -l /sbin/pfctl -r-xr-xr-x 1 root bin 500856 Mar 18 15:36 /sbin/pfctl $ md5 /sbin/pfctl
On Thu, Jun 3, 2010 at 7:18 PM, Richard Toohey Thanks, Richard. No, you couldn't encounter it. It comes in later. I have now the whole upgrade session of my third machine, the log is > 2 MB. Whenever I rebooted, it was okay: 1. reboot to start bsd.rd - okay 2. reboot directly after bsd.rd upgrade - okay 3. reboot after 'Final steps', before pkg_add - okay 4. reboot after 'Upgrading packages' - okay 5. reboot after patching - old files and wrong timestamps - bummer, as Theo might say. I wonder if I can put the file up into the open, or if it contains security-related matter.?? As bz2 it is just 91 k; I will of course make it available to individuals on request. Uwe
Sorry, guys, (too quick as too often), just cat-grep pfctl shows where the old one comes in: pfctl: pf already enabled # ls -l # ls -l /etc/# ls -l /sbin/pfctl -r-xr-xr-x 1 root bin 500856 Mar 18 10:36 /sbin/pfctl # ls -l # ls -l /sbin/ # ls -l # ls -l /sbin/pfctl # ls -l /sbin/pfctl -r-xr-xr-x 1 root bin 500856 Mar 18 10:36 /sbin/pfctl -r-xr-xr-x 1 root bin 500856 Mar 18 10:36 pfctl # pfctl -f # pfctl -f /etc/# pfctl -f # pfctl -f /etc/pf.conf# pfctl -f /etc/pf.conf # # pfctl -e pfctl: pf already enabled # # pfctl -d # # pfctl -e ===> pfctl /usr/src/sbin/pfctl/obj -> /usr/obj/sbin/pfctl ===> pfctl ===> pfctl nroff -Tascii -mandoc /usr/src/sbin/pfctl/pfctl.8 > pfctl.cat8 ===> pfctl install -c -s -o root -g bin -m 555 pfctl /sbin/pfctl install -c -o root -g bin -m 444 pfctl.cat8 /usr/share/man/cat8/pfctl.0 pfctl: DIOCBEGINADDRS: Operation not supported by device pfctl: DIOCBEGINADDRS: Operation not supported by device -r-xr-xr-x 1 root bin 492664 Jun 4 13:28 pfctl Through patching outdated(?) source files; though with the proper time stamp: # cd /home/ftp/pub/OpenBSD/4.7 # ls -l -r-xr-xr-x 1 root ftp 131759003 Mar 21 19:17 src.tar.gz -rw-r--r-- 1 root ftp 20668814 Mar 21 19:17 sys.tar.gz # md5 src.tar.gz MD5 (src.tar.gz) = 5214cd951cac5b7fbd89c968d1b5f859 # md5 sys.tar.gz MD5 (sys.tar.gz) = 566c0cd7c3d2f28b17a9795324ead6ff Maybe TeXitoi was right, after all, when he mentioned corrupted files on some mirrors? I wouldn't bet on it, but usually our fastest mirror here is ftp://ftp.jaist.ac.jp. Uwe
you mean applying the errata47.html patches? If so, are you certain your source tree is tagged OPENBSD_4_7 and not anything else?
I think we are getting closer, aren't we? So, NOTHING to do with the actual upgrade, is it? Or the ports/packages. It is something to do with how you are PATCHING after an upgrade. You don't mention where/when you get the source you patch? Because that would be a separate step, wouldn't it? (I usually install from CD, so I scrub /usr/src & load from src.tar.gz on the
On Fri, Jun 4, 2010 at 3:00 PM, Richard Toohey No absolutely nothing. I withdraw the subject with regret. At least Exactly. Just explained it in the previous post, and don't want to repeat myself. Except that I download, and then the actual files used were: # md5 /usr/src.tar.gz MD5 (/usr/src.tar.gz) = 5214cd951cac5b7fbd89c968d1b5f859 # md5 /usr/sys.tar.gz MD5 (/usr/sys.tar.gz) = 566c0cd7c3d2f28b17a9795324ead6ff (Here, contrary to the earlier post, at the actual location in /usr of the target machine before extraction: # ls -l /usr/s* -rw-r--r-- 1 root wheel 131759003 Mar 21 19:17 /usr/src.tar.gz -rw-r--r-- 1 root wheel 20668814 Mar 21 19:17 /usr/sys.tar.gz) Uwe
Do I understand you correctly? I am not building releases. I am installing/downloading the sets; then I do all the stuff in 'Upgrade guide', then rm -Rf * in /usr/src rm -Rf * in /usr/xenocara rm -Rf * in /usr/ports, and then tar ... the source files meticulously as pointed out in the guide: # cd /usr/src # tar xzf ../sys.tar.gz # tar xzf ../src.tar.gz # cd /usr # tar xzf xenocara.tar.gz # tar xzf ports.tar.gz and then download the patches into /usr/src, then applying them.... and this is what you would see in the serial log. So I don't tag, because I don't cvs; what i do is just download the 4 files. (Also see my other post, it points clearly to the sequence and the reboots done, with always checking pfctl after each reboot.) Uwe
Don't you have old stuff lying around in /usr/obj that gets installed over your new binaries?
That's probably the critical question now. Though, sorry to say, there is nowhere written that you have to rm -Rf it, when you - upgrade - patch Actually, I wasn't even aware of the existence of this directory until several minutes ago. (I expected it to be cleaned with wiping the source directories.) Then, according to what is written by a number of people further up, an number of people could be hit by this. I for one would expect the time stamps to take care for that. And, to stress it again: When you are under 'quality control', and responsible for the uptime of a system, you would never do anything out of the scope of instructions, naturally. especially not some rm -Rf * in a directory of your arbitrary choice. ;) And don't point me to man release, please. I am not doing releases, I am not doing stable, I do, like many others, 'Upgrade Guide X.Y to X.Z', and then get and apply the errata from http://openbsd.org/errataXZ.html; according to their instructions. If this happens to be wrong, by all means, then I make a mistake, and have been making this mistake for 5 years. So, rm -Rf * in /usr/obj is necessary? Uwe
I've been doing upgrades from *around* the 4.2 release, but always from the release CDs. And then I've patched as per the errata instructions. And I've not (so far as I can recall) can to clear /usr/obj before applying patches. And as I type that I remembered! Hang on, there *was* once a patch that didn't apply cleanly ... think it was this one (but then I must have started with 3.9) - definitely an SSL one that wouldn't build without clearing /usr/obj first: http://marc.info/?l=openbsd-misc&m=116335647308807&w=2 So something for the upgrade docs or the patch file(s)? Maybe patch 3 for 4.7 might be responsible this time around? If you try the make clean step when applying patch 3 (something like in the link above - it might fix your problems.) Anyway, absolutely nothing to do with the installer or the 4.6 to 4.7 upgrade, so enough from me. Thanks.
if this is so important: a) reinstall, don't upgrade learn the system and tools you use. is it necessary? depends on the history of the machine in question. I bet you built pfctl at least once before, no? -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
'rm -rf /usr/obj/*' is not your arbitrary choice, it's a documented step when building the system. http://www.openbsd.org/faq/faq5.html#BldUserland
Also documented there is keeping /usr/obj/ in its own partition and using 'newfs' to zap everything more quickly. /Lars
Where did you get those tar-balls from? Those are most likely not 4.7 sources. --patrick
I gave the potential link and their md5 sums further up. Our link here is sooo slooow; I *am* currently downloading the archives from ftp://ftp.openbsd.org/pub/OpenBSD/4.7 to compare the checksums. That would explain a lot (though not everything, since the kernel looks pretty correct: 4.7). Maybe someone is faster and can confirm or refute the authenticity of the archives? Uwe
oh good grief. you had a dirty /usr/obj. just look at the pfctl snippet of the log you posted. do you see pfctl being built? do you see pfctl being installed from /usr/obj? -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Oh, yes. So the blame is on my side, I guess. Mea culpa maxima! I didn't know that the object directories need to be cleaned manually. Until yesterday, I would have taken a bet that the object directories lie within the source trees (/usr/xenocaram /usr/src), and be cleaned when cleaning the sources. Now I am aware that I need to know the location of the object directories and clean them manually. I was totally unaware that, in case of a patch, the installer would take the next best file of the correct name from there; irrespective of the underlying version. Though I feel in good company. I guess, a great number of people on this list were in a similar situation. Knowing the 'social contract' of OpenBSD, I only have to blame myself for ignorance. Still, may I suggest, that the next Upgrade Guide gets an extra line, with a remark pointing out the existence of /usr/obj; and the suggestion to clean it? Also, with respect to the 'errata', the patches, they describe in detail what needs to be done. Maybe here, it could as well be suggested, that before applying the first patch of a new version of OpenBSD, /usr/obj should be cleaned, or be verified to be clean? Thanks for the various people who helped me patiently at analysing this problem to the very end! Uwe
Might be better to read and comprehend ``man patch'' before assuming
It is always so nice to trample on the person lying on the ground, ain't it! Where in 'man patch' is the underlying problem addressed? - oh, yeah, maybe mine is the old version, again ... .
you can't supply a patch? can't even attempt one? all these posts and time wasted and you can't try to make a patch to maybe save someone else from the same fate? -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
a patch to the upgrade guide would be wrong. The problem is the patching process (a special case of the userland build process) assumes a clean obj dir. This has nothing to do with upgrades. If you try to rebuild the same userland utility more than once for /any/ reason without clearing the obj dir, you can run into problems. Clearing the obj directory as part of the upgrade is like flushing your toilet based on the date -- may help, but after a while, things start to stink. It isn't the general (or proper) solution. faq10.html, section 10.15 would be more appropriate, I think. It will probably require more than a couple line diff to work it in clearly. Nick.
oops. What's the recommended procedure for this? -B
process) assumes a clean obj dir. This has nothing to do with upgrades. If you try to rebuild the same userland utility more than once for /any/ reason without clearing the obj dir, you can run into problems. Clearing the obj directory as part of the upgrade is like flushing your toilet based on the date -- may help, but after a while, things start to stink. It isn't the So something in or around here ... "Not all patches are for the kernel. In some cases, you will have to rebuild individual utilities. At other times, will require recompiling all utilities statically linked to a patched library. Follow the guidance in the header of the patch, and if uncertain, rebuild the entire system." Along the lines of: "In some cases (you'll know you have do this because xxxxx) you need to clean /usr/obj first, you do this by yyyyy." Let me learn what xxxxx and yyyyy are. Thanks.
I'm still curious how anything left in /usr/obj can be anything but a possible problem after updating system binaries and sources to a new release. especially for people who are just "following the directions as they are written." -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
On Fri, Jun 4, 2010 at 7:49 PM, Jacob Meuser <jakemsr@sdf.lonestar.org> Do you not agree barring broken makefiles and unreliable system clock (as someone pointed out), object files and binaries (in obj/) should have been rebuilt? --patrick
Consider the follwoing scenario: I have a release n system, last built on May 1. So the obj files have a time stamp of May 1. The files of the tarbal of the new release n+1 have timestamps of Apr 1 or earlier, since it was made at that time. If I then install the tarball by extracting, according to makethe object files are still fresh, since the sources will be older than the object files. By default the files extracted form a tartball get the timestamps from the tarbal. There are some variations on this scenario. -Otto
?? odds that OP found a bad date and "fixed" it (silently) ??
Jacob Meuser wrote: a patch to the upgrade guide would be wrong. The problem is the patching process (a special case of the userland build process) assumes a clean obj dir. This has nothing to do with upgrades. If you try to rebuild the same userland utility more than once for /any/ reason without clearing the obj dir, you can run into problems. Clearing the obj directory as part of the upgrade is like flushing your toilet based on the date -- may help, but after a while, things start to stink. It isn't ANYTHING left in /usr/obj will be a possible problem. ANYTHING left ANYWHERE will be a possible problem anytime anything assumes (or has/likes to assume) that it is working with a clean slate. "Fixing" minor problems (and bending everything else out of shape) does NOT make for better systems. For me, I prefer things (upgrade/update/whatever) that do as little collateral damage as possible. (And anytime you want/need to find out what went wrong you do NOT clean up everything first.)
so Tony, tell me, how does 'rm -rf /usr/obj/*', after installing new binaries and new sources code (from a tarball - not an insignificant part of the issue, and exactly what the directions say to do) create collateral damage? you're already past the point of no return anyway, right? maybe I worded it wrongly but that's what I'm asking. is telling people to 'rm -rf /usr/obj/*' after they have completed the update really a necessary part of the upgrade process. no. but I bet if it would say that in the upgrade guide, this stupid thread would never have happened. -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Jacob Meuser wrote: so Tony, tell me, how does 'rm -rf /usr/obj/*', after installing new binaries and new sources code (from a tarball - not an insignificant part of the issue, and exactly what the directions say to do) create collateral damage? you're already past the point of no return anyway, right? maybe I worded it wrongly but that's what I'm asking. is telling people to 'rm -rf /usr/obj/*' after they have completed the update really a necessary part of the upgrade process. no. but I bet if it would say that in the upgrade guide, this stupid thread would never have happened. -- jakemsr@sdf.lonestar.org Ok, my take on this mess. If not this stupid thread, then some other stupid thread. You do not 'rm -rf /usr/obj/*' AFTER the update. You do the 'rm -rf /usr/obj/*' BEFORE you stick strange stuff into /usr/obj. Collateral damage is anything that gets in the way of finding out exactly what is or exactly what happened. This whole mess seems to be because some unstated something AFTER the update was claimed to be as a result of the update. How often should /tmp be obliterated? When you say "after installing new sources", what exactly is left on the system? The new sources presumably are there, but what else is there and does it matter? The answer requires a directory listing of everything on the system that did not come from the new sources. Anything short of that and you cannot state what it is that you did. All I need to break any automated system you devise is to have some programs that I compile myself and use the system directories to hold the sources etc.
then you are on your own, not someone who is "just following the directions". you'd know that it doesn't apply to you. but whatever. -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Jacob Meuser wrote: some programs that I compile myself and use the system directories then you are on your own, not someone who is "just following the directions". you'd know that it doesn't apply to you. but whatever. -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org ------- It is essential that I understand the difference. (Although I have some difficulty in understanding how anybody could possibly actually be "just following the directions".) As soon as I depart from the directions, everything downstream is my responsibility. The developers are not and can not be responsible for guessing what I have or have not squirreled away wherever. On this silly thread, the upgrade did actually function as it should. Some unmentioned stuff AFTER the upgrade put things in the state BEFORE the upgrade. I can imagine scenarios where that is EXACTLY the results I would want, but that was not the case for this silly thread. For this silly thread, there is nothing that I see in the OpenBSD system that needs any fixing. (but some people who know better may/will disagree) Until and unless selecting "all" also gets the sources, I must assume that setting up the system for following -stable is a separate process.
wtf are you talking about tony? have you even read the upgrade guide? have you read any of this thread, at all, or did you see some long thread on misc@ and decide to jump in? we have users that say they follow the install and upgrade guides to the letter and they get fucked. there is a problem. they don't even know /usr/obj exists. why is enlightening them about /us/obj at the point in the process where /usr/obj, if they have been following the directions to the letter, is basically poison such a terrible idea? yes, blindly rm -rf /usr/obj/* is not the answer. I did not send a patch to nick@ that added that to the upgrade guide, that is not what I'm saying. and I certainly never ever said anything about anything being automated or changing anyting whatsoever in the installer. -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Jacob Meuser wrote: we have users that say they follow the install and upgrade guides to the letter and they get fucked. there is a problem. they don't even know /usr/obj exists. ---- What they say. What they did. Two different things. There's lots of things they do not know about. I fail to understand why it is important to warn them about /usr/obj and not warn them about /usr/src. Surely there's lots of other things they need to be warned about. Enough warnings and you might even attain Microsoft Windows.
what a totally useless bunch of misc traffic only because a drunk OpenBSD user did not remove /usr/obj before building shit
this should not be needed assuming system time didn't jump. it is still good practice tho. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
On Fri, Jun 4, 2010 at 9:22 AM, Uwe Dippel <udippel@gmail.com> wrote:
Please point to the part of the Upgrade Guide which talks about
building from source, untarring the src tar file, or applying errata.
I can't seem to find any such reference, but I'm sure it's in there
somewhere, because you originally said that you did the upgrade
exactly following the upgrade guide and, as we found out later, your
steps included building from source.
The other possibility is that you did stuff that was *not* in the
upgrade guide, in which case adding text to the upgrade guide saying
"if you do this other stuff that's described elsewhere then you should
read those other directions and follow them completely" seems kinda
It already is the first bullet in the directions for building userland
from source:
http://www.openbsd.org/faq/faq5.html#BldUserland
Philip Guenther
You misread what I did. I was following the Upgrade Guide to the dot, following "Applying patches in OpenBSD" to the dot, and then the instructions in the patch files. To the dot. This is where my unfortunate quarrel with Jacob came from, when he said I was building userland, and I insisted I was applying errata. From what I have learned, "Applying patches in OpenBSD" should be removed from the FAQ, since we would all have been spared this thread. It obviously has carried a number of people away. Uwe
Unfortunately, I read your first five message exactly, in which say you upgraded but completely fail to mention building from source or patching. It was only in the last message of the original thread you mention patching, though you didn't describe the process you used at This thread perhaps wouldn't have happened if you hadn't waited until your 13th message to describe that last part. You now have and now it seems the core discussion is just about whether (or where) an additional "rm -rf /usr/obj/*" should be added to help people that know enough to set up the source tree for building/patching by untaring src.tar.gz but don't know to remove the obj tree at the same time. <shurg> I'm just glad to hear that it's PEBCAK instead of some bizarre bug in the kernel or installer. Philip Guenther
So, no diff here, but a suggestion:
If one needs to avoid stale stuff lying around in /usr/obj at applying a patch,
the only logical consequence is, to clean out all /obj totally, even before
applying a single patch.
If I am correct, the instructions should be clear for 00N_ThisApp.patch:
Apply by doing:
cd /usr/src
patch -p0< 00N_ThisApp.patch
Clean the build directories by issuing the command /usr/sbin/mk_build_clean
And then rebuild and install the library and statically-linked binaries
that depend upon it:
cd lib/libThisApp
make obj
make depend
make includes
make
make install
cd ../../sbin
make obj
make depend
make
make install
, where mk_build_clean is just the set of steps pointed out in 'man release',
respectively in FAQ5.
To me, and I guess Richard Toohey, the case is solved.
Everyone who can read, and likes following instructions, can read and follow
this easily.
Uwe
No, the point that people are making (over and above HOW you report an issue) is that blindly following the patch instructions is *not* good enough. It doesn't matter how much more gets put in the docs or the patch files, we didn't *think* enough about what we were doing - that's my mistake and I intend to learn from it. If we just end up blindly doing stuff and clicking on buttons to see what happens, we should probably be using another operating system. This *is* in the docs - if you read a little bit further than we did, and do a bit more thinking. Maybe another line in the patch file would help ... but then what about the next issue that comes up? The patch file doesn't tell you how to put the source there, so if you do *literally* follow "cd /usr/src" and then the patch line, you won't even have the right source, will you? You had to read elsewhere to know how to get the source in the first place. Or next someone will argue that "Then build and install a new kernel" is too brief and there should be full instructions in every patch file. If we go off and read the FAQ about building the kernel because the full instructions were not in the patch file, why didn't we go and read the FAQ about building userland? That's my take on it and I think the list members are rather bored of this
dot, following > "Applying patches in OpenBSD" to the dot, and then the instructions in the patch > files. To the dot. "Applying the patches in OpenBSD" says clearly that after applying the patches, you can _build_the_kernel_ as normal, which sends you to faq5.html#Building (a broken link BTW) Applying errata means patching the files and then building either kernel or userland as normal. Right?
More importantly, you have now read all of http://www.openbsd.org/faq/faq5.html So you still _haven't_ read http://www.openbsd.org/faq/faq5.html#BldUserland ? Cleaning /usr/obj is the very first line. You didn't read the documentation, screwed up, and wasted everyone's time with nonsensical speculationas. End of analysis. You are welcome.
I wanted to understand where I was going wrong in my patching because it sounded similar to what Uwe is doing. In my case I was *just* following the errata patch instructions, and that's *not* enough, depending on the patch. So, RTFM, FAQs 10.15 and 5.3.5 in my case.
Where is the complete serial log of the install and subsequent md5 checks? Because that's the only No. You claim the installer of 4.7 installs some, but not all, of the files in the install sets; or that some of the files instal 4.7 install sets are actually 4.6 files, according to their md5 hashes. That's what's highly suspectible (if not ridiculous). Don't be surprised that people want to be sure this actually happened before they invest That's not a substitute for the complete, unedited serial log of everything that happend from the moment you put an official CD in to the moment you run the md5 test (included). Having root account That were _where_? Do you claim that the base47.tgz file contains 4.6 versions of certain files in /sbin? Where exactly does this Packages install under /usr/local and don't interfere with files from a base install. Jan
The problem is obviously relating to something that you didn't come across otherwise you wouldn't be posting here - if you can post logs this will give more people a chance to spot it.. Ideally send everything right back to the boot messages from bsd.rd. The request for unedited is because some people will "tidy things up" before posting, which might remove something that other people would find important. You'll get a clearly visible error if the hash doesn't match that stored in the install kernel.
