[9fans] Installer problems

[9fans] Installer problems

[Jason Lash]

I am having problems with the installer. I am trying to install under
Xen with a 1gb virtual machine. The system boots up. I can manually
use disk/mbr to install the mbr manually. I can also use disk/fdisk to
delete the trash partitions it makes up and add a new one, make it
primary, and write it out. I think prep and format are also working,
but i haven't gotten far enough to understand if this is right or not.
Keep in mind I am doing all this manually from the installer shell.

"Why on earth would a newbie do that?!!?", you ask? Well, I tried
using inst/textonly at first. I was able to select my format and move
on to the partition portion with no problems. It shown my 2 drives:
sd00 (cd rom) sd01 (my 1gb virtual disk).  I select sd01, and it warns
that I have no mbr. Would i like to write an mbr? Sure, why not. Next,
it says fdisk can't find the mbr on sd01.... rinse, repeat, cry. If i
say 'no' to the mbr installation prompt, i still get the same error
from fdisk (who woulda guessed?)

I also tried manually installing the mbr before starting
inst/textonly. This gave the same result.

So I have 2 questions:
1) the obvious: Whats going wrong and how can i fix it?
2) What are all the steps required to manually install from the shell?
I've gotten the mbr install, the fdisk partitioning, now i'm stuck at
the options for parm and format.

Any help is appreciated!

Thanks,
Jason
--
Jason Lash
jason.lash (at) gmail.com

Re: [9fans] Installer problems

[Russ Cox]

> So I have 2 questions:
> 1) the obvious: Whats going wrong and how can i fix it?
> 2) What are all the steps required to manually install from the shell?
> I've gotten the mbr install, the fdisk partitioning, now i'm stuck at
> the options for parm and format.

Now that it has an mbr and fdisk is happy, 
I would try running inst/textonly again.

I just looked at the install scripts and I don't
see why disk/mbr would fail without printing an error.
Perhaps disk/mbr decided the sector size
was 0 instead of 512?  cat /dev/sd01/ctl.

I'm surprised you've gotten this far.  I didn't
think the standard PC kernels booted under Xen.

Russ

Re: [9fans] Installer problems

[Jason Lash]

Thanks for the quick reply Russ. I did try running textonly AFTER
manually running mbr and fdisk. It gave me the same result.

HOWEVER! out of pure frustration and lack of anything else to do ;) I
decided to take it from the top. I rewiped my virtual machine drive
file and filled it with 0s (dd if=/dev/zero of=plan9.img bs=1024
count=1024k). After doing this, I booted the VM back up and was able
to successfully install with no quirks or hacks! Well, at least it
looks like its going to be successful. I am at the copydist stage now
(knock on wood).

And yes, you have to use the 9xeninst kernel to boot the installer. I
just grabbed it from http://cm.bell-labs.com/sources/xen/9xeninst.gz.

Anyway, this is still a bug in my opinion. For the record, the drive
geometry/size was WAY off in fdisk when I started. it said i had some
like 4x 200GB partitions with free space in between. i wish ;) WHen i
deleted them all, however, it accurately showed the free space size of
1gb flat. Might be related, might not be. Either way, the partitioner
and mbr installer should not need a zeroed drive to work correctly.

Thanks again and let me know if you need reproducing this later!
Jason

On 2/23/06, Russ Cox <rsc@swtch.com> wrote:
> > So I have 2 questions:
> > 1) the obvious: Whats going wrong and how can i fix it?
> > 2) What are all the steps required to manually install from the shell?
> > I've gotten the mbr install, the fdisk partitioning, now i'm stuck at
> > the options for parm and format.
>
> Now that it has an mbr and fdisk is happy,
> I would try running inst/textonly again.
>
> I just looked at the install scripts and I don't
> see why disk/mbr would fail without printing an error.
> Perhaps disk/mbr decided the sector size
> was 0 instead of 512?  cat /dev/sd01/ctl.
>
> I'm surprised you've gotten this far.  I didn't
> think the standard PC kernels booted under Xen.
>
> Russ
>
>


--
Jason Lash
jason.lash (at) gmail.com

Re: [9fans] Installer problems

[Russ Cox]

> Anyway, this is still a bug in my opinion. For the record, the drive
> geometry/size was WAY off in fdisk when I started. it said i had some
> like 4x 200GB partitions with free space in between. i wish ;) WHen i
> deleted them all, however, it accurately showed the free space size of
> 1gb flat. Might be related, might not be. Either way, the partitioner
> and mbr installer should not need a zeroed drive to work correctly.

