[9fans] plan9 iso image
I've downloaded the plan9.iso image twice from http://plan9.bell-labs.com/plan9/download.html Once about two weeks ago, once today. Both times I extracted the plan9.iso.bz2 file to plan9.iso. Both times I burned the image to a cd, and both times the program(k3b) told me the image wasn't the same size as the header suggests?? Upon trying to boot off the cd I get this: boot from cd : PBSR...EI _ - blinking cursor I've waited, nothing else happens I hit enter, and my machine reboots back to the above boot from cd : message. Any ideas? Different download site? Any advice? Thanks in advance, Terry.
Re: [9fans] plan9 iso image
On Fri Jun 28 12:27:26 EDT 2013, silicon.pengui...@gmail.com wrote: I've downloaded the plan9.iso image twice from http://plan9.bell-labs.com/plan9/download.html Once about two weeks ago, once today. Both times I extracted the plan9.iso.bz2 file to plan9.iso. Both times I burned the image to a cd, and both times the program(k3b) told me the image wasn't the same size as the header suggests?? Upon trying to boot off the cd I get this: boot from cd : PBSR...EI _ - blinking cursor these are two, unrelated issues. the .iso size issue should not be a big deal. there appears to be some accounting that's off for cd-roms in the plan 9 iso burning software. (mk9660(8)). the new boot process can sometimes fail on new hardware. you might try the 9atom iso hget http://ftp.9atom.org/other/9atom.iso.bz2 this iso uses the traditional el-torito method. unfortunately, the installer is size-constrained (1.44MB) and doesn't support usb. while the image hget http://ftp.9atom.org/other/9atom.nboot.iso.bz2 has the new installer which uses bios to access the hard drive without el-torito emulation, and thus has no size constraints. while it does fail on more hardware, it does support usb during the install. the images http://ftp.9atom.org/other/+9atom.nboot.iso.bz2 http://ftp.9atom.org/other/+9atom.nboot.iso.bz2 are untested, and shouldn't be used unless you wish to verify they work. if you do, please let me know offlist what the results are. i keep forgetting to do this. - erik
Re: [9fans] plan9 iso image
On Jun 28, 2013, at 6:27 PM, Terry Wendt silicon.pengui...@gmail.com wrote: I've downloaded the plan9.iso image twice from http://plan9.bell-labs.com/plan9/download.html Once about two weeks ago, once today. Both times I extracted the plan9.iso.bz2 file to plan9.iso. Both times I burned the image to a cd, and both times the program(k3b) told me the image wasn't the same size as the header suggests?? I'm confused. Why is the burning software looking inside the iso?
Re: [9fans] plan9 iso image
these are two, unrelated issues. the .iso size issue should not be a big deal. there appears to be some accounting that's off for cd-roms in the plan 9 iso burning software. (mk9660(8)). Wouldn't surprise me, but it seems to work for me. If anyone has a more detailed explanation of what is wrong where, I'll take a look at it. this iso uses the traditional el-torito method. unfortunately, the installer is size-constrained (1.44MB) and doesn't support usb. while the image hget http://ftp.9atom.org/other/9atom.nboot.iso.bz2 has the new installer which uses bios to access the hard drive without el-torito emulation, and thus has no size constraints. while it does fail on more hardware, it does support usb during the install. I don't know much about how 9atom works, but the new plan 9 loader uses el-torito, but version 3 which lets you access the whole cd as an lba device. G.
Re: [9fans] plan9 iso image
Thank you for your response erik. The machine I'm trying to boot this on is an old dell inspiron 530. Processor - Intel Pentium Dual CPU E2140 @ 1.60 GHz Ram - 1 GB I just thought of something... The HD is on the primary cable, and a DVD and CD are on the secondary. The DVD drive is the device setup as a boot device in the BIOS. Anything? Not really, right? Can I use any of the 9atom images on this PC? Are they only for install, or can I use them as live CDs? I'm downloading: http://ftp.9atom.org/other/9atom.iso.bz2 http://ftp.9atom.org/other/9atom.nboot.iso.bz2 http://ftp.9atom.org/other/+9atom.nboot.iso.bz2 You included 2 links to that last one. I'll try burning one of each of these and let you know how the process goes. I might not get back to you until later... but I will get back. If you meant to include a forth link, resend and I'll grab a copy of that and do the same. Thanks, Terry.
Re: [9fans] plan9 iso image
The file has an actual size on the file system, but the files header tells the burning app that it has a different size. This is my guess only... Terry. On Fri, Jun 28, 2013 at 12:06 PM, Gorka Guardiola pau...@gmail.com wrote: On Jun 28, 2013, at 6:27 PM, Terry Wendt silicon.pengui...@gmail.com wrote: I've downloaded the plan9.iso image twice from http://plan9.bell-labs.com/plan9/download.html Once about two weeks ago, once today. Both times I extracted the plan9.iso.bz2 file to plan9.iso. Both times I burned the image to a cd, and both times the program(k3b) told me the image wasn't the same size as the header suggests?? I'm confused. Why is the burning software looking inside the iso?
Re: [9fans] plan9 iso image
Terry Wendt silicon.pengui...@gmail.com wrote: Thank you for your response erik. The machine I'm trying to boot this on is an old dell inspiron 530. 9front runs fine on my dell inspiron 530. i have to boot it with *acpi= in plan9.ini, though. pap
Re: [9fans] plan9 iso image
Wouldn't surprise me, but it seems to work for me. If anyone has a
more detailed explanation of what is wrong where, I'll take a look at
it.
we're now writing the nwa to disk. this calculation appears to be incorrect.
here's the check in cdfs:
/* reconcile differing nwas */
if (aux-mmcnwa != nwa) {
fprint(2, %s: nwa from drive %,ld != computed nwa %,ld\n,
argv0, aux-mmcnwa, nwa);
fprint(2, \tbe careful! assuming computed nwa\n);
/* the invisible track may still start at the old nwa. */
// aux-mmcnwa = nwa;
}
has the new installer which uses bios to access the hard drive
without el-torito emulation, and thus has no size constraints.
while it does fail on more hardware, it does support usb during the
install.
I don't know much about how 9atom works, but the new plan 9 loader
uses el-torito, but version 3 which lets you access the whole cd as an
lba device.
9atom uses either 9load (and pre version 3 el torito) or cinap's bios loader.
(this is the .nboot. version of the iso) the cd appears as a bios disk. this
is
likely el torito version 3 under the covers, but that's not the programming
interface.
you can look at the code online /n/atom/plan9/sys/src/cmd/boot/iplpxe/
- erik
Re: [9fans] plan9 iso image
On Fri, Jun 28, 2013 at 12:40:46PM -0400, erik quanstrom wrote: this iso uses the traditional el-torito method. unfortunately, the installer is size-constrained (1.44MB) and doesn't support usb. FWIW (I implemented El-Torito support for GRUB years ago), the image has to be some floppy size, and 2.88MB is perfectly supported. There is also hd emulation, but this it seems not to be widely supported by BIOSes. -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] plan9 iso image
On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom quans...@quanstro.netwrote:
Wouldn't surprise me, but it seems to work for me. If anyone has a
more detailed explanation of what is wrong where, I'll take a look at
it.
we're now writing the nwa to disk. this calculation appears to be
incorrect.
here's the check in cdfs:
/* reconcile differing nwas */
if (aux-mmcnwa != nwa) {
fprint(2, %s: nwa from drive %,ld != computed nwa %,ld\n,
argv0, aux-mmcnwa, nwa);
fprint(2, \tbe careful! assuming computed nwa\n);
/* the invisible track may still start at the old nwa. */
// aux-mmcnwa = nwa;
}
Maybe I am not understanding. We were talking about mkisofs which generates
an iso file.
This is cdfs check for the first writable block of the track, which has to
do with burning it.
An iso is burnt inside a track and is mostly independent from the details
of what tracks exist.
Terry downloaded the iso, and tried to burn it in linux. If something is
wrong it would be
in the iso file generated, which does not have to do anything with cdfs.
G.
[9fans] Tried 9atom.nboot.iso.bz2
This was a fail to boot. It actually gets to: Booting from CD: ... then reboots the pc goes through BIOS screen Booting from CD: ... over and over. Next I'll try the 9atom.iso.bz2 Foolish newbie question: I am supposed to unzip the image before burning it, right? Just making sure I'm not doing something and not letting you know. I sure that's the procedure, just being thorough. Thanks, Terry. pap: If you can give me a link to get 9front, I'll try that to. Thanks.
Re: [9fans] Tried 9atom.nboot.iso.bz2
Foolish newbie question: I am supposed to unzip the image before burning it, right? Just making sure I'm not doing something and not letting you know. I sure that's the procedure, just being thorough. bunzip the image before burning. :-) - erik
Re: [9fans] plan9 iso image
If its any help, when I select 9atom.nboot.iso within K3b to burn to
disc, it reports the filesize as 360.9 MB but the declared volume size
as 721.7 GB.
Interesting.
Terry.
On Fri, Jun 28, 2013 at 12:43 PM, Gorka Guardiola pau...@gmail.com wrote:
On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom quans...@quanstro.net
wrote:
Wouldn't surprise me, but it seems to work for me. If anyone has a
more detailed explanation of what is wrong where, I'll take a look at
it.
we're now writing the nwa to disk. this calculation appears to be
incorrect.
here's the check in cdfs:
/* reconcile differing nwas */
if (aux-mmcnwa != nwa) {
fprint(2, %s: nwa from drive %,ld != computed nwa
%,ld\n,
argv0, aux-mmcnwa, nwa);
fprint(2, \tbe careful! assuming computed nwa\n);
/* the invisible track may still start at the old nwa. */
// aux-mmcnwa = nwa;
}
Maybe I am not understanding. We were talking about mkisofs which generates
an iso file.
This is cdfs check for the first writable block of the track, which has to
do with burning it.
An iso is burnt inside a track and is mostly independent from the details of
what tracks exist.
Terry downloaded the iso, and tried to burn it in linux. If something is
wrong it would be
in the iso file generated, which does not have to do anything with cdfs.
G.
Re: [9fans] Tried 9atom.nboot.iso.bz2
I did, just wanted to make sure... I'm also writing the discs using DAO. Correct? I'm more or less following the same procedure I would for a linux distro. On Fri, Jun 28, 2013 at 12:48 PM, erik quanstrom quans...@labs.coraid.com wrote: Foolish newbie question: I am supposed to unzip the image before burning it, right? Just making sure I'm not doing something and not letting you know. I sure that's the procedure, just being thorough. bunzip the image before burning. :-) - erik
Re: [9fans] Tried 9atom.nboot.iso.bz2
On Fri Jun 28 13:57:37 EDT 2013, silicon.pengui...@gmail.com wrote: I did, just wanted to make sure... I'm also writing the discs using DAO. Correct? I'm more or less following the same procedure I would for a linux distro. that's right. - erik
Re: [9fans] Tried 9atom.nboot.iso.bz2
pap: If you can give me a link to get 9front, I'll try that to. Thanks. I am not pap (nor a suitable alternative), but you can get 9front at http://9front.org . Also has nice links to our wiki. -- Veety
Re: [9fans] plan9 iso image
On Fri, Jun 28, 2013 at 7:38 PM, tlaro...@polynum.com wrote: On Fri, Jun 28, 2013 at 12:40:46PM -0400, erik quanstrom wrote: this iso uses the traditional el-torito method. unfortunately, the installer is size-constrained (1.44MB) and doesn't support usb. FWIW (I implemented El-Torito support for GRUB years ago), the image has to be some floppy size, and 2.88MB is perfectly supported. There is also hd emulation, but this it seems not to be widely supported by BIOSes. There are various ways of booting with El-torito. http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf One of the ways is non-emulation (I thought it had appeared in a later version of El-torito, but checking the spec it was already in version 1, 1995), the byte 1 in page 19, description in page 16. Mkisofs lets you create a non-emulation bootable image (see /sys/src/cmd/disk/9660/boot.c:166, which is set with -B) or an emulation image. Emulation goes hand in hand with pbsraw.s. It used to be that many BIOSes did not support non-emu, but that has not been true AFAIK for a long while (at least more than 10 years). As long as you have the blocks 2M aligned you should be fine with most modern BIOSes. I think the problem is that the Plan 9 iso is somewhat different than k3b expects and it is fixing it, although as I said, the iso format is complex enough and has enough variants that there may be some error somewhere or the BIOS may have a bug... G.
Re: [9fans] plan9 iso image
generates an iso file. This is cdfs check for the first writable
block of the track, which has to do with burning it. An iso is burnt
inside a track and is mostly independent from the details of what
tracks exist. Terry downloaded the iso, and tried to burn it in
linux. If something is wrong it would be in the iso file generated,
which does not have to do anything with cdfs. G.
/sys/src/cmd/disk/9660/dump9660.c:316,326
if(mk9660){
/*
* Patch in root directories.
*/
setroot(cd, cd-iso9660pvd, iroot.block, iroot.length);
setvolsize(cd, cd-iso9660pvd, (vlong)cd-nextblock *
Blocksize);
if(cd-flags CDjoliet){
setroot(cd, cd-jolietsvd, jroot.block, jroot.length);
setvolsize(cd, cd-jolietsvd,
(vlong)cd-nextblock * Blocksize);
}
- erik
Re: [9fans] plan9 iso image
On Fri, Jun 28, 2013 at 8:13 PM, Gorka Guardiola pau...@gmail.com wrote: On Fri, Jun 28, 2013 at 7:38 PM, tlaro...@polynum.com wrote: On Fri, Jun 28, 2013 at 12:40:46PM -0400, erik quanstrom wrote: this iso uses the tradition Emulation goes hand in hand with pbsraw.s. I mean emulation goes hand in hand with pbs.s (emulated, inside the floppy) or pbsraw.s (non emulated, used by the cd itself for booting). G.
Re: [9fans] plan9 iso image
the blocks 2M aligned you should be fine with most modern BIOSes. I meant 2K aligned. On Fri, Jun 28, 2013 at 7:50 PM, Terry Wendt silicon.pengui...@gmail.com wrote: If its any help, when I select 9atom.nboot.iso within K3b to burn to disc, it reports the filesize as 360.9 MB but the declared volume size as 721.7 GB. This is very interesting because it is exactly double setvolsize(cd, cd-iso9660pvd, (vlong)cd-nextblock * Blocksize); Yes, the volume size is set here, but I don't see any at least obvious error. Everything seems to be counted rightly in 2K blocks. Are you pointing to an error? because I cannot see it... G.
Re: [9fans] plan9 iso image
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf page 19: Volume Space Size (BP 81 to 88) This field shall specify as a 32-bit number the number of Logical Blocks in which the Volume Space of the volume is recorded. This field shall be recorded according to 7.3.3.
Re: [9fans] plan9 iso image
On Fri, Jun 28, 2013 at 7:50 PM, Terry Wendt silicon.pengui...@gmail.com wrote: If its any help, when I select 9atom.nboot.iso within K3b to burn to disc, it reports the filesize as 360.9 MB but the declared volume size as 721.7 GB. This is very interesting because it is exactly double setvolsize(cd, cd-iso9660pvd, (vlong)cd-nextblock * Blocksize); Yes, the volume size is set here, but I don't see any at least obvious error. Everything seems to be counted rightly in 2K blocks. Are you pointing to an error? because I cannot see it... the original claim was, the size was not set by mk9660. i was showing where it is set. and yes, if this calculation is wrong, then here it is. perhaps volsize is in kb. :-) - erik
Re: [9fans] plan9 iso image
So... looking at the standard, the problem may be that the volume size is in bytes instead of in blocks? When I xd a plan 9 image (bytes are represented in little and big endian): 0008000 01434430 30310100 504c414e 20392042 0008010 4f4f5420 49534f39 36363020 20202020 0008020 20202020 20202020 504c414e 2039202d 0008030 204d4159 20372032 30313220 32333a32 0008040 33202020 20202020 0008050 00305600 00563000 ^^ ^^^ volume size in bytes (should this be in logical blocks?) 0008060 0008070 0101 0101 0008080 00080800 0a00 000a c60a ^ Block size, 2K 0008090 0ac7 2200c20a 00080a0 0ac20010 10007005 00080b0 07151737 0002 0101 01003956 The size of the iso given by ls is 5656576, 0x00565000 which is close enough to 0x563000 in bytes. I xd a 90M linux iso I have and got: 0008000 01434430 30310100 4c494e55 58202020 0008010 20202020 20202020 20202020 20202020 0008020 20202020 20202020 4344524f 4d202020 0008030 20202020 20202020 20202020 20202020 0008040 20202020 20202020 0008050 fdb3 b3fd ^ 90M/2K 0008060 0008070 0101 0101 0008080 00080800 0a00 000a 1400 ^ 2K block size 0008090 0016 22001800 00080a0 00180008 08006b05 00080b0 1808100a 2002 0101 01002020 So the size should be in Blocks and it is in bytes, this is why it is wrong. I don't understand why k3b reports double the size because it is much more. Unless I am not seeing something... G. On Fri, Jun 28, 2013 at 8:57 PM, Gorka Guardiola pau...@gmail.com wrote: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf page 19: Volume Space Size (BP 81 to 88) This field shall specify as a 32-bit number the number of Logical Blocks in which the Volume Space of the volume is recorded. This field shall be recorded according to 7.3.3. -- - curiosity sKilled the cat
Re: [9fans] plan9 iso image
So, the proposed change would be to take out the *Blocksize from the last parameter of setvolsize in the calls. Can someone test it with, say... k3b and see if it improves something? I still don't understand why it would report a *2 difference... G.
Re: [9fans] plan9 iso image
Agh, now I see it, I thought the units was the same, but it was actually 2K the difference. 360.9 MB but the declared volume size ^^^ as 721.7 GB. ^^^ So all is explained. Ok, I'll create a patch. G. On Fri, Jun 28, 2013 at 10:13 PM, Gorka Guardiola pau...@gmail.com wrote: So, the proposed change would be to take out the *Blocksize from the last parameter of setvolsize in the calls. Can someone test it with, say... k3b and see if it improves something? I still don't understand why it would report a *2 difference... G. -- - curiosity sKilled the cat
Re: [9fans] plan9 iso image
I created the patch mkisovolsize. G.
[9fans] plan9 iso image cont.
K3b actually said 721.7 GB. As in Gigabytes. So, I've downloaded, burned, and tried to install the following iso images: 9front-2688.28a9914426a3.iso (I used Brasero to burn the cd, no size complaints) +9atom.iso 9atom.iso 9atom.nboot.iso plan9.iso None actually booted, but some got farther then others. Results: plan9.iso - PBSR...EI as far as it got and froze 9atom.nboot.iso - circular reboot +9atom.iso - circular reboot 9atom.iso - booted from cd, got to choose option 2(boot from cd), these are the last few lines: ehci 0xe0001000: port3 didn't reset within 500ms; status 0x1101 ehci 0xe0001000: port4 didn't reset within 500ms; status 0x1101 usb/kb... usb/kb... root is from(il, tcp, local)[local!#S/sdD0/data]: cpu0: spurious interupt 39, last 11 I hit enter after about 3 minutes of no action... kfs...version...time... init: starting /bin/rc Nothing else ever happened, even after lots of key-presses. 9front.iso - never gave me an option to run from cd or install, it just started launching itself. Several screens of info and it stop on this line: bootargs is (tcp, il, local!device)[local!dev/sdD0/data] _ blinking cursor, doa! I burned all the iso images with K3b, with the exception of 9front. I used brasero for that and brasero did not complain about file size and volume size not matching. However, when I open 9front up in K3b, it does complain that the filesize is 530.9 MiB, while the volume size is reported as 1 TiB. Gorka - The reason I asked about whether or not I should be unzipping the iso is the plan9 install instruction have a line thus: boot from: sdC1!cdboot!9pcflop.gz I realize that's probably a floppy sized gzipped boot image on the cd, my question made me feel like a dolt, but I don't mind that too much. Anyway, next steps? Terry.
Re: [9fans] plan9 iso image cont.
Anyway, next steps? Terry. Hit enter at the 9front bootargs prompt.
Re: [9fans] plan9 iso image cont.
On Fri, 28 Jun 2013 16:26:51 CDT Terry Wendt silicon.pengui...@gmail.com wrote: K3b actually said 721.7 GB. As in Gigabytes. It really has no business looking into a .iso when all it is doing is copying it to a CD. On FreeBSD I can just do burncd -f /dev/acd0 data plan9.iso fixate ehci 0xe0001000: port3 didn't reset within 500ms; status 0x1101 ehci 0xe0001000: port4 didn't reset within 500ms; status 0x1101 usb/kb... usb/kb... root is from(il, tcp, local)[local!#S/sdD0/data]: cpu0: spurious interupt 39, last 11 I am guessing either some acpi related setting or a bad CD drive. I have not been lucky with CD drives. Especially on old laptops. One thing you can try to isolate the problem is to bring up plan9 from the cd in a virtual machine (qemu or virtual box or something).
Re: [9fans] plan9 iso image cont.
On Fri, Jun 28, 2013 at 11:26 PM, Terry Wendt silicon.pengui...@gmail.comwrote: K3b actually said 721.7 GB. As in Gigabytes. Yes, 720GB/360MB is 2K. The size complains are fixed by my patch. I can't generate an image now, but that problem should be fixed for the future. In any case, I don't think it affects the images you burnt with brasero at least. So, I've downloaded, burned, and tried to install the following iso images: 9front-2688.28a9914426a3.iso (I used Brasero to burn the cd, no size complaints) +9atom.iso 9atom.iso 9atom.nboot.iso plan9.iso None actually booted, but some got farther then others. Results: plan9.iso - PBSR...EI as far as it got and froze This is an error reported by the bios. This does not have to do with the other error. This has to do with something bad happening when the BIOS is accessing the drive. My guess is the BIOS is buggy, the cd is wrong (physically) or the reader is wrong, but it may be some bug interacting with the hardware. 9front.iso I don't know much about about 9atom or 9front, but they are quite different from plan9 in the way it boots. Other people are more qualified than me to answer questions about both. I burned all the iso images with K3b, with the exception of 9front. I used brasero for that and brasero did not complain about file size and volume size not matching. However, when I open 9front up in K3b, it does complain that the filesize is 530.9 MiB, while the volume size is reported as 1 TiB. This is again 1TB/530MB - 2K, so mkisofs is the most probable culprit, but again, this should not affect the booting. Gorka - The reason I asked about whether or not I should be unzipping the iso is the plan9 install instruction have a line thus: boot from: sdC1!cdboot!9pcflop.gz I realize that's probably a floppy sized gzipped boot image on the cd, This is the compressed kernel inside the image. Anyway, next steps? I would recommend either a virtual machine like Bakul says or, if possible change the CD drive. You could try also booting from USB, I don't know if there are any usb images laying around... G.
Re: [9fans] plan9 iso image cont.
I did that, nothing. I thought I might need to enter something, so I browsed the plan9 install instructions, then tried to enter something but no characters echoed. Terry. On Fri, Jun 28, 2013 at 6:01 PM, Matthew Veety mve...@gmail.com wrote: Anyway, next steps? Terry. Hit enter at the 9front bootargs prompt.
Re: [9fans] plan9 iso image cont.
I'm using GRUB2, and I have an empty primary partition. I'm thinking about using grub to install it. It's worth a shot! Thanks, Terry. On Fri, Jun 28, 2013 at 6:11 PM, Bakul Shah ba...@bitblocks.com wrote: On Fri, 28 Jun 2013 16:26:51 CDT Terry Wendt silicon.pengui...@gmail.com wrote: K3b actually said 721.7 GB. As in Gigabytes. It really has no business looking into a .iso when all it is doing is copying it to a CD. On FreeBSD I can just do burncd -f /dev/acd0 data plan9.iso fixate ehci 0xe0001000: port3 didn't reset within 500ms; status 0x1101 ehci 0xe0001000: port4 didn't reset within 500ms; status 0x1101 usb/kb... usb/kb... root is from(il, tcp, local)[local!#S/sdD0/data]: cpu0: spurious interupt 39, last 11 I am guessing either some acpi related setting or a bad CD drive. I have not been lucky with CD drives. Especially on old laptops. One thing you can try to isolate the problem is to bring up plan9 from the cd in a virtual machine (qemu or virtual box or something).
[9fans] plan9 iso image cont.
Anyway, next steps? I would recommend either a virtual machine like Bakul says or, if possible change the CD drive. You could try also booting from USB, I don't know if there are any usb images laying around... I'm starting to think maybe the dvd drive is buggy. I'll probably swap the cd and dvd. If that doesn't help, I'll try the grub install. Thanks again 9fans, Terry.
Re: [9fans] plan9 iso image cont.
It really has no business looking into a .iso when all it is doing is copying it to a CD. On FreeBSD I can just do burncd -f /dev/acd0 data plan9.iso fixate ehci 0xe0001000: port3 didn't reset within 500ms; status 0x1101 ehci 0xe0001000: port4 didn't reset within 500ms; status 0x1101 usb/kb... usb/kb... root is from(il, tcp, local)[local!#S/sdD0/data]: cpu0: spurious interupt 39, last 11 I am guessing either some acpi related setting or a bad CD drive. I have not been lucky with CD drives. Especially on old laptops. no that looks good. the spurious irq messages can be ignored. (sorry, though.) hit return and the install should continue. unless D0 (secondary master) drive isn't the one with the dvd drive. - erik
Re: [9fans] plan9 iso image cont.
did you enable *acpi= when booting 9front? see the section Boot at [1]. pap [1] http://code.google.com/p/plan9front/wiki/troubleshooting
Re: [9fans] plan9 iso image cont.
9front.iso - never gave me an option to run from cd or install, it just started launching itself. Several screens of info and it stop on this line: bootargs is (tcp, il, local!device)[local!dev/sdD0/data] _ blinking cursor, doa! Press enter. -sl
