[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 1870260] Re: initramfs unpacking failed: Decoding failed", message appears on boot up.

2021-01-18 Thread Deadly Effect
*** This bug is a duplicate of bug 1835660 ***
https://bugs.launchpad.net/bugs/1835660

How to fix this bug? Anyone? I would like to use Ubuntu Server on my PC,
but I even can't install it.

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

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

Status in linux package in Ubuntu:
  Confirmed
Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  OS : Ubuntu 20.04(20200401)

  Problem: "initramfs unpacking failed: Decoding failed", message
  appears on boot up

  solution: 
If we edit /etc/initramfs-tools/initramfs.conf and COMPRESS=lz4, to 
COMPRESS=gzip 
  then the error is fixing .

  Expected solution:
  This but in there from a long time I have seen this from 
Ubuntu 18.04,19.04,19.10
  now in 20.04 So please fix it or change it from lz4 to gzip.
  an early reply is highly appreciated 
  Thank you .
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  tamal  1451 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 20.04
  InstallationDate: Installed on 2020-04-02 (0 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200331)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 0bda:b009 Realtek Semiconductor Corp. 802.11n WLAN 
Adapter
   Bus 001 Device 003: ID 0408:5365 Quanta Computer, Inc. HP TrueVision HD 
Camera
   Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: HP HP Laptop 15-da0xxx
  Package: ubuntu-meta
  ProcEnviron:
   LANGUAGE=en_IN:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_IN
   SHELL=/bin/bash
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-21-generic 
root=UUID=29f895bf-ab7b-4df8-8e9a-c277376a2685 ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-21-generic N/A
   linux-backports-modules-5.4.0-21-generic  N/A
   linux-firmware1.187
  Tags:  focal
  Uname: Linux 5.4.0-21-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 11/29/2019
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.23
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 84A6
  dmi.board.vendor: HP
  dmi.board.version: 80.43
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.23:bd11/29/2019:svnHP:pnHPLaptop15-da0xxx:pvrType1ProductConfigId:rvnHP:rn84A6:rvr80.43:cvnHP:ct10:cvrChassisVersion:
  dmi.product.family: 103C_5335KV HP Notebook
  dmi.product.name: HP Laptop 15-da0xxx
  dmi.product.sku: 5AY34PA#ACJ
  dmi.product.version: Type1ProductConfigId
  dmi.sys.vendor: HP

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1870260/+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