Re: Duplicate Requests in autopkgtest-cloud
Hi Tim, On Thu, Jul 27, 2023 at 11:10:05AM +0100, Tim Andersson wrote: > Hi all, > In the Ubuntu QA team we recently made and deployed a change which now > makes it impossible to queue duplicate requests. > If a request is currently in the queue, or is currently running, and you > request the same test, you will be taken to an error page which tells you > the test details and whether it is currently queued or currently running. > It looks like this: > ``` > > You submitted an invalid request: > > Test already queued: > > release: lunar > > pkg: gzip > > arch: arm64 > > triggers: gzip/1.12-1ubuntu1 > > ``` > This is to try and ease the load on autopkgtest-cloud. > If you experience any bugs or unexpected functionality, please file a bug > against `autopkgtest-cloud` and let us know. We expect it to work > seamlessly but always expect the unexpected right :) Does the code also properly distinguish between tests queued with proposed=1 and those without, so that it's possible to queue both ways in parallel? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Duplicate Requests in autopkgtest-cloud
On Thursday, July 27 2023, Tim Andersson wrote: > In the Ubuntu QA team we recently made and deployed a change which now > makes it impossible to queue duplicate requests. [...] Thank you very much, Tim. This is a much appreciated feature. -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: grub 2.12 mantic PPA
Hello party people, grub 2.12~rc1-4~ubuntu1~ppa1 is now available in the Ubuntu development PPA for testing, signed with the PPA signing key. https://launchpad.net/~ubuntu-uefi-team/+archive/ubuntu/ppa/+packages I have tested booting on my laptop and it's fine, but I've specifically not gotten around to any arm64 or riscv64 testing or PC BIOS for that matter. Well I booted a kernel in arm64 qemu. To test on a secure boot enabled machine, you have two options: 1. Enroll the signing key using $ wget https://ppa.launchpadcontent.net/ubuntu-uefi-team/ppa/ubuntu/dists/mantic/main/uefi/grub2-amd64/2.12~rc1-4~ubuntu1~ppa1/control/uefi.crt $ openssl x509 -in uefi.crt -out uefi.der -outform DER $ sudo mokutil --import uefi.der 2. Just install it and enroll the specific binary by its hash. To do so, at boot after you get a seucrity violation, MokManager pops up and presents a menu. Select to enroll a hash, and navigate to EFI/ubuntu/grubx64.efi on your EFI system partition and enroll it. I plan to do some more cleanup and release the -4 to Debian, and have the final version go to mantic-proposed during the first half of next week if signing works out and machines boot :) Probably we'll then go tag it block-proposed for yet some more time so we can do some more testing with signed binaries, but have it in the archive to ease testing. Known issues: - Several UEFI networking patches have not yet been rebased to the new APIs in 2.12. Sadly the patches were not merged upstream when they were submitted :( - Kernels older than 5.8 will not boot in full UEFI mode on amd64, but use the legacy entry points used by BIOS. This is because we are switching from the Red Hat loading code to the upstream loading code in our effort to make bold changes to be the first. OK realistically to get rid of a 20 patch stack and 3 separate loader implementations. I have plans for a better workaround on x86, and the wonderful Ard Biesheuvel has backported the EFI stub with LoadFile2 support to the 5.4 kernel which we might want to pick for 20.04. - Measurement changes may require followup changes to TPM sealing calculations, but not sure there are any - Software - The GRUB_FLAVOUR_ORDER feature used by OEM images is not yet supported. Support will be reinstated later this cycle to early next cycle. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Font load problem in jammy grub 2.06-2ubuntu14.1
As of now in jammy this piece in font.c does not work when there is no memdisk
containing the font file[1]:
file = try_open_from_prefix ("(memdisk)", filename);
if (!file)
{
const char *prefix = grub_env_get ("prefix");
if (!prefix)
{
grub_error (GRUB_ERR_FILE_NOT_FOUND, N_("variable `%s' isn't set"),
"prefix");
goto fail;
}
file = try_open_from_prefix (prefix, filename);
}
Test:
grub> loadfont unicode
error: no server is specified.
grub > lsfonts
Loaded fonts:
grub >
This bug was reported[2] upstream (in ubuntu context) by another person.
The source of the problem was patched upstream in e375394fb9. I see bookworm
and bullseye have the fix ported to 2.06 already:
https://git.launchpad.net/ubuntu/+source/grub2/tree/debian/patches/kern-file-Fix-error-handling-in-grub_file_open.patch?h=applied/debian/bullseye
Could the grub maintainers in ubuntu add the patch to the 2.06 branch as well?
It would be nice having it fixed in jammy.
[1] Like when installing grub as
sudo grub-install --target x86_64-efi --no-uefi-secure-boot ..
[2] https://savannah.gnu.org/bugs/?63975
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Duplicate Requests in autopkgtest-cloud
Hi all, In the Ubuntu QA team we recently made and deployed a change which now makes it impossible to queue duplicate requests. If a request is currently in the queue, or is currently running, and you request the same test, you will be taken to an error page which tells you the test details and whether it is currently queued or currently running. It looks like this: ``` You submitted an invalid request: Test already queued: release: lunar pkg: gzip arch: arm64 triggers: gzip/1.12-1ubuntu1 ``` This is to try and ease the load on autopkgtest-cloud. If you experience any bugs or unexpected functionality, please file a bug against `autopkgtest-cloud` and let us know. We expect it to work seamlessly but always expect the unexpected right :) Thanks, Ubuntu QA -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Amendment: Update on reducing initramfs size and speed up
On Thu, Jul 27, 2023, Michael Hudson-Doyle wrote: > On Thu, 27 Jul 2023 at 09:21, Benjamin Drung wrote: > > > On Wed, 2023-07-26 at 17:53 +0200, Benjamin Drung wrote: > > > Hi all, > > > > > > A few weeks ago, I posted an idea how to reduce the initramfs size and > > > speed up the generation: > > > > > > https://lists.ubuntu.com/archives/ubuntu-devel/2023-July/042652.html > > > > > > This post sparked a lively discussion. The initial idea was ditched for > > > a better solution: mkinitramfs will put all compressed files (kernel > > > modules and firmware files) into a cpio archive that is not compressed > > > (because compressing compressed files makes no sense). All other files > > > will be added to a cpio archive that gets compressed. As next steps, the > > > kernel modules and firmware files need to be shipped compressed. > > > > > > After several iterations for the implementation and review by Daves > > > Jones, I just uploaded initramfs-tools 0.142ubuntu8 to mantic that puts > > > compressed kernel modules and firmware files in an uncompressed cpio > > > (https://launchpad.net/bugs/2028567). > > > > > > I created/updated the follow-up tickets and added my patches to them: > > > > > > Ship kernel modules Zstd compressed > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028568 > > > > > > compress firmware in /lib/firmware > > > https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1942260 > > > > > > And without further ado, here come the benchmark results: > > > > > > The benchmarks were done either on an AMD Ryzen 7 5700G with schroot and > > > overlay on tmpfs or on the hardware mentioned. All tests were running > > > the latest Ubuntu mantic development release. > > > > > > * minimal: schroot with linux-image-generic initramfs-tools zstd > > > * full: minimal + busybox-initramfs cryptsetup-initramfs > > > isc-dhcp-client kbd lvm2 mdadm ntfs-3g plymouth plymouth-theme-spinner > > > * nvidia: full + linux-headers-generic nvidia-driver-525 > > > * nvidia fw: nvidia + compressed /lib/firmware/nvidia/525.125.06/ > > > * VisionFive 2: VisionFive 2 RISC-V board > > > * RPi Zero 2: Raspberry Pi Zero 2 ARM board (running armhf) > > > > > > "next" means using kernel/firmware/initramfs from ppa:bdrung/ppa i.e. > > > * initramfs-tools 0.142ubuntu7bd4 > > > * linux 6.3.0-7.7bd2 > > > * linux-firmware 20230629.gitee91452d-0ubuntu1bd1 > > > > > > > || build | size | uncompressed size | > > > > | test | time| in bytes | in MiB | in bytes | in MiB | > > > > ||-|---||| > > > > | minimal| 4.30 s | 66701818 | 63.6 | 224087608 | 213.7 | > > > > | minimal next | 4.54 s | 59935186 | 57.2 | 67738810 | 64.6 | > > > > | full | 7.15 s | 118007038 | 112.5 | 387976843 | 370.0 | > > > > | full next | 7.29 s | 106937908 | 102.0 | 128610985 | 122.7 | > > > > | nvidia | 7.04 s | 209200523 | 199.5 | 513554279 | 489.8 | > > > > | nvidia next| 7.21 s | 195246287 | 186.2 | 235288174 | 224.4 | > > > > | nvidia fw next | 7.16 s | 191329102 | 182.5 | 213078234 | 203.2 | > > > > | VisionFive 2 | 142.9 s | 121895035 | 116.2 | 411160836 | 392.1 | > > > > | VF 2 next | 126.7 s | 111651453 | 106.5 | 134120804 | 127.9 | > > > > | RPi Zero 2 | 109.5 s | 39803044 | 40.0 | 69592789 | 66.4 | > > > > | RPi Zero 2 ² | 103.5 s | 39804499 | 40.0 | 69592789 | 66.4 | > > > > | RPi Zero 2 next| 101.2 s | 31463352 | 30.0 | 41145762 | 39.2 | > > > > > > ² Updated initramfs-tools (but no compressed modules or firmware) > > > > > > The build time was averaged over five runs. > > > > > > > | improvement | build time | size | uncompressed size | > > > > |--|||---| > > > > | minimal | 105.6 % | 89.9 % | 30.2 % | > > > > | full | 102.0 % | 90.6 % | 33.1 % | > > > > | nvidia | 101.7 % | 91.5 % | 41.5 % | > > > > | VisionFive 2 | 88.7 % | 91.6 % | 32.6 % | > > > > | RPi Zero 2 | 92.4 % | 79.0 % | 59.1 % | > > > > > > Building the initramfs takes more CPU cycles (see tests on tmpfs), but > > > saves time on disk IO. Daves Jones saw much bigger time savings on his > > > Raspberry Pis but his tests were on lunar. > > > > > > Build time influence: > > > + add_directories plus uniq take several milliseconds > > > + depmod on compressed kernel modules take hundreds of > > > milliseconds longer > > > - copying smaller kernel modules (due to compression) is faster > > > - cpio archive that needs to be compressed is smaller > > > - not storing intermediate cpio archives saves time > > > > > > Saving 10 to 20 percent on the initramfs size and only needing half or a > > > third of the size when unpacked (i.e. needed memory during boot) is a > > > good improvement. > > > > The smaller initramfs overall