I agree, but how did you manage to create a new virtual disk that
wasn't zeroed?

It is possible that if there is garbage on sector 0, then installing
the mbr will still leave the garbage in the partition table,
but now that there is an mbr fdisk will think the partition table
is okay, so you'll get weird-looking entries.

However, this doesn't make sense, since you said that fdisk
said that the mbr was missing!

Russ

Re: [9fans] Installer problems

[Jason Lash]

I created the disk without zeroing via the instructions in the
'Installing in Xen' guide from the Plan9 wiki
(http://www.cs.bell-labs.com/wiki/plan9/Installing_in_Xen/).  If this
is reproducable, it might be worth an update to the guide.

I used the following originally (copied from the guide):
dd if=/dev/zero of=plan9.img seek=$((1024 * 1024 * 1024 - 1)) bs=1 count=1

It just zero's the last bit and allocates the rest as-is. Its instant,
which is nice, but obviously gave me a garbage mbr and partition
table.

On 2/24/06, Russ Cox <rsc@swtch.com> wrote:
> > Anyway, this is still a bug in my opinion. For the record, the drive
> > geometry/size was WAY off in fdisk when I started. it said i had some
> > like 4x 200GB partitions with free space in between. i wish ;) WHen i
> > deleted them all, however, it accurately showed the free space size of
> > 1gb flat. Might be related, might not be. Either way, the partitioner
> > and mbr installer should not need a zeroed drive to work correctly.
>
> I agree, but how did you manage to create a new virtual disk that
> wasn't zeroed?
>
> It is possible that if there is garbage on sector 0, then installing
> the mbr will still leave the garbage in the partition table,
> but now that there is an mbr fdisk will think the partition table
> is okay, so you'll get weird-looking entries.
>
> However, this doesn't make sense, since you said that fdisk
> said that the mbr was missing!
>
> Russ
>
>


--
Jason Lash
jason.lash (at) gmail.com

Re: [9fans] Installer problems

[Russ Cox]

> It just zero's the last bit and allocates the rest as-is. Its instant,
> which is nice, but obviously gave me a garbage mbr and partition
> table.

That's not obvious to me.

If plan9.img does not yet exist, running:

	dd if=/dev/zero of=plan9.img seek=$((1024 * 1024 * 1024 - 1)) bs=1 count=1
	dd if=/dev/zero of=plan9.img bs=1048576 count=1024

should appear to behave exactly the same.  (The second actually
chews through 1GB of disk while the first does not, but in both
cases, subsequent reads anywhere in the file should give you
zero bytes.)

Russ

Re: [9fans] Installer problems

[Ronald G Minnich]

Jason Lash wrote:
> I created the disk without zeroing via the instructions in the
> 'Installing in Xen' guide from the Plan9 wiki
> (http://www.cs.bell-labs.com/wiki/plan9/Installing_in_Xen/).  If this
> is reproducable, it might be worth an update to the guide.
> 
> I used the following originally (copied from the guide):
> dd if=/dev/zero of=plan9.img seek=$((1024 * 1024 * 1024 - 1)) bs=1 count=1
> 
> It just zero's the last bit and allocates the rest as-is. Its instant,
> which is nice, but obviously gave me a garbage mbr and partition
> table.


that's not it. What that dd does is what this perl script does, I think:

# make it look like C argv[]
unshift(@ARGV, "XX");

$size=1024*1024*1024*4;
$file = "file.out";
if ($#ARGV > 1) { $size = eval($ARGV[2]); }
if ($#ARGV > 0) { $file = $ARGV[1]; }

print "file $file, size $size\n";

open(FILE, ">", $file) || die("open $file failed: $!");
truncate($file, $size) || die("truncate to %size failed: $!");

i.e. just trunc it to size but don't allocate blocks. The perl script is 
more efficient: the dd allocates 512 bytes in the last block, the perl 
script allocates 0.

As you reference unallocated blocks in the file, the OS gives you ZFOD 
(zero-filled) data back for each block that was not allocated at file 
creation.

All OSes will  gives you zero-filled data as a security measure: in the 
old days, we had great fun doing this:
open(some file)
truncate(to a large value)
read(the whole damn thing)

you could troll for all kinds of stuff that way. People actually wrote 
'security' programs to open files in this way, then write them with 
zeros to make this impossible -- I am not kidding.

Anyways, I don't know why this failed ...

ron