similar to: Bug#404533: re the boot failure..

Howdy, The attached bug report was sent to the Debian bug tracking system. If you please preserve the CC to 405058-forwarded at bugs.debian.org on any responses? ----- Forwarded message from Joey Hess <joeyh at debian.org> ----- From: Joey Hess <joeyh at debian.org> To: Debian Bug Tracking System <submit at bugs.debian.org> Subject: Bug#405058: does not properly support

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-2 Severity: normal pygrub can't work with this package, because the fsys filesystem modules included in the source package are missing. As a workaround, I downloaded the xen-3.0 source package, went into tools/pygrub/src/, installed e2fslibs-dev and libreiserfs0.3-dev, ran "make", and copied stuff from

Package: xen-3.0 Version: 3.0.3-0-2 Severity: serious This source package is not binNMU safe, which I understand is an RC bug. If the changelog, or any of several other files are changed, the build process wants to rebuild debian/control, and tries to use files from linux-support-2.6.18-1 to do it. This fails, since that package is a) not a build dependency b) not in the archive under that name

Howdy, [Please preserve the CC to 424919-forwarded at bugs.debian.org on any replies.] The following bug in Markdown was reported to the Debian bug tracking system. In short, running both the released version of Markdown and the latest beta on * foo > bar > baz produces invalid HTML. ----- Forwarded message from Joey Hess <joeyh at debian.org> ----- From: Joey Hess <joeyh

I second the feeling that hiding xen utilities in /usr/lib/xen-default/bin/ is not very good. I ran into it with pygrub, which is another program widely documented to be in /usr/bin. Seems like slave symlinks with update-alternatives could let these programs be available in the path and still be at versions in sync with the right version of xen. -- see shy jo -------------- next part

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-2 Severity: normal Since this package installs python modules in /usr/lib/xen-3.0.3-1/lib/python/, and uses them directly from there, not following the python policy, once xend has started up, lots of .pyc files are created there, which will not be removed if the package is purged. These pyc files may also cause problem for future python upgrades, I

severity 404538 normal thanks <vorlon> joeyh: binNMU support isn't RC, broken binNMU packages that get uploaded to the archive are. :) <vorlon> at least as the general rule -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url :

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20061225/6b78e0ae/attachment-0002.pgp

On Fri, Jun 04, 2004 at 01:20:54PM -0400, Joey Hess wrote: > My colocated server was refusing both ssh and ssl telnet connections. > It looked like this: > > joey:~>ssh -v kite > OpenSSH_3.8.1p1 Debian 1:3.8.1p1-4, OpenSSL 0.9.7d 17 Mar 2004 > debug1: Reading configuration data /home/joey/.ssh/config > debug1: Applying options for kite > debug1: Reading configuration

I've just done a fresh lenny amd64 install, and taken the xm-debian.cfg example: http://people.debian.org/~joeyh/d-i/images/daily/netboot/xen/xm-debian.cfg and built a 32 bit lenny inside a 64 bit lenny dom0 # xm create -c xm-th2.cfg install=true install-installer=http://people.debian.org/~joeyh/d-i/images/daily/ When I try to boot the domU: # xm create -c xm-debian.cfg it

Hello. I just tried (as my first attempt in xenning) to set up a lenny amd64 domU on a partitionable Mirror RAID (/dev/md_d0p1 - /dev/md_d0p4), using the Debian installer from "people.debian.org/~joeyh/d-i/images/daily/". The partitions of the md will be represented inside the domU as /dev/xvda1-4 accordingly. The dom0 seems to run fine, it''s Xen 3.2.1 on amd64 lenny. The

tags 439055 upstream thanks Hi Joey, interesting setup! Do you use it (the arm) to monitor the UPS and send notifications... I've sadly not much time to investigate, but have you tested the latest trunk? also, you mention that it was working before: which nut version? what has changed since? 2007/8/21, Joey Hess <joeyh at debian.org>: > Package: nut > Version: 2.0.5-3+b1 >

Hello, xen-utils-4.1's pygrub is unable to boot VMs from a partitionless blockdev that has grub installed in first sector. I'm not sure it deserves a bug report, although it is kind of a regression from 4.0. Long story short: zeroing first sector of domU's boot blockdev fixes it. Maybe some of this report would be useful in the wiki, if someone else has the same (odd) setup. --- The

Hi, I use Centos 5.4 x86_64 kernel used is 2.6.18-164.11.1.el5xen I have a physical machine running Debian Etch (32 bit) and Debian Lenny and I virtualized the first one as follows: *Created a HVM DomU with Virt-Manager with a virtual disk file of 40000 M *Boot from LiveCD, and created a swap and a ext3 partitions (Yes, very simple layout). *Rsync''d files from root partition of

Trying to create a 32 bit domU is unsuccessful. I also tried some of the older builds from http://people.debian.org/~joeyh/d-i/images and found similar problems Can someone point me to an installer kernel that will work? dom0: Linux dom0test 2.6.18-6-xen-amd64 #1 SMP Tue Aug 19 06:15:09 UTC 2008 x86_64 GNU/Linux Hardware: Intel Pentium D 960 with EMT64 /etc/xen# xm create -c xm-debtest1.cfg

Processing commands for control at bugs.debian.org: > reassign 699381 src:xen 4.0.1-5.5 Bug #699381 {Done: Julien Cristau <jcristau at debian.org>} [src:linux] linux-image-3.7-trunk-amd64: boot fails as xen domU: xc_dom_find_loader: no loader found Bug reassigned from package 'src:linux' to 'src:xen'. No longer marked as found in versions linux/3.7.3-1~experimental.1.

Hi, I use Centos 5.4 x86_64 kernel used is 2.6.18-164.11.1.el5xen I have a physical machine running Debian Etch (32 bit) and Debian Lenny and I virtualized the first one as follows: *Created a HVM DomU with Virt-Manager with a virtual disk file of 40000 M *Boot from LiveCD, and created a swap and a ext3 partitions (Yes, very simple layout). *Rsync'd files from root partition of physical

Processing commands for control at bugs.debian.org: > merge 414294 395305 Bug#395305: Unable to shutdown cleanly DomU when named more than 17 characters Bug#414294: xen-utils-common: /etc/init.d/xendomains fail to save domains with "long" names Merged 395305 414294. > merge 413181 404533 Bug#404533: missing build deps on e2fslibs-dev and libreiserfs0.3-dev Bug#413181: xen-3.0:

hello, On Mon, 16 Jun 2008, Joey Hess wrote: > klibc cpio segfaults extracting various cpio files. It seems to work for > small files, but fail for larger ones, including the d-i root floppy > image. > > For example: > > joey at kodama:/tmp/empty>wget http://people.debian.org/~joeyh/d-i/images/20080401-09:01/floppy/root.img > joey at kodama:/tmp/empty>zcat

Package: xen-hypervisor-3.2-1-i386 Version: 3.2.0-2 Severity: normal I'm afraid this bug report will be somewhat unspecific. Please let me know what I need to do in order to extract more useful information out of xen. I have done the following to install xen: installed xen-hypervisor-3.2-1-i386, xen-utils-3.2-1, linux-image-2.6.23-1-xen-686 fixed /usr/sbin/update-grub (see bug #455706)