Ubuntu
libvirt package

Cannot use /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf as bootloader due to AppArmor

Bug #1990499 reported by Isaac True on 2022-09-22

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	libvirt (Ubuntu)	Fix Released	Undecided	Unassigned
	Jammy	Fix Released	Undecided	Unassigned

Bug Description

[ Impact ]

* Riscv gets more and more common, but still lacking
   real (or powerful) HW it is often used in an emulated
   environment. So far people usually directly call qemu,
   but for the benefit of better lifecycle management and
   many comfort features they start to drive it through
   libvirt. But when doing so they are blocked by the
   apparmor guest isolation.

  * Fix by allowing virt-aa-helper to consider adding
    the paths that Ubuntu delivers the boot elements
    for riscv64. That means only guests configuring
    for it in the XML can access that - and even those
    just read-only

[ Test Plan ]

# apt install -y libvirt-daemon-system qemu-system
# wget https://cdimage.ubuntu.com/releases/22.04.1/release/ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img.xz
# unxz ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img.xz
# mv ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img /var/lib/libvirt/images/
# cat << EOF > riscv-guest.xml
<domain type='qemu'>
    <name>ubuntu22.10-riscv64</name>
    <os>
        <type arch='riscv64' machine='virt'>hvm</type>
<kernel>/usr/lib/u-boot/qemu-riscv64_smode/uboot.elf</kernel>
<loader readonly="yes" type="rom">/usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf</loader>
    </os>
    <memory unit="GiB">2</memory>
    <vcpu placement="static">4</vcpu>
    <devices>
        <emulator>usr/bin/qemu-system-riscv64</emulator>
        <disk type='file' device='disk' cache='none'>
          <driver name='qemu' type='raw'/>
   <source file='/var/lib/libvirt/images/ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img'/>
          <target dev='sda' bus='scsi'/>
        </disk>
<controller type='scsi' model='virtio-scsi'/>
        <interface type='network'>
            <source network='default'/>
            <target dev='vnet0'/>
        </interface>
        <console type='pty'>
            <target type='serial' port='0'/>
        </console>
    </devices>
</domain>
EOF
# virsh define riscv-guest.xml
# virsh start ubuntu22.10-riscv64
error: Failed to start domain 'ubuntu22.10-riscv64'
error: internal error: cannot load AppArmor profile 'libvirt-e4089ffc-671d-4d28-9fa5-d0d52dc2d67f'

And in the journal I pick up the mentioned error:
internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u libvirt-e4089ffc-671d-4d28-9fa5-d0d52dc2d67f) unexpected exit status 1: virt-aa-helper: error: /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf
virt-aa-helper: error: skipped restricted file
virt-aa-helper: error: invalid VM definition
internal error: cannot load AppArmor profile 'libvirt-e4089ffc-671d-4d28-9fa5-d0d52dc2d67f'

With the fix in place virt-aa-helper will no more spill those messages to the log and create a per-guest file that allows the access to those files.

[ Where problems could occur ]

* This is not reducing, but allowing more access and therefore
   has much smaller regression risk than vice versa. To be on the
   save side (as with other roms and such) we only add this to
   the guest rules when configured on the host and never with a
   write rule. Together that is considered safe.

* So much for safety, on the functional side if we messed up
   virt-aa-helper the potential regressions would be
   a) break when executed -> no apparmor rules breaking guest start
   b) runs, but emits odd rules -> guest could access more
   Gladly the change is rather small and both risks are considered
   highly unlikely, but in any case that is how the potential risk would
   most likely surface.

[ Other Info ]

@SRU team - 1989078 (just entered J-proposed) and 1990499 (this upload) could land together in Jammy if you want. It is just that 1989078 was delayed for quite some time waiting in -unapproved, but I'm more than happy to re-generate 8.0.0-1ubuntu7.3 with -V 8.0.0-1ubuntu7.1 - in that case we could have ONE (1) update released to users.

Avoids one extra download for many people.
And they are even thematically close (apparmor handling for less common architectures)
Ping me (paelzer) if you prefer to do it this way.

---- original report ----

I am trying to adapt the guide to booting the riscv64 QEMU image from https://wiki.ubuntu.com/RISC-V to work with libvirt, but I'm running into an AppArmor issue:

