Ian Campbell <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
