Henning Sprang wrote: > Michael Tautschnig rote: >>> I'm installing XenSource VMs
> BTW: XenServer commercial stuff or just GPL Xen VM's? (XenSource > is dead/swallowed, in any case and not operating by that name anymore) It's the commercial version. (Citrix XenServer) >>> Does someone have an explanation what is happening? > Hmm, maybe something along these lines: your going to install > a kernel, which pulls in a bootloader. But the bootloader has > some hard time when "looking at the disk", as you're only > handing over a single partition to the xen guest (it sees > something like /dev/sda1 without /devsda), if you're doing it > like most people do it on debian. See above. There's a real disk (well as far as "real" is valid in this context) which is exposed to the VM as an IDE disk. I create a partition table with 2 "real" partitions. (root and swap, obviously.) While installing these are called /dev/hda1 and /hda2. (After rebooting with a xen optimized kernel they turn into /dev/xvda1 and /dev/xvda2 respectively.) > Some of the helper tools involved around this process have > some trouble with the type of setup... It just seems to happen when installing a xen-optimized kernel. I never noticed problems when installing "simple" kernels. Before using the "and"-patch I detected the classes "DEBIAN32", "DEBIAN64", "UBUNTU32" and "UBUNTU64" and installed linux-image-686 / linux-image-amd64 or linux-image-server regard- less if it was a virtualized server or not. Later on I removed the freshly installed "normal" kernels and downloaded/installed a xen-optimized kernel instead. This worked without the workaround/hack, but I wasn't satisfied with this solution and rewrote the procedure to never download a kernel that won't be used anyway later on. (A fully configured systems installs in about 150 seconds now. I like the look in my colleagues eyes when they realize I'm talking about a complete installation including our own modifications. Just log in and start working.) tschüß thomas
