Re: does i386 still work?

[Greg Troxel <gdt%lexort.com@localhost>]

"Mathew, Cherry G.*" <c%bow.st@localhost> writes:

>>>>>> Greg Troxel <gdt%lexort.com@localhost> writes:
>
>
> [...]
>
>
>     > Thanks.  After disabling autoballoon (for dom0), checking things
>     > over, rebooting the dom0, and trying again, it worked normally.
>
> Would you know if this is to do with the domU (balloon(4)) or something
> else ? ie; does the boot dmesg give any indication about when the hang
> occurs ?

The hang is just before the root filesystem should be accessed.

The autoballoon that I changed was only supposed to change dom0
behavior.   As documented, if dom0 memory is not explicitly configured
(so it should get all), then if you start a domU, the needed memory is
obtained from dom0 via the balloon driver which presumably allocates RAM
and promises not to use it, passing the dom0 addrs back so that the
hypervisor can treat those pages as freed.  But that's me guessing.

I have 8 GB, and had been booting with:

  menu=Xen:load /netbsd-XEN3_DOM0.gz root=wd0a rndseed=/var/db/entropy-file console=pc;multiboot /xen.gz dom0_mem=4096M

so autoballoon should not be happening, but it was and my dom0 went down
to 2GB.  This and zfs do not play well, but that's a rant for another
day.

So I set:

  autoballoon="off"

which indeed caused dom0 RAM not to get taken.

I was observing the domU starting fine, memory/CPU ok, probing devices
included xennet and xbd and failing later.  So I'm pretty sure the
autoballoon change is unrelated.

I had been messing with the zvol, mounting and unmounting to fix the
fstab for the new root device, new hostname, and deleting ssh keys (was
dump/restore from a physical computer to make the domU).   But after a
fresh boot, I started the domU without any of that.  So my theory is
that my zvol got somehow unhappy and/or that xen is extra twitchy about
opening it, and that balloon is not relevant to the not-finding-disk
issue.