Re: preliminary patch towards XEN virtual disk naming
Ian Campbell <ijc@hellion.org.uk> writes:
> On Sun, 2008-04-06 at 15:18 +0200, Ferenc Wagner wrote:
>
> Thanks Ferenc, I've commented on #474556.
Thanks, I replyed there. On speling you are definitely right, I
changed the patch. Starting number, well, do we actually need it at
all?
> Do you have plans to work on D-I for Xen extensively? If so we should
> sync up.
I've just started with this as in my day job I got responsibe for a
couple of Xen machines. Till now I don't think that really extensive
work is needed, the installer worked almost perfectly.
The only real problem is with kbd-chooser, which errors out on me, but
I could simply skip it with preseeding. On the other hand, it may be
a Xen 3.0 issue, HVC support in 3.2 may solve that. Or at least
provide a way to fix it right. Unfortunately I don't have a 3.2
installation handy, so can't test.
Probably related, that I can't use ssh (from openssh-client-udeb) from
the installation console (tty), it gives the error:
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
ln -sf /dev/tty /dev/console helps it, though.
The grub-installer problem you reported doesn't concern me now, I
don't use pygrub it this setup. And seems like you solved it already.
Kernel image selection comes to my mind, but again, I don't quite need
it in my paravirtualized setup, having no boot loader... And one
initrd can boot all my machines, they don't really need any kernel
modules either. But it can be an issue in different setups.
(I wonder if installing no kernel would skip all the boot loader
stuff, including nobootloader/confirmation...)
But a Xen-friendly libc (libc6-xen) would be nice in the installer,
don't you think? As far as I know it doesn't penalize real hardware
setups noticeably, but is a huge gain under Xen. And in the target
system the correct version could be installed anyway.
I also changed debian-installer/exit/always_halt to true, because the
Xen config is not reread on domU reboot, so I couldn't change the
ramdisk. If it's still the case in Xen 3.2, this could be detected
automatically for the very least. And also noted that the initrd
should be copied out... But this again depends on the type of
virtualization and pygrub usage, I can only see a narrow slice.
Well, it seems pretty much, but neither is a real show stopper for me.
(No support for partitionable raids is more of one, but unrelated.)
Still, I'm willing to put some work into the above, so please share
your thoughts on the matter!
--
Regards,
Feri.
Reply to: