X.org broken after changing resolution from Mac OS 9.2.2 (details and workaround enclosed)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After changing the resolution to 640x480 in Mac OS 9.2.2 and rebooting into OpenBSD, X.org was broken and the system required a hard reboot. However, after changing the resolution back to 1024x768 from Mac OS 9.2.2, X.org was able to work again. Thus, the workaround is to ensure the resolution is set to 1024x768 before shutting down Mac OS 9.2.2. Below are the xorg.conf and dmesg. # This is a sample xorg.conf. All sections are commented out, but may # be uncommented in order to enable them. You'll almost definitely # need to edit the values given here to suit your own system. # # It is not recommended to uncomment any more than is necessary, as # the server will choose good defaults in most cases. Thus, your # xorg.conf should only be used to override the server when those # defaults are incorrect for your system. # # For full documentation see xorg.conf(5) # Section "Files" # FontPath "/usr/share/fonts/X11/100dpi" # FontPath "/usr/share/fonts/X11/75dpi" # FontPath "/usr/share/fonts/X11/cyrillic" # FontPath "/usr/share/fonts/X11/misc" # FontPath "/usr/share/fonts/Type1" # ModulePath "/usr/lib/xorg/modules" # EndSection # Section "ServerFlags" # Option "DontZap" "False" # Option "DefaultServerLayout" "Layout" # Option "AllowMouseOpenFail" "False" # Option "AllowEmptyInput" "True" # Option "AutoAddDevices" "True" # EndSection # Section "Module" # Load "glx" # EndSection # Section "Extensions" # Option"Composite" "Enable" # EndSection Section "InputDevice" Identifier "Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "Protocol" "standard" Option "XkbRules" "xorg" Option "XkbModel" "macintosh" Option "XkbLayout" "us" Option "XkbOptions""grp:win_switch" EndSection Section "InputDevice" Identifier "Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/wsmouse" Option "Protocol" "wsmouse" EndSection Section "Device" Identifier "Video Card" Driver "ati" VendorName "ATI" BoardName "Radeon Mobility M7" # Option"AccelMethod" "EXA" # Option"Monitor-LVDS" "Monitor1" # Option"Monitor-VGA" "Monitor2" EndSection # Section "Device" # Identifier"Internal Graphics Card We Disable" # Option"Ignore" "true" # BusID "PCI:1:0:0" # EndSection # Section "Monitor" # Identifier"Monitor2" # DisplaySize 304 228 # EndSection Section "Monitor" Identifier "Monitor1" # HorizSync 24-82 # VertRefresh 55-77 # Option"RightOf" "Monitor1" EndSection Section "Screen" Identifier "Screen" Device "Video Card" Monitor"Monitor" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" EndSubSection Subsection "Display" Depth 8 Modes "1024x768" "800x600" "640x480" EndSubSection EndSection # Section "ServerLayout" # Identifier"Layout" # Screen"Screen" # InputDevice "Keyboard" # InputDevice "Mouse" # EndSection [ using 479780 bytes of bsd ELF symbol table ] console out [ATY,Bee_A]console in [keyboard] , using ADB using parent ATY,BeeParent:: memaddr 9800 size 800, : consaddr 9c008000, : ioaddr 9002, size 2: memtag 8000, iotag 8000: width 1024 linebytes 1024 height 768 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2011 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.9 (GENERIC) #48: Wed Mar 2 07:02:32 MST 2011 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 671088640 (640MB) avail mem = 636690432 (607MB) mainbus0 at root: model PowerBook4,3 cpu0 at mainbus0: 750FX (Revision 0x203): 900 MHz: 512KB L2 cache mem0 at mainbus0 spdmem0 at mem0: no EEPROM found spdmem1 at mem0: 512MB SDRAM non-parity PC133CL2 memc0 at mainbus0: uni-n kiic0 at memc0 offset 0xf8001000 iic0 at kiic0 admtmp0 at iic0 addr 0xac mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple Pangea AGP" rev 0x00 vgafb0 at pci0 dev 16 function 0 "ATI Radeon Mobility M7" rev 0x00, mmio wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation) mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x0 pci1 at mpcpcibr1 bus 0 pchb1 at pci1 d
Re: Obsolescence engineering (was: vmmap: bad software everywhere)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 01 Jun 2011 04:42:02 + annathemerm...@hush.com wrote: >On 31 May 2011 19:51, Otto Moerbeek wrote: >> On Tue, May 31, 2011 at 07:23:46PM +, Christian Weisgerber >wrote: >> >>> Marc Espie wrote: >>> >>> > Not surprisingly, a lot of software that claims to be 64 bits- > >ready isn't. >>> > This touches all web navigators, most jit engines, and >probably lots more >>> > of software (our ports tree version of gnu-grep, for >instance). >>> >>> I don't think a lot suffers from it, but some prominent cases >do. >>> Three problems have been mentioned: >>> >>> (1) Truncation of pointers to 32 bits. Our malloc(3) has >returned >>> addresses >4 GB for some time now on amd64 (and before that >on >>> other archs like alpha), so I don't expect any new fallout >>> there. I seem to remember that we had a rash of ports >fixes >>> back when this first happened on amd64. >>> >>> (2) Tagged pointers. A tagged pointer is when you "know" that >not >>> all the bits in a pointer are used to generate an address >and >>> you squeeze some other data into the "spare" bits. This >blocks >>> newer versions of Firefox on sparc64. Mozilla's new >JavaScript >>> engine uses tagged pointers and those "unused" address bits >on >>> x86 are actually used on sparc64. >>> >>> (3) The expectation that, no matter what their absolute >address, >the >>> relative offsets between all your pieces of data fit into >32 >>> bits, i.e., all data is within a 4 GB window. That sounds >like >>> a bizarre requirement, but apparently some JIT engines are >>> "optimized" to rely on this. These are the cases that >break >>> with new vmmap. >> >> The smart programmers "solve" number (3) by allocating 2G of >memory in >> advance to store their jit compiled code, so their code can use >32 bit >> relative offsets. They say, hey, it's only virtual memory, so it >> doesn't take much resources. Often that is true and it seems a >smart >> idea, but it has the consequence that you lose randomization and >> protected memory with page size granularity. Or you are forced >to >do >> all the memory mangement on your own, basically rewriting the >memory >> management part of the OS in your browser. Suddenly the smart >idea >> does not sound so smart anymore. >> >>-Otto >> >>> >>> But, hey, 64-bit desktop machines have only been around since >1993 >>> or so, and I guess some of the Mozilla programmers weren't born >yet >>> when we watched oh-so-clever tagged pointer use blow up at, >say, >>> the Motorola 68000 to 68020 transition some 25 years ago. >>> >>> -- >>> Christian "naddy" Weisgerber >na...@mips.inka.de > >Great. Just absolutely fantastic. These people come up with more >and more resource intensive ways of doing the same old computing >tasks we've been able to do for a decade or more so that the rest >of us have to buy newer, fancier, more expensive machines to do >the >same things we've been able to do for a decade or more. > >Of course, for a significant portion of the population, "high >performance computing" means "a computer I can access from the >convenience of my home, rather than having to spend an hour >walking >to the library and an hour walking back just so I can sign up and >wait an hour or two for the chance to use it for 30 minutes and >then rush to do the important things, like fill out job >applications for blue collar positions for companies who can't be >bothered to take paper applications or check to see if I have any >important business e-mail from people who are too annoying to send >old-fashioned snail mail". > >For a lot of people, a computer is like a glorified communications >device and typewriter. Except a whole lot more expensive. > >Hence the usefulness of old computers. When everyone else is >rushing to get the latest and greatest, it's often possible to get >a sufficiently aged computer for very cheap or even free. > >Of course, the big corporations don't make as much money if people >do that. Which probably explains at least some of the bad >software. >If we make this new software resource intensive and inefficient >enough, then people will have to buy newer, more expensive >computers in order to run it. But the older software works just >fine? Then we'll just have to stop releasing security patches for >it. Good thing we didn't write solid, secure code to begin with. >Now the hackers (or crackers, or whatever the correct term is) out >there will force the laggards to upgrade to newer more expensive >hardware than runs newer more expensive more inefficient software >than we still support, and the computer industry goes on! Yay >hackers! > >Well, I can understand that line from corporations looking to earn >money, but it makes less sense to hear it from not-for-profits >like >Linux or Firefox. > >They say we should all upgrade our computers after three years, >five years if we want to push it. What they seem
Obsolescence engineering (was: vmmap: bad software everywhere)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31 May 2011 19:51, Otto Moerbeek wrote: > On Tue, May 31, 2011 at 07:23:46PM +, Christian Weisgerber wrote: > >> Marc Espie wrote: >> >> > Not surprisingly, a lot of software that claims to be 64 bits- ready isn't. >> > This touches all web navigators, most jit engines, and probably lots more >> > of software (our ports tree version of gnu-grep, for instance). >> >> I don't think a lot suffers from it, but some prominent cases do. >> Three problems have been mentioned: >> >> (1) Truncation of pointers to 32 bits. Our malloc(3) has returned >> addresses >4 GB for some time now on amd64 (and before that on >> other archs like alpha), so I don't expect any new fallout >> there. I seem to remember that we had a rash of ports fixes >> back when this first happened on amd64. >> >> (2) Tagged pointers. A tagged pointer is when you "know" that not >> all the bits in a pointer are used to generate an address and >> you squeeze some other data into the "spare" bits. This blocks >> newer versions of Firefox on sparc64. Mozilla's new JavaScript >> engine uses tagged pointers and those "unused" address bits on >> x86 are actually used on sparc64. >> >> (3) The expectation that, no matter what their absolute address, the >> relative offsets between all your pieces of data fit into 32 >> bits, i.e., all data is within a 4 GB window. That sounds like >> a bizarre requirement, but apparently some JIT engines are >> "optimized" to rely on this. These are the cases that break >> with new vmmap. > > The smart programmers "solve" number (3) by allocating 2G of memory in > advance to store their jit compiled code, so their code can use 32 bit > relative offsets. They say, hey, it's only virtual memory, so it > doesn't take much resources. Often that is true and it seems a smart > idea, but it has the consequence that you lose randomization and > protected memory with page size granularity. Or you are forced to do > all the memory mangement on your own, basically rewriting the memory > management part of the OS in your browser. Suddenly the smart idea > does not sound so smart anymore. > >-Otto > >> >> But, hey, 64-bit desktop machines have only been around since 1993 >> or so, and I guess some of the Mozilla programmers weren't born yet >> when we watched oh-so-clever tagged pointer use blow up at, say, >> the Motorola 68000 to 68020 transition some 25 years ago. >> >> -- >> Christian "naddy" Weisgerber na...@mips.inka.de Great. Just absolutely fantastic. These people come up with more and more resource intensive ways of doing the same old computing tasks we've been able to do for a decade or more so that the rest of us have to buy newer, fancier, more expensive machines to do the same things we've been able to do for a decade or more. Of course, for a significant portion of the population, "high performance computing" means "a computer I can access from the convenience of my home, rather than having to spend an hour walking to the library and an hour walking back just so I can sign up and wait an hour or two for the chance to use it for 30 minutes and then rush to do the important things, like fill out job applications for blue collar positions for companies who can't be bothered to take paper applications or check to see if I have any important business e-mail from people who are too annoying to send old-fashioned snail mail". For a lot of people, a computer is like a glorified communications device and typewriter. Except a whole lot more expensive. Hence the usefulness of old computers. When everyone else is rushing to get the latest and greatest, it's often possible to get a sufficiently aged computer for very cheap or even free. Of course, the big corporations don't make as much money if people do that. Which probably explains at least some of the bad software. If we make this new software resource intensive and inefficient enough, then people will have to buy newer, more expensive computers in order to run it. But the older software works just fine? Then we'll just have to stop releasing security patches for it. Good thing we didn't write solid, secure code to begin with. Now the hackers (or crackers, or whatever the correct term is) out there will force the laggards to upgrade to newer more expensive hardware than runs newer more expensive more inefficient software than we still support, and the computer industry goes on! Yay hackers! Well, I can understand that line from corporations looking to earn money, but it makes less sense to hear it from not-for-profits like Linux or Firefox. They say we should all upgrade our computers after three years, five years if we want to push it. What they seem to have missed is that it is a recession. A really bad recession. Goodbye art shows! Hello tent cities! Welcome to the most dangerous town in California: stop laying off cops! And that sort of thin
Asking whether or not to start X.org at boot time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have changed /etc/rc to ask me at boot time whether I want to
start xdm, gdm, or a console. (Adding kdm presumably wouldn't be
too hard.) This is because OpenBSD/powerpc apparently does not
support multiple wsdisplays, hence it is not possible to run X.org
and a console at the same time. However, I do not always want
X.org. Often, I'd much rather have a console. Unfortunately, X.org
doesn't work quite right if started from the console; the keyboard
is all screwed up. This script allows me to pick at boot time
whether I want to run X.org or a console.
Entering x or xdm will start xdm. Entering g or gdm will start gdm.
Anything else will start a console.
I do not believe my script is quite right. If I start gdm or a
console, there's an error at shutdown about rc being exited
abnormally. Also, the login console will ask what terminal type
after login. Entering vt220 works. Nevertheless, I hope someone
else will find this useful.
Here are the original lines:
# Alternatively, on some architectures, xdm may be started in
/etc/ttys.
if [ X"${xdm_flags}" != X"NO" -a -x /usr/X11R6/bin/xdm ]; then
echo 'starting xdm...'; /usr/X11R6/bin/xdm
${xdm_flags}
fi
Here are my new lines:
# Alternatively, on some architectures, xdm may be started in
/etc/ttys.
if [ X"${xdm_flags}" != X"NO" -a -x /usr/X11R6/bin/xdm ]; then
echo -n "Do you wish to run (x)dm, (g)dm, or a (c)onsole?\n"
read GRAPHICAL
if [ $GRAPHICAL = "x" ] || [ $GRAPHICAL = "xdm" ] ; then
echo 'starting xdm...'; /usr/X11R6/bin/xdm
${xdm_flags}
else
if [ $GRAPHICAL = "g" ] || [ $GRAPHICAL = "gdm" ] ;
then
echo 'starting gdm...';
/usr/local/sbin/gdm -nodaemon
else
/usr/libexec/getty std.9600
fi
fi
fi
-BEGIN PGP SIGNATURE-
Charset: UTF8
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 3.0
wsBcBAEBAgAGBQJN5QPwAAoJEKlMTST7VF+o98UH/jCub4rdNe3920D/CwW/ovUv8VE6
/oL93KC9IuVYqSuTABggU6cSMpIV6A1trKZOg+rOldXmZFpGizpxYvj1ASRz7oJ3KitT
N7QKaQzrs1UsSYRKuZiSGXm26M25zX7Zro1qmDC81gnzPUqdIanQsoYHsRanulipqL6Q
pHqviCuDIWXBCOascC20p9f8tr/Ky6bhNpQU5P2sFQk6euXuguS0F7QYI2rS/PrNWx8V
7odtlG/9zsHLJQtM0/RcbSVtbvJyDdzQEbUsIMNDh/JWkGAyMRlZD3yLRM+KtZuvbRy4
ExwObCWp9QzSKvtyzii7IwDOzZdk7168grjPE0ryeVY=
=Omkt
-END PGP SIGNATURE-
Re: mount:mfs: mmap: Cannot allocate memory
Kevin Chadwick wrote: >On Wed, 18 May 2011 17:41:32 + >annathemerm...@hush.com wrote: > >> I'm just trying to make it take advantage of the swap >> encryption (random keys unlike a single key I have to remember the >> password for); > >bioctl or vnconfig and /dev/urandom maybe useful here So you are suggesting I create a boot-time script to do the following every time my computer starts: 1. Create a softraid or svnd encrypted partition with a key from /dev/urandom (without overwriting existing data) 2. Open it. 3. Create a new ffs filesystem on it. 4. Mount the new ffs filesystem, async most likely. Well, it's a horribly convoluted idea, not at all elegant like an mfs or a tmpfs, but if one doesn't mind the long boot time while OpenBSD creates the new ffs filesystem, it ought to work. Stuart Henderson wrote: >On 2011-05-18, annathemerm...@hush.com wrote: >>> In -current it has been bumped to 2GB so you'll be able to use >>> more there. >> >> A bit below, but now it works. I'm quite happy with stable. Unless >> current fixes my X11 keyboard issues, I'd rather not deal with >> current unless I have a second hard disk to play with. I suppose if >> I ever temporarily need more space in /tmp I'll just have to set up >> a softlink to /var/tmp or somewhere. >> >> However, is there any way to get mfs to use swap first rather than >> memory first? > >I don't think so. (And afaik mfs doesn't give memory back once >you've used it, at least without umounting). Oh well. Stuart Henderson wrote: >>If I tell xorg.conf to use kbd >> or akbd, it doens't work at all, but if I tell it to use keyboard, >> sometimes it randomly decides not to notice that I've pressed >> certain keys, and is particularly reluctant to recognize the >> backspace key. Sometimes, it becomes convinced I am holding a key >> down even when I am not: this is particularly annoying when it >> thinks I'm holding the down arrow key. None of these issues occur >> when not running X.org. > >This sounds rather like the behaviour you get when you need to >disable /dev/ttyC0 (see /usr/X11R6/README). It states: "The wsfb driver uses whatever graphics mode the console is set to (by Mac OS) as a dumb unaccelerated framebuffer in 8 bits per pixel. You should be able to use 'startx' or xdm to start X without further configuration. "To use xdm from rc.conf, it is necessary to disable /dev/ttyC0 in /etc/ttys, change the 'status' of /dev/ttyC0 to 'off'." I don't want to use xdm from rc.conf. I want to start it from the console on an as-needed basis. I don't actually like X.org. I find it annoying and bloated, but nonetheless, a necessary evil. Thus, I don't want it to start when my computer starts: I want to call on it when I have need of graphical programs.
Re: mount:mfs: mmap: Cannot allocate memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3 May 2011 21:25, Stuart Henderson wrote: > On 2011-05-03, annathemerm...@hush.com wrote: >> >> So, I'm trying to create put my /tmp partition on my swap. >> >> So I have a line like this in my fstab: >> swap /tmp mfs rw,nodev,nosuid,-s=2097152 >> I also tried changing swap to /dev/wd0b, and changing the n in - s=n >> to smaller numbers. > > [assuming this is still macppc] > > 2097152 x 512 (bytes per sector) = 1GB > > Up to OpenBSD 4.9, MAXDSIZ on macppc is 512MB so you will be > limited to -s=1048576 or slightly below. > > In -current it has been bumped to 2GB so you'll be able to use > more there. A bit below, but now it works. I'm quite happy with stable. Unless current fixes my X11 keyboard issues, I'd rather not deal with current unless I have a second hard disk to play with. I suppose if I ever temporarily need more space in /tmp I'll just have to set up a softlink to /var/tmp or somewhere. However, is there any way to get mfs to use swap first rather than memory first? I'm just trying to make it take advantage of the swap encryption (random keys unlike a single key I have to remember the password for); I don't really need speed improvements and certain excessively bloated applications like Firefox and Gimp, which I might occasionally want to run, could really use the memory. >> Also, is there any way to switch consoles? On i386 it was >> Ctrl+Alt+F2, Ctrl+Alt+F3, and so on (in fact I think the Ctrl was >> optional unless leaving X11), but it doesn't seem to work on >> macppc, even with the Fn key held down too. > > No separate consoles, you will need to use tmux or similar > (or X of course). tmux works fine. Not as convenient as separate consoles, but it does the job. And, with one tmux terminal displaying the output of pdisk and another running disklabel, I was able to manually tell disklabel where the Linux partitions were so OpenBSD and Linux could share swap and ext2/3 home. For some reason, OpenBSD did not seem able to find the Linux partitions automatically like it could on x86, even when I tried re-installing OpenBSD after Debian. Unfortunately, once I start X11, I don't know how to get out, short of rebooting the computer. This is very inconvenient when X crashes, or I can't click the exit button in fvwm because the faulty keyboard driver things I'm holding down the arrow down key even though I'm not. For the record, X seems to crash in framebuffer mode, but not in ati/radeon accelerated mode. In framebuffer mode, even running some xterm program, like top, might kill it, although it seems more likely to die on me if Firefox is running. Changing the driver seemed to fix mouse issues. (Whatever it had by default, sometimes I would lose control of the cursor and it would go toward the bottom of the screen.) I haven't figured out the right driver for the keyboard. If I tell xorg.conf to use kbd or akbd, it doens't work at all, but if I tell it to use keyboard, sometimes it randomly decides not to notice that I've pressed certain keys, and is particularly reluctant to recognize the backspace key. Sometimes, it becomes convinced I am holding a key down even when I am not: this is particularly annoying when it thinks I'm holding the down arrow key. None of these issues occur when not running X.org. Running X -configure crashes the system, and not even Ctrl+C or Ctrl+Z was able to uncrash it, so the configuration had to be done manually. -BEGIN PGP SIGNATURE- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wsBcBAEBAgAGBQJN1ATLAAoJEKlMTST7VF+omA0H/iRSQ3inWMcin+0d9nB9odznLVTD nh73vTCqSFpNJSaeu4hW4mJENlzbBA9C2ioy5vg1XKjxTeqXFIl2QHLiCrdGLBEB/C36 bBQd+3WKbisRzpeJOTRh7Oaqo1fEmSPdEOo2a3vlHqWDo1kUgp3maguHlzSHZN+4L0IG Biuh7bN5jwPAgV7WM5Ne3fQPNM02kS6mP7gw/WJQP1XY6C5H0u+MqHjGNl80X+tKtZuy b5owR2k5RbciOOK+pZ10t2fcWCumd4rtPMlmI4KsG09IP60Vffmf8ve5WAGOyzcxlZmy W2zhCEc7Poi/ub7OaxftN829eQSNIBXeF/zwvoObPi0= =WPkG -END PGP SIGNATURE-
mount:mfs: mmap: Cannot allocate memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So, I'm trying to create put my /tmp partition on my swap. So I have a line like this in my fstab: swap /tmp mfs rw,nodev,nosuid,-s=2097152 I also tried changing swap to /dev/wd0b, and changing the n in -s=n to smaller numbers. Anyway, mount /tmp returns: mount_mfs: mmap: Cannot allocate memory. swapctl says neither of my swap partitions are being used. Computer is a PowerPC, G3 iBook. Also, is there any way to switch consoles? On i386 it was Ctrl+Alt+F2, Ctrl+Alt+F3, and so on (in fact I think the Ctrl was optional unless leaving X11), but it doesn't seem to work on macppc, even with the Fn key held down too. -BEGIN PGP SIGNATURE- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wsBcBAEBAgAGBQJNwGKoAAoJEKlMTST7VF+oVUAIAJ9u57uLGR9zvfQzYXPWavKJ1W9a YPsewbGtW+3iSbG2Ec4gMqqEPSzdUZ9NBW9yzaWhr1uYiwqVvOVTFQyR73Uq5Lwpmla/ dgPrX7x7cXwueRqFEYwxB//znGyIWOXDyl1qCHSf158f7JC/DGyTgnTjd3jByfuIyfxF MJeJGXpms0B4j4wt23YwaIwhOnSUwv6fBjd9CAdapfYLgT9n462/5uF9Ml90gDE+kIsj 45KY78YKhRnj7HZJl0sh7gMGGlSTNKbeh25upyLHwgZG5pl9wF9t/VBhTMYlialmD2+A eVwo/zmWdxXjN3zumtZXudxsGf1xxfcHyHfKMknaBJI= =nIdn -END PGP SIGNATURE-
Re: boot wd0:,ofwboot /bsd boots into... Mac OS 9.2.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After reading the excellent NetBSD documentation, I realized that the problem was dyslexic in nature. OpenBSD's ofwboot does in fact work correctly on my computer. However, the NetBSD documentation is very excellent. http://netbsd.gw.com/cgi-bin/man-cgi?ofwboot+8.macppc+NetBSD-current http://www.netbsd.org/ports/macppc/faq.html#boot-trouble On Tue, 03 May 2011 07:48:23 -0400 annathemerm...@hush.com wrote: >So, finished installing OpenBSD 4.9 the other day on a recently >acquired old iBook. It all went very well, right up until the >point >where I tried to boot my new OpenBSD system up. In Open Firmware, >I >had to play around with the device name to find something that >didn't give an error, and when I finally did, it booted into... >Mac >OS 9.2.2! Tada! Not really. It was actually very anti-climatic. > >Then I tried installing a small Debian partition, hoping that >maybe >OpenBSD would do better at booting via yaboot than via Open >Firmware, but, no luck: Debian won't even install. It complains >that either there is no Apple Bootstrap partition or else it is >the >wrong size. I'm not sure what to do about that. Wasn't Mac OS X >supposed to install any necessary Apple Bootrap partitions? If it >didn't, what can I do? The Mac OS X installer's partitioning tool >really isn't that powerful. > >Why should ofwboot take me to Mac OS 9.2.2? And what's this Apple >Bootstrap partition Debian is complaining about? -BEGIN PGP SIGNATURE- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wsBcBAEBAgAGBQJNwGCvAAoJEKlMTST7VF+oRZEIALcFqhyCL+hjoHviZpN8t+VU07RV uC3NbOjbnD1L9y2ScmblHv7II5K/kcn6gZm40kMd5Pcn237lYz3QglVGko8JSm/EfZCj oabTY6PMy37Gn7a0IDG/fZgQI6DQDhcanTKAPKljI89zsJ1nq5bCSLRstU83GYVAniGa Zlh7sKiVfk0PjfWgn33PQKXe8ATCkjE7jCjS6mBaK+URfWm2Eg9pu+odqhK3PmYNaTo/ uYw5LeSUmwDWsHIr8gSMi+xj9EmppyluuVIGTZtD5qu6sjqNgVowOByfd/e1HhVJMUdV jTVxpfZAF8FSUZ74EwhIUfp4+730Gsl+tauPjuLOmkA= =Ca/H -END PGP SIGNATURE-
boot wd0:,ofwboot /bsd boots into... Mac OS 9.2.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So, finished installing OpenBSD 4.9 the other day on a recently acquired old iBook. It all went very well, right up until the point where I tried to boot my new OpenBSD system up. In Open Firmware, I had to play around with the device name to find something that didn't give an error, and when I finally did, it booted into... Mac OS 9.2.2! Tada! Not really. It was actually very anti-climatic. Then I tried installing a small Debian partition, hoping that maybe OpenBSD would do better at booting via yaboot than via Open Firmware, but, no luck: Debian won't even install. It complains that either there is no Apple Bootstrap partition or else it is the wrong size. I'm not sure what to do about that. Wasn't Mac OS X supposed to install any necessary Apple Bootrap partitions? If it didn't, what can I do? The Mac OS X installer's partitioning tool really isn't that powerful. Why should ofwboot take me to Mac OS 9.2.2? And what's this Apple Bootstrap partition Debian is complaining about? -BEGIN PGP SIGNATURE- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wsBcBAEBAgAGBQJNv+uHAAoJEKlMTST7VF+o/cYIALZPDztm9OfPLHfjZF+zfsv0oC8K XIPQzHWvWF/3im8G3uUhhk3UH0vRUckBj5mwcNT0KIgIEAL5YtKeFz8P0JSki1DPeRQi Olgkbxt+uXJYRS0mEzbSFtdo4d+9li64HQrBU9TvMDDmahXX7jK+Zkfe5g99aY202QFG /YQV86zHV2GvX8kx4HYImV0eBLoW8yvS/FfXkRxLtjBaqnKAku23TxrNiAXgrni+EG4m mS5t6KTi3gIbGLfBHWIzWCzVDHAjWSQNTqb7GnWtVlD6FODgxWgph4gbhrhD3ogghi2J XR4YDmz6Ju0yS4ZtYhV9mDUl0fZ4jRxU+E02Wgy1+zI= =sMUO -END PGP SIGNATURE-
