[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-09-04 Thread Ken Takusagawa
I've discovered that this behavior can also occur with the installer
(similar to bug 1900130) when the USB stick to which the installer ISO
was written is bad.  (In this case, the error message is saying exactly
what it should be saying.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  Fix Released
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-08-07 Thread Yuan-Chen Cheng
** Changed in: oem-priority
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  Fix Released
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-08-03 Thread Norbert
** Tags removed: eoan

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-07-05 Thread Dimitri John Ledkov
@superm1 yes I have, it is now pulled into v5.14
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c484419efc09e7234c667aa72698cb79ba8d8ed

I will request it to be included in linux-stable series.

Note that in Impish we have now switched to zstd compression for the
initramfs, as it has even better bootspeed performance.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-07-02 Thread Mario Limonciello
#134: @xnox, have you re-sent it?  It looks like
https://lkml.org/lkml/2021/1/14/1091 got no feedback.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-03-28 Thread Daniel van Vugt
** Changed in: initramfs-tools (Ubuntu Focal)
 Assignee: Armandoobnaiala (armando1986) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


Re: [Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-03-26 Thread paul-lawrenceville
Works well, thank you for the update.


On Fri, Mar 26, 2021, 7:31 AM Armandoobnaiala <1835...@bugs.launchpad.net>
wrote:

> update-initramfs: Generating /boot/initrd.img-5.8.0-45-generic
> /usr/sbin/mkinitramfs: 177: COMPRESS: parameter not set
> update-initramfs: failed for /boot/initrd.img-5.8.0-45-generic with 2.
>
>
> ** Changed in: initramfs-tools (Ubuntu Focal)
>  Assignee: (unassigned) => Armandoobnaiala (armando1986)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1835660
>
> Title:
>   initramfs unpacking failed
>
> Status in OEM Priority Project:
>   New
> Status in grub2 package in Ubuntu:
>   Invalid
> Status in initramfs-tools package in Ubuntu:
>   Invalid
> Status in linux package in Ubuntu:
>   Fix Released
> Status in grub2 source package in Focal:
>   Invalid
> Status in initramfs-tools source package in Focal:
>   Invalid
> Status in linux source package in Focal:
>   Fix Released
> Status in grub2 source package in Groovy:
>   Invalid
> Status in initramfs-tools source package in Groovy:
>   Invalid
> Status in linux source package in Groovy:
>   Fix Released
> Status in grub2 source package in Hirsute:
>   Invalid
> Status in initramfs-tools source package in Hirsute:
>   Invalid
> Status in linux source package in Hirsute:
>   Fix Released
>
> Bug description:
>   "initramfs unpacking failed: Decoding failed",  message appears on
>   boot up.
>
>   If I "update-initramfs" using gzip instead of lz, then boot up passes
>   without decoding failed message.
>
>   ---
>
>   However, we currently believe that the decoding error reported in
>   dmesg is actually harmless and has no impact on usability on the
>   system.
>
>   Switching from lz4 to gzip compression, simply papers over the
>   warning, without any benefits, and slows down boot.
>
>   Kernel should be fixed to correctly parse lz4 compressed initrds, or
>   at least lower the warning, to not be user visible as an error.
>
>   [Impact]
>
>* Decoding failure messages in dmsg with a single lz4 initrd
>
>* Multiple lz4 compressed initrds cannot be decompressed by kernel,
>   when loaded by grub
>
>* Multiple lz4 compressed initrds cannot be decompressed by kernel,
>   when there is padding between them
>
>   [Test Case]
>
>* Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4
>
>* Create an lz4 compressed initrd with a single test-file in it with
>   some content. I.e. echo "second-initrd" > test-file, and then pack
>   that with cpio hewc owned by root & lz4 -l.
>
>* Create a combined padded initrd of stock initrd, pad4, and the
>   test-marker initrd created above.
>
>* Boot above with "break=top" kernel command line.
>
>* With broken kernels, there should be dmesg error message that
>   decoding failed, and one will observe that /test-file does not exist
>   in the shell.
>
>* With fixed kernel, /test-file in the initrd shell should exist, and
>   should have the expected content "second-initrd".
>
>* The alignment and padding in the above test case depends on the
>   size of the first initrd => if a given padded initrd does not
>   reproduce the problem, try varying the size of the first initrd or
>   that of the padding between 0..4.
>
>
>   [Where problems could occur]
>
>* This changes compatible lz4 decompressor in the kernel, which can
>   also be used by other kernel modules such as cryptography, squashfs,
>   zram, f2fs, comprssed kernel image, pstore. For example, previously
>   rejected files with "bogus" length and extra padding may now be
>   accepted, whereas they were previously getting rejected by the
>   decompressor.
>
>* Ideally kernel should switch to the stable lz4 format which has
>   better specification of end of stream.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I 

[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-03-26 Thread Armandoobnaiala
# An empty value - compcache isn't used, or added to the initramfs at all.
# An integer and K (e.g. 65536 K) - use a number of kilobytes.
# An integer and M (e.g. 256 M) - use a number of megabytes.
# An integer and G (e.g. 1 G) - use a number of gigabytes.
# An integer and % (e.g. 50 %) - use a percentage of the amount of RAM.
#
# You can optionally install the compcache package to configure this setting
# via debconf and have userspace scripts to load and unload compcache.
#

COMPCACHE_SIZE=""

#
# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | xz ]
#

stuck here

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-03-26 Thread Armandoobnaiala
update-initramfs: Generating /boot/initrd.img-5.8.0-45-generic
/usr/sbin/mkinitramfs: 177: COMPRESS: parameter not set
update-initramfs: failed for /boot/initrd.img-5.8.0-45-generic with 2.


** Changed in: initramfs-tools (Ubuntu Focal)
 Assignee: (unassigned) => Armandoobnaiala (armando1986)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-03-22 Thread Dimitri John Ledkov
@Fred eldmannen+launchpad

This issue is only fixed in the Ubuntu patchset for the Linux Kernel.
Although I have submitted this fix upstream, it has not been picked up
yet by kernel.org vanilla kernels. See
https://lkml.org/lkml/2021/1/14/1091

The mainline builds you point to, do not contain Ubuntu patchset, and
thus are as vanilla as possible. Meaning that yes, those builds are
affected by this issue.

There should be point release updates for Hirsute soon.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-03-21 Thread Fred
I have this issue on Hirsuite.
Is this only fixed in 5.8 and 5.10 but not 5.11?

$ uname -a
Linux example 5.11.8-051108-generic #202103200636 SMP Sat Mar 20 11:17:32 UTC 
2021 x86_64 x86_64 x86_64 GNU/Linux

I got the 5.11.8 kernel from 
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11.8/
because 5.11.0 caused GPU hangs for me on Intel 4770K Haswell.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-02-19 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.10.0-14.15

---
linux (5.10.0-14.15) hirsute; urgency=medium

  * hirsute/linux: 5.10.0-14.15 -proposed tracker (LP: #1913724)

  * Restore palm ejection on multi-input devices (LP: #1913520)
- HID: multitouch: Apply MT_QUIRK_CONFIDENCE quirk for multi-input devices

  * intel-hid is not loaded on new Intel platform (LP: #1907160)
- platform/x86: intel-hid: add Rocket Lake ACPI device ID

  * Hirsute update: v5.10.11 upstream stable release (LP: #1913430)
- scsi: target: tcmu: Fix use-after-free of se_cmd->priv
- mtd: rawnand: gpmi: fix dst bit offset when extracting raw payload
- mtd: rawnand: nandsim: Fix the logic when selecting Hamming soft ECC 
engine
- i2c: tegra: Wait for config load atomically while in ISR
- i2c: bpmp-tegra: Ignore unknown I2C_M flags
- platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634
- ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info()
- ALSA: hda/realtek - Limit int mic boost on Acer Aspire E5-575T
- ALSA: hda/via: Add minimum mute flag
- crypto: xor - Fix divide error in do_xor_speed()
- dm crypt: fix copy and paste bug in crypt_alloc_req_aead
- ACPI: scan: Make acpi_bus_get_device() clear return pointer on error
- btrfs: don't get an EINTR during drop_snapshot for reloc
- btrfs: do not double free backref nodes on error
- btrfs: fix lockdep splat in btrfs_recover_relocation
- btrfs: don't clear ret in btrfs_start_dirty_block_groups
- btrfs: send: fix invalid clone operations when cloning from the same file
  and root
- fs: fix lazytime expiration handling in __writeback_single_inode()
- pinctrl: ingenic: Fix JZ4760 support
- mmc: core: don't initialize block size from ext_csd if not present
- mmc: sdhci-of-dwcmshc: fix rpmb access
- mmc: sdhci-xenon: fix 1.8v regulator stabilization
- mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend
- dm: avoid filesystem lookup in dm_get_dev_t()
- dm integrity: fix a crash if "recalculate" used without "internal_hash"
- dm integrity: conditionally disable "recalculate" feature
- drm/atomic: put state on error path
- drm/syncobj: Fix use-after-free
- drm/amdgpu: remove gpu info firmware of green sardine
- drm/amd/display: DCN2X Find Secondary Pipe properly in MPO + ODM Case
- drm/i915/gt: Prevent use of engine->wa_ctx after error
- drm/i915: Check for rq->hwsp validity after acquiring RCU lock
- ASoC: Intel: haswell: Add missing pm_ops
- ASoC: rt711: mutex between calibration and power state changes
- SUNRPC: Handle TCP socket sends with kernel_sendpage() again
- HID: sony: select CONFIG_CRC32
- dm integrity: select CRYPTO_SKCIPHER
- x86/hyperv: Fix kexec panic/hang issues
- scsi: ufs: Relax the condition of UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
- scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback
- scsi: qedi: Correct max length of CHAP secret
- scsi: scsi_debug: Fix memleak in scsi_debug_init()
- scsi: sd: Suppress spurious errors when WRITE SAME is being disabled
- riscv: Fix kernel time_init()
- riscv: Fix sifive serial driver
- riscv: Enable interrupts during syscalls with M-Mode
- HID: logitech-dj: add the G602 receiver
- HID: Ignore battery for Elan touchscreen on ASUS UX550
- clk: tegra30: Add hda clock default rates to clock driver
- ALSA: hda/tegra: fix tegra-hda on tegra30 soc
- riscv: cacheinfo: Fix using smp_processor_id() in preemptible
- arm64: make atomic helpers __always_inline
- xen: Fix event channel callback via INTX/GSI
- x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery
- x86/xen: Fix xen_hvm_smp_init() when vector callback not available
- dts: phy: fix missing mdio device and probe failure of vsc8541-01 device
- dts: phy: add GPIO number and active state used for phy reset
- riscv: defconfig: enable gpio support for HiFive Unleashed
- drm/amdgpu/psp: fix psp gfx ctrl cmds
- drm/amd/display: disable dcn10 pipe split by default
- HID: logitech-hidpp: Add product ID for MX Ergo in Bluetooth mode
- drm/amd/display: Fix to be able to stop crc calculation
- drm/nouveau/bios: fix issue shadowing expansion ROMs
- drm/nouveau/privring: ack interrupts the same way as RM
- drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
- drm/nouveau/mmu: fix vram heap sizing
- drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
- io_uring: flush timeouts that should already have expired
- libperf tests: If a test fails return non-zero
- libperf tests: Fail when failing to get a tracepoint id
- RISC-V: Set current memblock limit
- RISC-V: Fix maximum allowed phsyical memory for RV32
- x86/xen: fix 'nopvspin' build error
- nfsd: Fixes for nfsd4_encode_read_plus_data()
   

[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-26 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.8.0-41.46

---
linux (5.8.0-41.46) groovy; urgency=medium

  * groovy/linux: 5.8.0-41.46 -proposed tracker (LP: #1912219)

  * Groovy update: upstream stable patchset 2020-12-17 (LP: #1908555) // nvme
drive fails after some time (LP: #1910866)
- Revert "nvme-pci: remove last_sq_tail"

  * initramfs unpacking failed (LP: #1835660)
- SAUCE: lib/decompress_unlz4.c: correctly handle zero-padding around 
initrds.

  * overlay: permission regression in 5.4.0-51.56 due to patches related to
CVE-2020-16120 (LP: #1900141)
- ovl: do not fail because of O_NOATIME

 -- Kleber Sacilotto de Souza   Mon, 18 Jan
2021 17:01:08 +0100

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-26 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.4.0-65.73

---
linux (5.4.0-65.73) focal; urgency=medium

  * focal/linux: 5.4.0-65.73 -proposed tracker (LP: #1912220)

  * initramfs unpacking failed (LP: #1835660)
- SAUCE: lib/decompress_unlz4.c: correctly handle zero-padding around 
initrds.

  * overlay: permission regression in 5.4.0-51.56 due to patches related to
CVE-2020-16120 (LP: #1900141)
- ovl: do not fail because of O_NOATIME

  * Focal update: v5.4.79 upstream stable release (LP: #1907151)
- net/mlx5: Use async EQ setup cleanup helpers for multiple EQs
- net/mlx5: poll cmd EQ in case of command timeout
- net/mlx5: Fix a race when moving command interface to events mode
- net/mlx5: Add retry mechanism to the command entry index allocation

  * Kernel 5.4.0-56 Wi-Fi does not connect (LP: #1906770)
- mt76: fix fix ampdu locking

  * [Ubuntu 21.04 FEAT] mpt3sas: Request to include the patch set which supports
topology where zoning is enabled in expander (LP: #1899802)
- scsi: mpt3sas: Define hba_port structure
- scsi: mpt3sas: Allocate memory for hba_port objects
- scsi: mpt3sas: Rearrange _scsih_mark_responding_sas_device()
- scsi: mpt3sas: Update hba_port's sas_address & phy_mask
- scsi: mpt3sas: Get device objects using sas_address & portID
- scsi: mpt3sas: Rename transport_del_phy_from_an_existing_port()
- scsi: mpt3sas: Get sas_device objects using device's rphy
- scsi: mpt3sas: Update hba_port objects after host reset
- scsi: mpt3sas: Set valid PhysicalPort in SMPPassThrough
- scsi: mpt3sas: Handling HBA vSES device
- scsi: mpt3sas: Add bypass_dirty_port_flag parameter
- scsi: mpt3sas: Handle vSES vphy object during HBA reset
- scsi: mpt3sas: Add module parameter multipath_on_hba
- scsi: mpt3sas: Bump driver version to 35.101.00.00

 -- Kleber Sacilotto de Souza   Mon, 18 Jan
2021 17:31:23 +0100

** Changed in: linux (Ubuntu Focal)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-16120

** Changed in: linux (Ubuntu Groovy)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Released
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This 

[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-26 Thread Dimitri John Ledkov
$ sudo qemu-system-x86_64 -kernel ./vmlinuz-5.8.0-41-generic -initrd
./initrd-pad4-5.8.0-41-generic -append 'break=top quiet console=ttyS0'
-m 2G -nographic -no-reboot

Spawning shell within the initramfs


BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6.3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cat /test-file 
hello
(initramfs) uname -a
Linux (none) 5.8.0-41-generic #46-Ubuntu SMP Mon Jan 18 16:48:44 UTC 2021 
x86_64 GNU/Linux
(initramfs) 


Groovy verified too now.

** Tags removed: verification-needed-groovy
** Tags added: verification-done-groovy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-26 Thread Dimitri John Ledkov
Verifying v5.8 build

$ sudo qemu-system-x86_64 -kernel ./vmlinuz-5.8.0-41-generic -initrd
./initrd-pad4-5.8.0-41-generic -append 'break=top quiet console=ttyS0'
-m 2G -nograt

Spawning shell within the initramfs


BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6.3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) uname -a
Linux (none) 5.8.0-41-generic #46~20.04.1-Ubuntu SMP Mon Jan 18 17:52:23 UTC 
2021 x86_64 GNU/Linux
(initramfs) cat /test-file
second
(initramfs) 


** Tags removed: verification-needed-focal
** Tags added: verification-done-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-26 Thread Dimitri John Ledkov
1) checking that reproducer still fails

sudo qemu-system-x86_64 -kernel ./vmlinuz-5.4.0-64-generic -initrd
./initrd-pad4-5.4.0-64-generic -append 'break=top quiet console=ttyS0'
-m 2G -nograt


[3.581106] Initramfs unpacking failed: Decoding failed
Spawning shell within the initramfs


BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6.3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cat /test-file
cat: can't open '/test-file': No such file or directory
(initramfs) uname -a
Linux (none) 5.4.0-64-generic #72-Ubuntu SMP Fri Jan 15 10:27:54 UTC 2021 
x86_64 GNU/Linux
(initramfs) 

As expected, error message shown and file from second initrd is not
accessible

2) checking that #65 ABI build of v5.4 is good

Verifying v5.4 using a custom test case:

sudo qemu-system-x86_64 -kernel ./vmlinuz-5.4.0-65-generic -initrd
./initrd-pad4-5.4.0-65-generic -append 'break=top quiet console=ttyS0'
-m 2G -nograt


Spawning shell within the initramfs


BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6.3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) cat /test-file 
second
(initramfs) uname -a
Linux (none) 5.4.0-65-generic #73-Ubuntu SMP Mon Jan 18 17:25:17 UTC 2021 
x86_64 GNU/Linux
(initramfs) QEMU 5.0.0 monitor - type 'help' for more information
(qemu) quit

All is good.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-26 Thread Dimitri John Ledkov
@vmc

this bugfix is not yet available on any .iso for any series yet. It can
only be tested from installed systems and enabling proposed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-25 Thread vmc
The corrected ISO date is this:
 hirsute-desktop-amd64.iso  2021-01-26 05:51
from Kubuntu daily-live current. It still fails.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-25 Thread vmc
This bug is still failing per current ISO dated 01/25/2021 booting from
Kubuntu 21.04:

$ sudo dmesg|grep failed
[0.538632] Initramfs unpacking failed: Decoding failed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-25 Thread vmc
This bug failure is still present as of current ISO dated 01/25/2021 using 
Kubuntu:
[code]vmc@01-25-21:~$ sudo dmesg|grep failed
[0.538632] Initramfs unpacking failed: Decoding failed[/code]

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-25 Thread Kelsey Skunberg
@vmclarck, @xnox, or anyone who has been dealing with this bug - may you
please verify if the kernel in -proposed resolves the problem for you in
Focal and/or Groovy? Instructions are listed in comment #120

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-21 Thread shanghf
Fix this bug with a patch, please have a try.

** Patch added: "Fix padding parse error"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835660/+attachment/5455378/+files/0001-initramfs-fix-Decoding-failed.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-20 Thread Ubuntu Kernel Bot
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-
focal' to 'verification-done-focal'. If the problem still exists, change
the tag 'verification-needed-focal' to 'verification-failed-focal'.

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!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-20 Thread Ubuntu Kernel Bot
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-
groovy' to 'verification-done-groovy'. If the problem still exists,
change the tag 'verification-needed-groovy' to 'verification-failed-
groovy'.

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-groovy

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-18 Thread Deadly Effect
I have successfully resolved the problem. I don't know exactly what
helped because I did a few things. Namely: I switched all SATA cables
from the second controller to the first (my computer motherboard has two
SATA controllers) and disabled the Compatibility Support Module.
Unfortunately, CSM turned off the BIOS boot options, only UEFI was left.
After changing the settings and rebooting, the message "Initramfs
unpacking failed: Decoding failed" was still showing on the screen, but
the system continued the boot process and finally saw the Ubuntu Server
20.04 installer

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-18 Thread Deadly Effect
The same thing happened when I try Ubuntu 20.10 live server... Let me
check the 18.04 server. I currently use Ubuntu Desktop 18.04 on my
laptop, maybe the server edition will work.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-18 Thread Deadly Effect
Hi
I have this issue when I try to boot USB installation pendrive with Ubuntu 
20.04.1 live server made from ISO available from the official webpage.
I downloaded ISO two times, I sha256 its content and compared to value stored 
in the SHA256SUMS file.
I want to install Ubuntu on my PC next to Windows 10 (dual-boot).
My PC is 4790k, 16GB RAM, GTX1080, multiple hard drives, system disk is SSD.

How can I cope with this issue? What can I do to omit it or to resolve it?
The "Initramfs unpacking failed: Decoding failed" message pops up just after 
the GRUB menu disappears.
Please help, I would really like to run the Ubuntu server on my computer.

Best regards

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-18 Thread Kleber Sacilotto de Souza
** Changed in: linux (Ubuntu Groovy)
   Status: Confirmed => Fix Committed

** Changed in: linux (Ubuntu Focal)
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Fix Committed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-14 Thread Dimitri John Ledkov
** Also affects: grub2 (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: grub2 (Ubuntu Hirsute)
   Importance: High
 Assignee: Dimitri John Ledkov (xnox)
   Status: Invalid

** Also affects: initramfs-tools (Ubuntu Hirsute)
   Importance: High
   Status: Invalid

** Also affects: linux (Ubuntu Hirsute)
   Importance: High
   Status: Confirmed

** Also affects: grub2 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: initramfs-tools (Ubuntu Groovy)
   Status: New => Invalid

** Changed in: initramfs-tools (Ubuntu Focal)
   Status: New => Invalid

** Changed in: grub2 (Ubuntu Groovy)
   Status: New => Invalid

** Changed in: grub2 (Ubuntu Focal)
   Status: New => Invalid

** Changed in: linux (Ubuntu Groovy)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Groovy)
   Status: New => Confirmed

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Focal)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  Confirmed
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Confirmed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-14 Thread Dimitri John Ledkov
** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  Invalid
Status in initramfs-tools source package in Focal:
  Invalid
Status in linux source package in Focal:
  New
Status in grub2 source package in Groovy:
  Invalid
Status in initramfs-tools source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  Confirmed
Status in grub2 source package in Hirsute:
  Invalid
Status in initramfs-tools source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2021-01-04 Thread Soren ONeill
I struggled with the same issue on a fresh Kubuntu 20.04 installation
(Lenovo Thinkpad P52s).

>From the Grub / Advanced options / Recovery mode / root terminal I was
able to remount the / as rw (rather than ro)

Changing 'lz4' to 'gzip' as per 
https://forums.linuxmint.com/viewtopic.php?f=46=323152
and running update-initramfs -c -k $(uname -r) I had a new issue: the fstab 
entry UUID=3e757667-25352354... was not resolved.

To solve this I had to:
manually changed the fstab entry from UUID=... to /dev/nvme0n1p2 
change COMPRESS=lz4 to gzim in /etc/initramfs-tools/initramfs.conf
update-initramfs as per above
reboot

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Triaged

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the kernel, which can
  also be used by other kernel modules such as cryptography, squashfs,
  zram, f2fs, comprssed kernel image, pstore. For example, previously
  rejected files with "bogus" length and extra padding may now be
  accepted, whereas they were previously getting rejected by the
  decompressor.

   * Ideally kernel should switch to the stable lz4 format which has
  better specification of end of stream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-12-02 Thread Dimitri John Ledkov
** Description changed:

  "initramfs unpacking failed: Decoding failed",  message appears on boot
  up.
  
  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.
  
  ---
  
  However, we currently believe that the decoding error reported in dmesg
  is actually harmless and has no impact on usability on the system.
  
  Switching from lz4 to gzip compression, simply papers over the warning,
  without any benefits, and slows down boot.
  
  Kernel should be fixed to correctly parse lz4 compressed initrds, or at
  least lower the warning, to not be user visible as an error.
+ 
+ [Impact]
+ 
+  * Decoding failure messages in dmsg with a single lz4 initrd
+ 
+  * Multiple lz4 compressed initrds cannot be decompressed by kernel,
+ when loaded by grub
+ 
+  * Multiple lz4 compressed initrds cannot be decompressed by kernel,
+ when there is padding between them
+ 
+ [Test Case]
+ 
+  * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4
+ 
+  * Create an lz4 compressed initrd with a single test-file in it with
+ some content. I.e. echo "second-initrd" > test-file, and then pack that
+ with cpio hewc owned by root & lz4 -l.
+ 
+  * Create a combined padded initrd of stock initrd, pad4, and the test-
+ marker initrd created above.
+ 
+  * Boot above with "break=top" kernel command line.
+ 
+  * With broken kernels, there should be dmesg error message that
+ decoding failed, and one will observe that /test-file does not exist in
+ the shell.
+ 
+  * With fixed kernel, /test-file in the initrd shell should exist, and
+ should have the expected content "second-initrd".
+ 
+  * The alignment and padding in the above test case depends on the size
+ of the first initrd => if a given padded initrd does not reproduce the
+ problem, try varying the size of the first initrd or that of the padding
+ between 0..4.
+ 
+ 
+ [Where problems could occur]
+ 
+  * This changes compatible lz4 decompressor in the kernel, which can
+ also be used by other kernel modules such as cryptography, squashfs,
+ zram, f2fs, comprssed kernel image, pstore. For example, previously
+ rejected files with "bogus" length and extra padding may now be
+ accepted, whereas they were previously getting rejected by the
+ decompressor.
+ 
+  * Ideally kernel should switch to the stable lz4 format which has
+ better specification of end of stream.

** Patch added: 
"0001-lib-decompress_unlz4.c-correctly-handle-zero-padding.patch"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835660/+attachment/5440421/+files/0001-lib-decompress_unlz4.c-correctly-handle-zero-padding.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Triaged

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

  [Impact]

   * Decoding failure messages in dmsg with a single lz4 initrd

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when loaded by grub

   * Multiple lz4 compressed initrds cannot be decompressed by kernel,
  when there is padding between them

  [Test Case]

   * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4

   * Create an lz4 compressed initrd with a single test-file in it with
  some content. I.e. echo "second-initrd" > test-file, and then pack
  that with cpio hewc owned by root & lz4 -l.

   * Create a combined padded initrd of stock initrd, pad4, and the
  test-marker initrd created above.

   * Boot above with "break=top" kernel command line.

   * With broken kernels, there should be dmesg error message that
  decoding failed, and one will observe that /test-file does not exist
  in the shell.

   * With fixed kernel, /test-file in the initrd shell should exist, and
  should have the expected content "second-initrd".

   * The alignment and padding in the above test case depends on the
  size of the first initrd => if a given padded initrd does not
  reproduce the problem, try varying the size of the first initrd or
  that of the padding between 0..4.

  
  [Where problems could occur]

   * This changes compatible lz4 decompressor in the 

[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-30 Thread Dimitri John Ledkov
so what grub is doing is correct.

It pads/aligns every initrd by 4, which is fine, and as per spec.

https://www.kernel.org/doc/html/latest/driver-api/early-userspace
/buffer-format.html

initramfs size can be filled with arbitrary amount of "\0" all the way
upto initramfs_size.

"In human terms, the initramfs buffer contains a collection of
compressed and/or uncompressed cpio archives (in the “newc” or “crc”
formats); arbitrary amounts zero bytes (for padding) can be added
between members."

Thus it feels to me that decompress_unlz4.c method in the kernel does
not correctly stop decompressing and returning consumed output position
(posp).

For example, decompress_inflate.c skips over trailer and updates output
pos by 8, at the end of successful conversion.

Similarly unlzma also updates posp at the end of conversion.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Triaged

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-30 Thread Dimitri John Ledkov
** Changed in: grub2 (Ubuntu)
   Status: Triaged => Invalid

** Changed in: linux (Ubuntu)
   Status: Invalid => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Triaged

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-30 Thread Dimitri John Ledkov
@twetzel21 this is not related to those changes at all.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-30 Thread Tim Wetzel
Dimitri, I note your comment #106 about secureboot patches upstream. If
I recall correctly, a linux security update came down through Ubuntu
Updater about the same time or just prior to the LTS 20.04.1 updates in
mid September. A number of issues with LTS 20.04.1 appeared following
two "batches" of September Ubuntu updates. To the extent that these
issues may be inter-related -- at least insofar as being triggered by
upstream Linux security change(s) -- please note the bug numbers listed
in post #93 above.

If not relevant to this particular bug, then please disregard in
deference to the other individual bug numbers; if inter-related, then
perhaps this can be helpful.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-26 Thread Dimitri John Ledkov
As discussed at https://github.com/lz4/lz4/issues/956 I really think it
is grub2 secureboot patches linuxefi bug. WIP thing is here
https://github.com/rhboot/grub2/pull/77/files

** Bug watch added: github.com/lz4/lz4/issues #956
   https://github.com/lz4/lz4/issues/956

** Changed in: grub2 (Ubuntu)
 Assignee: (unassigned) => Dimitri John Ledkov (xnox)

** Changed in: grub2 (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-26 Thread Dimitri John Ledkov
NAK on the linux patch.

I think this is a grub bug.

When loading multiple initrds, grub aligns_up each one of them at 4bytes
boundary, and allocates pages for that. And it declares and passes
ramdisk_image as the total allocated memory. Rather than the true size
of the initrds.

** Changed in: grub2 (Ubuntu)
   Status: New => Triaged

** Changed in: linux (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-26 Thread Ubuntu Foundations Team Bug Bot
The attachment "[PATCH] unlz4: Handle 0-size chunks, discard trailing
padding/garbage" seems to be a patch.  If it isn't, please remove the
"patch" flag from the attachment, remove the "patch" tag, and if you are
a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-26 Thread Dimitri John Ledkov
** Also affects: grub2 (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in grub2 package in Ubuntu:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-25 Thread Dimitri John Ledkov
So lz4 compressed initrd looks like this with hexdump

568f580 0523 00ac 54bf 4152 4c49 5245 2121 0021
568f590 0001 1cff 0050     
568f59a

I do wonder what ram is initialized too, and how those things look when
kernel reads initrd from memory as loaded by the bootloader / qemu.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-17 Thread Dimitri John Ledkov
Also i guess we (i) need to retest if
https://github.com/lz4/lz4/releases/tag/v1.9.3 fixes all the things =/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-17 Thread Dimitri John Ledkov
@Siarhei

That looks very valid. And we were close to getting to that, when apw &
I timed out looking at this.

lz4 -l Use Legacy format (typically for Linux Kernel compression)
  Note : -l is not compatible with -m (--multiple) nor -r

Which must always be used when creating initrd. Ideally, both userspace
output and linux kernel consumption should agree what said legacy format
should look like and what it must produce and consume.

Is https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md#legacy-
frame underspecified, or does lz4 produce non-compliant frames, or
kernel misprocesses compliant frames?

Also, can we upgrade lz4 in the kernel tree to 1.9.2?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-16 Thread Ubuntu Foundations Team Bug Bot
** Tags added: patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-16 Thread Siarhei Liakh
The patch had also been posted to LKML:

https://lkml.org/lkml/2020/11/16/1438

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-16 Thread Siarhei Liakh
Please take a look at the following patch as it might be relevant to the
issue at hand.


** Patch added: "[PATCH] unlz4: Handle 0-size chunks, discard trailing 
padding/garbage"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835660/+attachment/5434929/+files/0001-unlz4-Handle-0-size-chunks-discard-trailing-padding-.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


Re: [Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-06 Thread Tomek
Dziękuję za zainteresowanie. Aktualnie mój HP 8760 nie działa, więc
jak dla mnie problem z Ubuntu 20.04 stał się nieistotny.
Jeszcze raz dziękuję i pozdrawiam ekipę Ubuntu.
Tomek P.

2020-11-06 12:18 GMT+01:00, archi02 <1835...@bugs.launchpad.net>:
> Same issue here and no workaround works : neither switching from lz4 to
> gzip nor keeping lz4 and only update initramfs. I also tried to launch
> with another kernel, without success.
>
> The computer is now blocked (Xubuntu 20.04, fresh install). I really
> don't want to reinstall 18.04.
>
> What can I do ? Any idea will be welcome ! :)
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1900130).
> https://bugs.launchpad.net/bugs/1835660
>
> Title:
>   initramfs unpacking failed
>
> Status in OEM Priority Project:
>   New
> Status in initramfs-tools package in Ubuntu:
>   Invalid
> Status in linux package in Ubuntu:
>   Confirmed
>
> Bug description:
>   "initramfs unpacking failed: Decoding failed",  message appears on
>   boot up.
>
>   If I "update-initramfs" using gzip instead of lz, then boot up passes
>   without decoding failed message.
>
>   ---
>
>   However, we currently believe that the decoding error reported in
>   dmesg is actually harmless and has no impact on usability on the
>   system.
>
>   Switching from lz4 to gzip compression, simply papers over the
>   warning, without any benefits, and slows down boot.
>
>   Kernel should be fixed to correctly parse lz4 compressed initrds, or
>   at least lower the warning, to not be user visible as an error.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-11-06 Thread archi02
Same issue here and no workaround works : neither switching from lz4 to
gzip nor keeping lz4 and only update initramfs. I also tried to launch
with another kernel, without success.

The computer is now blocked (Xubuntu 20.04, fresh install). I really
don't want to reinstall 18.04.

What can I do ? Any idea will be welcome ! :)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-10-24 Thread Gon Solo
Has this to do with BLK_DEV_RAM being compiled as a module? From
init/initramfs.c:

>   if (IS_ENABLED(CONFIG_BLK_DEV_RAM))
>printk(KERN_INFO "Trying to unpack rootfs image as 
> initramfs...\n");
>else
>printk(KERN_INFO "Unpacking initramfs...\n");

>err = unpack_to_rootfs((char *)initrd_start, initrd_end - 
> initrd_start);
>if (err) {
>#ifdef CONFIG_BLK_DEV_RAM
>populate_initrd_image(err);
>#else
>printk(KERN_EMERG "Initramfs unpacking failed: %s\n", err);
>#endif

So the IS_ENABLED line is true while the ifdef CONFIG_BLK_DEV_RAM line
seems to evaluate to false.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-10-21 Thread Tim Wetzel
The fix for 1872159 (spinning logo hang on startup) has allowed me to
turn the splash screen back on; and this error is not visible. I do,
though, encourage completion of the fix for it since it rears its head
when the splash screens have to be disabled.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-10-21 Thread ed20900
I'm having this error too.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-10-14 Thread Matthieu Clemenceau
** Tags added: fr-79

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-10-12 Thread Rex Tsai
** Tags added: oem-priority originate-from-1896145 sutton

** Changed in: oem-priority
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in OEM Priority Project:
  New
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-10-02 Thread Tim Wetzel
Continues to occur even once the bug 1871268 install crash has been
dealt with (installing from latest daily-live current image). So affects
even a fresh install. Seemed to appear in mid-September updates along
with recurrence of bug 1872159, the dreaded spinning Ubuntu logo hang on
startup. So a fresh install does not resolve it; and the workarounds of
recreating the ram drive image no longer seem to work either.

This issue 1835660, the spinning logo hang 1872159, a problem with the
login password immediately triggering suspend 1897185, and then the
reinstallation crashes 1871268 (which happen when reinstalling to try to
get rid of all this) appeared with the last two Ubuntu updater packages,
since mid-September. The last of these also included an nVidia driver
update, which is believed to affect at least one of these issues.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-09-30 Thread Diego González
Still happening on 2020-10-01 (since at least 2019-10-01) on multiple
computers.

Quoting what bug description says:

"Kernel should be fixed to correctly parse lz4 compressed initrds, or at
least lower the warning, to not be user visible as an error."

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-09-25 Thread gruberm
Just installed a new system and the bug is still there, leading me straight 
back to this bug report for the 'fix'.
I was really hoping that this bug would have been addressed in 20.04.1.
Not sure why no one from the dev team is picking this up to rectify it.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-09-13 Thread Tony Thuitai
Applied the 'fix' from Comment #11 by vmc(vmclark) in Linux Mint 20. The
error is no longer logged. Some boots on my HP laptop with a 5400RPM
spinning Hard drive are slow but some are faster but some around the
same time with lz4. Hard disk performance on my laptop is better with
gzip than lz4. With lz4 the PC extremely lags when some apt packages are
being set up and configured and some final configurations after most or
all packages are installed, set up and configured but with gzip, the lag
never occurs and PC is usable. Hard disk read benchmarks are better with
gzip than with lz4. I think that lz4 is more suitable for an SSD than a
spinning hard drive

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-09-10 Thread ipv
i get this right away when i try to do a fresh install :

initramfs unpacking failed: Decoding failed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-09-08 Thread martin suc
This error is still happening and it is critical error which does not
allow me to start Ubuntu !

Distributor ID: Ubuntu
Description:Ubuntu 20.04.1 LTS
Release:20.04
Codename:   focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-08-31 Thread Sujit Kumar
Ubuntu put it at lz4 by default, so my gut tells me that'll give the
fastest boot time. I didn't change lz4 to anything, just ran this
command to get rid of the error:

sudo update-initramfs -c -k $(uname -r)

I believe you have to run this command everytime certain packages are
updated.

Runnning: Ubuntu 20.04.1

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-08-11 Thread danindenver
Been seeing this since new install of Linux Mint 20 (2 weeks ago)
(Have not noticed on a LM19.3 upgrade on a different machine)

I have been finding several small bugs and wondered if this may have
something to do with any of them.

I just tried the above fix.

I no longer see the error on boot up, but according to dmesg, my boot
time has increased by approximately 0.85 seconds.

No clue, yet, whether any other processes have been affected.

---
System:Kernel: 5.4.0-42-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 
Desktop: MATE 1.24.0 
   wm: marco dm: LightDM Distro: Linux Mint 20 Ulyana base: Ubuntu 
20.04 focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-08-06 Thread Pjotr12345
This is a simplified version of the means to work around this problem:

Step 1:
sudo sed -i 's/COMPRESS=lz4/COMPRESS=gzip/g' /etc/initramfs-tools/initramfs.conf

Step 2:
sudo update-initramfs -u

Step 3:
Reboot.

Now I wonder whether someone has already tried something other than gzip? 
Because initramfs.conf mentions no less than six options:
# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | xz ]

Apparently gzip is slower than lz4, which might slow the boot process by
several seconds. One of the other alternatives might be faster.

Of course I could test that myself, but I'm too lazy today, so I'm
hoping somebody else has done the footwork already

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-08-06 Thread gruberm
I'm watching this error since about 10 months hoping that this would be fixed 
before the 20.04 release.
Now we're almost 4 months past the release date and it's still there.
Given that the fix is quite easy, I'm wondering why this is still an unresolved 
issue.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-08-03 Thread Md Ayquassar
I recall that on one of my machines I had exactly the same situation as
reported in #20 and #21 up to the timings (5.3.0-26-generic in Ubuntu
19.10 with EFI Secure Boot and dual boot with Windows 10,
fastboot/hibernation disabled, LZ4 image by default, booting failed
often, booting succeeded upon reinstall with EFI secure boot).
Unfortunately, I don't have this machine any longer. @mario-gleirscher
would probably be of help if they provide us with some debugging when
asked by the Ubuntu maintainers.

On another machine, I still have this annoying printf in dmesg (and
journalctl -b):

[0.215092] NET: Registered protocol family 1
[0.215096] NET: Registered protocol family 44
[0.215105] pci :00:02.0: Video device with shadowed ROM at [mem 
0x000c-0x000d]
[0.215670] PCI: CLS 64 bytes, default 64
[0.215696] Trying to unpack rootfs image as initramfs...
[0.303126] Initramfs unpacking failed: Decoding failed
[0.306614] Freeing initrd memory: 48364K

I run 5.4.0-42-generic in Ubuntu 20.04.1 LTS focal.

As for me, this issue seems to simply uselessly burn processor cycles
(and, as every such issue, indirectly generate superfluous carbon
dioxide); there is a potential for optimization here.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-07-31 Thread Redsandro
Confirmed on Linux 5.4.0-42-generic with Linux Mint 20 (Ubuntu 20.04)
clean install.

Changing lz4 to gzip in /etc/initramfs-tools/initramfs.conf removed the
error (after doing sudo update-initramfs -u)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-07-25 Thread TJ
Is part of the issue here that some (most) initramfs-tools created
images have an uncompressed early CPU microcode firmware prefixed ?

That is stored as ASCII CPIO which is why Con see's that reported by
'file' since that tool checks the magic signatures at start of a file.

binwalk reveals more detail.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-07-24 Thread Davide
Ubuntu 20.04
for me the problem started after upgrading to the kernel version 
5.4.0-42-generic,
I noticed it because the boot up failed once.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-07-16 Thread Edmand Thipursian
Hi, I had this same issue while updating ubuntu 20, however, I have
noticed that kernal hung error while the update stalled.

So I have added the following in  /etc/sysctl.conf and rebooted the
server, this issue has gone(we can apply those parameter without
restarting server usings sysctl -w vm.dirty_background_ratio=5.

vm.dirty_background_ratio=5
vm.dirty_ratio=10

vm.swappiness=30
vm.vfs_cache_pressure=50

I have tried 4 different vms and it works with the workaround. Kernal is used 
as follows; 
5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 
x86_64 GNU/Linux

I am sure the could help some people out there to resolve this issue
asap.

Thanks
Edmand

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-07-04 Thread Saroumane
I think "file" is wrong. (I have the same kind of misleading output :
"ASCII cpio archive ..." )

You can try to you use "unmkinitramfs" on your inird.img (unfortunately "cpio" 
does not work to fully "unarchive" this kind of "multi-segments" archive) and 
check the size.
I have "lz4" initrd.img files around 80MB. If I uncompress/unarchive them with 
"unmkinitramfs", I get around 260MB of files and folders.
If I remake initrd with COMPRESS=gzip in /etc/initramfs-tools/initramfs.conf  I 
get initrd files a bit smaller (around 74 MB)

So I think update-initramfs (and the invoked script mkinitramfs) are doing 
their job.
The "initramfs unpacking failed: Decoding failed" error might just be a 
cosmetic error from grub or kernel.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-07-03 Thread Con Kolivas
The issue appears to be that update-initramfs creates uncompressed
images.

I have the same error but have been dealing with a different issue of it
failing to boot with a custom kernel by UUID which is why I haven't
posted a bug report. However, since this issue appears to be related,
upon further inspection I find that none of the initramfs images being
created are actually compressed at all.

file /boot/initrd.img*
/boot/initrd.img:  symbolic link to initrd.img-5.4.0-40-generic
/boot/initrd.img-5.4.0-33-generic: ASCII cpio archive (SVR4 with no CRC)
/boot/initrd.img-5.4.0-37-generic: ASCII cpio archive (SVR4 with no CRC)
/boot/initrd.img-5.4.0-39-generic: ASCII cpio archive (SVR4 with no CRC)
/boot/initrd.img-5.4.0-40-generic: ASCII cpio archive (SVR4 with no CRC)

These should all be lz4 images. I tried changing the initramfs config to
gzip but it still did not show a compressed file.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-06-18 Thread Stéphane Graber
All LXD virtual machines are hitting this too.

Run:
 - lxc launch images:ubuntu/focal/cloud f1 && lxc console f1

And you'll see it show that message. As mentioned above, boot then still
goes ahead and you get a login prompt, but as that may not always be the
case.

For example in linux-kvm, that fallback mechanism doesn't appear to work and we 
instead get a kernel panic unless we've manually modified the initrd to be gzip:
https://bugs.launchpad.net/cloud-images/+bug/1873809

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-06-18 Thread ALinuxUser
Given that the change to the compression format is one of the headline
features of Ubuntu 20, and that Ubuntu 20 is a LTS release (and thus,
for one thing, a release upon which other Linux distributions are based)
I am surprised that this problem made it into the final release.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-06-16 Thread Arnold
Same thing here. In my case, the computer keeps booting into emergency mode, 
with output like in #5, and some additional ACPI errors.
I changed COMPRESS to gzip as described in #47, but not back to lz4.
Now the computer keeps booting into emergency mode with the message "/dev/sda2 
clean" (which is my root partition). No more ACPI errors are reported.
However, in emergency mode, I need to do "mount -a" each time and then "exit", 
otherwise it will return to emergency mode after FS check. The booting is quite 
slow, though.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-06-13 Thread Denis
Can confirm 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835660/comments/26
What I did was I changed 

`COMPRESS=lz4` to `COMPRESS=gzip` in `/etc/initramfs-tools/initramfs.conf`, then
`sudo update-initramfs -u`

After, without a reboot I've changed `COMPRESS` back to `lz4`, and then
`sudo update-initramfs -u`

And after the reboot that error is gone.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-06-10 Thread Rhonal Velasco
I was dealing with some of these issues after install new kernel version this 
morning. However I was able to boot with older kernel versions. After a lot of 
test, now I am able to boot in the new kernel without any problem.
Here there are some checks and tasks that I could accomplish:

-) Check in /etc/fstab and make sure that there are not duplicated mount
points for EFI.

-) Try apt install --reinstall linux-image-5.4.0-37-generic

-) Try sudo update-grub

Also, I removed drivers for nvidia and VirtualBox because some errors
that I saw in journalctl.

Hope this helps somebody.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-26 Thread Smittie
This is the error that I get on boot up after a software update this
morning:

[   0478394 ] Initramfs unpacking failed: Decoding failed
[1356011] atas.00: failed to set xfermode (err mask=0x40) /dev/sda3: clean, 
205993/1831424 files, 2350143/7324160 blocks You are in emergency mode. After 
logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to 
reboot, "systemctl default" or "exit"
to boot into default mode.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-26 Thread Smittie
This is a blocking issue for me as well. Rolling back to 18.04 LTS.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-26 Thread Simon Repp
Correction for my last post: More investigation revealed that the issue
IS harmless after all - the error message just happened to be the only
message printed on an otherwise black and unresponsive screen for
multiple seconds before a timeout occurs that after further research
turned out to be caused by something else, not the decoding failure.
Regardless of that the rest of my previous post still applies. (The
"harmless message" exists and does not go away by following the steps
outlined by others, at least for me)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-25 Thread Simon Repp
I did a clean install of 20.04 on my machine (which has been running
Ubuntu, most recently 19.04, without issue so far) and I am facing this
- importantly in my case it is NOT a harmless message but actually
preventing boot - I am stuck in the initramfs prompt.

I tried the suggested workaround of editing "/etc/initramfs-
tools/initramfs.conf" to specify COMPRESS=gzip instead of COMPRESS=lz4
to no avail (issue remains on next boot attempt).

I can not run try elsewhere also suggested "sudo update-initramfs -u"
command because as I understand it I am lacking the proper context in
which this would be run - in the initramfs prompt I can not run it (or
at least don't know how), and if I boot into live ubuntu (which works
perfectly - this is also where I was able to edit the initramfs.conf
file) I could probably run this although it would be in the wrong
context (that of the live ubuntu, not the one on disk I installed
previously).

Thanks everyone for the effort to resolve this! I'll run 19.10 or
another distro in the meantime and hope this can be resolved soon.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-24 Thread Vitaly Larchenkov
Confirmed on 20.04 vmlinuz-5.4.0-31-generic

[0.691523] Trying to unpack rootfs image as initramfs...
[0.850467] Initramfs unpacking failed: Decoding failed
[0.864022] Freeing initrd memory: 83456K

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-21 Thread Zakhar
Confirmed also on a clean 20.04, kernel 5.4.0-31-generic

The time difference between gzip and lz4 is not noticeable by the user:
LZ4:
Startup finished in 14.815s (firmware) + 3.483s (loader) + 1.879s (kernel) + 
23.176s (userspace) = 43.354s 
graphical.target reached after 23.164s in userspace

GZIP:
Startup finished in 14.760s (firmware) + 3.441s (loader) + 2.276s (kernel) + 
22.805s (userspace) = 43.283s 
graphical.target reached after 22.775s in userspace

Actually, same as one poster above, it's a fraction of second faster
with gzip... but that could be in the limits of the precision of this
kind of measure.

So I'll stick to GZIP until the bug is fixed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-11 Thread mrazster
Same problem here in Ubuntu (Focal) no matter the kernelversion, even with 
custom compiled kernels (wich is what I use)
The problem was however easy fixed, as per earlier description, with changing 
compression by editing /etc/initramfs-tools/initramfs.conf to use gzip and then 
do "sudo update-initramfs -u".

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-11 Thread Rui Salvaterra
Running 20.04 here, and I've also noticed the same message. Maybe a
useful data point: I only see this on UEFI machines, my traditional BIOS
machines seem unaffected. Could it be something related to GRUB on UEFI?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-09 Thread VINAY KUMAR
8

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-06 Thread Ivan Prokopov
@vmc, I've noticed the same with nvme, or at least not slower. It slowed
after the last update for 20.04 and updating the kernel to 5.40.0-29
however. it was almost 5 seconds faster with version -28

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-05 Thread vmc
Ye, I tried X,K,U,b ubuntu, and all boot without errors. I also prefer
gzip. I had the reverse though. I find gzip is faster than lz4, and I'm
using nvme for boot.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-05-05 Thread Ivan Prokopov
Appears after upgrade from 18.04 to 20.04. Doesn't seem to affect the
system but I preferred to use gzip instead of lz4 as for me it doesn't
slow the boot (perhaps related to the fact I have nvme) - I've made
several tests with both compression methods. But even if it slows a
couple seconds I prefer this then priority 0 error. I agree that it
either has to be fixed for the LTS versions kernels at least, as if you
do not plan to change to the next LTS you will stuck with the current
Kernel version, and it make sense in some case as for me some drivers
didn't work with other kernel versions. Or the priority has to be
lowered that it won't appear as emergency.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-29 Thread Leon Adato
regarding #58 - ignore the last line. That's a copy-paste fail on my
part. Sorry.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-29 Thread Leon Adato
I've been experiencing this for several months now (not exactly sure
when it started). For me, the error leads to a hard stop and the option
to Ctrl-D to continue or ENTER for maintenance.

I followed the process from #47 (Saroumane wrote on 2020-04-06:)

Adding COMPRESS=gzip to /etc/initramfs-tools/initramfs.conf (instead of lz4) 
then:
sudo update-grub;sudo update-initramfs -c -k all;sudo update-grub
Reboot.

Still got error message.

I restored COMPRESS=lz4 then
sudo update-grub;sudo update-initramfs -c -k all;sudo update-grub
Reboot 

Still failed

systemd-analyse says :
Startup finished in 158us (firmware) + 568us (loader) + 2.027s (kernel) + 1min 
31.97s (userspace) = 1min 33.999s
graphical.target never reached

I can eventually get back into the system through a combination of
multiple reboots and dumb luck, but this is pretty annoying.

I rebooted a 3rd time : no change, still no more Decoding errors.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-29 Thread Jatin Sarda
>From the time i upgraded from 19.10 to 20.04 on 24th April, this didn't
came at first, during the boot just after upgrade, even now this error
randomly appears not every-time, but i can confirm its there with Ubuntu
20.04 too

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-26 Thread Eromatic
USB 2.0 flash drive install of ubuntu-20.04-desktop-amd64.iso
UNetbootin 677-1~bionic1 
AMD Athlon II X4 640
ASRock N68-S

The first time that I ran the USB install, the live version of Ubuntu
20.04 succeeded in booting without issue. Now each and every time I
attempt to boot the live USB, I get the following display which prevents
me from installing Ubuntu 20.04:

[0.391406] Initramfs unpacking failed: Decoding failed
[0.571137] Failed to execute /init (error -2)
[0.571241] Kernel panic - not syncing: No working init found. Try passing init= 
option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
[0.571349] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.4.0-26-generic #30-Ubuntu
[0.571434] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./N68-S, 
BIOS P2.00 12/15/2009
[0.571521] Call Trace:
[0.571593]  dump_stack+0x6d/0x9a
[0.571661]  ? rest_init+0x30/0xb0
[0.571729]  panic+0x101/0x2e3
[0.571797]  ? do_execve+0x25/0x30
[0.571863]  ? rest_init+0xb0/0xb0
[0.571930]  kernel_init+0xfb/0x100
[0.571998]  ret_from_fork+0x22/0x40
[0.572091] Kernel Offset: 0x29a0 from 0x8100 (relocation range: 
0x8000-0xbfff)
[0.572182] ---[ end Kernel panic - not syncing: No working init found.  Try 
passing init= option to kernel. See Linux Documentation/admin-guide/init.rst 
for guidance. ]---


Think that maybe something got corrupted on the flash drive, I redid the 
UNetbootin install, but the issue still remains. MD5 of 
ubuntu-20.04-desktop-amd64.iso checked good before procceeding.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-22 Thread Francis Ginther
** Tags added: id-5e861a6d29650f3423a935c0

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-20 Thread Steve Langasek
> I am having the same trouble, but during INSTALLATION, I already
installed Ubuntu 20.04 twice and I haven't access to it yet.

That is not this bug.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-20 Thread Steve Langasek
As stated, this is believed to not be a bug in initramfs-tools, only in
the kernel for displaying a spurious message.  Hence the 'linux' bug
task is confirmed.

** Changed in: initramfs-tools (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-19 Thread Kred1t
I’ve had the same problem during installation Ubuntu 20.04 Beta and last
daily release.

I’m not sure if it’s necessary  but  my  PC spec is Intel i9
9900k/RTX2080Ti.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-17 Thread Daniel Silva Capera
I am having the same trouble, but during INSTALLATION, I already
installed Ubuntu 20.04 twice and I haven't access to it yet. The first
time I got black screen (with safe graphics installation) then normal
installation didn't let me to install, and I try to reinstall with safe
graphics again. I got the same problem. (The first time I tried Ibunto
on normal mode without conplications, then after installing I had the
trouble).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-17 Thread John Gilmore
This happened for me yesterday, when booting the main Ubuntu 20.04 beta
x86_64 iso on real hardware (not a virtual machine).  It has a graphical
splash screen but in the upper left corner I get this "console" message.
Then eventually in a few seconds, after it has fully booted, that splash
screen is replaced and the system has booted up fine.  But it's a worry-
producing message that should really not be there.  If the kernel is
actually able to handle the stock ISO's initramfs, then please change
the kernel boot process to not produce an error message when there is no
error.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-10 Thread vmc
In post#14, I showed how my gzip booted faster.

"We currently believe that the decoding error reported in dmesg is
actually harmless and has no impact on usability on the system."

If 'harmless', then why the error in the first place? Something is
causing it. Sticking the error in the sand is NOT the answer!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-04-10 Thread Daniel Monteiro
For me its happening the same, if lz4 is activated get this initramfs
unpacking failed: Decoding failed at first line of boot, if switch to
gzip the error is gone, switching back to lz4 make the initramfs
unpacking failed: Decoding failed back again at boot, staying at gzip
for the time being.

Also no idea if relative, on my machine running Ubuntu Cinnamon 20.04 ,
when the lz4 is activated over the initramfs , it gives the error at
boot and will not show the oem logo during boot, if gzip is activated,
no error and it does show the oem logo during boot. Secure boot on my
machine have been always disabled and remains disabled.

** Changed in: initramfs-tools (Ubuntu)
   Status: Invalid => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1835660

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


  1   2   >