Sep 22 11:07:06 Isaac-Laptop libvirtd[6243]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-86ff0d62-f2fc-4f21-b84a-dc8c3e8097ff) unexpected exit status 1: 2022-09-22 09:07:06.069+0000: 34566
75: info : libvirt version: 8.0.0, package: 1ubuntu7.1 (Christian Ehrhardt <email address hidden> Thu, 19 May 2022 08:14:48 +0200)#0122022-09-22 09:07:06.069+0000: 3456675: info : hostname: Isaac-Laptop#0122022-09-22 09:07:06.069+0000: 34
56675: error : virStorageFileBackendFileRead:109 : Failed to open file '/dev/zvol/rpool/vm/ubuntu-22.04-riscv64': Permission denied#012virt-aa-helper: error: /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf#012virt-aa-helper: error: skipped restricted fi
le#012virt-aa-helper: error: invalid VM definition

This seems to be caused by the U-Boot path not being permitted by AppArmor to be used by libvirt.

I'm using the following XML snippet for setting the loader and kernel (adapted from the QEMU instructions):

  <os>
    <type arch="riscv64" machine="virt">hvm</type>
    <loader readonly="yes" type="rom">/usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf</loader>
    <kernel>/usr/lib/u-boot/qemu-riscv64_smode/uboot.elf</kernel>
  </os>

Moving the U-Boot binary to /var/tmp/uboot.elf resolves this issue, but libvirt then generates another AppArmor error due to the fw_jump.elf file:

Sep 22 11:12:09 Isaac-Laptop libvirtd[6243]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-86ff0d62-f2fc-4f21-b84a-dc8c3e8097ff) unexpected exit status 1: 2022-09-22 09:12:09.664+0000: 3461255: info : libvirt version: 8.0.0, package: 1ubuntu7.1 (Christian Ehrhardt <email address hidden> Thu, 19 May 2022 08:14:48 +0200)#0122022-09-22 09:12:09.664+0000: 3461255: info : hostname: Isaac-Laptop#0122022-09-22 09:12:09.664+0000: 3461255: error : virStorageFileBackendFileRead:109 : Failed to open file '/dev/zvol/rpool/vm/ubuntu-22.04-riscv64': Permission denied#012virt-aa-helper: error: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf#012virt-aa-helper: error: skipped restricted file#012virt-aa-helper: error: invalid VM definition

Moving this to /var/tmp/fw_jump.elf also resolves this issue and allows the VM to boot.

Should these two file paths be added to the AppArmor rules? Maybe the equivalent paths for all architectures should be added?

---

$ lsb_release -rd
Description: Ubuntu 22.04.1 LTS
Release: 22.04

$ apt policy libvirt0
libvirt0:
  Installed: 8.0.0-1ubuntu7.1
  Candidate: 8.0.0-1ubuntu7.1
  Version table:
*** 8.0.0-1ubuntu7.1 500
        500 http://de.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     8.0.0-1ubuntu7 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

See original description

Tags:

Related branches

~paelzer/ubuntu/+source/libvirt:lp-1990499-riscv64-loader-apparmor-KINETIC-v2

Merged into ubuntu/+source/libvirt:ubuntu/kinetic-devel at revision eddcbb0255640c6f35d47c1c450e7515e90f3659

git-ubuntu bot: Approve on 2022-10-04

Sergio Durigan Junior (community): Approve on 2022-10-04

Canonical Server Reporter: Pending requested 2022-10-04

~paelzer/ubuntu/+source/libvirt:lp-1990499-riscv64-loader-apparmor-JAMMY-v2

Merged into ubuntu/+source/libvirt:ubuntu/jammy-devel at revision 34dcf774abdace4d5d50a7c9eac9ceca8bc75eb7

git-ubuntu bot: Approve on 2022-10-04

Sergio Durigan Junior (community): Approve on 2022-10-04

Canonical Server Reporter: Pending requested 2022-10-04

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-09-22:

Thank Isaac, I thought we do generate the paths in loader / kernel in aa-helper into the rules.
If not we should :-)

I'll need some time to have a real look myself, and time is scarce atm :-/

Can you until then provide:
1. the release you are on
2. the packages you installed to get uboot and all other elements in place
3. the full guest XML you are using

Revision history for this message

Isaac True (itrue) wrote on 2022-09-22:

ubuntu22.04-riscv64.xml Edit (7.9 KiB, application/xml)

Release: 22.04.1 amd64

Loader package: opensbi

$ apt policy opensbi
opensbi:
  Installed: 1.0-3ubuntu1
  Candidate: 1.0-3ubuntu1
  Version table:
*** 1.0-3ubuntu1 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main i386 Packages
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://ports.ubuntu.com jammy/main arm64 Packages
        500 http://ports.ubuntu.com jammy/main armhf Packages
        500 http://ports.ubuntu.com jammy/main riscv64 Packages
        100 /var/lib/dpkg/status

