* [9fans] plan9 iso image @ 2013-06-28 16:27 Terry Wendt 2013-06-28 16:40 ` erik quanstrom 2013-06-28 17:06 ` Gorka Guardiola 0 siblings, 2 replies; 21+ messages in thread From: Terry Wendt @ 2013-06-28 16:27 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 16:27 [9fans] plan9 iso image Terry Wendt @ 2013-06-28 16:40 ` erik quanstrom 2013-06-28 17:12 ` Terry Wendt ` (2 more replies) 2013-06-28 17:06 ` Gorka Guardiola 1 sibling, 3 replies; 21+ messages in thread From: erik quanstrom @ 2013-06-28 16:40 UTC (permalink / raw) To: 9fans On Fri Jun 28 12:27:26 EDT 2013, silicon.penguin67@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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 16:40 ` erik quanstrom @ 2013-06-28 17:12 ` Terry Wendt 2013-06-28 17:17 ` Paul A. Patience 2013-06-28 17:12 ` Gorka Guardiola 2013-06-28 17:38 ` tlaronde 2 siblings, 1 reply; 21+ messages in thread From: Terry Wendt @ 2013-06-28 17:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 17:12 ` Terry Wendt @ 2013-06-28 17:17 ` Paul A. Patience 0 siblings, 0 replies; 21+ messages in thread From: Paul A. Patience @ 2013-06-28 17:17 UTC (permalink / raw) To: 9fans Terry Wendt <silicon.penguin67@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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 16:40 ` erik quanstrom 2013-06-28 17:12 ` Terry Wendt @ 2013-06-28 17:12 ` Gorka Guardiola 2013-06-28 17:19 ` erik quanstrom 2013-06-28 17:38 ` tlaronde 2 siblings, 1 reply; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 17:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 17:12 ` Gorka Guardiola @ 2013-06-28 17:19 ` erik quanstrom 2013-06-28 17:43 ` Gorka Guardiola 0 siblings, 1 reply; 21+ messages in thread From: erik quanstrom @ 2013-06-28 17:19 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 17:19 ` erik quanstrom @ 2013-06-28 17:43 ` Gorka Guardiola 2013-06-28 17:50 ` Terry Wendt 2013-06-28 18:13 ` erik quanstrom 0 siblings, 2 replies; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 17:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1234 bytes --] On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom <quanstro@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. [-- Attachment #2: Type: text/html, Size: 1804 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 17:43 ` Gorka Guardiola @ 2013-06-28 17:50 ` Terry Wendt 2013-06-28 18:13 ` erik quanstrom 1 sibling, 0 replies; 21+ messages in thread From: Terry Wendt @ 2013-06-28 17:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <paurea@gmail.com> wrote: > > > > On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom <quanstro@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. > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 17:43 ` Gorka Guardiola 2013-06-28 17:50 ` Terry Wendt @ 2013-06-28 18:13 ` erik quanstrom 1 sibling, 0 replies; 21+ messages in thread From: erik quanstrom @ 2013-06-28 18:13 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 16:40 ` erik quanstrom 2013-06-28 17:12 ` Terry Wendt 2013-06-28 17:12 ` Gorka Guardiola @ 2013-06-28 17:38 ` tlaronde 2013-06-28 18:13 ` Gorka Guardiola 2 siblings, 1 reply; 21+ messages in thread From: tlaronde @ 2013-06-28 17:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 17:38 ` tlaronde @ 2013-06-28 18:13 ` Gorka Guardiola 2013-06-28 18:16 ` Gorka Guardiola 2013-06-28 18:41 ` Gorka Guardiola 0 siblings, 2 replies; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 18:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1541 bytes --] On Fri, Jun 28, 2013 at 7:38 PM, <tlaronde@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. [-- Attachment #2: Type: text/html, Size: 2452 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 18:13 ` Gorka Guardiola @ 2013-06-28 18:16 ` Gorka Guardiola 2013-06-28 18:41 ` Gorka Guardiola 1 sibling, 0 replies; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 18:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 468 bytes --] On Fri, Jun 28, 2013 at 8:13 PM, Gorka Guardiola <paurea@gmail.com> wrote: > > > > On Fri, Jun 28, 2013 at 7:38 PM, <tlaronde@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. [-- Attachment #2: Type: text/html, Size: 1281 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 18:13 ` Gorka Guardiola 2013-06-28 18:16 ` Gorka Guardiola @ 2013-06-28 18:41 ` Gorka Guardiola 2013-06-28 18:50 ` erik quanstrom 1 sibling, 1 reply; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 18:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 699 bytes --] > > 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.penguin67@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. [-- Attachment #2: Type: text/html, Size: 1951 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 18:41 ` Gorka Guardiola @ 2013-06-28 18:50 ` erik quanstrom 2013-06-28 18:57 ` Gorka Guardiola 0 siblings, 1 reply; 21+ messages in thread From: erik quanstrom @ 2013-06-28 18:50 UTC (permalink / raw) To: 9fans > On Fri, Jun 28, 2013 at 7:50 PM, Terry Wendt <silicon.penguin67@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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 18:50 ` erik quanstrom @ 2013-06-28 18:57 ` Gorka Guardiola 2013-06-28 20:06 ` Gorka Guardiola 0 siblings, 1 reply; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 18:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 303 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 583 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 18:57 ` Gorka Guardiola @ 2013-06-28 20:06 ` Gorka Guardiola 2013-06-28 20:13 ` Gorka Guardiola 0 siblings, 1 reply; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 20:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2354 bytes --] 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 00000000 00000000 0008050 00305600 00563000 00000000 00000000 ^^^^^^ ^^^^^^^ volume size in bytes (should this be in logical blocks?) 0008060 00000000 00000000 00000000 00000000 0008070 00000000 00000000 01000001 01000001 0008080 00080800 0a000000 0000000a c60a0000 ^^^^^ ^^^^ Block size, 2K 0008090 00000000 00000ac7 00000000 2200c20a 00080a0 00000000 0ac20010 00000000 10007005 00080b0 07151737 00020000 01000001 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 00000000 00000000 0008050 fdb30000 0000b3fd 00000000 00000000 ^^^^^^^^^^^^^^^^^ 90M/2K 0008060 00000000 00000000 00000000 00000000 0008070 00000000 00000000 01000001 01000001 0008080 00080800 0a000000 0000000a 14000000 ^^^^^^^^^ 2K block size 0008090 00000000 00000016 00000000 22001800 00080a0 00000000 00180008 00000000 08006b05 00080b0 1808100a 20020000 01000001 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 <paurea@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 [-- Attachment #2: Type: text/html, Size: 3775 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 20:06 ` Gorka Guardiola @ 2013-06-28 20:13 ` Gorka Guardiola 2013-06-28 20:20 ` Gorka Guardiola 0 siblings, 1 reply; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 20:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 258 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 511 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 20:13 ` Gorka Guardiola @ 2013-06-28 20:20 ` Gorka Guardiola 2013-06-28 20:36 ` Gorka Guardiola 0 siblings, 1 reply; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 20:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 658 bytes --] 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 <paurea@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 [-- Attachment #2: Type: text/html, Size: 2300 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 20:20 ` Gorka Guardiola @ 2013-06-28 20:36 ` Gorka Guardiola 0 siblings, 0 replies; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 20:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 41 bytes --] I created the patch mkisovolsize. G. [-- Attachment #2: Type: text/html, Size: 174 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 16:27 [9fans] plan9 iso image Terry Wendt 2013-06-28 16:40 ` erik quanstrom @ 2013-06-28 17:06 ` Gorka Guardiola 2013-06-28 17:15 ` Terry Wendt 1 sibling, 1 reply; 21+ messages in thread From: Gorka Guardiola @ 2013-06-28 17:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Jun 28, 2013, at 6:27 PM, Terry Wendt <silicon.penguin67@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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [9fans] plan9 iso image 2013-06-28 17:06 ` Gorka Guardiola @ 2013-06-28 17:15 ` Terry Wendt 0 siblings, 0 replies; 21+ messages in thread From: Terry Wendt @ 2013-06-28 17:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <paurea@gmail.com> wrote: > On Jun 28, 2013, at 6:27 PM, Terry Wendt <silicon.penguin67@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? > ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-06-28 20:36 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-06-28 16:27 [9fans] plan9 iso image Terry Wendt 2013-06-28 16:40 ` erik quanstrom 2013-06-28 17:12 ` Terry Wendt 2013-06-28 17:17 ` Paul A. Patience 2013-06-28 17:12 ` Gorka Guardiola 2013-06-28 17:19 ` erik quanstrom 2013-06-28 17:43 ` Gorka Guardiola 2013-06-28 17:50 ` Terry Wendt 2013-06-28 18:13 ` erik quanstrom 2013-06-28 17:38 ` tlaronde 2013-06-28 18:13 ` Gorka Guardiola 2013-06-28 18:16 ` Gorka Guardiola 2013-06-28 18:41 ` Gorka Guardiola 2013-06-28 18:50 ` erik quanstrom 2013-06-28 18:57 ` Gorka Guardiola 2013-06-28 20:06 ` Gorka Guardiola 2013-06-28 20:13 ` Gorka Guardiola 2013-06-28 20:20 ` Gorka Guardiola 2013-06-28 20:36 ` Gorka Guardiola 2013-06-28 17:06 ` Gorka Guardiola 2013-06-28 17:15 ` Terry Wendt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).