remount of multilower moved pivoted-root overlayfs root, results in I/O errors on some modified files

Bug #1824407 reported by Dimitri John Ledkov on 2019-04-11
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Status tracked in Focal
Disco
Critical
Unassigned
Eoan
Critical
Unassigned
Focal
Critical
Colin Ian King
linux-hwe (Ubuntu)
Undecided
Unassigned
Bionic
Critical
Colin Ian King

Bug Description

== SRU Justification Disco, Eoan, Focal ==

Multiple squashfs filesystems with overlayfs cause file corruption issues
when modifying zero sized files

== Fix ==

The current fix is pending in https://github.com/amir73il/linux/commit/b2d4f0ea5af42e16e154254de99da064f3ac551a

== Test case ==

With an Ubuntu ISO on the cdrom drive, use:

#!/bin/bash -x
mkdir -p /cdrom
mount -t iso9660 -o ro,noatime /dev/sr0 /cdrom
sleep 1
mkdir -p /cow
mount -t tmpfs -o 'rw,noatime,mode=755' tmpfs /cow
sleep 1
mkdir -p /cow/upper
mkdir -p /cow/work
modprobe -q -b overlay
sleep 1
modprobe -q -b loop
sleep 1
dev=$(losetup -f)
mkdir -p /filesystem.squashfs
losetup $dev /cdrom/casper/filesystem.squashfs
mount -t squashfs -o ro,noatime $dev /filesystem.squashfs
sleep 1

dev=$(losetup -f)
mkdir -p /installer.squashfs
losetup $dev /cdrom/casper/installer.squashfs
mount -t squashfs -o ro,noatime $dev /installer.squashfs
sleep 1

mkdir -p /root-tmp
mount -t overlay -o 'upperdir=/cow/upper,lowerdir=/installer.squashfs:/filesystem.squashfs,workdir=/cow/work' /cow /root-tmp

FILE=/root-tmp/etc/.pwd.lock

echo foo > $FILE
cat $FILE
sync
#
# dropping caches or remounting causes the bug
#
echo 3 > /proc/sys/vm/drop_caches
cat $FILE

Without the fix the cat of the file will produce an error. With the the cat will work correctly.

== Regression Potential ==

There is an unhandled corner case:
    - two filesystems, A and B, both have null uuid
    - upper layer is on A
    - lower layer 1 is also on A
    - lower layer 2 is on B

However, since this is an issue without the fix and will be addressed later with subsequent fixes once they are OK with upstream I think the risk is minimal considering nobody is complaining about these corner cases with the current broken overlayfs squashfs layering.

-----------------------

1) Download focal subiquity pending image, or eoan release image
2) boot, and press ESC and edit boot command line (F6 in bios, e in UEFI)
3) After --- insert the following options

   break=top debug init=/bin/bash

4) Continue boot (Enter in BIOS, ctrl+x in UEFI)
5) in the initramfs execute:

    rm /scripts/casper-bottom/25adduser
    exit

6) you will be dropped into pivoted root filesystem, before systemd is execed as pid one
7) /run/initramfs/ will contain a debug log, showing how everything was mounted. Ie. cdrom mounted, squashfs losetup from there, then multilower overlay setup from them, moved to /root, and then pivot-root to /root done to finally end up as /. Underlying layers are moved into /cow for your convenience.

8) At this point modifying zero-byte length files, that exist in the lowest layer, but not the middle one, in certain ways, will results in them to be corrupted, after / is remounted.

9) Corruption examples

(On both focal & eoan)

cat /etc/.pwd.lock
systemd-sysusers
cat /etc/.pwd.lock
mount -o remount /
cat /etc/.pwd.lock
overlayfs: invalid origin (etc/.pwd.lock, ftype=8000, origin ftype=4000)
cat: /etc/.pwd.lock: Input/output error

(Only on eoan)

cat /etc/machine-id
systemd-machine-id-setup
cat /etc/machine-id
mount -o remount /
cat /etc/machine-id
overlayfs: invalid origin (etc/machine-id, ftype=8000, origin ftype=4000)
cat: /etc/machine-id: Input/output error

