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
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
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
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
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
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
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
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 */
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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
I created the patch mkisovolsize.
G.
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
Anyway, next steps?
Terry.
Hit enter at the 9front bootargs prompt.
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
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
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
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
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
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
did you enable *acpi= when booting 9front?
see the section Boot at [1].
pap
[1] http://code.google.com/p/plan9front/wiki/troubleshooting
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
36 matches
Mail list logo
