Re: Upgrade i386 to amd64
On Thu, Apr 7, 2011 at 5:58 PM, Amit Kulkarni wrote: > Ok, seriously some parts of this discussion should be incorporated in > the FAQ. I will look into this again and again from a newbie's eye (I > am not that far off from a newbie anyway) and see if I can give some > feedback. I have another idea on how to improve the upgrade process > further but first I will do some due diligence. I don't think there's anything to improve. The FAQ recommends a complete "wipe and reinstall" operation. That is the correct recommendation. It sounds like you are searching for a way to complicate the instructions. Please don't.
Re: Upgrade i386 to amd64
> The only thing you should be trying to save are data containing > directories -- /home and maybe some other "special" directories, like my > /u1 example here. A possible exception to his might be /var; I could > see you may have websites or mail and didn't think far enough ahead to > put those in their own partition, but you will have a bit of a clean-up > job to do there, as things like the pkg database live there, restoring > that over a machine with a different package collection installed is > annoying. > > AFTER your first boot, edit /etc/fstab to put back your other > partitions. AFTER install. > > That should be non-eventful, but you should practice on a non-critical > system. > Nick, Ok, seriously some parts of this discussion should be incorporated in the FAQ. I will look into this again and again from a newbie's eye (I am not that far off from a newbie anyway) and see if I can give some feedback. I have another idea on how to improve the upgrade process further but first I will do some due diligence. Right now, I blew all my system partitions just to test (all /usr/src etc.. is saved, so no download of all those) and re-assembled the softraid mirror. Good time to practice before you really need it. Thanks
Re: Upgrade i386 to amd64
On Thu, Apr 7, 2011 at 3:31 PM, Amit Kulkarni wrote: >>> On 2011-04-07 0:57:10 Amit Kulkarni wrote: >>> >>> Is this in the FAQ? Never thought I would read such a question. >>> >> >> I will be sure to put it in the IFAQ for 5.0. B Along with "where is >> the sea-urchin flavored frozen yogurt?" and "do these gloves make >> my butt look big?" >> > > Can't some people get sarcasm? You are the second person to refer to > this. Nick got it. Maybe a smiley would have reinforced the sarcasm... > > You need to use the sarcasm tags:
Re: Upgrade i386 to amd64
>> On 2011-04-07 0:57:10 Amit Kulkarni wrote: >> >> Is this in the FAQ? Never thought I would read such a question. >> > > I will be sure to put it in the IFAQ for 5.0. Along with "where is > the sea-urchin flavored frozen yogurt?" and "do these gloves make > my butt look big?" > Can't some people get sarcasm? You are the second person to refer to this. Nick got it. Maybe a smiley would have reinforced the sarcasm...
Re: Upgrade i386 to amd64
On Thu, Apr 7, 2011 at 9:30 AM, Ted Unangst wrote: > On Thu, Apr 7, 2011 at 12:10 PM, Steven R. Gerber > wrote: >> The partitions/mounts problem is far more disconcerting. What if I need >> to save data to a striped array to do the migration? >> Recreating/resetting those parameters is dangerous. How can I create >> and use a site script to preserve them through install? Is it possible >> to do an install without walloping the existing filesystem(s)? (Deleting >> files is OK.) > > The installer will not overwrite an existing disklabel if you have one > and will only newfs filesystems that have mount points. This is easy > to screw up if you aren't careful, but it's certainly possible to do a > clean install and keep some filesystems from before. beautiful feature I count on on every install!
Re: Upgrade i386 to amd64
On 4/7/2011 3:39 PM, Nick Holland wrote: > On 04/07/2011 02:08 PM, Steven R. Gerber wrote: >> Nick, >> Thanks for the clue, but I still don't get it (me dummy?). >> ** >> NOTE for re-installers: The new installer will not clear your old >> disklabel if you chose "(C)ustom Layout", but you will need to >> re-specify each mount point using the 'm' option in disklabel(8). >> >> The installer now creates those partitions and creates file systems on >> them using newfs(8), and mounts them for installation: >> ** >> The FAQ indicates that I must set mounts in disklabel and that they'll >> be newfs'd. >> If I don't set them then how/where will the installer copy and unpack >> files? > > you don't not set ALL the mount points, you just don't set the mount > points you wish to save. > > i.e., simple case, you have: > / sd0a > /usr sd0d > /var sd0e > /home sd0h > /tmp sd0f > /u1 sd0g > > You want to save /u1 and /home. So, don't define mount points for the > partitions that would have been mounted (sd0g, sd0h). Define the other > four partitions mount points. sd0g and sd0h won't be newfs'd. > >> Is there a point in the process (after disklabel, before file sets) >> where I can fix /etc/fstab and mount? > > NO. > if you are trying to unpack files on to partitions you tried to avoid > newfs-ing, you are doing it wrong! > > What if you want to save /usr from newfs? YOU ARE DOING IT WRONG. > what if you want to save /var from newfs? YOU ARE DOING IT WRONG > (probably). > what if you want to save / from newfs? YOU ARE DOING IT WRONG. > What if you want to save /tmp from newfs? You are missing the point of > /tmp. > > The only thing you should be trying to save are data containing > directories -- /home and maybe some other "special" directories, like my > /u1 example here. A possible exception to his might be /var; I could > see you may have websites or mail and didn't think far enough ahead to > put those in their own partition, but you will have a bit of a clean-up > job to do there, as things like the pkg database live there, restoring > that over a machine with a different package collection installed is > annoying. > > AFTER your first boot, edit /etc/fstab to put back your other > partitions. AFTER install. > > That should be non-eventful, but you should practice on a non-critical > system. > > Nick. > > > Lightbulb and a forehead slap!!! Thanks, Steven
Re: Upgrade i386 to amd64
On 04/07/2011 02:08 PM, Steven R. Gerber wrote: Nick, Thanks for the clue, but I still don't get it (me dummy?). ** NOTE for re-installers: The new installer will not clear your old disklabel if you chose "(C)ustom Layout", but you will need to re-specify each mount point using the 'm' option in disklabel(8). The installer now creates those partitions and creates file systems on them using newfs(8), and mounts them for installation: ** The FAQ indicates that I must set mounts in disklabel and that they'll be newfs'd. If I don't set them then how/where will the installer copy and unpack files? you don't not set ALL the mount points, you just don't set the mount points you wish to save. i.e., simple case, you have: / sd0a /usr sd0d /var sd0e /home sd0h /tmp sd0f /u1 sd0g You want to save /u1 and /home. So, don't define mount points for the partitions that would have been mounted (sd0g, sd0h). Define the other four partitions mount points. sd0g and sd0h won't be newfs'd. Is there a point in the process (after disklabel, before file sets) where I can fix /etc/fstab and mount? NO. if you are trying to unpack files on to partitions you tried to avoid newfs-ing, you are doing it wrong! What if you want to save /usr from newfs? YOU ARE DOING IT WRONG. what if you want to save /var from newfs? YOU ARE DOING IT WRONG (probably). what if you want to save / from newfs? YOU ARE DOING IT WRONG. What if you want to save /tmp from newfs? You are missing the point of /tmp. The only thing you should be trying to save are data containing directories -- /home and maybe some other "special" directories, like my /u1 example here. A possible exception to his might be /var; I could see you may have websites or mail and didn't think far enough ahead to put those in their own partition, but you will have a bit of a clean-up job to do there, as things like the pkg database live there, restoring that over a machine with a different package collection installed is annoying. AFTER your first boot, edit /etc/fstab to put back your other partitions. AFTER install. That should be non-eventful, but you should practice on a non-critical system. Nick.
Re: Upgrade i386 to amd64
On 4/7/2011 1:37 PM, Nick Holland wrote: > On 04/07/2011 01:02 PM, Steven R. Gerber wrote: >> On 4/7/2011 12:30 PM, Ted Unangst wrote: >>> On Thu, Apr 7, 2011 at 12:10 PM, Steven R. Gerber >>> wrote: The partitions/mounts problem is far more disconcerting. What if I need to save data to a striped array to do the migration? Recreating/resetting those parameters is dangerous. How can I create and use a site script to preserve them through install? Is it possible to do an install without walloping the existing filesystem(s)? (Deleting files is OK.) >>> The installer will not overwrite an existing disklabel if you have one >>> and will only newfs filesystems that have mount points. This is easy >>> to screw up if you aren't careful, but it's certainly possible to do a >>> clean install and keep some filesystems from before. >>> >>> >> I am missing the point. It seems like a Catch-22 to me. >> The installer takes me into disklabel: >> Whole disk OR Auto OR Existing? > > that's not disklabel. that's fdisk. > > you chose "edit MBR" to look at what you currently have and perhaps > change it in your own way, and if I recall properly, it's "OpenBSD" to > use the existing partition. Use the existing partition. > > Then when you get to disklabel, you will chose a "custom" layout. > Define mount points for the partitions you want cleared, and not for > those you wish to retain, and then add them to /etc/fstab afterwards. > > See http://www.openbsd.org/faq/faq4.html#InstDisks for more details. > > >> I also have mount points for my arrays. How do I preserve the softraid >> parameters etc.? > > Same way as any other disk. The install kernel will see, recognize and > configure any existing softraid "disks", and treat them as the other > disks on the system. You do the same. :) > > Nick. > > > Nick, Thanks for the clue, but I still don't get it (me dummy?). ** NOTE for re-installers: The new installer will not clear your old disklabel if you chose "(C)ustom Layout", but you will need to re-specify each mount point using the 'm' option in disklabel(8). The installer now creates those partitions and creates file systems on them using newfs(8), and mounts them for installation: ** The FAQ indicates that I must set mounts in disklabel and that they'll be newfs'd. If I don't set them then how/where will the installer copy and unpack files? Is there a point in the process (after disklabel, before file sets) where I can fix /etc/fstab and mount? Thanks, Steven
Re: Upgrade i386 to amd64
On 07/04/11 01:46, Steven R. Gerber wrote: I ran the upgrade from CD. I want to be sure that packages are OK. Is "pkg_add -u" sufficient? (It looks like nothing changed.) Should I try "pkg_add -u -D update" or something else? Thanks, Steven Save your self from trouble. Backup /etc, /root, /home and whatever custom you have like pkg_info Install, do the diff -ru /etc etc_backup/ and apply the changes. Better run now than later when the system is in production and you don't know why xzy binary or library shows you the finger. regards, Giannis
Re: Upgrade i386 to amd64
On 04/07/2011 01:02 PM, Steven R. Gerber wrote: On 4/7/2011 12:30 PM, Ted Unangst wrote: On Thu, Apr 7, 2011 at 12:10 PM, Steven R. Gerber wrote: The partitions/mounts problem is far more disconcerting. What if I need to save data to a striped array to do the migration? Recreating/resetting those parameters is dangerous. How can I create and use a site script to preserve them through install? Is it possible to do an install without walloping the existing filesystem(s)? (Deleting files is OK.) The installer will not overwrite an existing disklabel if you have one and will only newfs filesystems that have mount points. This is easy to screw up if you aren't careful, but it's certainly possible to do a clean install and keep some filesystems from before. I am missing the point. It seems like a Catch-22 to me. The installer takes me into disklabel: Whole disk OR Auto OR Existing? that's not disklabel. that's fdisk. you chose "edit MBR" to look at what you currently have and perhaps change it in your own way, and if I recall properly, it's "OpenBSD" to use the existing partition. Use the existing partition. Then when you get to disklabel, you will chose a "custom" layout. Define mount points for the partitions you want cleared, and not for those you wish to retain, and then add them to /etc/fstab afterwards. See http://www.openbsd.org/faq/faq4.html#InstDisks for more details. I also have mount points for my arrays. How do I preserve the softraid parameters etc.? Same way as any other disk. The install kernel will see, recognize and configure any existing softraid "disks", and treat them as the other disks on the system. You do the same. :) Nick.
Re: Upgrade i386 to amd64
On Thu, Apr 7, 2011 at 12:10 PM, Steven R. Gerber wrote: > The partitions/mounts problem is far more disconcerting. What if I need > to save data to a striped array to do the migration? > Recreating/resetting those parameters is dangerous. How can I create > and use a site script to preserve them through install? Is it possible > to do an install without walloping the existing filesystem(s)? (Deleting > files is OK.) The installer will not overwrite an existing disklabel if you have one and will only newfs filesystems that have mount points. This is easy to screw up if you aren't careful, but it's certainly possible to do a clean install and keep some filesystems from before.
Re: Upgrade i386 to amd64
> On 2011-04-07 0:57:10 Amit Kulkarni wrote: > > Is this in the FAQ? Never thought I would read such a question. > I will be sure to put it in the IFAQ for 5.0. Along with "where is the sea-urchin flavored frozen yogurt?" and "do these gloves make my butt look big?" -- Ed Ahlsen-Girard
Re: Upgrade i386 to amd64
On Thu, Apr 7, 2011 at 5:30 PM, Nick Holland wrote: > That's the nature of OpenBSD, they try to keep things as machine > independent as they can. It's pretty amazing, really. > No, that's not amazing. That, my friend, is fucking awesome. -- chs
Re: Upgrade i386 to amd64
On 4/7/2011 12:30 PM, Ted Unangst wrote: > On Thu, Apr 7, 2011 at 12:10 PM, Steven R. Gerber > wrote: >> The partitions/mounts problem is far more disconcerting. What if I need >> to save data to a striped array to do the migration? >> Recreating/resetting those parameters is dangerous. How can I create >> and use a site script to preserve them through install? Is it possible >> to do an install without walloping the existing filesystem(s)? (Deleting >> files is OK.) > > The installer will not overwrite an existing disklabel if you have one > and will only newfs filesystems that have mount points. This is easy > to screw up if you aren't careful, but it's certainly possible to do a > clean install and keep some filesystems from before. > > I am missing the point. It seems like a Catch-22 to me. The installer takes me into disklabel: Whole disk OR Auto OR Existing? If I choose Existing then there are no mount points. If I quit now then there are no mount points and the installer will not proceed? If I define mount points then they will be newfs'd. Like many others, my usual filesystem layouts are production *** / /home /root /tmp /usr /var /var/crash /var/log /var/mail /var/www *** OR development *** / /home /tmp /usr /usr/X11R6 /usr/local /usr/obj /usr/src /var *** I also have mount points for my arrays. How do I preserve the softraid parameters etc.? Thanks, Steven
Re: Upgrade i386 to amd64
On 4/7/2011 3:06 AM, Tomas Bodzar wrote: > On Thu, Apr 7, 2011 at 7:47 AM, Steven R. Gerber > wrote: >> On 4/7/2011 1:01 AM, Abel Abraham Camarillo Ojeda wrote: >>> On Wed, Apr 6, 2011 at 11:37 PM, Steven R. Gerber >>> wrote: B B B B Going through /etc manually or by sysmerge is tedious. >>> >>> I wish we had some kind of super-black-magic-mind-reading-hyper-sysmerge > tool... >>> >>> >> >> Dear Abel, >> That was unnecessary. > > It was as sysmerge(8) is doing great job. > >> My point was that migrating from 4.8/i386 to 4.8/amd64 requires >> virtually no changes to main /etc. > > Virtually maybe. Practically for sure. > >> But, a fresh install (not an upgrade) makes me (re)verify all of /etc. >> The upgrade FAQ 4.7 -> 4.8 was fairly clear about what parts of /etc >> were touched and needed special attention. > > You can use site scripts to make your own changes directly during install. > >> >> Thanks, >> Steven > > > Thanks to everyone for the thorough comments. I know that sysmerge is a great tool. My "tedious" thought was just that (all the tools are available for this part). After all the comments and some reflection, I have some questions (I might be reaching). Since going from i386 to amd64 will probably be common, should a guide be in FAQ? I am very willing to do what I can. I just don't want to be barking up the wrong tree. The partitions/mounts problem is far more disconcerting. What if I need to save data to a striped array to do the migration? Recreating/resetting those parameters is dangerous. How can I create and use a site script to preserve them through install? Is it possible to do an install without walloping the existing filesystem(s)? (Deleting files is OK.) Thanks, Steven
Re: Upgrade i386 to amd64
On 04/07/2011 12:37 AM, Steven R. Gerber wrote: On 4/6/2011 8:57 PM, Amit Kulkarni wrote: Is this in the FAQ? Never thought I would read such a question. Don't see that one too often, no. :) On Wed, Apr 6, 2011 at 7:06 PM, Nick Holland wrote: On 04/06/11 18:46, Steven R. Gerber wrote: I ran the upgrade from CD. from i386 to amd64? No. Don't do this. Boot off the CD again, and this time pick "install". You can save your /home directory and config files. amd64 and i386, for OpenBSD, are totally different platforms. You can't "upgrade" from one platform to another safely, you have to reinstall. I want to be sure that packages are OK. Is "pkg_add -u" sufficient? (It looks like nothing changed.) Should I try "pkg_add -u -D update" or something else? nuke from orbit, only way to be sure. Sure, you might be able to get away with this, but one left over library or binary will really ruin your day at some point. Nick. Sorry for the stupid question? But, this is a real scenario. Testing for bug system/6586: rdist (file larger than 2GB) times out but will not die. I need(ed) one of my configured/development machines to go from i386 to amd64. I did not want to lose my configuration in /etc nor /home nor /root ... hey, sometimes you can get away with it. In fact, you may get away with it most of the times on a "normal" OpenBSD install. But man. you get one binary left behind (library file, perhaps?) and you will have a bad time, so the "proper" advice for a production machine is to reload. You want to improvise, go ahead, it's your computer. We supply the bullets, you provide the foot, but we try not to help you put them together. In the bigger picture, many users/admins will probably be doing similar things as we can use more physical memory. An appropriate FAQ entry would be terrific. http://www.openbsd.org/faq/faq12.html#amd64 : 'Note that the OpenBSD/amd64 and OpenBSD/i386 boot loaders will load each other's kernels, making it easier to reinstall a system with the "other" platform. However, it has to be a complete "wipe and reinstall" operation -- left-over binaries from the "previous" installation will most likely make your life unpleasant.' Perhaps not where you might have been looking, but unfortunately, when it comes to doing things wrong, there is a nearly unlimited number of ways. It is hard to cover it all. :) I did save my /etc, /home, /root, etc. to an array and did a full reinstall. Some thoughts: Having to redo partitions/mounts was a pain. Going through /etc manually or by sysmerge is tedious. Thanks, Steven re: another message in this thread, yes, the amd64 and i386 /etc directories are very very very similar. So is the sparc64 and i386 /etc directories. That's the nature of OpenBSD, they try to keep things as machine independent as they can. It's pretty amazing, really. Nick.
Re: Upgrade i386 to amd64
* Steven R. Gerber [110407 02:51]: > I ran the upgrade from CD. > I want to be sure that packages are OK. > Is "pkg_add -u" sufficient? (It looks like nothing changed.) > Should I try "pkg_add -u -D update" or something else? I did i386->amd64 upgrade once, it went smoothly. I had to reinstall packages, though. pkg_add -u -D installed was not enough. And you can always make sure that your binaries are of right arch by running file on them. -- Alexander Polakov | plhk.ru
Re: Upgrade i386 to amd64
On Thu, Apr 7, 2011 at 7:47 AM, Steven R. Gerber wrote: > On 4/7/2011 1:01 AM, Abel Abraham Camarillo Ojeda wrote: >> On Wed, Apr 6, 2011 at 11:37 PM, Steven R. Gerber >> wrote: >>> >>> B B B B Going through /etc manually or by sysmerge is tedious. >>> >> >> I wish we had some kind of super-black-magic-mind-reading-hyper-sysmerge tool... >> >> > > Dear Abel, > That was unnecessary. It was as sysmerge(8) is doing great job. > My point was that migrating from 4.8/i386 to 4.8/amd64 requires > virtually no changes to main /etc. Virtually maybe. Practically for sure. > But, a fresh install (not an upgrade) makes me (re)verify all of /etc. > The upgrade FAQ 4.7 -> 4.8 was fairly clear about what parts of /etc > were touched and needed special attention. You can use site scripts to make your own changes directly during install. > > Thanks, > Steven
Re: Upgrade i386 to amd64
> I need(ed) one of my configured/development machines to go from i386 to > amd64. Once I needed one of my old machines to go from i386 to sparc and I experienced similar problems.
Re: Upgrade i386 to amd64
On Wed, Apr 6, 2011 at 11:37 PM, Steven R. Gerber wrote: > > B B B B Going through /etc manually or by sysmerge is tedious. > I wish we had some kind of super-black-magic-mind-reading-hyper-sysmerge tool...
Re: Upgrade i386 to amd64
On 4/7/2011 1:01 AM, Abel Abraham Camarillo Ojeda wrote: > On Wed, Apr 6, 2011 at 11:37 PM, Steven R. Gerber > wrote: >> >>Going through /etc manually or by sysmerge is tedious. >> > > I wish we had some kind of super-black-magic-mind-reading-hyper-sysmerge > tool... > > Dear Abel, That was unnecessary. My point was that migrating from 4.8/i386 to 4.8/amd64 requires virtually no changes to main /etc. But, a fresh install (not an upgrade) makes me (re)verify all of /etc. The upgrade FAQ 4.7 -> 4.8 was fairly clear about what parts of /etc were touched and needed special attention. Thanks, Steven
Re: Upgrade i386 to amd64
On 4/6/2011 8:57 PM, Amit Kulkarni wrote: > Is this in the FAQ? Never thought I would read such a question. > > On Wed, Apr 6, 2011 at 7:06 PM, Nick Holland > wrote: >> On 04/06/11 18:46, Steven R. Gerber wrote: >>> I ran the upgrade from CD. >> >> from i386 to amd64? No. Don't do this. >> >> Boot off the CD again, and this time pick "install". >> You can save your /home directory and config files. >> >> amd64 and i386, for OpenBSD, are totally different platforms. You can't >> "upgrade" from one platform to another safely, you have to reinstall. >> >>> I want to be sure that packages are OK. >>> Is "pkg_add -u" sufficient? (It looks like nothing changed.) >>> Should I try "pkg_add -u -D update" or something else? >> >> nuke from orbit, only way to be sure. >> >> Sure, you might be able to get away with this, but one left over library >> or binary will really ruin your day at some point. >> >> Nick. > > > Sorry for the stupid question? But, this is a real scenario. Testing for bug system/6586: rdist (file larger than 2GB) times out but will not die. I need(ed) one of my configured/development machines to go from i386 to amd64. I did not want to lose my configuration in /etc nor /home nor /root ... In the bigger picture, many users/admins will probably be doing similar things as we can use more physical memory. An appropriate FAQ entry would be terrific. I did save my /etc, /home, /root, etc. to an array and did a full reinstall. Some thoughts: Having to redo partitions/mounts was a pain. Going through /etc manually or by sysmerge is tedious. Thanks, Steven
Re: Upgrade i386 to amd64
Is this in the FAQ? Never thought I would read such a question. On Wed, Apr 6, 2011 at 7:06 PM, Nick Holland wrote: > On 04/06/11 18:46, Steven R. Gerber wrote: >> I ran the upgrade from CD. > > from i386 to amd64? No. Don't do this. > > Boot off the CD again, and this time pick "install". > You can save your /home directory and config files. > > amd64 and i386, for OpenBSD, are totally different platforms. You can't > "upgrade" from one platform to another safely, you have to reinstall. > >> I want to be sure that packages are OK. >> Is "pkg_add -u" sufficient? (It looks like nothing changed.) >> Should I try "pkg_add -u -D update" or something else? > > nuke from orbit, only way to be sure. > > Sure, you might be able to get away with this, but one left over library > or binary will really ruin your day at some point. > > Nick.
Re: Upgrade i386 to amd64
On 04/06/11 18:46, Steven R. Gerber wrote: > I ran the upgrade from CD. from i386 to amd64? No. Don't do this. Boot off the CD again, and this time pick "install". You can save your /home directory and config files. amd64 and i386, for OpenBSD, are totally different platforms. You can't "upgrade" from one platform to another safely, you have to reinstall. > I want to be sure that packages are OK. > Is "pkg_add -u" sufficient? (It looks like nothing changed.) > Should I try "pkg_add -u -D update" or something else? nuke from orbit, only way to be sure. Sure, you might be able to get away with this, but one left over library or binary will really ruin your day at some point. Nick.
Upgrade i386 to amd64
I ran the upgrade from CD. I want to be sure that packages are OK. Is "pkg_add -u" sufficient? (It looks like nothing changed.) Should I try "pkg_add -u -D update" or something else? Thanks, Steven
Re: same version upgrade i386 to amd64 gotchas?
On Fri, 2 Mar 2007, Paul Pruett wrote: I copied a current i386 kernel from this week , and it rebooted okay on the athlon64 platform. To test I did a make for /usr/ports/sytutils/cdrtools and it did not complain, so thats a small warm fuzzy. Now I wait a week and see if it freezes/hangs The revert has completely fixed the hangs on my amd64 running in i386 mode. I could wedge the machine in a couple of hours - now it's been crunching for almost a couple of weeks without issue Sam -- Intuition, like a flash of lightning, lasts only for a second. It generally comes when one is tormented by a difficult decipherment and when one reviews in his mind the fruitless experiments already tried. Suddenly the light breaks through and one finds after a few minutes what previous days of labour were unable to find. -- Cryptonomincon. Neal Stephenson.
Re: same version upgrade i386 to amd64 gotchas?
On 2007/03/03 14:01, Paul Pruett wrote: > Umm, it frooze/hung up again at 5:08 am. about > 23 hours after rebooting with the current 4.1 kernel > on the i386 4.0 userland (not recommended...I'm sure you know that already though) > I was remote so I did not see the monitor for any > panics, but reset using the apc power switch. If you set ddb.panic=0 you'll _sometimes_ get something useful in syslog. Try and arrange serial console access if possible though. Was it definitely not running, or is there a chance you just lost the network? (you could check for newsyslog's hourly entries in /var/cron/log if there's nothing else that would be logging without network input). > ... My personal experience is that going forward > I would strongly recommend to readers to use OpenBSD amd64 > (not i386) on the AMD K8 platforms (athlon64). there are definitely times when you want to use i386. (don't rule out defective hardware too soon, either).
Re: same version upgrade i386 to amd64 gotchas?
The fix was just to remove PAE support from the i386 kernel (until the bug is found). So, try copying the latest snapshot kernel to /bsd and reboot. Just grab it from the snapshots/i386 directory on the ftp server. I copied a current i386 kernel from this week , and it rebooted okay on the athlon64 platform. Now I wait a week and see if it freezes/hangs Umm, it frooze/hung up again at 5:08 am. about 23 hours after rebooting with the current 4.1 kernel on the i386 4.0 userland I was remote so I did not see the monitor for any panics, but reset using the apc power switch. I looked through the logs and the only thing I saw queer was that it created a file /var/log/mail with zero content just as it hung up. Weird, I used the kernel from current on stable i386 userland on a K8 cpu, which is something that I would normally not do, but since it was an simple test, we tried. Staying with i386 on a athlon64 K8 cpu has caused hangups/freezes about every day or two of note here is the log snips indicating when logging stopped --- from daemon Mar 3 05:05:38 mail dhcpd: DHCPDISCOVER from 00:18:39:f0:c8:be via rl0 Mar 3 05:05:38 mail dhcpd: DHCPOFFER on 172.16.254.224 to 00:18:39:f0:c8:be via rl0 Mar 3 08:08:56 mail named[14969]: starting BIND 9.3.2-P1 Mar 3 08:08:56 mail named[14969]: loading configuration from '/etc/named.conf' And here is a weird file that showed up in the /var/log/ at the apparent time of the hang: -rw-r--r-- 1 root wheel0 Mar 3 05:06 mail Yes it may be with enough effort we could find the culprit, and it may be an port or something else, but with less effort I could roll back to stable or upgrade to current amd64 instead of trying to make i386 not hang. ... My personal experience is that going forward I would strongly recommend to readers to use OpenBSD amd64 (not i386) on the AMD K8 platforms (athlon64).
Re: same version upgrade i386 to amd64 gotchas?
The fix was just to remove PAE support from the i386 kernel (until the bug is found). So, try copying the latest snapshot kernel to /bsd and reboot. Just grab it from the snapshots/i386 directory on the ftp server. Agreed, I did not see a easy one line change to kernel compile to remove PAE for openbsd 4.0 stable. So I did as suggested. I copied a current i386 kernel from this week , and it rebooted okay on the athlon64 platform. To test I did a make for /usr/ports/sytutils/cdrtools and it did not complain, so thats a small warm fuzzy. Now I wait a week and see if it freezes/hangs If the 4.1 kernel solves your problem (it probably will) then you should wait for a 4.1 cd and do a proper upgrade when you have the time and have gone over the documentation. Better yet, after you've decided how you want to handle the upgrade, try doing it on another machine first, unless this one is experimental. I been testing the i386 snapshots on 32bit athlons, and some of the portpackages I desire are not making yet, but it's a lot closer. Agreed, I unboxed my emergency spare power supply to put together a experiment computer with AMD K8 cpu to test with, and DOH, it had a 20pin not 24pin as marked. ... :( so yep, more power supplies are on order, and next time I'll open and verify the spares to before shelving. Thanks for the clarifications, now I know to google "pae openbsd" I see the notes in http://www.openbsd.org/plus40.html "Implemented separate pmap for PAE i386 machines, allows for support for machines with more than 4G RAM. Not enabled by default." http://www.openbsd.org/plus.html "Revert PAE pmap for now, stops freezes commonly seen on amd64 machines running in i386 mode."
Re: same version upgrade i386 to amd64 gotchas?
The fix was just to remove PAE support from the i386 kernel (until the bug is found). So, try copying the latest snapshot kernel to /bsd and reboot. Just grab it from the snapshots/i386 directory on the ftp server. Some system utilities were converted to interact with the kernel using sysctl, instead of trying to dig directly into kmem. So, this is a more reliable method than it was in the past (2.x, early 3.x) where it would totally break if the kernel didn't use whatever memory structures that the utility expected. If the 4.1 kernel solves your problem (it probably will) then you should wait for a 4.1 cd and do a proper upgrade when you have the time and have gone over the documentation. Better yet, after you've decided how you want to handle the upgrade, try doing it on another machine first, unless this one is experimental. Paul Pruett [EMAIL PROTECTED] wrote: > I have received several assurances that > -current may have resolved some weirds > for i386 on amd64 processors... > > With hesitation I could try jumping to current > instead of stable amd64. > > I have used -current on productin before, > but only after verifying the ports could > make w/o fubars > > Either amd64 stable or i386 current > I'll still should remake the ports to match, > especially openldap and cyrus-imapd and > verify. :(
Re: same version upgrade i386 to amd64 gotchas?
Paul Pruett wrote: > I have received several assurances that > -current may have resolved some weirds > for i386 on amd64 processors... > > With hesitation I could try jumping to current > instead of stable amd64. > > I have used -current on productin before, > but only after verifying the ports could > make w/o fubars That's really not much of a test. The porting people do exactly that for you. If -current is broke in such a way that it can't build ports, they usually spot it. Use a package. > > Either amd64 stable or i386 current > I'll still should remake the ports to match, > especially openldap and cyrus-imapd and > verify. :( For reference, a machine I have managed to consistently demonstrate the i386-on-amd64 hang after less than ten minutes of "make build" has completed 158 (and counting) builds in a non-stop loop. I think -current will be much better for you than -release/stable. (one problem with this kind of testing: I'm not sure when to end it! :) At this point in the release cycle, if you have problems with -current, you are going to have problems with 4.1 unless you report them, so I'd suggest testing. :) Nick. (proud owner of his first amd64, which has been stuck running i386 code almost since assembly...) (damn. just about had a heart attack there as the build output stopped for a few seconds (in perl) after typing that...not used to seeing any pause in this thing's output! :)
Re: same version upgrade i386 to amd64 gotchas?
I have received several assurances that -current may have resolved some weirds for i386 on amd64 processors... With hesitation I could try jumping to current instead of stable amd64. I have used -current on productin before, but only after verifying the ports could make w/o fubars Either amd64 stable or i386 current I'll still should remake the ports to match, especially openldap and cyrus-imapd and verify. :(
Re: same version upgrade i386 to amd64 gotchas?
On 2007/02/27 17:03, Paul Pruett wrote: > After consideration and due to weird > problems afore discussed, I will likely be > upgrading an openbsd 4.0 i386 server to > an openbsd 4.0 amd64. A new i386 snapshot is very likely to fix this. > I have upgraded version on i386 and on amd64, > but never same version, different archtecture. It's not very fun. As well as ports, you have to take care of the boot loader; install an amd64 bsd.rd and boot loader from i386; reboot into the new bsd.rd and you can do an upgrade install from *.tgz. Not really recommended unless there's no alternative.
same version upgrade i386 to amd64 gotchas?
After consideration and due to weird
problems afore discussed, I will likely be
upgrading an openbsd 4.0 i386 server to
an openbsd 4.0 amd64.
Yes in retrospect I should have used the
amd64 build not the i386 build on an athlon64
cpu... But I now have a 'production '
cyrus-imapd/sendmail server that even after
make builds, changing motherboard, cpu, & memory still has a
random lockup w/ no kernel fault displayed
about once a week, ... and for that and
I would prefer to have amd64 go forward,
it is time to bite the bullet.
I have upgraded version on i386 and on amd64,
but never same version, different archtecture.
I would think that the 'etc' files would be
the same, but with cvs updated src, I do
plan on running mergemaster
again after the upgrade by cdrom.
A gotcha I'd expect would be the ports.
I also plan prior to upgrade to uninstall all
the port packages, then reinstall using
amd64 packages after.
other?
ps. I attached the dmesg for the headache
server, note it is running a sempron right now,
and the sempron like the athlon still hangs
randomly.
OpenBSD 4.0-stable (OPCA) #1: Sun Feb 11 18:00:48 EST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/OPCA
cpu0: AMD Sempron(tm) Processor 2800+ ("AuthenticAMD" 686-class, 128KB L2
cache) 1.61 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16
real mem = 468987904 (457996K)
avail mem = 419725312 (409888K)
using 4256 buffers containing 23552000 bytes (23000K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 10/31/06, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.3 @ 0xf0740 (50 entries)
bios0: ASUSTeK Computer INC. M2V-MX
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 3.0 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf73a0/272 (15 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x1106 product 0x3337
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #5 is the last bus
bios0: ROM list: 0xc/0x9200 0xc9800/0x2800!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 vendor "VIA", unknown product 0x0336 rev 0x00
pchb1 at pci0 dev 0 function 1 vendor "VIA", unknown product 0x1336 rev 0x00
pchb2 at pci0 dev 0 function 2 vendor "VIA", unknown product 0x2336 rev 0x00
pchb3 at pci0 dev 0 function 3 vendor "VIA", unknown product 0x3336 rev 0x00
pchb4 at pci0 dev 0 function 4 vendor "VIA", unknown product 0x4336 rev 0x00
vendor "VIA", unknown product 0x5336 (class system subclass interrupt, rev
0x00) at pci0 dev 0 function 5 not configured
pchb5 at pci0 dev 0 function 6 vendor "VIA", unknown product 0x6290 rev 0x00
pchb6 at pci0 dev 0 function 7 vendor "VIA", unknown product 0x7336 rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA K8HTB AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 vendor "VIA", unknown product 0x3230 rev 0x11:
aperture at 0xd000, size 0x1000
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 2 function 0 "VIA K8T890 PCI-PCI" rev 0x00
pci2 at ppb1 bus 2
ppb2 at pci0 dev 3 function 0 "VIA K8T890 PCI-PCI" rev 0x00
pci3 at ppb2 bus 3
pciide0 at pci3 dev 0 function 0 "JMicron JMB363 IDE/SATA" rev 0x02: DMA
(unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide0: using irq 11 for native-PCI interrupt
pciide0: channel 0 ignored (not responding; disabled or no drives?)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
pciide1 at pci0 dev 15 function 0 "VIA VT8237A SATA" rev 0x80: DMA
pciide1: using irq 5 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 305245MB, 625142448 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1 at pciide1 channel 1 drive 0:
wd1: 16-sector PIO, LBA48, 305245MB, 625142448 sectors
wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5
pciide2 at pci0 dev 15 function 1 "VIA VT82C571 IDE" rev 0x07: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide2 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom
removable
cd0(pciide2:0:0): using PIO mode 4, DMA mode 2
pciide2: channel 1 disabled (no drives)
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0xa0: irq 10
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0xa0: irq 5
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0xa0: irq 3
usb2 at uhci2: USB revisi
