Bug#778849: Support restoring initrd on shutdown and pivoting into it

[alsauser]

On Fri 07 Apr 2017 12:02:46 +0200, intrigeri wrote:
> /lib/systemd/system/initramfs-shutdown.service:
> ⋯
> /usr/share/initramfs-tools/initramfs-restore:
> ⋯
> /usr/bin/unmkinitramfs /initrd.img "$WORKDIR"
> ⋯
> /lib/systemd/system-shutdown/initramfs-tools:
> ⋯
> /usr/share/initramfs-tools/hooks/shutdown:
> ⋯
> copy_exec /lib/systemd/systemd-shutdown /shutdown
> touch $DESTDIR/etc/initrd-release

I was also experiencing improper shutdown of a root filesystem on nvme drives 
:(  This is a new Bookworm install with the root file system on an LVM thin 
pool which in turn resides on two nvme drives configured for Raid10 via mdadm.

I tried the suggestion from intrigeri but did not accomplish a successful pivot 
to initramfs.  I -believe- the problem was that the "mount -o remount,exec 
/run" occurred too "late" when it was attempted in 
/usr/lib/systemd/system-shutdown/initramfs-tools.  I moved the "mount -o 
remount,exec /run" to /usr/share/initramfs-tools/initramfs-restore and was able 
to get systemd to successfully pivot into the initramfs, and detach all drives 
... YMMV :)

Bug#872623: kbd: setmetamode fails with StackSmashing detected

[alsauser]

As a follow-up to my initial post ...

Obviously, changing the return statement in setmetamode.c is only
a "band-aid" that restores operation, but does nothing to correct
the underlying problem.

Upon closer examination, it appears that the KDGKBMETA IOCTL that
is called by setmetamode.c, is subsequently calling:
   put_user (, (int __user*) arg);

Unfortunately, the argument (ometa) is only declared as "char" in
setmetamode.c.  So, in essence, we are asking the kernel to store
an  into a user space location that has only been
allocated as a "char".

I now believe that the appropriate correction is to change the
"char ometa, nmeta;" declaration in setmetamode.c to
"unsigned int ometa, nmeta;".  During my testing, this change
eliminated the StackSmashing detection and subsequent traceback.

If this problem and analysis is confirmed by other users, I would
hope that this fix could be propagated into a subsequent Stretch
update so as to restore operation of the setmetamode utility.

Bug#872623: kbd: setmetamode fails with StackSmashing detected

[alsauser]

Package: kbd
Version: 2.0.3-2+b1
Severity: normal

Dear Maintainer,

Standard Stretch release.
Running "setmetamode esc" (or setmetamode meta) results in a report that
StackSmashing was detected and subsequent stack traceback messages.

Although by no means an expert, I -believe- that the problem is with the
last line of setmetamode.c, which reads "return EXIT_SUCCESS;".  In my
tests, replacing this with "exit(EXIT_SUCCESS);" eliminated the
StackSmashing detection and traceback messages.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kbd depends on:
ii  libc6 2.24-11+deb9u1
ii  lsb-base  9.20161125

Versions of packages kbd recommends:
ii  console-setup  1.164

kbd suggests no packages.

-- no debconf information

Bug#848671: xpdf: Many errors "Config Error: Unknown config file command..."

[alsauser]

I can confirm that this problem is still present in Stretch 9.0.

Starting from a Debian LiveCD image (9.0.1 Debian Mate), and
using "apt-get install xpdf" to install xpdf, and then entering
"xpdf " yields a long list of Config Errors on the
xterm console ... of the form:

Config Error: Unknown config file command 'fontFileCC' 
(/usr/share/xpdf/xpdfrc-korean:6)
Config Error: Some work needs to be done to support this option in the Poppler 
version of xpdf

The suggested Workaround of adding "include /etc/xpdf/includes"
is not helpful as this line is already at the end of the
/etc/xpdf/xpdfrc file in the stock Debian Stretch release :(

Additional suggestions appreciated - thanks !

Bug#592834: Grub messages during upgrade

[alsauser]

On Thu, 09 Mar 2017 19:57:36 +0800 Steve M  wrote:
> Last couple of upgrades have seen similar results to the below:
> 
> Generating grub configuration file ...
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9473: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9473: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9486: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9486: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9499: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9499: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9512: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9512: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9572: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9572: 
> /usr/sbin/grub-probe

I am experiencing the exact same messages.  Brand new Debian Stretch install, 
root file system installed on LVM volume.  Messages occur during subsequent 
apt-get install of mdadm package from "official" Debian 9.0.0 BluRay DVD (the 
apt-get install was performed immediately after a successful shutdown and 
reboot).  Same "pairs" of Parent PIDS: 1308,1308, 1338,1338, 1368,1368, 
1398,1398, then 1563, etc.

Bug#847802: can't open /sys/block/*/removable: 9990-misc-helpers.sh

[alsauser]

Package: live-boot
Version: 4.0.2-1

On some computer systems, when booting from the "debian GNU/Linux 8.1 Live 
"Jessie" amd64 Standard" CDROM, the 9990-misc-helpers.sh script is dispatched 
before the /sys/block directory is populated, resulting in a multiple copies of 
the disturbing message: "cat: can't open '/sys/block/*/removable': no such file 
or directory" on the console.

This occurs after the splash screen is removed and just after the initial 
"Loading, please wait ..." message has been displayed.  My (limited) testing 
indicates that the /sys/block directory is present but empty when the 
9990-misc-helpers.sh script is run.

The behavior occurs on a system with an ASRock E3C226D2I motherboard, populated 
with an E3-1240L v3 Xeon processor and 16 GB of ECC memory and no internal 
drives when booted from an external USB-3 CD/DVD drive.  The behavior does not 
seem present on my older desktop workstation with internal sata hard drives and 
an internal sata CD/DVD drive.

I have been able to temporarily correct the issue with the following "hook" 
file used during the live-build process:

1234-fixhelper.hook.chroot:
#!/bin/sh
set -e
sed -i '\:echo /sys/block:s:|fd:|fd|\\*$:' /lib/live/boot/9990-misc-helpers.sh

Best regards, Scott.