Lots of things break once machine-id and .pwd.lock are corrupted. I.e. unable to dhcp, connect to dbus, add/remove/change users or groups, etc.

We were unable to recreate the issue outside of booting things with casper. Ie. statically on a regular host machine without pivot-root. But hopefully booting to a quite state with nothing running is sufficient to reproduce this.

Instead of booting with `bebroken init=/bin/bash` you can boot with `bebroken systemd.mask=systemd-remount-fs.service` this will complete the boot, with /etc/machine-id & .pwd.lock modified, meaning that remount of / will cause IO errors on those files.

Currently, we are shipping two hacks in casper's 25adduser script to "rm" the offending files, and create them again on the upper rw layer. They then survive remount without i/o errors. However, we'd rather not ship those hacks, and have kernel overlay fixed to work correctly with multi-lower-dir and not corrupt files upon remounting /.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1824407

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: disco

@dimitri are you still having this issue? There isn't much to go on in this bug submission yet.

Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
Dimitri John Ledkov (xnox) wrote :

Yes this is still a problem affecting Ubuntu Desktop and Server (new one) ISOs.

Errors are visible on boot, during initrd, and after installer started.

And they make the boot messages ugly.

I do not know if there is a bug in vfs (we do overlay, sometimes multilowerdir, on top of squashfs) or if our squashfs are buggy and don't have things that kernel is expecting.

Changed in linux (Ubuntu):
status: Expired → New

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1824407

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
description: updated
Changed in linux (Ubuntu):
status: Incomplete → New
Changed in linux-hwe (Ubuntu Bionic):
milestone: none → ubuntu-18.04.4
importance: Undecided → Critical
no longer affects: linux (Ubuntu Bionic)
Changed in linux (Ubuntu):
milestone: none → ubuntu-20.01
importance: Undecided → Critical
Changed in linux-hwe (Ubuntu):
status: New → Invalid
Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux-hwe (Ubuntu Bionic):
status: New → Confirmed
Steve Langasek (vorlon) on 2019-10-23
summary: - why does booting any livefs squashfs has kernel complaining about
- unable to read metadata something rather
+ why does booting any livefs squashfs cause the kernel to complain about
+ being unable to read metadata
summary: why does booting any livefs squashfs cause the kernel to complain about
- being unable to read metadata
+ being unable to read metadata‽
tags: added: rls-ff-incoming
description: updated
description: updated
summary: - why does booting any livefs squashfs cause the kernel to complain about
- being unable to read metadata‽
+ remount of multilower moved pivoted-root overlayfs root, results in I/O
+ errors on some modified files
Changed in linux (Ubuntu):
assignee: nobody → Colin Ian King (colin-king)
Changed in linux-hwe (Ubuntu Bionic):
assignee: nobody → Colin Ian King (colin-king)
description: updated
Colin Ian King (colin-king) wrote :

Hi Dimitri,

while debugging this I found the following in setup_unionfs() in scripts/casper:

    # move the first mount; no head in busybox-initramfs
    for d in $(mount -t squashfs | cut -d\ -f 3); do
        mkdir -p "${rootmnt}/rofs"
        if [ "${UNIONFS}" = unionfs-fuse ]; then
            mount -o bind "${d}" "${rootmnt}/rofs"
        else
            mount -o move "${d}" "${rootmnt}/rofs"
        fi
        break
    done

and looking at the debug /run/initramfs/initramfs.debug log for the above stanza I see:

+ cut '-d ' -f 3
+ mount -t squashfs
+ mkdir -p /root/rofs
+ '[' overlay '=' unionfs-fuse ]
+ mount -o move /filesystem.squashfs /root/rofs
+ break

however, when I cannot reproduce this mount -o move operation by hand as I get the mount error:

mount: /root/rofs: /filesystem.squashfs is not a block device.

It appears to me that the scripts/casper mount seems to silently ignore this failure. Should the mount be a bind mount instead?

Colin Ian King (colin-king) wrote :

