Has this been tested in 14.04 with libvirt 1.2.1? There was a bug when
merging libvirt 1.2.0 which should be resolved now.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
https://bugs.launchpad.net/bugs/1180281
Title:
Test packages in people.cc/~smb/vmcitest.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to open-vm-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1271669
Title:
Move vmware related modules from extras into main kernel package
To
James/Robie, where would one tweak which random source is used?
Currently playing around with it btu I don't understand why tweaking a
certain new setting has the effect it seems to have...
So there is this new /proc/sys/kernel/random/urandom_min_reseed_secs
which is said to be the time between
So this might be an exceptional SRU. MRE was overshooting its purpose.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to iscsitarget in Ubuntu.
https://bugs.launchpad.net/bugs/1262712
Title:
[SRU] Backport iscsitarget 1.4.20.3+svn490
** Patch added: Updated the changelog with a reference to this bug report
https://bugs.launchpad.net/ubuntu/+source/iscsitarget/+bug/1262712/+attachment/3948652/+files/iscsitarget-mre.debdiff
** Patch removed: iscsitarget-mre.debdiff
** Changed in: linux (Ubuntu)
Assignee: Stefan Bader (smb) = (unassigned)
** Changed in: linux (Ubuntu Saucy)
Assignee: Stefan Bader (smb) = (unassigned)
** Changed in: qemu-kvm (Ubuntu)
Assignee: Stefan Bader (smb) = (unassigned)
** Changed in: qemu-kvm (Ubuntu Saucy
For prepared source packages location ping me on IRC (that was prepared
with -v1.4.20.2-5ubuntu3.3).
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to iscsitarget in Ubuntu.
https://bugs.launchpad.net/bugs/1262712
Title:
[MRE]
The debdiff between current and proposed version of iscsitarget.
** Patch added: iscsitarget-mre.debdiff
https://bugs.launchpad.net/ubuntu/+source/iscsitarget/+bug/1262712/+attachment/3932610/+files/iscsitarget-mre.debdiff
--
You received this bug notification because you are a member of
built and installed
- Rebooted VM in Saucy kernel and verified that iscsi disk is still usable.
** Affects: iscsitarget (Ubuntu)
Importance: High
Assignee: Stefan Bader (smb)
Status: Triaged
** Changed in: iscsitarget (Ubuntu)
Status: New = Triaged
** Changed
(this problem was no longer present in Xen 4.2 and later).
** Changed in: xen (Ubuntu Precise)
Importance: Undecided = Low
** Changed in: xen (Ubuntu Precise)
Status: New = Fix Committed
** Changed in: xen (Ubuntu Precise)
Assignee: (unassigned) = Stefan Bader (smb)
** Changed in: xen
For the records, I did not receive any import error since uploading and
moving to proposed.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
https://bugs.launchpad.net/bugs/1176209
Title:
Import problem caused by
Tested Quantal for regressions. None found.
** Attachment added: q-report
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1180396/+attachment/3919987/+files/q-report
** Tags removed: verification-needed-quantal
** Tags added: verification-done-quantal
--
You received this bug
Tested Precise for regressions. None found.
** Attachment added: p-report
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1180396/+attachment/3919998/+files/p-report
** Tags removed: verification-needed-precise
** Tags added: verification-done-precise
--
You received this bug
** Changed in: xen (Ubuntu)
Status: In Progress = Invalid
** Changed in: xen (Ubuntu Precise)
Status: New = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
** Description changed:
SRU Justification:
Impact: Upstream Xen has released a stable update to 4.1.5. Since
Precise and Quantal are based on 4.1 it would be gaining us bug fixes
without waiting for people to run into them. Like we do with upstream
stable on the kernel.
Fix:
** Description changed:
Request for SRU:
[Impact]
DRBD will not work (hang) on fresh install using Ubuntu 12.04.3 media, and
will stop working on sites where the Raring Enablement Stacks is manually
installed as the API between older and newer drbd kernel modules has changed.
[Fix]
Thanks Lionel, I will update the SRU description and we will see.
Backporting a much newer version of anything into an older release
always is met with a lot of (justified by experience) reservations. It
probably will need more volunteers to make a case for it (at least
convincing the SRU team
)
MarkForUpload: True
SourcePackage: linux-lts-raring
UpgradeStatus: No upgrade log present (probably fresh install)
** Changed in: drbd8 (Ubuntu Precise)
Assignee: (unassigned) = Stefan Bader (smb)
** Changed in: drbd8 (Ubuntu)
Status: Confirmed = Invalid
--
You received this bug
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
Add a more recent version of XCP to the Ubuntu Archive: POSTPONED
Write XCP documentation and Openstack: POSTPONED
Test XCP and Openstack: POSTPONED
Write documenation on vmware and Openstack: POSTPONED
Work items
Backports might be an option, too. Though then requiring to be aware of
the problem and manually pick the backports version when upgrading to
the LTS Raring kernel. Usability looks to be simpler with a SRU but I
would defer that decision to the SRU team.
--
You received this bug notification
That is in release by now.
** Changed in: xen (Ubuntu)
Status: Triaged = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
https://bugs.launchpad.net/bugs/1218817
Title:
[FFE] Update to Xen-4.3 in
So it seems the version displayed by the tools is coded to be that older
version. The code itself rather looks to be more recent. So I would
rather just tweak the version numbers.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to drbd8
** Attachment added: drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1185756/+attachment/3851297/+files/drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
I re-uploaded the Raring debdiff and packages (sorry a bit unclean and
using the same version number again). The only change to the previous
version is the legacy tools version number being bumped.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Attachment added: drbd8-utils_8.4.3-0ubuntu0.12.04.1_i386.deb
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1185756/+attachment/3851298/+files/drbd8-utils_8.4.3-0ubuntu0.12.04.1_i386.deb
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Attachment removed: drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1185756/+attachment/3840756/+files/drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
** Attachment removed: drbd8-utils_8.4.3-0ubuntu0.12.04.1_i386.deb
@Numérigraphe,
thanks for the quick testing. To answer the question from #12 first: The
version used by that package depends on the version of the kernel. So
just upgrading kernel to 3.8 (or later) and booting with that kernel
will cause the 8.4 utils part to be used. This unfortunately does some
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[serge-hallyn] (Dwight is pushing this, but has no lp id) Push fix for XFS
and user namespaces: DONE
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable
Adding the test results as an attachment to keep the formatting sane.
Note on the one occasional failure of the security QRT run: one of the
tests for /proc/pid/maps turns out to be racy at least (I need to talk
to the security team about it). But failing or not failing is only
depending on
The newer version of the drbd8 utils offer a way to include backwards
compatible versions of drbdadm and drbdsetup. So it seemed possible to backport
that version. There were a few details to add but I think I got a version that
seems to work ok within 12.04/Precise and a 3.2 kernel and after
** Attachment added: drbd8-utils_8.4.3-0ubuntu0.12.04.1_i386.deb
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1185756/+attachment/3840757/+files/drbd8-utils_8.4.3-0ubuntu0.12.04.1_i386.deb
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Attachment added: drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1185756/+attachment/3840756/+files/drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
Hi Brian,
not formally yet as I wanted to write that down here as comments with
results. Need to see how much effort it will be to leverage some or more
of the regression testing that xen upstram does on the git repos. But
since I am travelling right now it will get delayed till next week.
--
As it seemed that starting a 64bit hypervisor (qemu-system-x86_64) from
a 32bit user-space running on another 64bit hypervisor has different
issues which seem to go back even further, I concentrated on bisecting
the case of host running 64bit user-space on a 64bit CPU and the first
level guest
Btw, James, this means there is a simple but not very helpful work-
around for Saucy: use AMD CPU based hosts. Did not check for 32bit user-
space on 1rst level but with 64bit and had no issues. Not very
surprising as the regression seems to be in the nested VMX code. But
also not very useful when
** Description changed:
SRU Justification:
Impact: Upstream Xen has released a stable update to 4.2.2. Since Raring
and Saucy are based on 4.2 it would be gaining us bug fixes without
waiting for people to run into them. Like we do with upstream stable on
the kernel.
Fix:
Since I have not heard anything back from Citrix, I did an attempt of
checking myself and found that even without any update to Xen the xen-
api/xcp state is ... highly improvable. The command-line examples in the
README.Debian of xcp-xapi more or less work (with the caveat that you
have to leave
** Patch added: Xen-README.diff
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1218817/+attachment/3795024/+files/Xen-README.diff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
(Ubuntu)
Importance: High
Assignee: Stefan Bader (smb)
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
https://bugs.launchpad.net/bugs/1218817
Title:
[FFE] Update to Xen-4.3 in Saucy
To manage
I uploaded and build the new Xen package in my PPA (ppa:smb/xen):
https://launchpad.net/~smb/+archive/xen/+build/4880118/+files/buildlog_ubuntu-saucy-amd64.xen_4.3.0-0ubuntu3_UPLOADING.txt.gz
Several bugfixes were required in virt-install, libvirt and qemu and
already have been uploaded to Saucy and submitted upstream when
appropriate.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
Add a more recent version of XCP to the Ubuntu Archive: POSTPONED
Write XCP documentation and Openstack: POSTPONED
Test XCP and Openstack: POSTPONED
Write documenation on vmware and Openstack: POSTPONED
Work items
They can be even together. The -nographic removes any emulated graphics
card. I am not sure in detail how the cloud images work, but I believe
serial line as a console is always on. Depending on which release (in
that case I think it is the qemu user-space) the used setup would not
work even.
Actually for Saucy I would rather like to get Xen 4.3 uploaded instead.
** Changed in: xen (Ubuntu Saucy)
Status: In Progress = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
Trying to summarize my testing so far:
Host: saucy 64bit, 1rst level saucy 32bit, 2nd level saucy 32bit:
- 2nd level guest did not start when using qemu-system-x86_64:
- This may be some regression or feature, not sure, yet.
- Using qemu only (defaulting to same arch) the 2nd level guest
So host Q and 1rst 32 completed 35 runs and 1rst 64 completed 40.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
https://bugs.launchpad.net/bugs/1208455
Title:
general protection fault running apt-get inside
I saw a similar crash when running the prepare script with a Saucy64
host, a Saucy32 1rst and Saucy32 2nd level guest. The 1rst level guest
cpu set to core2duo and I also had to replace the qemu-system-x86_64 by
qemu (which maps to the same arch). Otherwise the 2nd level guest was
not started at
Using a 64bit 1rst level guest seemed better on manual runs but running
in loops seemed to have locked up on the third run. Though completely
without any messages. I have to look into that next week. I need to run
again with qmp enabled. At least this allows to check for the
instruction pointer of
Before running prepare-testbed:
- create a directory in /mnt that user ubuntu can write to (say /mnt/adt)
- echo BASEDIR=/mnt/adt ~/.adtrc
autopkgtest should then use /mnt which has lots of space on medium
guests.
--
You received this bug notification because you are a member of Ubuntu
Server
Serge mentioned today on IRC that this may be also a glibc issue, but I
am not sure what exactly he was looking at and why he thinks so.
Apparently ftracing (I guess the qemu process) and some partially
inlining clone function (those with .isra extention) were involved.
--
You received this bug
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
This looks to be the third case we hit with the same symptom (and likely
for yet another reason). The complicating issue is that lxc containers
make use of net namespaces and if those are released, references to I
think the netdevice structures, are temporarily moved over to the
loopback device.
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
I changed it from virt-manager to libvirt as this can be reproduced by
virsh - xen host. And would also remove the affects from virt-manager.
** Summary changed:
- Timeout connecting 12.04 virt-manager to libvirt 1.0.6-0ubuntu1 + xen in Saucy
+ Timeout connecting 12.04 libvirt to libvirt
Scott, what would you think about this. This isn't really a backport but
would seem to do what I was thinking about inside a Xen domU. That
should get verified against a cloud-init deployment somewhere else
(which uses grub-legacy-ec2, if this exists). The one part that could
affect other places
Yeah, the problem, I realised, is that in Lucid we got the linux-ec2
packages installed right now. The plan is to change the dependency of
the meta-package to change from linux-image-*-ec2 to linux-
image-*-virtual (which is a generic-pae or server in fact). The problem
is that ec2 kernels have a
Ah, I probably confused that with the mechanism used to find dom0 usable
kernel. In the end this does not need to be overly clever at all. I
suppose it should be enough just to sort kernels by version and name.
Preferring the ec2 kernel name if there are multiple kernels with the
same version.
Public bug reported:
In order to try transitioning from the specially patched EC2 kernels for Lucid,
we are aiming to have the virtual(server/generic-pae) kernels have the required
Xen drivers built-in. At some point the ec2 meta-package could pull people over
to the other kernels.
For that
Samantha, could you load this module ever before on that HW?
** Summary changed:
- missing kernel module ipmi_si module
+ Kernel module ipmi_si fails to load
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[lars-kurth] sort contributions pie chart by percentage: TODO
[dunlapg] Link to slides that were shown: DONE
[ijc] Ian and Adam discuss grub2 booting Xen first: TODO
[dunlapg] MaaS for installing Xen: TODO
- [stefan
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[serge-hallyn] Have virbr0 not be set to autostart if it's network is in use:
DONE
- [stefan-bader-canonical] watch for libxl patches for xen 4.2: TODO
+ [stefan-bader-canonical] watch for libxl patches for xen 4.2 (see
Blueprint changed by Stefan Bader:
Whiteboard changed:
User Stories:
Risks:
Test Plans:
The qrt libvirt testsuite is to be run before every package upload.
Release Note:
* Libvirt can now be used to launch and test UEFI based VMS.
* Libvirt-qemu can now be set up
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[louis-bouchard] - kdump-tools needs to be MIR / file a bug: DONE
- [stefan-bader-canonical] - discuss linuxcrashdump changes on ubuntu-devel /
ubuntu-kernel: TODO
+ [stefan-bader-canonical] - discuss linuxcrashdump changes
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[lars-kurth] sort contributions pie chart by percentage: TODO
[dunlapg] Link to slides that were shown: DONE
[ijc] Ian and Adam discuss grub2 booting Xen first: TODO
[dunlapg] MaaS for installing Xen: TODO
[stefan
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[lars-kurth] sort contributions pie chart by percentage: TODO
[dunlapg] Link to slides that were shown: DONE
[ijc] Ian and Adam discuss grub2 booting Xen first: TODO
[dunlapg] MaaS for installing Xen: TODO
[dunlapg
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[lars-kurth] sort contributions pie chart by percentage: TODO
[dunlapg] Link to slides that were shown: DONE
[ijc] Ian and Adam discuss grub2 booting Xen first: TODO
[dunlapg] MaaS for installing Xen: TODO
- [dunlapg
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[louis-bouchard] - kdump-tools needs to be MIR / file a bug: TODO
- [smb] - discuss linuxcrashdump changes on ubuntu-devel / ubuntu-kernel: TODO
- [smb] - linuxcrashdump changed to install kdump-tool (after discussion
Reading through comments again I am rather sure this should be in fixed
now.
** Changed in: linux (Ubuntu)
Status: Fix Committed = Fix Released
** Changed in: linux (Ubuntu)
Assignee: Stefan Bader (stefan-bader-canonical) = (unassigned)
--
You received this bug notification because
** Changed in: libvirt (Ubuntu)
Status: Fix Released = Triaged
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in Ubuntu.
https://bugs.launchpad.net/bugs/914788
Title:
libvirt expexts qemu-dm in wrong path for xen
To
Cannot remember but either it was not a problem or nobody really depends
on it. So as long as there isn't someone really in need I would not
touch Oneiric.
** Changed in: libvirt (Ubuntu Oneiric)
Status: Confirmed = Won't Fix
--
You received this bug notification because you are a member
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[zulcss] merge latest upstream libvirt: DONE
[serge-hallyn] finish MIR of netcf bug 904014: DONE
[serge-hallyn] link libvirt against netcf: DONE
- [stefan-bader-canonical] look into transition from xend to libxl: TODO
I have not personally looked (because I have none and no access) on HP servers.
But talking to other people gave the impression that HP not automatically
allows IPMI access. Sounds like it would be some option one needs to buy. So
before asking for debug access, are we sure this should work
Is this hardware that did work before or new hardware?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/1032724
Title:
Cannot access IPMI card
To manage notifications about this
Actually, second question: was ipmitool run as root, too? The /dev/ipmi0
file is only readable by root.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/1032724
Title:
Cannot access
Ok, stupid question as it seems to be obvious from the login prompt,
sorry. Tried this on my machine and it did work, though.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/1032724
One thing I saw in the dmesg: the io memory (0xca8) which the SMBIOS
returns is not registered/reserved before. On my machine there is a
reservation by one of the ACPI PNP devices (PNP0c02).
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
So this seems to cause some errors later and no BMC in found, thus no
device /dev/ipmi0 is created.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/1032724
Title:
Cannot access
without an other changes
and evaluate the situation after that.
I will attach diffs for the merge as I would do it. Please have a look.
Thanks.
** Affects: squid3 (Ubuntu)
Importance: Wishlist
Assignee: Stefan Bader (stefan-bader-canonical)
Status: In Progress
--
You received
** Patch added: ubuntu-merge.debdiff
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1016560/+attachment/3200335/+files/ubuntu-merge.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to squid3 in Ubuntu.
** Patch added: debian-merge.debdiff
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1016560/+attachment/3200336/+files/debian-merge.debdiff
** Patch removed: ubuntu-merge.debdiff
** Patch added: ubuntu-merge.debdiff
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1016560/+attachment/3200338/+files/ubuntu-merge.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to squid3 in Ubuntu.
Realized that I forgot to update the release pocket. Adding an amended
debian-merge diff.
** Patch added: debian-merge-v2.debdiff
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1016560/+attachment/3200355/+files/debian-merge-v2.debdiff
--
You received this bug notification because
I can see the same on most my reboots on a Atom based mini-server. An
educated guess would be that SIGHUP happens before squid3 actually has
set up its own sighandler for it. And the default is exit.
** Changed in: squid3 (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[smoser] jump for joy: DONE
[rbasak] follow up on console log size limit implementation (ringbuffer): TODO
- [stefan-bader-canonical] confirm the xen and qemu prom naming is correct
after the debian merge back: TODO
On 29.05.2012 00:15, Ben Howard wrote:
Oh...
After cracking open a local copy of the image, it looks like linux-
image-virtual has gone away. We are assuming that linux-image-virtual is
going to be there.
Actually no. This may be a result of merging generic and virtual images together
as
Serge, I had not directly thought of it because our discussion went
probably into some confusion when also talking about (bug 949028). But
it would make sense. It is not critical to get it into Ubuntu right now
as the Xen build has been fixed to use the alternative file name which
works.
--
You
Hm, thinking of this again, it does seem to me that the whole allqemu
target and special kvm-ipxe may be Ubuntu specific and neither in
upstream or Debian. Checking the latest Debian source to confirm this...
--
You received this bug notification because you are a member of Ubuntu
Server Team,
Ok, I think I confirmed this to be only in the Ubuntu version. Marc, I
believe you have been working on this. Maybe we could get the change
reviewed and loosely queued (without upload) to be picked up whenever
something serious (or the next release) come up?
--
You received this bug notification
This is how I would propose to do the fix. It keeps the target names for
kvm-ipxe but modifies the file names in the makefile and target name for
the links. I did it that way because to fix the Xen issue I modified the
xen package to look for the 8086100e.rom.
Before:
The bug, if to say so, is that for kvm there have been additional rom image
targets added. By the way the build system for ipxe works, I believe all the
required rom images have been build already by the makeall (whatever it is
called again). Just the names are different for some of them (for
Or actually modify the QEMUS line instead of removing things:
QEMUS = 8086100e ne pcnet32 rtl8139 virtio-net
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipxe in Ubuntu.
https://bugs.launchpad.net/bugs/948323
Title:
Rom images
Public bug reported:
The build system depends on a certain naming scheme of the rom images.
The basename of the rom file (e.g. rtl8139.rom - rtl8139) must be
defined in the drivers PCI_ROM or ISA_ROM makro. For the rtl8139 driver
this is correctly done:
PCI_ROM(0x10ec, 0x8139, rtl8139,
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipxe in Ubuntu.
https://bugs.launchpad.net/bugs/948323
Title:
Rom images for e1000 and ne2k missign vendor and device id
To manage notifications about this bug go to:
Ok, / is non-sense as it is certainly mounted and also the failing fsck
is fot /mnt. But generally it looks like mountall and cloud-init running
concurrently and anything that opens the device may block a rw access
for the fsck. So any blkid could do that. The window is not very big but
who
Hm weird. I would have expected at least a rw open on the block device should
fail, let alone a ro (since fsck probably wants to modify the fs). Though I'd
need to check exactly what access mode mount -oro uses (maybe its some ro
exclusive). Actually it is not really a read-only open on the
Hm, when I look at /etc/init/cloud-init-local.conf and */cloud-init.conf
they seem to say start on mounted MOUNTPOINT=/. So I'd somehow expect
mountall to be finished with / at that point. Still the output of cloud-
init and mountall seem to intermix often. As if they are executed around
the same
*** This bug is a duplicate of bug 662711 ***
https://bugs.launchpad.net/bugs/662711
This is actually fixed in Precise by a change to nfs-utils for bug
#662711. For that reason I'll mark the bug report here as a duplicate.
** Changed in: module-init-tools (Ubuntu)
Status: New =
201 - 300 of 346 matches
Mail list logo