U-Boot package: u-boot-qemu

$ apt policy u-boot-qemu
u-boot-qemu:
  Installed: 2022.01+dfsg-2ubuntu2
  Candidate: 2022.01+dfsg-2ubuntu2
  Version table:
*** 2022.01+dfsg-2ubuntu2 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main i386 Packages
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://ports.ubuntu.com jammy/main arm64 Packages
        500 http://ports.ubuntu.com jammy/main armhf Packages
        500 http://ports.ubuntu.com jammy/main riscv64 Packages
        100 /var/lib/dpkg/status

Guest XML is attached

Revision history for this message

Heinrich Schuchardt (xypron) wrote on 2022-09-22:

QEMU 7.0 comes with an internal version of OpenSBI which is in package qemu-system-data, file /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin.

You should not need parameter -bios once you are on QEMU 7.0:

/usr/bin/qemu-system-riscv64 \
-machine virt -nographic -m 2048 -smp 4 \
-kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \
-device virtio-net-device,netdev=eth0 -netdev user,id=eth0 \
-drive file=ubuntu-20.04.5-preinstalled-server-riscv64+unmatched.img.xz,format=raw,if=virtio

When using KVM the parameter bios is explicitly forbidden for RISC-V.

@Isaac
Could you, please, retest on Kinetic without
<loader readonly="yes" type="rom">/usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf</loader>
This will allow us to understand if only Jammy needs a fix.

Revision history for this message

Isaac True (itrue) wrote on 2022-09-22:

@Heinrich

On 22.10 daily with qemu-system-misc 7.0+dfsg-7ubuntu2 I still get the AppArmor exception due to the U-Boot binary:

Sep 22 17:19:52 vm-kinetic libvirtd[14801]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u libvirt-65ce8bc3-7adf-465b-b2d8-438942789983) unexpected exit status 1: virt-aa-helper: error: /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf#012virt-aa-helper: error: skipped restricted file#012virt-aa-helper: error: invalid VM definition

Moving the binary to /var/tmp/uboot.elf allows it to boot (as on 22.04) without specifying the fw_jump.elf binary as the loader.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-09-27:

I can recreate the same with these simple steps in Jammy (independent to the add-loader or not):

$ wget https://cdimage.ubuntu.com/releases/22.04.1/release/ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img.xz
$ mv ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img /var/lib/libvirt/images/
$ cat << EoF > riscv-guest.xml
<domain type='qemu'>
    <name>ubuntu22.10-riscv64</name>
    <os>
        <type arch='riscv64' machine='virt'>hvm</type>
<kernel>/usr/lib/u-boot/qemu-riscv64_smode/uboot.elf</kernel>
<loader readonly="yes" type="rom">/usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf</loader>
    </os>
    <memory unit="GiB">2</memory>
    <vcpu placement="static">4</vcpu>
    <devices>
        <emulator>usr/bin/qemu-system-riscv64</emulator>
        <disk type='file' device='disk' cache='none'>
          <driver name='qemu' type='raw'/>
   <source file='/var/lib/libvirt/images/ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img'/>
          <target dev='sda' bus='scsi'/>
        </disk>
<controller type='scsi' model='virtio-scsi'/>
        <interface type='network'>
            <source network='default'/>
            <target dev='vnet0'/>
        </interface>
        <console type='pty'>
            <target type='serial' port='0'/>
        </console>
    </devices>
</domain>
EOF
$ virsh define riscv-guest.xml
$ virsh start ubuntu22.10-riscv64
error: Failed to start domain 'ubuntu22.10-riscv64'
error: internal error: cannot load AppArmor profile 'libvirt-e4089ffc-671d-4d28-9fa5-d0d52dc2d67f'

P.S. when bypassing apparmor I realized I'd still need to munge the disc a bit to be able to boot, but that problem is for another day.

I can recreate the same with these simple steps in Jammy (independent to the add-loader or not):