BTW, I can generate the mount move failure with the cut down script as follows (which follows the same mount patterns as the casper script)

#!/bin/bash -x
mkdir -p /cdrom
mount -t iso9660 -o ro,noatime /dev/sr0 /cdrom
sleep 1
mkdir -p /cow
mount -t tmpfs -o 'rw,noatime,mode=755' tmpfs /cow
sleep 1
mkdir -p /cow/upper
mkdir -p /cow/work
modprobe -q -b overlay
sleep 1
modprobe -q -b loop
sleep 1
dev=$(losetup -f)
mkdir -p /filesystem.squashfs
losetup $dev /cdrom/casper/filesystem.squashfs
mount -t squashfs -o ro,noatime $dev /filesystem.squashfs
sleep 1

dev=$(losetup -f)
mkdir -p /installer.squashfs
losetup $dev /cdrom/casper/installer.squashfs
mount -t squashfs -o ro,noatime $dev /installer.squashfs
sleep 1

mount -t overlay -o 'upperdir=/cow/upper,lowerdir=/installer.squashfs:/filesystem.squashfs,workdir=/cow/work' /cow /root

mkdir -p /root/rofs
mount -o move /filesystem.squashfs /root/rofs

Colin Ian King (colin-king) wrote :

OK, now managed to get a reproducer script to kick this bug even outside the early install context. Seems like we can force this bug by either remounting OR sync'ing and dropping caches.

Attached is the reproducer script.

Run as root, we hit the error:

cat: /root-tmp/etc/.pwd.lock: Input/output error

dmesg:
[ 42.415432] overlayfs: invalid origin (etc/.pwd.lock, ftype=8000, origin ftype=4000).

Colin Ian King (colin-king) wrote :

And if we change use a different file: /root-tmp/var/log/ubuntu-advantage.log we get the following error too:

[ 24.531406] SQUASHFS error: squashfs_read_data failed to read block 0xffff89c066e0b540
[ 24.531444] SQUASHFS error: Unable to read metadata cache entry [ffff89c066e0b540]

Colin Ian King (colin-king) wrote :

Replaced read-only squashfs with read-only ext4 partitions and can't reproduce the error.

Colin Ian King (colin-king) wrote :

Replaced one of the two squashfs with read-only ext4 partitions and can't reproduce the error. Seems that we need 2 stacked squashfs file systems.

Colin Ian King (colin-king) wrote :

4.15: ovl_get_origin_fh detects zero sized files on lower paths and treats these a special zero sized "copied up but origin unknown" magic.

[ 25.442916] ovl_check_origin: etc/.pwd.lock 2
[ 25.442918] ovl_get_origin_fh: 104 etc/.pwd.lock
[ 25.442919] ovl_get_origin_fh: 107 res=0
[ 25.442920] ovl_get_origin_fh: 117 res == 0, return NULL
[ 25.442921] ovl_get_origin: 179 fh = (null) 1
[ 25.442922] ovl_get_origin_fh: 104 etc/.pwd.lock
[ 25.442922] ovl_get_origin_fh: 107 res=0
[ 25.442923] ovl_get_origin_fh: 117 res == 0, return NULL
[ 25.442923] ovl_get_origin: 179 fh = (null) 1

5.3: the lower is / and hence is a directory hence the S_IFDIR origin return.

[ 33.320630] ovl_get_fh: 112 dentry: etc/.pwd.lock name: trusted.overlay.origin
[ 33.320632] ovl_get_fh: 115: res = 29
[ 33.320634] ovl_get_fh: 152: return fh = 000000006e71855c
[ 33.320634] ovl_check_origin: 413 fh = 000000006e71855c
[ 33.320635] ovl_check_origin_fh: 354 upperdentry = etc/.pwd.lock
[ 33.320635] ovl_decode_real_fh: 174
[ 33.320769] ovl_decode_real_fh: 211 return dentry (OK)
[ 33.320769] ovl_check_origin_fh: 360, i=0, origin = /
[ 33.320770] ovl_check_origin_fh: level=0 upper: etc/.pwd.lock 100600, lower: / 40755
[ 33.320770] ovl_check_origin_fh: 380 goto invalid
[ 33.320771] overlayfs: invalid origin (etc/.pwd.lock, ftype=8000, origin ftype=4000).
[ 33.320773] ovl_check_origin: 422 err = -5
[ 33.320774] ovl_check_origin: 429, return -5

