Skip to content
Snippets Groups Projects
  1. Sep 25, 2014
  2. Aug 31, 2014
  3. Aug 30, 2014
    • Michael Prokop's avatar
      Do not spawn shell when panic=... is used · 2290173f
      Michael Prokop authored
      Quoting Lukas Anzinger in #751488:
      
      | I've set panic=0 as a kernel cmdline argument which should trigger a
      | reboot instead of spawning a shell. However, the reboot seems to be
      | uneffective and a shell is spawned nevertheless. This is unpleasing
      | since spawn=0 is "marketed" as a security feature in
      | initramfs-tools(8):
      |
      |     panic sets an timeout on panic.  panic=<sec> is a documented
      |     security feature: it disables the debug shell.
      |
      | [...]
      |
      | The commands halt, reboot, etc. don't work either.
      |
      | To fix the security impact of an open shell I propose to at least add a
      | return after the reboot command so that if the reboot is effectively a
      | NOP still no shell is spawned.
      
      Thanks: Lukas Anzinger <l.anzinger@gmail.com> for the analysis and patch
      Closes: #751488
      2290173f
    • Michael Prokop's avatar
      Fix hidden dependency issue with btrfs and crc32c · 4c0338a7
      Michael Prokop authored
      Quoting Markus Wanner in #748805:
      
      | Since Linux 3.14 (or 0b947aff1599afbbd2ec07ada87b05af0f94cf10, to be
      | precise), the btrfs module no longer depends on libcrc32c, but only on
      | crc32c. However, this is one of the "hidden" dependencies, so
      | modules.dep doesn't list it. If mkinitramfs doesn't happen to include
      | crc32c for some other reason, an initrd without that module is
      | generated, even if btrfs needs it to boot. For me, this led to the same
      | error upon boot, as others have posted, before:
      |
      | modprobe: can't load module btrfs (kernel/fs/btrfs/btrfs.ko): unknown
      | symbol in module, or unknown parametr
      |
      | (Without any further hints in dmegs, BTW)
      |
      | The attached patch adds an entry to the list of hidden dependencies to
      | /usr/share/initramfs-tools/hook-functions to fix this issue. This also
      | renders the work-around proposed by Tristan unnecessary.
      
      Thanks: Markus Wanner <markus@bluegap.ch> for the analysis and patch
      Closes: #748805
      4c0338a7
  4. Jun 11, 2014
    • Aurelien Jarno's avatar
      hook-functions: add support for virtio-mmio · 2e325a2b
      Aurelien Jarno authored
      
      On most virtual machines it is possible to use the virtio interface
      through the PCI bus to export for example block or net devices. On some
      architectures the emulated machine does not have a PCI bus, and thus the
      transport goes through an MMIO interface.
      
      Currently initramfs-tools correctly handle the PCI case, but not the
      MMIO on. In case of a virtio based root device, the virtio_mmio module
      is not available in the initramfs causing the boot to fail. This commit
      adds the virtio_mmio module if virtio is used (in dep mode), or by
      default (in most mode).
      
      Closes: #751143
      Signed-off-by: default avatarMichael Prokop <mika@debian.org>
      2e325a2b
  5. Jun 03, 2014
  6. Apr 26, 2014
    • Helge Deller's avatar
      get_fstype: initialize FSTYPE variable · cee3e18f
      Helge Deller authored
      
      On the hppa platform the fstype program from klibc crashed (details in Bug#745660) which exposed a problem in the
      get_fstype() shell function in file scripts/functions.
      
      In this script, fstype is called like this:
              eval $(fstype "${FS}" 2> /dev/null)
              if [ "$FSTYPE" = "unknown" ] ....
      Since fstype crashed and returned nothing in the variable "FSTYPE", FSTYPE stayed empty instead of the value "unknown" and as such no further analysis via blkid was done.
      
      I think it makes sense to pre-initialize FSTYPE to the value "unknown" before
      calling fstype. That way the program logic will continue correctly if something
      with the fstype program is wrong.
      
      Closes: #745731
      
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarmaximilian attems <maks@debian.org>
      cee3e18f
  7. Nov 04, 2013
  8. Sep 28, 2013
  9. Sep 26, 2013
  10. Sep 22, 2013
  11. Sep 12, 2013
  12. Sep 11, 2013
  13. Jun 18, 2013
  14. Jun 17, 2013
  15. May 06, 2013
  16. Apr 23, 2013
  17. Mar 30, 2013
  18. Mar 01, 2013
  19. Jan 21, 2013
  20. Oct 05, 2012
Loading