[Expired for xen-3.1 (Ubuntu) because there has been no activity for 60
days.]
** Changed in: xen-3.1 (Ubuntu)
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/144631
[Expired for xen-3.2 (Ubuntu) because there has been no activity for 60
days.]
** Changed in: xen-3.2 (Ubuntu)
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/144631
Your Ubuntu version is EOL so please try to reproduce the error with a
supported Ubuntu version! Thank you!
** Changed in: xen-3.2 (Ubuntu)
Status: New = Incomplete
** Changed in: xen-3.1 (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a
Thank you for taking the time to report this bug and helping to make
Ubuntu better. The issue that you reported should be reproducible with
the live environment of the Desktop CD development release - Maverick
Meerkat. It would help us greatly if you could test with it so we can
work on getting it
Since according to several comments this seems to happen independent of
xen-create-image being used or not, I'm marking this invalid for xen-
tools. Seems to be a problem with Xen in general. (Please tell me if you
think I'm wrong, but also tell me why. :-)
** Changed in: xen-tools (Ubuntu)
I am not seeing this problem on Hardy 8.04.3. Can anyone confirm/deny?
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
As if this bugreport is not long enough already, I want share my
findings here: my DomU (Debian/sid) would stop booting and not be
reachable via ping/ssh:
[0.515574] EXT3-fs: mounted filesystem with ordered data mode.
[0.515597] VFS: Mounted root (ext3 filesystem) readonly on device
Yes it is still required but: considering that xen-create-image (from
xen tools) now create the correct configuration that does not have to be
tweaked by hand (i.e. the workaround does not have to be applied by
hand) and that we do not ship dom0 anymore in intrepid, this bug is
probabily a Won't
Is this symptom also reproducible using Xen 3.3 (i.e., is the workaround
still required)?
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Also please all note that the VM is not crashed/freezed, it's just that
VM console is not working (so network services and programs are still
running fine, try to log with SSH and you will see)
To fix the problem, in the dimU config file, add/replace a line with :
extra = 4 xencons=tty
It's
** Also affects: xen-3.2 (Ubuntu)
Importance: Undecided
Status: New
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
This problem is showing up in Xen 3.2, but the workarounds don't seem to
work.
I even tried adding the modules as suggested in bug #199533
https://bugs.launchpad.net/ubuntu/+source/xen-3.2/+bug/199533
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You
i used both removing execution of the hwclock script as well as
extra='xencons=tty'. My domU's are all booting fine now.
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I just wanted to comment since I have been researching this for a couple
of hours myself. Once I added
extra='xencons=tty'
to my domain.cfg files, I was able to use the console to monitor the
bootup. I saw an immediate error about not being able to set the
hardware clock, but the boot continued.
Thanks Karl!
That fixed it for me.
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Is anybody still having trouble with this?
The only two files I needed to change were:
append to /etc/xen-tools/xm.tmpl
extra = ' xencons=tty console=tty1'
append to /usr/lib/xen-tools/gutsy.d/15-disable-hwclock
rm -f ${prefix}/etc/init.d/hwclock.sh ${prefix}/etc/init.d/hwclockfirst.sh
I have had great luck following these items from a Xen mailing list
poster. In the (gutsy) domU,
-- cat xvc0 /etc/securetty
-- sed -ie '[EMAIL PROTECTED]@[EMAIL PROTECTED]' /etc/event.d/tty1 mv
/etc/event.d/tty1 /etc/event.d/xvc0
-- chmod -x /lib/udev/set_hwclock
FYI, I have never used
Sorry, I had a senior moment. You won't get much use out of
cat xvc0 /etc/securetty
Try this, instead:
echo xvc0 /etc/securetty
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs,
I don't think the --ide is required.
On my working system, I've got it on the default sda interface.
As far as networking is concerned, I've have no issues with a static MAC
assignment and DHCP.
Difference with our systems though, is that I don't have NetworkManager.
I think it only comes with
And again, same problem here!
After installing Ubuntu Desktop 7.10 amd64 I directly installed Xen 3.1 from
the repositories. Creating a guest via xen-create-image works fine but the domU
hangs when trying to mount / mounting the file system. After adding the extra
= 'xencons=tty1' line though
I tried the howtoforge instructions.
I noticed the --ide and also that they are using a hard-coded IP
address.
Even with those changes. I don't have networking...
I am also running into this bug again:
https://bugs.launchpad.net/ubuntu/+source/xen-3.1/+bug/150805
The work around seemed to work
I have a working system currently... More testing is needed, but you can
see Bug # 150805 for how i got to a working state. Hopefully it helps
somebody.
https://bugs.launchpad.net/ubuntu/+source/xen-3.1/+bug/150805
--
xen guest hangs after mounting filesystem
according to:
http://www.howtoforge.com/ubuntu-7.10-server-install-xen-from-ubuntu-repositories-p2
The --ide option is required for the xen-create-image in order for it to
boot... Can somebody test/confirm that?
I will follow through with the howtoforge suggestions as soon as I get a
chance.
I don't know if this will help since it sounds a bit different:
We had some Ubuntu booting problems before (run manual build xen on
centos). We fixed this by building a new initrd in the domU and copy
that initrd to dom0 and use it in the config file instead of the
supplied one.
you can build a
Same problem here
# xm top
Shows 100% cpu load on the DomU
DomU Console in Gutsy with 2.6.22-14-xen:
* Setting preliminary keymap... [ OK ]
* Setting the system clock
The problem occurs with 2.6.22-13-xen 2.6.22-14-xen, kernel
2.6.22-12-xen
The above comments seem to have resolved my issues booting up Gutsy
DomUs.
Previous problems :
- At no time can I login to console.
- After xm-create-image the DomU responds to ssh.
- After xm-shutdown/create the DomU does not respond to ssh.
Fresh install of Gutsy with vmlinuz-2.6.22-14-xen :
Hi,
I have got the same problem on my gutsy server install.
I have tried the patches the previous post described:
- disabling of hwclock in the /etc/rc0.d and in the rc6.d directories by
removing the links.
- stripping the execution permission on the /lib/udev/set_hwclock file by
chmod...
-
Just to add my experience here: I had some stuff working on Xen-3.0,
Kubuntu feisty host, gutsy-server guest. Paravirtualized, using kernel
2.6.19-4-generic, on a socket-A based host. I upgraded dom0 to gutsy
(and fixed the damage after the upgrade tool crashed), updated my config
to point to the
I have also seen lockups of the Xen Dom0 with no DomU started under
heavy I/O by a process owned by root. Strangely bonnie++ runs fine under
an unprivileged account. I think this is not at all ready for production
and will scratch the Ubuntu 7.10 gutsy server installation now and move
to something
After install gusty ubuntu-xen-server packages, the system boot don't
pass Setting the system clock, what can I do for solve this? Any
workaround at least yet?
I'm using a virtual machine to test (VMWare). Any body have installed
this packages with successful? Or it is broken at all?
--
xen
I too am experiencing precisely the same issues as reported above on my
Dell 430SC server with dual core pentium D920 processors running 64 bit
Ubuntu 7.10 gutsy server and Xen 3.1 ( 2.6.22-14-xen #1 SMP Sun Oct 14
23:20:20 GMT 2007 x86_64 GNU/Linux).
However, immediately after initially creating
Same problems here with ubuntu gutsy, adding a new line to the DomU
configuration file:
extra='xencons=tty'
This does make the VMs Virtually work but now they hung in the state of
setting the system clock.. forever!
In other words, this must be a complicated problem an yes it might be
the case
Exactly the same problems, adding a new line to the DomU configuration file:
extra='xencons=tty'
fixed it. Problem is not related to hwclock, this may be another issue. However
I see lockups apparently in the loopback driver, dd segfaulted durcing setup,
etc... had to hard reset the server
I can confirm that /lib/udev/set_hwclock is problematic. My gutsy domU
took forever to boot, and when it did, top showed hwclock hogging the
CPU. I removed execute permissions on /lib/udev/set_hwclock and now it
boots quite snappily.
--
xen guest hangs after mounting filesystem
It seems that the problem is the /lib/udev/set_hwclock script; it calls
hwclock, even when HWCLOCKACCESS is set to 'no' in /etc/default/rcS
(which is obeyed by the /etc/init.d/hwclockfirst.sh script). I tried
turning off all the 'x' bits on /lib/udev/set_hwclock, and then a Xen
domU running gutsy
The hwclock scripts have nothing to do with this bug.
Removing them did not cause bootup to continue, nor should it have. The
guest instances hang immediately _before_ even mounting the root
filesystem, so none of the init scripts have even had a chance to run.
--
xen guest hangs after mounting
Ummm maybe my eyesight is going on me, but the bug report says xen
guest hangs *after* mounting filesystem, no idea why it's hanging for
you before the file system is mounted but the hwclock stuff was deff
hanging my DomU gutsy guests.
--
xen guest hangs after mounting filesystem
The console shows EXT3-fs: mounted filesystem with ordered data mode.
which would normally cause you to believe it's already mounted the
filesystem. But in reality, it hasn't.
With this bug, you're still able to mount the filesystem in the dom0
even while the domU machine is supposedly running.
I'm not sure how safe it is to mount the file system like that twice.
I've had systems in a mess because of doing similar things and they hard
lockup on me as a result.
Dom0 has to be able to mount the file systems of any DomU at any time,
otherwise the DomU's wouldn't see their data. I don't
I think this should be default in xen-tools.
You just need to add one line to a tmpl file:
echo extra = ' TERM=xterm xencons=tty console=tty1' /etc/xen-
tools/xm.tmpl
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification
printf Disabling threads:
mv /tmp/${xendomu}/lib/tls /tmp/${xendomu}/lib/tls.disabled
printf done.\n
I don't think this needs to be done if you are installing libc6-xen
Can anyone confirm progress made on this bug?
The hwclock.sh scripts hold the whole thing up afaik, before launching a
new
Forgot to mention, in /etc/xen-tools/xen-tools.conf
Down the bottom of the file it has:
# If you're using a newer version of the Xen guest kernel you will
# need to make sure that you use 'xvc0' for the guest serial device,
# and 'xvdX' instead of 'sdX' for serial devices.
#
# serial_device =
Actually I've been digging more into this, as part of xen-create-image
hwclock should be disabled by:
/usr/lib/xen-tools/gutsy.d/15-disable-hwclock
However the gutsy.d directory is really a symlink to edgy.d and this
doesn't seem to work for gutsy for some reason.
Seems a udev entry is blocking bootup, edit /usr/lib/xen-tool/gutsy.d/25
-disable-hwclock and add the following line:
rm -f ${prefix}/etc/init.d/hwclock.sh
${prefix}/etc/init.d/hwclockfirst.sh
${prefix}/etc/udev/rules.d/85-hwclock.rules
Below these lines:
chroot ${prefix} /usr/sbin/update-rc.d
Can anyone confirm progress made on this bug? Since the workaround
involves using a kernel that can only run one Xen domU at a time, this
effectively kills Xen on Gutsy.
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because
I think we may be chasing the wrong problem by pursuing xen-tools for
the fix.
This problem is also 100% reproducible using manual domain creation.
The only working fix I have found is to add extra='xencons=tty1' to the
xendomu config file.
This would be incorrect behaviour. It should work
#17 Todd: I have just checked the xencons line and it is correct, but
when booting the domU with 2.6.22 kernel it hangs after mounting the
filesystem as always. As you (Stephen and you) have been discussing, I
think this is related to bug #139046 as you do, and because of the
similar symptoms it
I'd say this is more of a bug in xen-tools. I've worked out how to get
them booting using the default value for xencons (ie. using /dev/xvc0).
One addition is required in each domU config:
extra = 'console=xvc0'
Apparently the kernel doesn't detect it automatically.
Once that is done, a couple
I'm testing XEN 3.1 in Ubuntu Gutsy Gibbon. When I start a Feisty
debootstrap domU with a .sxp configuration file manually created from
scratch, It hangs after mounting the ext3 filysystem, happening exactly
the same as Todd Deshane described above. The problem is that the
virtual machine does not
William: I really appreciate your efforts in tracking down fixes for
things. I think we need to figure out how to make this work out of the
box. Adding anything extra to the guest is unexceptable. Just before
tribe5 I didn't have this problem.
Let's see if we can come up with a set up patches to
It looks to me like the xencons solution is fixing another problem: Bug
#139046.
This problem doesn't have anything to do with the console, since it
actually renders the machine unbootable. Nothing happens after the
filesystem driver is loaded, with the box spiking at 100% CPU usage and
no
Bug #139046 is a different problem, though it is very related. It is
specific to the guest type, in the case of bug #139046 it seems specific
to edgy guest for example. The fixes/workarounds don't apply directly to
a feisty guest for example.
The 2.6.19-4 is the kernel that I was using too until
Right. Bug #139046 is a different problem, but the symptoms are roughly
similar. I believe that is causing some confusion about the true nature
of this bug.
I firmly believe that this bug is entirely unrelated to the console.
SSHing to the box after boot does _not_ work, nor does pinging it. The
Stephen: I see what you are getting at now
It seems to me that you are right, there are more like 3 bugs here.
1) The console one, which is not completely a dup of a
href=https://bugs.launchpad.net/bugs/139046;bug #139046/a
2) Not being able to SSH into domU even after (did you report this
** Also affects: xen-3.1 (Ubuntu)
Importance: Undecided
Status: New
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs
If everybody specifies either 'console=xvc0' or 'xencons=tty0' in their
guest, it should get further, so we can see what's actually happening in
each case. Even after modifying /etc/securettys and adding a getty on
xvc0, I had to poke a couple of things inside the domU filesystem to get
a Gutsy
quick update for those following a potential network problem as well. I
filed a bug for the network problem I am seeing here:
https://bugs.launchpad.net/ubuntu/+source/xen-3.1/+bug/150805
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug
I was having exactly the same problem, and the above extra line did not
help me. However the line:
extra='xencons=tty'
did work for me, and I now have a booted domain that was not previously
booting. Please note that this may disable the framebuffer. If you need
that you will need to look at
Thanks Paul, that did work.
Do anyone know what the real fix should be?
Why does it not work out of the box like it used to?
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Confirmed here on i386 (Pentium M @ 1.6GHz, if it might matter). I've
tried variations of ext2, ext3, reiserfs, and they all just hang. At one
stage I did get the warning about init being slow due to bad tls
emulation or so, but only once, and it didn't get any further.
** Changed in: xen-3.1
Adding the extra= line above doesn't work.
I also looked into the other things reported in
https://bugs.launchpad.net/bugs/139046 but nothing seemed to work or was
applicable. It hanged on the same spot regardless of the change.
I never had any tls warnings on this one.
Also, recall that the
I've also tried replacing /sbin/init with dash, but that doesn't execute
either.
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs
Try adding extra='xenconsole=tty'.
I think this should be default in xen-tools.
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs
in gutsy amd64 host here,
after fixing the network/bridge script
the guest boots, but the console is not working
I can ssh to the guest though and it's up and working fine otherwise
might just be the init console which is broken somewhere
Mik
--
xen guest hangs after mounting filesystem
config for feisty image made manually with debootstrap
** Attachment added: feisty
http://launchpadlibrarian.net/9496381/feisty
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs,
output of xm log
** Attachment added: xm_log.out
http://launchpadlibrarian.net/9496384/xm_log.out
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for
full output of feisty boot process
** Attachment added: feisty-boot.out
http://launchpadlibrarian.net/9496398/feisty-boot.out
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
Bugs, which
strace of full boot of feisty
** Attachment added: strace-feisty-boot.out
http://launchpadlibrarian.net/9496435/strace-feisty-boot.out
--
xen guest hangs after mounting filesystem
https://bugs.launchpad.net/bugs/144631
You received this bug notification because you are a member of Ubuntu
the config for the guest made with xen-create-image (from xen-tools) is
attached
The behavior is the same, I don't notice any big differences in behavior
compared to feisty
it freezes a few lines longer because of swap and th loading of a couple
things:
EXT3-fs: mounted filesystem with ordered
Also this is on i386 with the latest updates available... i.e.
linux-meta (2.6.22.12.15) gutsy; urgency=low
* Add cell flavour on powerpc.
-- Colin Watson [EMAIL PROTECTED] Sun, 23 Sep 2007 21:47:42 +0100
linux-meta (2.6.22.12.14) gutsy; urgency=low
* ABI bump for -12.
* Add virtual
OK. I am back running xen kernel 2.6.19-4-generic-amd64. It works great,
booted the feisty guest and a guest created with xen-create-image with
no problems.
I also booted my Windows XP guest too.
So this is the last xen in the gusty series that works for me:
2.6.19-4-generic-amd64
ii
71 matches
Mail list logo