Colin Ian King (colin-king) wrote :

Comparing the previous debug with 2 squashfs overlayfs lowers with the *same* data on ext4 as the 2 overlayfs lowers we have:

[ 56.257691] repro-nosquashf (1038): drop_caches: 3
[ 56.265075] ovl_get_fh: 112 dentry: etc/.pwd.lock name: trusted.overlay.origin
[ 56.265077] ovl_get_fh: 115: res = 29
[ 56.265079] ovl_get_fh: 152: return fh = 00000000b56cf4e7
[ 56.265079] ovl_check_origin: 413 fh = 00000000b56cf4e7
[ 56.265080] ovl_check_origin_fh: 354 upperdentry = etc/.pwd.lock
[ 56.265081] ovl_decode_real_fh: 174
[ 56.265081] ovl_decode_real_fh: 181 uuid not equal, return NULL
[ 56.265082] ovl_check_origin_fh: 363, i=0, origin = NULL
[ 56.265082] ovl_decode_real_fh: 174
[ 56.266162] ovl_decode_real_fh: 211 return dentry (OK)
[ 56.266163] ovl_check_origin_fh: 360, i=1, origin = /
[ 56.266164] ovl_check_origin_fh: level=1 upper: etc/.pwd.lock 100600, lower: / 100600
[ 56.266166] ovl_check_origin_fh: 395 return 0
[ 56.266166] ovl_check_origin: 422 err = 0
[ 56.266167] ovl_check_origin: 439, return 0
  (
So this works fine, note that the squashfs lower / is 40755 (S_IFDIR | S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH) where as the ext3 lower / is 100600 (S_IFREG | S_IRUSR | S_IWUSR)

Colin Ian King (colin-king) wrote :

Adding a uuid into the superblock on squashfs seems to resolve the issue. Since squashfs does not have UUID support, my hack below generates one based on some squashfs superblock metadata that provides a good enough UUID for our purposes.

diff --git a/fs/squashfs/super.c b/fs/squashfs/super.c
index effa638d6d85..cfb34a75feb6 100644
--- a/fs/squashfs/super.c
+++ b/fs/squashfs/super.c
@@ -186,6 +186,12 @@ static int squashfs_fill_super(struct super_block *sb, void *data, int silent)
        sb->s_flags |= SB_RDONLY;
        sb->s_op = &squashfs_super_ops;

+ memcpy(&sb->s_uuid.b[0], &sblk->inodes, 4);
+ memcpy(&sb->s_uuid.b[4], &sblk->mkfs_time, 4);
+ memcpy(&sb->s_uuid.b[8], &sblk->fragments, 4);
+ memcpy(&sb->s_uuid.b[12], &sblk->compression, 2);
+ memcpy(&sb->s_uuid.b[14], &sblk->block_log, 2);
+
        err = -ENOMEM;

        msblk->block_cache = squashfs_cache_init("metadata",

Colin Ian King (colin-king) wrote :

The concern I have is for other file systems that also don't populate the UUID - this seems to be a general problem for overlayfs. Perhaps a UUID can be autogenerated based on the superblock rather than file system specific UUID magic if the UUID is zero.

Dimitri John Ledkov (xnox) wrote :

I think kernel already generates some faked up UUIDs, i.e. i think there is something for like FAT and DOS partition table, either fs uuid, or like partition table uuid, partition uuid, partition type uuid, some such.

They are "shorter" than normal, and less unique, but at least something.

Should we request squashfs userspace tooling and kernel to start having a UUID in the squashfs?

We do use squashfs a lot, all the snaps and all the installer media.

Dimitri John Ledkov (xnox) wrote :

There is mkfs-time of the filesystem superblock, which could be converted to a timebased UUID.

Dimitri John Ledkov (xnox) wrote :

blkid

/dev/nvme0n1p1: LABEL="ESP" UUID="B407-D3BC" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="fb8a1f92-fbd6-4ce2-ade4-0a11bdbaf74b"

ah, but that UUID is actually fat serial number / volume-id

Sets the volume ID of the newly created filesystem; VOLUME-ID is a 32-bit hexadecimal number (for example, 2e24ec82). The default is a number which depends on the filesystem creation time.

It would be nice if squashfs had UUID support, and like blkid /dev/loop* printed them, and kernel used them, etc.

Colin Ian King (colin-king) wrote :

I was thinking of a more generalized overlayfs solution that detects if file systems don't initialize the superblock uuid and overlayfs improvises by generating the internal overlayfs uuid, something like:

diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 698d112bdb17..da3faaf68d69 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -248,6 +248,7 @@ struct ovl_fh *ovl_encode_real_fh(struct dentry *real, bool is_upper)
        void *buf;
        int buflen = MAX_HANDLE_SZ;
        uuid_t *uuid = &real->d_sb->s_uuid;
+ static const uuid_t z_uuid;

        buf = kmalloc(buflen, GFP_KERNEL);
        if (!buf)
@@ -289,7 +290,22 @@ struct ovl_fh *ovl_encode_real_fh(struct dentry *real, bool is_upper)
        if (is_upper)
                fh->flags |= OVL_FH_FLAG_PATH_UPPER;
        fh->len = fh_len;
- fh->uuid = *uuid;
+
+ if (uuid_equal(uuid, &z_uuid)) {
+ struct super_block *sb = real->d_sb;
+ u16 hash;
+
+ pr_warn("ovl_encode_real_fh: ZERO UUID, generating one from superblock\n");
+
+ memcpy(&fh->uuid.b[0], &sb->s_magic, 8);
+ memcpy(&fh->uuid.b[8], &sb->s_dev, 6);
+ hash = ((long)sb ^ (long)sb->s_fs_info) >> 12;
+ memcpy(&fh->uuid.b[14], &hash, 2);
+ } else {
+ fh->uuid = *uuid;
+ }
+

Colin Ian King (colin-king) wrote :

Just love the way launchpad mangles pasted code.

Adam Conrad (adconrad) wrote :

While there may be arguments for synthesizing UUIDs in various fs drivers, or creating them in the first place in fs-creation tools, I agree that if overlayfs has a hard dependency on UUIDs for uniquely identifying layers, it needs to fill in the gaps where the previous tools/drivers failed to provide.

So, yeah, I think Colin's on the right track here with making overlayfs itself fix its own use-case, which will cover any future filesystem/tool that otherwise fails to UUID itself.

My only review of the above is that you might want to mix a monotonic or random seed in with your superblock when generating your fake UUIDs, in case someone does something like stacking multiple empties on top of each other, or some other madness where you effectively have the same superblock more than once at the RO level, but need to identify them as different.

At least it doesn't mangle email notifications! Such that in email code is
readable.

On Wed, 6 Nov 2019, 18:50 Colin Ian King, <email address hidden>
wrote:

> Just love the way launchpad mangles pasted code.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1824407
>
> Title:
> remount of multilower moved pivoted-root overlayfs root, results in
> I/O errors on some modified files
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824407/+subscriptions
>

Dimitri John Ledkov (xnox) wrote :

I thought all lowerdirs must be read-only, and the first one in the stack
will win. Even if there are same ones down the stack it shouldn't matter.
But I guess needs testing.

I wouldn't want to use random, as that will eat entropy on early boot of
Ubuntu Core systems.

Do we need a separate upstream issue to create uuid in the squashfs
Superblock?

On Wed, 6 Nov 2019, 21:21 Adam Conrad, <adconrad@0c3.net> wrote:

> While there may be arguments for synthesizing UUIDs in various fs
> drivers, or creating them in the first place in fs-creation tools, I
> agree that if overlayfs has a hard dependency on UUIDs for uniquely
> identifying layers, it needs to fill in the gaps where the previous
> tools/drivers failed to provide.
>
> So, yeah, I think Colin's on the right track here with making overlayfs
> itself fix its own use-case, which will cover any future filesystem/tool
> that otherwise fails to UUID itself.
>
> My only review of the above is that you might want to mix a monotonic or
> random seed in with your superblock when generating your fake UUIDs, in
> case someone does something like stacking multiple empties on top of
> each other, or some other madness where you effectively have the same
> superblock more than once at the RO level, but need to identify them as
> different.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1824407
>
> Title:
> remount of multilower moved pivoted-root overlayfs root, results in
> I/O errors on some modified files
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824407/+subscriptions
>

Colin Ian King (colin-king) wrote :

When I'm more awake tomorrow I'll send a patch upstream as a suggested fix and see if we can get a good solution on the UUIDs worked out.

Adam Conrad (adconrad) wrote :

I didn't mean actually random, and I think clock-based would be entirely fine, but my paranoia about stacking two things with identical superblocks might be just paranoia too. I dunno.

Colin Ian King (colin-king) wrote :

been iterating on a fix with upstream: https://lkml.org/lkml/2019/11/7/317

Dimitri John Ledkov (xnox) wrote :

pr_warn sounds awkward though

Ie. a user will not be able to do anything about it, if that's the only thing they have to mount and boot. Our installer images boot quiet, but this will make it be printed on every boot of Ubuntu installer media.

Things that a user didn't cause, and cannot control should not be at warning level.

Colin Ian King (colin-king) wrote :

pr_warn can be removed with a sauce patch, so no worries with that.

Colin Ian King (colin-king) wrote :

I'm doing some testing right now on the current upstream fix, hopefully will SRU this by EOD.

description: updated
description: updated
no longer affects: linux-hwe (Ubuntu Focal)
no longer affects: linux-hwe (Ubuntu Eoan)
no longer affects: linux-hwe (Ubuntu Disco)
Changed in linux (Ubuntu Focal):
status: Confirmed → In Progress
Changed in linux-hwe (Ubuntu Bionic):
status: Confirmed → In Progress
Stefan Bader (smb) on 2019-11-28
Changed in linux (Ubuntu Eoan):
importance: Undecided → Critical
Changed in linux (Ubuntu Disco):
importance: Undecided → Critical
Stefan Bader (smb) on 2019-11-28
Changed in linux (Ubuntu Eoan):
status: New → Fix Committed
Changed in linux (Ubuntu Disco):
status: New → Fix Committed

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-disco
Colin Ian King (colin-king) wrote :

Verified for disco:

Run reproducer script with old kernel: 5.0.0-37-generic, results:

cat /root-tmp/etc/.pwd.lock
cat: /root-tmp/etc/.pwd.lock: Input/output error

Run with -proposed kernel: 5.0.0-38-generic

cat /root-tmp/etc/.pwd.lock
foo

Marking as verification-done-disco

tags: added: verification-done-disco
removed: verification-needed-disco

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-eoan' to 'verification-done-eoan'. If the problem still exists, change the tag 'verification-needed-eoan' to 'verification-failed-eoan'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-eoan
Colin Ian King (colin-king) wrote :

Hrm, I can't see the fix in the Ubuntu-5.3.0-24.26 kernel, so I think comment #34 a premature SRU test request. As it stands, I tested Ubuntu-5.3.0-24.26 and the issue still exists, and looking at the source the fix isn't present so that correlates with my test observations.

Dimitri John Ledkov (xnox) wrote :

The comment in #34 is about 5.3.0-25.27 which is in eoan-proposed.

Also ubuntu-kernel-bot must post these message when the kernel is copied into -proposed pocket, and it should state the release series and version, just like all other SRU comments do.

Colin Ian King (colin-king) wrote :

Tested with 5.3.0-25-generic #27-Ubuntu with the regression test and it now works fine. Marking bug as verification-done for eoan

tags: added: verification-done-eoan
removed: verification-needed-eoan
Changed in linux (Ubuntu Focal):
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments