** Changed in: initramfs-tools (Ubuntu)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1931725
Title:
initramfs-tools: use zstd as the default compression method
```
However, on the c6g.metal instance, while apt did not report an error, there
were error messages printed out:
Inserting key update /usr/share/secureboot/updates/dbx/dbxupdate_arm64.bin into
dbx
Error writing key update: Invalid argument
Error syncing keystore file
$ reverse-depends -b dwarves
Reverse-Testsuite-Triggers
* linux
* linux-aws
* linux-azure
* linux-gcp
* linux-kvm
* linux-oracle
* linux-riscv
Thus if update to dwarves regresses the kernel test-suite, it will be
blocked from updating.
--
You received this bug notification because you are a
And for v5.13 kernels even newer dwarves-dfsg is needed.
** Changed in: dwarves-dfsg (Ubuntu Bionic)
Status: Confirmed => Won't Fix
** Changed in: linux (Ubuntu Bionic)
Status: Confirmed => Won't Fix
** Changed in: dwarves-dfsg (Ubuntu)
Status: Confirmed => Fix Released
**
https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-460 460.84
is available in impish-proposed, but as dkms only at the moment - not
yet available as signed lrm package.
It would be nice to know if 460.84 works or not.
--
You received this bug notification because you are a member of
Public bug reported:
linux-uc20-efi: make it easy to build derivative kernel.efi
Currently debian/rules & debian.uc20-efi/control.stub are tightly
coupled and hardcode the source package name (linux-uc20-efi), its
relationship to linux-unsigned-image-* packages, and flavours to build
kernel.efi
** Patch added:
"0001-selftests-bpf-add-ifdefs-in-tests-for-required-Clang.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931129/+attachment/5502940/+files/0001-selftests-bpf-add-ifdefs-in-tests-for-required-Clang.patch
--
You received this bug notification because you are a
Public bug reported:
selftests/bpf: add ifdefs in tests for required Clang versions
This codifies the clang version requirements from README.rst in the
code, such that only expected working test cases are compiled for the
expected clang version combinations. This insures that most tests are
Public bug reported:
support for .ko.hash signatures
Sometimes we would like to sign .ko kernel modules, that we cannot
redistribute (i.e. linked nvidia .ko).
At the moment we attempt to sign them in private ppa builds only, then
extract detached signatures and whip those along with unlinked .o
Testing again, but without initramfs-tools installed, and with kernel-
img.conf set to do_initrd = yes and link_in_boot = no
End result is this:
# ls -l /vmlinu* /initrd.img* /boot/initrd.img*
ls: cannot access '/boot/initrd.img*': No such file or directory
lrwxrwxrwx 1 root root 53 May 28 10:30
Redid the test case with initramfs-tools installed and the updated
linux-base patch.
Installed generic, links pointed at generic.
Installed lowlatency, old pointed at generic and the current links pointed at
lowlatency.
Installed a kernel using installkernel script to /boot, old points at
Actually I think there is a way to buy hardware for this still.
Upstream development has stalled for 2 years now
https://github.com/asterisk/dahdi-linux
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
We should reach out to asterisk community about it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1929830
Title:
RM dahdi-linux hardware and upstream do not exist for years
To manage notifications
Public bug reported:
RM dahdi-linux hardware and upstream do not exist for years
Ubuntu effectively keeps on maintaining this, despite having no users or
hardware available for decades now.
Imho we should remove dahdi-linux from the archive.
Including support for new hwe kernels in stable
** Patch added: "lp1929255.patch"
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+attachment/5500691/+files/lp1929255.patch
** Patch removed: "lp1929255.patch"
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+attachment/5500663/+files/lp1929255.patch
# dpkg-query -W initramfs-tools linux-base
initramfs-tools 0.140ubuntu4
linux-base 4.5ubuntu8
# cat /etc/kernel-img.conf
do_symlinks = yes
do_bootloader = no
do_initrd = yes
link_in_boot = no
# ls -latr / | grep '> boot'
# apt install linux-generic
# ls -l / | grep '> boot'
lrwxrwxrwx 1
aha, my xx-update-initrd-links lost executable bit again. need to fix that up
in my packaging.
But also invalidates my previous test a bit.
# installkernel 5.13.0-051300rc3daily20210526-generic
./linux/boot/vmlinuz-5.13.0-051300rc3daily20210526-generic
** Description changed:
[Impact]
## Problem description
Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script
incorrectly detects symbolic links targets and then creates malformed
(hence broken) ones instead:
/initrd.img ->
** Description changed:
+ [Impact]
+
## Problem description
Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script
incorrectly detects symbolic links targets and then creates malformed
(hence broken) ones instead:
/initrd.img ->
Untested yet, but here is a proposed patch which hopefully will fix
installkernel in all link_in_boot modes, without regressing anything.
** Patch added: "lp1929255.patch"
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+attachment/5500663/+files/lp1929255.patch
--
You
Ubuntu Kernels in their postinst call linux-update-symlinks $change
$version $image_path to setup correct links.
This was not done by installkernel script, and a broken xx-update-
initrd-links script is being added to postinst.d that does not correctly
handle link_in_boot setting and breaks
On a given system we can have the following symlinks
/vmlinuz.old -> boot/vmlinuz-4.15.0-144-lowlatency
/vmlinuz -> boot/vmlinuz-4.15.0-144-generic
/boot/vmlinuz.old -> vmlinuz-4.15.0-144-lowlatency
/boot/vmlinuz -> vmlinuz-4.15.0-144-generic
which is controlled by /etc/kernel-img.conf setting
But we do call linux-update-symlinks in the maintainer scripts.
why doesn't installkernel call that, horum.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1929255
Title:
update-initrd-links
linux-update-symlinks install 4.15.0-144-generic
/boot/vmlinuz-4.15.0-144-generic => generates correct symlinks for
vmlinuz{.old} with both link_in_boot and without link_in_boot.
I am confused how come Debian kernels call linux-update-symlinks and
Ubuntu kernels (and upstream) do not.
--
You
I'm also not sure why that script exists at all in the current form.
I would have thought we could switch to linux package themselves to call
linux-update-symlinks like it is done in debian.
Or at least not reimplement the wheel and just call linux-update-
symlinks directly.
--
You received
Possibly a regression is being reported
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255
Please investigate, and if that needs fixing, please take appropriate
action. If determined to not be a regression, please remove the
validation-failed tags.
** Tags added:
Possibly a regression is being reported
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255
Please investigate, and if that needs fixing, please take appropriate
action. If determined to not be a regression, please remove the
validation-failed tags.
** Tags removed:
** Tags added: regresion-proposed regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1929255
Title:
update-initrd-links creates incorrect symlinks
To manage notifications about this
wwn: '0x5000' is not a valid wwn and should have been
rejected by udev & probert. All zeros are not allowed, and 5 is just a
prefix.
I think this is an OEM / whitelabel drive, with expectation that
somebody who ships these drives will use their WWN prefix and flash
their own WWN as
Hi,
5.4.0-1036.39 kernel is in focal-proposed. As a snap it is in 20/beta
channel.
You should be able to refresh pi-kernel from --channel 20/beta. If that
doesn't work, please boot and try one of the daily beta images for your
board.
Regards,
Dimitri.
--
You received this bug notification
** Tags added: bionic xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1929413
Title:
aws arm64 shipped tracking linux-aws-edge in xenial and never rolled
off
To manage notifications about
** Summary changed:
- linux-aws-hwe missing from bionic+ failing to upgrade from xenial on arm64
+ aws arm64 shipped tracking linux-aws-edge and never rolled off
** Description changed:
- linux-aws-hwe missing from bionic+ failing to upgrade from xenial on
- arm64
+ Looks like xenial instances
Public bug reported:
linux-aws-hwe missing from bionic+ failing to upgrade from xenial on
arm64
Possibly linux-aws must specify migration flavours, on arm64 from linux-
aws-hwe to linux-aws.
** Affects: linux-meta-aws-hwe (Ubuntu)
Importance: Undecided
Status: New
--
You
i still want to somehow eliminate efivars being missbuilt and not
garbage collected.
separately juliank is working on making shim _not_ mirror variables
which should make things better.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Description changed:
Currently this package generates /boot/grub/gfxblacklist.txt which is
processed with hwmatch which is only available on grub-pc platform and
not on the uefi platform.
on uefi platform we instead have smbios command.
Can we update grub-gfxpayload-lists &
Public bug reported:
Currently this package generates /boot/grub/gfxblacklist.txt which is
processed with hwmatch which is only available on grub-pc platform and
not on the uefi platform.
on uefi platform we instead have smbios command.
Can we update grub-gfxpayload-lists & grub to generate
Steve I'm not sure one gets valid grub2 binaries by building with
bionic's toolchain on neither amd64 nor arm64.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928674
Title:
grub-efi-amd64 from
** Description changed:
[Impact]
* gnutls28 fails to talk to letsencrypt website past September 2021,
despite trusting the letsencrypt root certificate.
[Test Plan]
* Import staging cert equivalent to ISRG Root X1
** Information type changed from Public to Public Security
** Tags removed: letsencrypt
** Tags added: letsencryptexpiry
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928989
Title:
expiring trust
Public bug reported:
[Impact]
* openssl fails to talk to letsencrypt website past September 2021,
despite trusting the letsencrypt root certificate.
[Test Plan]
* Import staging cert equivalent to ISRG Root X1
https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
* Import
** Tags added: letsencrypt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928648
Title:
expiring trust anchor compatibility issue
To manage notifications about this bug go to:
** Description changed:
[Impact]
- * gnutls28 fails to talk to letsencrypt website past September 2021,
+ * gnutls28 fails to talk to letsencrypt website past September 2021,
despite trusting the letsencrypt root certificate.
[Test Plan]
- * Import staging cert equivalent to
** Description changed:
+ [Impact]
+
+ * gnutls28 fails to talk to letsencrypt website past September 2021,
+ despite trusting the letsencrypt root certificate.
+
+ [Test Plan]
+
+ * Import staging cert equivalent to ISRG Root X1
** Description changed:
- https://community.letsencrypt.org/t/openssl-client-compatibility-
- changes-for-let-s-encrypt-certificates/143816
+
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
+
How can you introduce conffiles in grub-efi-amd64 & grub-efi-arm64 which
is shared across releases? If in later series they have been removed
from said package. That will cause a mess in focal+ then, since it will
conflict with grub2-common there.
Given that the future is for these conffiles to
We should not add opal keys to the built_trusted_keys_keyring as that's
not the purpose of these keys. We could add them direct to .platform or
.ima keyrings, but it would be best to load them from firmware direct.
Are the above attached keys & ESL available from the "powerpc:db"?
--
You
** Attachment added: "opal.esl"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1903288/+attachment/5498450/+files/opal.esl
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1903288
Title:
** Attachment added: "opal-2019-ppc64el.pem"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1903288/+attachment/5498449/+files/opal-2019-ppc64el.pem
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Attachment added: "opal-2017-ppc64el.pem"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1903288/+attachment/5498448/+files/opal-2017-ppc64el.pem
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Nayna Jain @Daniel
Hm but we have CONFIG_LOAD_PPC_KEYS=y already which I would expect
to be the only thing that loads keys into .platform keyring which was
enabled as part of
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1866909 LTC-184073
. Which keys are present in firmware / get
@kebkeb you can download that efivariable as a file into the efivars
dir. Or you need to compile the new mokutil that supports setting that
on non-secureboot systems too.
See
https://github.com/lcp/mokutil/commit/03bb7af4a84c39f2417fd14ef20b11b2e8d1ad51
Is this something you can compile
** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914279
Title:
linux from
*** This bug is a security vulnerability ***
Public security bug reported:
[Impact]
* Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx)
which revokes many Ubuntu kernel hashes and 2012 signing key.
* Kernel should import those into it's %:.blacklist keyring such that
it
** Description changed:
[Impact]
* /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
with grub-efi-arm64-signed installed, without grub-efi-arm64.
* /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
with grub-efi-amd64-signed installed without
*** This bug is a security vulnerability ***
Public security bug reported:
[Impact]
* /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
with grub-efi-arm64-signed installed, without grub-efi-arm64.
* /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
with
*** This bug is a security vulnerability ***
Public security bug reported:
https://community.letsencrypt.org/t/openssl-client-compatibility-
changes-for-let-s-encrypt-certificates/143816
Currently gnutls28 in bionic and earlier will not establish a
connection, if any parts of the trust chain
For your current work around to persist, you should also do:
$ sudo dpkg-divert /usr/lib/shim/shimx64.efi.signed
$ sudo cp /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
/usr/lib/shim/shimx64.efi.signed
This way whenever grub-install is called, _grub_ is used instead of
shim.
Unfortunately
** Description changed:
- When booting v5.11 based riscv unmatched image in qemu with uboot, it
- fails to boot.
+ [Impact]
- When booting v5.11 based riscv unmatched kernel+initrd directly, it
- boots fine.
+ * u-boot may crash when attempting to boot extlinux.conf which
+ specifies fdtdir;
** Changed in: shim-signed (Ubuntu)
Status: New => Triaged
** Changed in: shim-signed (Ubuntu)
Importance: Undecided => Critical
** Changed in: shim (Ubuntu)
Importance: Undecided => Critical
** Changed in: shim (Ubuntu)
Status: New => Triaged
--
You received this bug
** Changed in: u-boot (Ubuntu)
Status: Fix Released => New
** Changed in: u-boot (Ubuntu Hirsute)
Status: Fix Released => Triaged
** Changed in: u-boot (Ubuntu Hirsute)
Status: Triaged => New
** Changed in: u-boot (Ubuntu)
Importance: Critical => Undecided
** Also
sru-release comments:
virtualbox-hwe/6.1.16-dfsg-6ubuntu1.20.04.2 (s390x, ppc64el, armhf,
arm64) -> autopkgtest failures are a false negative. It only is built
and supported on amd64
sysdig/riscv64 - ftbfs is not a regression, never built on riscv64 in
focal
zfs-linux/riscv64 - ftbfs is not a
$ dput ubuntu dwarves-dfsg_1.20-1ubuntu1_source.changes
Checking signature on .changes
gpg: /tmp/dwarves-dfsg_1.20-1ubuntu1_source.changes: Valid signature from
9B8EC849D5EF70ED
Checking signature on .dsc
gpg: /tmp/dwarves-dfsg_1.20-1ubuntu1.dsc: Valid signature from 9B8EC849D5EF70ED
Uploading to
Could you please boot daily impish image, and let us know if you still
observe the messages in question?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867092
Title:
Failed to set MokListRT:
** Description changed:
shim supports disabling validation using shim specific variable, whilst
keeping the firmware secureboot on.
The state for it, is currently incorrectly parsed on Ubuntu, and thus
error message is not printed that machine is booting without signature
virtualbox-hwe/6.1.16-dfsg-6ubuntu1.20.04.2 (s390x, ppc64el, armhf,
arm64) -> is a false negative. virtualbox-hwe is only supported on amd64
i thought.
https://autopkgtest.ubuntu.com/packages/v/virtualbox
https://autopkgtest.ubuntu.com/packages/v/virtualbox-hwe
Suggests that to be the case.
--
This bug was fixed in the package lttng-modules - 2.12.5-1
Sponsored for Paolo Pisati (p-pisati)
---
lttng-modules (2.12.5-1) unstable; urgency=medium
* [8e0b514] New upstream version 2.12.5
* [9feae13] Refreshed patches
* Add support for kernel v5.11
* Add support for stable
@vorlon please do not publish packages in earlier series before later
ones, as otherwise, as shown above, upgrade from xenial to bionic
introduces regressions.
** Changed in: grub2 (Ubuntu)
Assignee: (unassigned) => Steve Langasek (vorlon)
--
You received this bug notification because you
This is because one-grub update was published in xenial, but not in
bionic.
Thus upgrading from xenial-proposed to bionic-updates introduces
regression.
To mitigate this issue you can temporarily eanble bionic-proposed and
install all packages from there.
This is due to breakage introduced in
dbxupdate got published on uefi.org website. I would be happy to sponsor
the fwupd debdiff for groovy now. To unblock roll-outs of the new shim.
The split to have standalone fwupd-efi should happen as it is a good
idea - it will enable shipping newer fwupd user-space tooling in the
snap / OEM
debdiffs are on https://bileto.ubuntu.com/#/ticket/4543
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914279
Title:
linux from security may force reboots without complete dkms modules
To manage
I've rebuilt all the packages mentioned above in bileto ppa against
security pocket and pushed them to focal-proposed queue, ready for sru
review and accept.
All, but openafs which ftbfs now, and will need to be fixed up for v5.11
anyway. So it will be rebuild in security pocket with v5.11 fixes
** Also affects: openafs (Ubuntu Focal)
Importance: Undecided
Status: New
** Tags added: rls-ff-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1915854
Title:
** Patch added: "grub2_2.02_beta2-36ubuntu3.31_2.02_beta2-36ubuntu3.32.diff"
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1926748/+attachment/5493871/+files/grub2_2.02_beta2-36ubuntu3.31_2.02_beta2-36ubuntu3.32.diff
--
You received this bug notification because you are a member of
Public bug reported:
[Impact]
* regression in xenial updates - grub2 cannot handle new relocations
* grub-efi-arm64-bin gained new recommends on -signed package which is
attempted to be installed
* it pulls in one grub which was built with a newer toolchain and has
more relocations
*
My understanding of resilient boot is that there are multiple ESPs
trying to boot the same raid device.
If there is only one rootfs filesystem, boot that one. Which in case of
raid, there will be only one.
I'm more concerned about the case of two ubuntu-server preinstalled
images on two usb
I am glad that this worked out fine now.
I am not sure there is time to fix this in 20.10, as it has only a few
months of support left. I hope that having libffi7 in 21.04 is enough.
** Changed in: pyopenssl (Ubuntu Groovy)
Status: Incomplete => Invalid
** Changed in: pyopenssl (Ubuntu)
Public bug reported:
something something precise (test bug)
** Affects: linux-gcp (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux-gcp (Ubuntu Precise)
Importance: Undecided
Status: Won't Fix
** Affects: linux-gcp (Ubuntu Trusty)
Public bug reported:
ARM images should support ttyAMA0 too
It is more common for i.e. arm virtual machines to have tty on ttyAMA0
rather than on ttyS0 or hvc0, thus we should support ttyAMA0 by default
in cloud images for ARM.
** Affects: cloud-images
Importance: Undecided
Status:
Public bug reported:
[Impact]
* armhf & arm64 images do not contain cpc image customizations for
grub.
Specifically they do not have
/etc/default/grub.d/50-cloudimg-settings.cfg
Which disables "quiet splash", removes timeouts, enables serial
consoles.
[Test Plan]
* Boot arm64
Note that upstream and all distro grubs have moved on to query for:
"""
This patch implements a search for a specific configuration when the config
file is on a remoteserver. It uses the following order:
1) DHCP client UUID option.
2) MAC address (in lower case hexadecimal with dash
Can you please paste the contents of MAAS generated:
grub.cfg-default-amd64
grub.cfg-default-arm64
?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923268
Title:
grubnet default grub.cfg should
Also i am kind of confused why there are different per-arch grub.cfg for
enlistment.
there is no reason to have different grub.cfg per arch, as inside the
grub.cfg that is served everything can be provided for all arches.
--
You received this bug notification because you are a member of Ubuntu
I am slightly confused what is being asked here.
The default grub.cfg that is built into grubnet comes from here:
https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian
/build-efi-images?h=ubuntu#n71
Can you please make a merge proposal with exactly what you are asking
for?
$ wget http://archive.ubuntu.com/ubuntu/dists/groovy-proposed/main/uefi
/fwupd-amd64/1.4.7-0~20.10.1/fwupdx64.efi.signed
$ md5sum fwupdx64.efi.signed
e3a387f8f87852e670d105145cb96168 fwupdx64.efi.signed
$ objdump -h ./fwupdx64.efi.signed
./fwupdx64.efi.signed: file format pei-x86-64
** Tags added: block-proposed block-proposed-hirsute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923162
Title:
riscv64 images fail to boot in qemu
To manage notifications about this bug go to:
** Tags added: block-proposed-hirsute
** Tags added: block-proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925267
Title:
u-boot unmatched dtb does not match kernel dtb
To manage
** Changed in: u-boot (Ubuntu Hirsute)
Status: Fix Released => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923162
Title:
riscv64 images fail to boot in qemu
To manage notifications
Public bug reported:
u-boot unmatched dtb does not match kernel dtb
We have reverted u-boot-menu upload and stopped using kernel provided
dtbs, because that was preventing booting hirsute images under qemu. As
dtb generated by qemu should be used, and there is no kernel provided
dtb for qemu
I am concerned about the -no-reboot option, and what constitutes a
"reboot".
Because chainloader; exit 1; boot linux => all can look like reboots
depending what qemu is monitoring/trapping. As all of those things start
brand new EFI application via LoadImage2 call.
--
You received this bug
Can you please try to have the installed machine booting without 'quiet'
and with 'earlyprintk=efi' ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the
ltrager - the secure-boot.log ends with
"EFI stub: UEFI Secure Boot is enabled."
Which is the first message from the loaded linux kernel. At this point
grub & shim have all succeeded, no?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Public bug reported:
shim supports disabling validation using shim specific variable, whilst
keeping the firmware secureboot on.
The state for it, is currently incorrectly parsed on Ubuntu, and thus
error message is not printed that machine is booting without signature
verification by shim.
Public bug reported:
efi: Failed to lookup EFI memory descriptor
is an error message generated by the kernel.
Please pull in https://github.com/rhboot/shim/pull/361/files to fix it.
** Affects: shim (Ubuntu)
Importance: Undecided
Status: New
** Affects: shim-signed (Ubuntu)
Upstream recommends to try https://github.com/rhboot/shim/pull/364/files
patch. I'll prepare an upload of that into a PPA.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925010
Title:
shim-signed
Can you please check that the machine boots with just grub without shim.
Aka, replace /EFI/Boot/BOOTX64.efi & /ef/ubuntu/shimx64.efi files wtih
/efi/ubuntu/grubx64.efi => this could possibly be a workaround, given
that secureboot is not possible on Mac platforms.
--
You received this bug
MBA 5,2 is https://support.apple.com/kb/SP670?locale=en_GB aka MacBook
Air (13-inch, Mid 2012)
** Also affects: shim-signed (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The concern is that uefi amd64 image format is widely used as the basis
for other image formats.
And that it must not have baked in datasource when creating new formats.
It should be harder to missbuild images.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
# display 3rd character of file name extension like 2 of bz2 or m of lzma
>&-1ubyte x \b%c
>>&0ubyte !0x20
>>>&-1 ubyte !0x2f
is odd.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
# file perl-base_5.32.1-3ubuntu2_amd64.deb
perl-base_5.32.1-3ubuntu2_amd64.deb: Debian binary package (format 2.0), with
control.tar.zs, data compression zst
Looks odd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@rcj
these are ubuntu-server daily-prinstalled images. See
http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/pending/
currently it's arm64+pi armhf+pi riscv64+unleashed riscv64+unmatched,
and this wants to add arm64+generic and amd64+generic variants.
--
You received this bug
701 - 800 of 9162 matches
Mail list logo