$ wget https://cdimage.ubuntu.com/releases/22.04.1/release/ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img.xz
$ mv ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img /var/lib/libvirt/images/
$ cat << EoF > riscv-guest.xml
<domain type='qemu'>
    <name>ubuntu22.10-riscv64</name>
    <os>
        <type arch='riscv64' machine='virt'>hvm</type>
	<kernel>/usr/lib/u-boot/qemu-riscv64_smode/uboot.elf</kernel>
	<loader readonly="yes" type="rom">/usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf</loader>
    </os>
    <memory unit="GiB">2</memory>
    <vcpu placement="static">4</vcpu>
    <devices>
        <emulator>usr/bin/qemu-system-riscv64</emulator>
        <disk type='file' device='disk' cache='none'>
          <driver name='qemu' type='raw'/>
	  <source file='/var/lib/libvirt/images/ubuntu-22.04.1-preinstalled-server-riscv64+unmatched.img'/>
          <target dev='sda' bus='scsi'/>
        </disk>
	<controller type='scsi' model='virtio-scsi'/>
        <interface type='network'>
            <source network='default'/>
            <target dev='vnet0'/>
        </interface>
        <console type='pty'>
            <target type='serial' port='0'/>
        </console>
    </devices>
</domain>
EOF
$ virsh define riscv-guest.xml
$ virsh start ubuntu22.10-riscv64
error: Failed to start domain 'ubuntu22.10-riscv64'
error: internal error: cannot load AppArmor profile 'libvirt-e4089ffc-671d-4d28-9fa5-d0d52dc2d67f'

And in the journal I pick up the mentioned error:
internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u libvirt-e4089ffc-671d-4d28-9fa5-d0d52dc2d67f) unexpected exit status 1: virt-aa-helper: error: /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf
                 virt-aa-helper: error: skipped restricted file
                 virt-aa-helper: error: invalid VM definition
internal error: cannot load AppArmor profile 'libvirt-e4089ffc-671d-4d28-9fa5-d0d52dc2d67f'

P.S. when bypassing apparmor I realized I'd still need to munge the disc a bit to be able to boot, but that problem is for another day.

Changed in libvirt (Ubuntu):
status:	New → Confirmed

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-09-27:

And that can again be reproduced easier afterwards without libvirt then.
$ virsh dumpxml ubuntu22.10-riscv64 > testguest.xml
$ /usr/lib/libvirt/virt-aa-helper -c -u libvirt-e4089ffc-671d-4d28-9fa5-d0d52dc2d67f < testguest.xml
virt-aa-helper: error: /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf
virt-aa-helper: error: skipped restricted file
virt-aa-helper: error: invalid VM definition

That we can use for debugging, but it already looks pretty obvious - more in the next comment ...

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-09-27:

Download full text (5.0 KiB)

The file placement of these
u-boot-qemu: /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf
opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf
is not ideal.

Roms and helpers are usually meant to be in
/usr/share/qemu/

There you'd find firmwares, roms and such binaries.

But /usr/lib is explicitly prohibited, quote:

The file placement of these
  u-boot-qemu: /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf
  opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf
is not ideal.

Roms and helpers are usually meant to be in
  /usr/share/qemu/

There you'd find firmwares, roms and such binaries.

But /usr/lib is explicitly prohibited, quote:

"""
  /*                                                                               
   * Don't allow access to special files or restricted paths such as /bin, /sbin,  
   * /usr/bin, /usr/sbin and /etc. This is in an effort to prevent read/write          
   * access to system files which could be used to elevate privileges. This is a   
   * safety measure in case libvirtd is under a restrictive profile and is         
   * subverted and trying to escape confinement.                                   
   *                                                                               
   * Note that we cannot exclude block devices because they are valid devices.         
   * The TEMPLATE file can be adjusted to explicitly disallow these if needed.         
   *                                                                               
   * RETURN: -1 on error, 0 if ok, 1 if blocked                                    
   */                                                                              
  static int                                                                       
  valid_path(const char *path, const bool readonly)                                
  {                                                                                
      const char * const restricted[] = {                                          
          "/bin/",                                                                 
          "/etc/",                                                                 
          "/lib",                                                                  
          "/lost+found/",                                                          
          "/proc/",                                                                
          "/sbin/",                                                                
          "/selinux/",                                                             
          "/sys/",                                                                 
          "/usr/bin/",                                                             
          "/usr/lib",                                                              
          "/usr/sbin/",                                                            
          "/usr/share/",                                                           
          "/usr/local/bin/",                                                       
          "/usr/local/etc/",                                                       
          "/usr/local/lib",                                                        
          "/usr/local/sbin/"                                                       
      };
      /* these paths are ok for readonly, but not read/write */                    
      const char * const restricted_rw[] = {                                       
          "/boot/",                                                                
          "/vmlinuz",                                                              
          "/initrd",                                                               
          "/initrd.img",                                                           
          "/usr/share/edk2/",                                                      
          "/usr/share/OVMF/",              /* for OVMF images */                   
          "/usr/share/ovmf/",              /* for OVMF images */                   
          "/usr/share/AAVMF/",             /* for AAVMF images */                  
          "/usr/share/qemu-efi/",          /* for AAVMF images */                  
          "/usr/share/qemu-efi-aarch64/"   /* for AAVMF images */                  
      };                                                                           
      /* override the above with these */                                          
      const char * const override[] = {                                            
          "/sys/devices/pci",                /* for hostdev pci devices */         
          "/sys/kernel/config/target/vhost", /* for hostdev vhost_scsi devices */  
          "/etc/libvirt-sandbox/services/"   /* for virt-sandbox service config */ 
      }; 
"""

Due to that virt-aa-helper which usually is responsible to add paths mentioned in the guest config can not add them.

We can not change the on disc location, since they are out in the field.
Therefore I think for this particular case we want to add those path prefixes (matching the packaged location) to explicitly allow those, despite being under /usr/lib.
- /usr/lib/u-boot/
- /usr/lib/riscv64-linux-gnu/opensbi

I can create a patch for that and build PPAs with it.
If it works fine for us I can submit that to upstream and once accepted we'd drive those fixes into Jammy+Kinetic.

Changed in libvirt (Ubuntu):
status:	Confirmed → Triaged

Revision history for this message

Isaac True (itrue) wrote on 2022-09-27:

> Therefore I think for this particular case we want to add those path prefixes (matching the packaged location) to explicitly allow those

Sounds good! Thanks for looking into it

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-09-27:

FYI - PPA with ain idea for a fix started building in
https://launchpad.net/~paelzer/+archive/ubuntu/lp-1990499-libvirt-riscv64-apparmor

If that succeeds I'll propose the change to upstream.

Revision history for this message

Isaac True (itrue) wrote on 2022-09-27:

#10

That's fixed it! Thanks Christian. Verified with your PPA

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-09-29:

#11

Thanks Isaac for the test, submitted upstream => https://listman.redhat.com/archives/libvir-list/2022-September/234531.html

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-10-04:

#12

The change got upstream accepted, I updated the PPA builds (no functional change, just the correct final references now).
I opened MPs for a fix in Kinetic/Jammy
- https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/430945
- https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/430946

Christian Ehrhardt  (paelzer) on 2022-10-04

description:

updated

Sergio Durigan Junior (sergiodj) on 2022-10-04

description:

updated

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-10-05:

#13

FYI
- uploaded to kinetic
- after quite some time 1989078 landed in j-proposed and I rebased and uploaded this for jammy as well

Avoids one extra download for many people.
And they are even thematically close (apparmor handling for less common architectures)
Ping me if you prefer to do it this way.

Changed in libvirt (Ubuntu Jammy):
status:	New → Triaged
Changed in libvirt (Ubuntu):
status:	Triaged → Fix Committed
description:	updated

Revision history for this message

Launchpad Janitor (janitor) wrote on 2022-10-08:

#14

This bug was fixed in the package libvirt - 8.6.0-0ubuntu3

---------------
libvirt (8.6.0-0ubuntu3) kinetic; urgency=medium

  * d/p/u/lp-1990499-virt-aa-helper-allow-common-riscv64-loader-paths.patch:
    easen the use of riscv64 through libvirt (LP: #1990499)
  * d/p/u/lp-1990949-virpcivpd-reduce-errors-in-log-due-to-invalid-VPD.patch:
    reduce log noise by invalid VPD data (LP: #1990949)

-- Christian Ehrhardt <email address hidden> Tue, 04 Oct 2022 08:29:46 +0200

Changed in libvirt (Ubuntu):
status:	Fix Committed → Fix Released

Revision history for this message

Timo Aaltonen (tjaalton) wrote on 2022-10-17: Please test proposed package

#15

Hello Isaac, or anyone else affected,

Accepted libvirt into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/8.0.0-1ubuntu7.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in libvirt (Ubuntu Jammy):
status:	Triaged → Fix Committed
tags:	added: verification-needed verification-needed-jammy

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-10-17:

#16

Download full text (4.9 KiB)

Before the update:

root@j:~# virsh start ubuntu22.10-riscv64
error: Failed to start domain 'ubuntu22.10-riscv64'
error: internal error: cannot load AppArmor profile 'libvirt-0273b78b-6c73-43cb-a64c-746067d84088'

Upgrade:

Other bug subscribers

Bug attachments

ubuntu22.04-riscv64.xml Edit

Add attachment

Remote bug watches

Bug watches keep track of this bug in other bug trackers.

Ubuntulibvirt package

Cannot use /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf as bootloader due to AppArmor

Bug Description

Related branches

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
libvirt package