> 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] _
>
did you enable *acpi= when booting 9front?
see the section Boot at [1].
pap
[1] http://code.google.com/p/plan9front/wiki/troubleshooting
> 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; stat
> 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
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 wrote:
> On Fri, 28 Jun 2013 16:26:51 CDT Terry Wendt
> wrote:
>> K3b actually said 721.7 GB. As in Gigabytes.
>
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 wrote:
>
>> Anyway, next steps?
>> Terry.
>>
>
> Hit enter at the 9front boo
On Fri, Jun 28, 2013 at 11:26 PM, Terry Wendt
wrote:
> 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
On Fri, 28 Jun 2013 16:26:51 CDT Terry Wendt
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 re
> Anyway, next steps?
> Terry.
>
Hit enter at the 9front bootargs prompt.
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
I created the patch mkisovolsize.
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 w
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.
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
> On Fri, Jun 28, 2013 at 7:50 PM, Terry Wendt
> 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
>
> >>
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.
>
> 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
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
On Fri, Jun 28, 2013 at 8:13 PM, Gorka Guardiola wrote:
>
>
>
> On Fri, Jun 28, 2013 at 7:38 PM, 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 han
> 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 i
On Fri, Jun 28, 2013 at 7:38 PM, 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 f
> 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 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
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
wrote:
>> Foolish newbie question: I am supposed to unzip the image before
>> burning it, ri
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 wrote:
>
>
>
> On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom
> 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
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
On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom 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.
> her
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 s
> 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 */
Terry Wendt 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
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 wrote:
> On Jun 28, 2013, at 6:27 PM, Terry Wendt wrote:
>
>> I've downloaded the plan9.iso
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 devic
> 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 o
On Jun 28, 2013, at 6:27 PM, Terry Wendt 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
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 im
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
36 matches
Mail list logo
