Bug#1006127: wireless-regdb stable policy

[Laurent Bigonville]

FTR, this seems to be fixed in the last release (2022-02-18) of 
wireless-regdb: 
https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=e427ff2a592e26fc1e8336769b9a1ad223f6f697

Bug#909473: fstrim shows incorrect trimmed size after reboot

[Laurent Bigonville]

Le 8/06/21 à 21:24, Bastian Blank a écrit :

Hi

Hello,

On Tue, Jun 08, 2021 at 03:48:11PM +0200, Laurent Bigonville wrote:

There is definitely something boggus here

Yes, just tested it now and  it's still happening with the kernel currently
in unstable (5.10.40-1)

Why do you think this numbers are wrong?  "fstrim" initially requests
discard of all unused blocks, so a large number.  But why should it do
the same on subsequent calls while it still knows what it did the last
time?

ext4 caches the information if a particular block group was trimmed, but
this information is not persistent.  (Using bit
EXT4_GROUP_INFO_WAS_TRIMMED_BIT in ext4_group_info.bb_state.)


Well I would expect that if I'm running fstrim, the same blocks would 
not be trimmed again (even after reboot) if I'm running the command again


Here it seems that it's the case, the number of blocks that are being 
trimmed are the same after reboot.


Are the discard commands delayed and actually not executed when the 
command is run, or am I overlooking something?

Bug#909473: fstrim shows incorrect trimmed size after reboot

[Laurent Bigonville]

Control: tags -1 - moreinfo

Le 28/05/21 à 21:28, Salvatore Bonaccorso a écrit :

Control: tags -1 + moreinfo

Hi Laurent,

On Mon, Sep 24, 2018 at 01:37:01PM +0200, Laurent Bigonville wrote:

Package: src:linux
Version: 4.18.8-1
Severity: normal

Hi,

Not sure who to blame here, but when running fstrim -va it show the size
of the disk it has trimmed, if I'm running fstrim again it shows 0 for
all the disk.

If I reboot, and then run fstrim again it shows (almost) the same value
as the 1st time. All the disks have the discard option enabled, all fs
are ext4, except /boot which is ext2/

See the logs:

bigon@valinor:~$ journalctl -u fstrim.service
-- Logs begin at Sat 2018-09-08 12:48:02 CEST, end at Mon 2018-09-24 13:32:05 
CEST. --
sep 17 10:44:21 valinor systemd[1]: Starting Discard unused blocks...
sep 17 10:44:51 valinor fstrim[11186]: /var/cache/apt-cacher-ng : 930,1 MiB 
(975245312 octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/sbuild/build : 9,8 GiB 
(10463989760 octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/docker : 10 GiB (10713788416 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /home : 11,3 GiB (12105969664 octets) 
taillés
sep 17 10:44:51 valinor fstrim[11186]: /boot : 126,9 MiB (133014528 octets) 
taillés
sep 17 10:44:51 valinor fstrim[11186]: / : 8,6 GiB (9217847296 octets) taillés
sep 17 10:44:51 valinor systemd[1]: Started Discard unused blocks.
-- Reboot --
sep 24 10:12:35 valinor systemd[1]: Starting Discard unused blocks...
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/sbuild/build : 9,8 GiB 
(10455736320 octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/cache/apt-cacher-ng : 922,8 MiB 
(967565312 octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/docker : 11,4 GiB (12180299776 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /home : 11 GiB (11825807360 octets) 
taillés
sep 24 10:13:08 valinor fstrim[26936]: /boot : 126,9 MiB (133008384 octets) 
taillés
sep 24 10:13:08 valinor fstrim[26936]: / : 8,6 GiB (9219850240 octets) taillés
sep 24 10:13:08 valinor systemd[1]: Started Discard unused blocks.
-- Reboot --
sep 24 13:20:54 valinor systemd[1]: Starting Discard unused blocks...
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/docker : 11,4 GiB (12181008384 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/cache/apt-cacher-ng : 793,9 MiB 
(832487424 octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /home : 10,8 GiB (11617431552 octets) 
taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/sbuild/build : 9,8 GiB 
(10463989760 octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /boot : 126,9 MiB (133008384 octets) 
taillés
sep 24 13:21:28 valinor fstrim[6751]: / : 8,6 GiB (9211752448 octets) taillés
sep 24 13:21:28 valinor systemd[1]: Started Discard unused blocks.
sep 24 13:32:05 valinor systemd[1]: Starting Discard unused blocks...
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/docker : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/cache/apt-cacher-ng : 0 B (0 octets) 
taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/libvirt : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /home : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/sbuild/build : 0 B (0 octets) 
taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/flatpak : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /boot : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: / : 0 B (0 octets) taillés
sep 24 13:32:05 valinor systemd[1]: Started Discard unused blocks.

There is definitely something boggus here

Is this still something you are able to reproduce this way with a
recent kernel?


Hello Salvatore,

Yes, just tested it now and  it's still happening with the kernel 
currently in unstable (5.10.40-1)

Bug#883194: please convert mountstats and nfsiostat scripts to Python3

[Laurent Bigonville]

On Thu, 30 Nov 2017 16:37:52 +0100 Matthias Klose  wrote:

>
> the changelog reads:
>
> - nfs-common: Add Recommends python for mountstats and nfsiostat
>
> Please convert these scripts to python3, and recommend Python3 instead.
>

I think they should already be compatible with python3 since 1.2.9 (or 
1.3.1) if I'm looking at upstream git repository:


http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=9f9289efda1a7eff26cd046997efc56c2de40534

http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=1df82a36df74a59f55eea99d08612564fa22cbef

So it's just a matter of changing the shebang and the dependency.

Question, why is this a recommends? The executable is using python(3) 
without any fallback mechanism I can understand that this is a "not 
often use binary", but shouldn't that be changed to a Depends?

Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

[Laurent Bigonville]

Source: linux
Version: 4.18.10-2
Followup-For: Bug #895378

Hi,

I can confirm this (and it's quite annoying).

It worked fine in 4.14 and it's broken since 4.15.

I'm trying to bissect the kernel but it is not even booting ("32-bits
relocation outside of the kernel) and I'm not too sure how to fix that.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#909473: fstrim shows incorrect trimmed size after reboot

[Laurent Bigonville]

Package: src:linux
Version: 4.18.8-1
Severity: normal

Hi,

Not sure who to blame here, but when running fstrim -va it show the size
of the disk it has trimmed, if I'm running fstrim again it shows 0 for
all the disk.

If I reboot, and then run fstrim again it shows (almost) the same value
as the 1st time. All the disks have the discard option enabled, all fs
are ext4, except /boot which is ext2/

See the logs:

bigon@valinor:~$ journalctl -u fstrim.service
-- Logs begin at Sat 2018-09-08 12:48:02 CEST, end at Mon 2018-09-24 13:32:05 
CEST. --
sep 17 10:44:21 valinor systemd[1]: Starting Discard unused blocks...
sep 17 10:44:51 valinor fstrim[11186]: /var/cache/apt-cacher-ng : 930,1 MiB 
(975245312 octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/sbuild/build : 9,8 GiB 
(10463989760 octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/docker : 10 GiB (10713788416 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 17 10:44:51 valinor fstrim[11186]: /home : 11,3 GiB (12105969664 octets) 
taillés
sep 17 10:44:51 valinor fstrim[11186]: /boot : 126,9 MiB (133014528 octets) 
taillés
sep 17 10:44:51 valinor fstrim[11186]: / : 8,6 GiB (9217847296 octets) taillés
sep 17 10:44:51 valinor systemd[1]: Started Discard unused blocks.
-- Reboot --
sep 24 10:12:35 valinor systemd[1]: Starting Discard unused blocks...
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/sbuild/build : 9,8 GiB 
(10455736320 octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/cache/apt-cacher-ng : 922,8 MiB 
(967565312 octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/docker : 11,4 GiB (12180299776 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 24 10:13:08 valinor fstrim[26936]: /home : 11 GiB (11825807360 octets) 
taillés
sep 24 10:13:08 valinor fstrim[26936]: /boot : 126,9 MiB (133008384 octets) 
taillés
sep 24 10:13:08 valinor fstrim[26936]: / : 8,6 GiB (9219850240 octets) taillés
sep 24 10:13:08 valinor systemd[1]: Started Discard unused blocks.
-- Reboot --
sep 24 13:20:54 valinor systemd[1]: Starting Discard unused blocks...
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/docker : 11,4 GiB (12181008384 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/cache/apt-cacher-ng : 793,9 MiB 
(832487424 octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/libvirt : 17,9 GiB (19241095168 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /home : 10,8 GiB (11617431552 octets) 
taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/sbuild/build : 9,8 GiB 
(10463989760 octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /var/lib/flatpak : 1,4 GiB (1496272896 
octets) taillés
sep 24 13:21:28 valinor fstrim[6751]: /boot : 126,9 MiB (133008384 octets) 
taillés
sep 24 13:21:28 valinor fstrim[6751]: / : 8,6 GiB (9211752448 octets) taillés
sep 24 13:21:28 valinor systemd[1]: Started Discard unused blocks.
sep 24 13:32:05 valinor systemd[1]: Starting Discard unused blocks...
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/docker : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/cache/apt-cacher-ng : 0 B (0 octets) 
taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/libvirt : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /home : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/sbuild/build : 0 B (0 octets) 
taillés
sep 24 13:32:05 valinor fstrim[7323]: /var/lib/flatpak : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: /boot : 0 B (0 octets) taillés
sep 24 13:32:05 valinor fstrim[7323]: / : 0 B (0 octets) taillés
sep 24 13:32:05 valinor systemd[1]: Started Discard unused blocks.

There is definitely something boggus here

Kind regards,

Laurent Bigonville

-- Package-specific info:
** Version:
Linux version 4.18.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.8-1 (2018-09-18)

** Command line:
BOOT_IMAGE=/vmlinuz-4.18.0-1-amd64 root=/dev/mapper/valinor--vg-root ro quiet 
splash audit=1 selinux=1 security=selinux

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20CK0002MB
product_version: ThinkPad T550
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N11ET46W (1.22 )
board_vendor: LENOVO
board_name: 20CK0002MB
board_version: SDK0E50510 WIN

** Loaded modules:
fuse
nf_conntrack_netlink
xfrm_user
xfrm_algo
xt_addrtype
br_netfilter
overlay
xt_CHECKSUM
ipt_MASQUERADE
xt_conntrack
ipt_REJECT
xt_tcpudp
tun
bridge
stp
llc
nf_tables_set
devlink
nft_fib_inet
nft_fib_ipv4
nft_fib_ipv6
nft_fib
nft_reject_inet
nf_reject_ipv4

Bug#906729: Please fix SELinux labels of /vmlinuz symlink after kernel update

[Laurent Bigonville]

Package: linux-base
Version: 4.5
Severity: normal
File: /usr/bin/linux-update-symlinks
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux

Hi,

After updating the kernel it seems that the /vmlinuz(.old) and
/initrd.img(.old) symlinks are deleted and then recreated.

This means that the SELinux label of these symlinks should be reset.

The easiest way of doing that is (as there are no perl bindings) to call
restorecon executable if the executable is installed on the machine as
it handel the case were selinux is disabled on the machine gracefully

ie. restorecon /vmlinuz

Kind regards,

Laurent Bigonville

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.69

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information:
  linux-base/removing-title:
  linux-base/removing-running-kernel: true

Bug#898446: Please reconsider enabling the user namespaces by default

[Laurent Bigonville]

Le 13/05/18 à 01:33, Ben Hutchings a écrit :

Control: tag -1 moreinfo

On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:

Source: linux
Version: 4.16.5-1
Severity: normal

Hi,

Firefox (and probably other applications) are using user namespaces these
days to enhance the security.

Can you provide some information about this?

https://www.morbo.org/2018/05/linux-sandboxing-improvements-in_10.html

Bug#898446: Please reconsider enabling the user namespaces by default

[Laurent Bigonville]

Source: linux
Version: 4.16.5-1
Severity: normal

Hi,

Firefox (and probably other applications) are using user namespaces these
days to enhance the security.

Debian is disabling these since 2013, the original patch states it's a
short term solution, but we are here 5 years later and they are still
disabled.

Apparently debian (and ubuntu) and arch are the only distributions
disabling the user namespaces.

Is there a list of remaining issues with the user namespaces? IIRC the
only discussion I've seen were about adding upstream the option to
disable them at runtime, nothing else.

Is it a possibility to reenable these for buster?

Kind regards,

Laurent Bigonville

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#897572: urandom hang in early boot

[Laurent Bigonville]

Hello,

Apparently it's also happening for other applications that are starting 
later during the boot like GDM.


Somebody has reported an issue on IRC where GDM was taking upto 8 
minutes to start (dmesg was showing several "random: systemd: 
uninitialized urandom read (16 bytes read)" during boot)


That problem might impact lot of people I'm afraid.

Installing rng-tools5 seems to help in that case.

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

[Laurent Bigonville]

On Sat, 05 May 2018 20:01:45 +0100 Ben Hutchings  
wrote:

> On Fri, 2018-05-04 at 12:20 +1200, Ben Caradoc-Davies wrote:
> > On 04/05/18 11:52, Ben Caradoc-Davies wrote:
> > > - Pressing *any* key repeatedly is enough to eventually wake up the
> > > plymouth LUKS screen. For example, pressing Backspace many times.
> >
> > Even a modifier key is sufficient. Without input, the screen remains
> > blank indefinitely (with just a blinking cursor for "quiet" boot).
> > Pressing right Alt 11-18 times (varies from test to test) causes the
> > plymouth LUKS passphrase screen to appear.
> >
> > I have attached a photo of the screen for a boot with "quiet" removed
> > from and "plymouth.debug" added to the kernel command line.
>
> I wonder if this is related to the recent RNG changes. It seems that
> many programs have started using blocking RNG functions like
> getentropy(), and now that the kernel is more conservative in its
> initial entropy estimation they can block for a long time. Keyboard or
> mouse input adds entropy.
>
> At a guess, plymouth is starting the X server and the X server wants
> random bits for MIT-MAGIC-COOKIE authentication.

Hello Ben,

plymouth doesn't uses Xorg, it uses libdrm and KMS directly.

Bug#874523: /usr/share/initramfs-tools/hook-functions: copy_exec can copy shared library twice in case of usr-merge

[Laurent Bigonville]

Package: initramfs-tools-core
Version: 0.130
Severity: normal
File: /usr/share/initramfs-tools/hook-functions
User: m...@linux.it
Usertags: usrmerge

Hi,

The plymouth package is doing the following in its hook file:

for _LIBRARY in /lib/@DEB_HOST_MULTIARCH@/libnss_files*
do
if [ -e "${_LIBRARY}" ]
then
copy_exec "${_LIBRARY}"
fi
done

On machine with usr-merge, this results with the following in the
initramfs

lrwxrwxrwx   1 root root   20 Sep  6 23:04 
usr/lib/x86_64-linux-gnu/libnss_files.so.2 -> libnss_files-2.24.so
-rw-r--r--   1 root root47632 Aug 26 11:09 
usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
lrwxrwxrwx   1 root root   20 Sep  6 23:04 
lib/x86_64-linux-gnu/libnss_files.so.2 -> libnss_files-2.24.so
-rw-r--r--   1 root root47632 Aug 26 11:09 
lib/x86_64-linux-gnu/libnss_files-2.24.so
lrwxrwxrwx   1 root root   51 Sep  6 23:04 
lib/x86_64-linux-gnu/libnss_files.so -> 
../../usr/lib/x86_64-linux-gnu/libnss_files-2.24.so

Passing the verbose flag to update-initramfs shows:

Adding binary /lib/x86_64-linux-gnu/libnss_files-2.24.so
Adding binary-link /lib/x86_64-linux-gnu/libnss_files.so
Adding binary /usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
Adding binary-link /lib/x86_64-linux-gnu/libnss_files.so.2

Regards,

Laurent Bigonville


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages initramfs-tools-core depends on:
ii  cpio 2.11+dfsg-6
ii  klibc-utils  2.0.4-9
ii  kmod 24-1
ii  udev 234-3

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.22.0-19+b3

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.1-4.3

-- no debconf information

Bug#872726: linux: apparmor doesn't use proper audit event ids

[Laurent Bigonville]

Le 03/09/17 à 13:01, intrigeri a écrit :

Hi Laurent!


Hello,


Laurent Bigonville:

IMVHO, in regard to the recent proposal of enabling apparmor in debian
by default, this needs to be addressed first.

I'm genuinely curious why this should be a blocker for Debian: this is
not obvious to me as a number of distros could enable AppArmor by
default and can apparently live with this bug.

Can you please make it explicit, e.g. describing what exact use cases
would be harmed by enabling AppArmor by default without fixing this
bug first?
I think that having the denials of a MAC properly logged is important 
for both people developing their policy and also for intrusion/non 
conformity detection.


If someone wants to send their logs to some logging services 
(ELK/splunk/...) having the messages properly logged/categorized seems 
to be the start here.


Kind regards,

Laurent Bigonville

Bug#872726: linux: apparmor doesn't use proper audit event ids

[Laurent Bigonville]

Source: linux
Version: 4.12.6-1
Severity: normal

Hi,

Currently the code in the kernel is not using the expected audit event
ids (it's using the one allocated to SELinux, 1400 to 1499) when it's
logging its messages (denials,...).

This has been discussed on the linux-audit back to 2014 and again in
2016, but it seems that nothing has moved. This makes auseach and other
audit tools not list these messages as they are seen as invalids.

Upstream of the audit framework insists that AppArmor should use
events ids from the range that has been allocated to them (1500-1599).
AFAIKS, the apparmor userspace is already supporting messaging from both
ranges (would be nice if this was confirmed).

IMVHO, in regard to the recent proposal of enabling apparmor in debian
by default, this needs to be addressed first.

Regards,

Laurent Bigonville

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#867486: Issue with the audit subsystem

[Laurent Bigonville]

Le 03/08/17 à 07:46, Salvatore Bonaccorso a écrit :

Hi Laurent,


Hi,


Sorry for the lack of time and no reply to this.

On Fri, Jul 14, 2017 at 02:40:02PM +0200, Laurent Bigonville wrote:

Le 09/07/17 à 21:58, Salvatore Bonaccorso a écrit :

Hi

Hi,


Unconfirmed, but the behaviour you are seen might be related to the
changes which went in in 4.11 around
264d509637d95f9404e52ced5003ad352e0f6a26 .

https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26


I posted on the linux-audit mailing list and I get the following reply from
Paul Moore:


On Mon, Jul 10, 2017 at 10:59 AM, Laurent Bigonville<bi...@debian.org>  wrote:

Hi,

With 4.11.6 (that has been uploaded in debian unstable) I get a lot of
messages in dmesg like

[100052.120468] audit: audit_lost=66041 audit_rate_limit=0
audit_backlog_limit=8192
[100052.120470] audit: kauditd hold queue overflow

And it also seems that the messages are not stored in auditd logs anymore.

https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26  seems
to be included in this release

An idea?

I'm going to assume that your backlog limit is set to a sane value for
your system's configuration, so that leaves me with two commits that
may be of interest:

* 1df30f8264b8 ("audit: fix the RCU locking for the auditd_connection
structure")

This was a manual backport of a v4.12 patch to v4.11, looking now, I
see it should be in +v4.11.5 so that probably isn't your problem ...

* c81be52a3ac0 ("audit: fix a race condition with the auditd tracking code")

This patch is relatively new and was just sent up to Linus during the
next merge window; it's a race condition fix so reproducing it can be
tricky, although it may be easily reproducible on your system at the
moment (luck you!).  If you aren't in a position to apply the patch,
the workaround is rather simple: restart auditd.

If none of the above works, let me know, but I strongly suspect you're
tripping over the race condition fixed in that last patch.

I still should test the last patch he mentioned

Did you manage to test the last patch he mentioned? And does it
resolve the issue?


I didn't had the time to recompile the kernel with that patch included.

I can just confirm that it still happening with the kernel currently in 
experimental (4.12.2-1~exp1)

Bug#867486: Issue with the audit subsystem

[Laurent Bigonville]

Le 09/07/17 à 21:58, Salvatore Bonaccorso a écrit :

Hi

Hi,


Unconfirmed, but the behaviour you are seen might be related to the
changes which went in in 4.11 around
264d509637d95f9404e52ced5003ad352e0f6a26 .

https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26



I posted on the linux-audit mailing list and I get the following reply 
from Paul Moore:



On Mon, Jul 10, 2017 at 10:59 AM, Laurent Bigonville<bi...@debian.org>  wrote:

Hi,

With 4.11.6 (that has been uploaded in debian unstable) I get a lot of
messages in dmesg like

[100052.120468] audit: audit_lost=66041 audit_rate_limit=0
audit_backlog_limit=8192
[100052.120470] audit: kauditd hold queue overflow

And it also seems that the messages are not stored in auditd logs anymore.

https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26  seems
to be included in this release

An idea?

I'm going to assume that your backlog limit is set to a sane value for
your system's configuration, so that leaves me with two commits that
may be of interest:

* 1df30f8264b8 ("audit: fix the RCU locking for the auditd_connection
structure")

This was a manual backport of a v4.12 patch to v4.11, looking now, I
see it should be in +v4.11.5 so that probably isn't your problem ...

* c81be52a3ac0 ("audit: fix a race condition with the auditd tracking code")

This patch is relatively new and was just sent up to Linus during the
next merge window; it's a race condition fix so reproducing it can be
tricky, although it may be easily reproducible on your system at the
moment (luck you!).  If you aren't in a position to apply the patch,
the workaround is rather simple: restart auditd.

If none of the above works, let me know, but I strongly suspect you're
tripping over the race condition fixed in that last patch.


I still should test the last patch he mentioned

Bug#867486: Issue with the audit subsystem

[Laurent Bigonville]

Package: src:linux
Version: 4.11.6-1
Severity: important

Hi,

Starting with 4.11 I get issues with the audit subsystem.

Most of the audit trails are not logged in auditd but in dmesg and I
also see a lot of warnings/erros in there:

[34078.975005] audit: audit_lost=117558 audit_rate_limit=0 
audit_backlog_limit=8192
[34078.975005] audit: kauditd hold queue overflow

This is annoying

Regards,

Laurent Bigonville

-- Package-specific info:
** Version:
Linux version 4.11.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.11.6-1 (2017-06-19)

** Command line:
BOOT_IMAGE=/vmlinuz-4.11.0-1-amd64 root=/dev/mapper/valinor--vg-root ro quiet 
splash audit=1 selinux=1 security=selinux

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20CK0002MB
product_version: ThinkPad T550
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N11ET41W (1.17 )
board_vendor: LENOVO
board_name: 20CK0002MB
board_version: SDK0E50510 WIN

** Loaded modules:
ctr
ccm
usb_serial_simple
usbserial
dm_snapshot
dm_bufio
vhost_net
vhost
tap
fuse
rfcomm
xt_CHECKSUM
ipt_MASQUERADE
nf_nat_masquerade_ipv4
xfrm_user
xfrm_algo
xt_addrtype
tun
br_netfilter
overlay
nf_conntrack_netbios_ns
nf_conntrack_broadcast
xt_tcpudp
xt_CT
ip6t_rpfilter
ip6t_REJECT
nf_reject_ipv6
ipt_REJECT
nf_reject_ipv4
xt_conntrack
ip_set
nfnetlink
ebtable_nat
ebtable_broute
bridge
stp
llc
ip6table_raw
ip6table_nat
nf_conntrack_ipv6
nf_defrag_ipv6
nf_nat_ipv6
ip6table_mangle
ip6table_security
iptable_raw
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
iptable_mangle
iptable_security
ebtable_filter
ebtables
ip6table_filter
ip6_tables
iptable_filter
cmac
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
iTCO_wdt
iTCO_vendor_support
arc4
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
efi_pstore
kvm_intel
kvm
irqbypass
intel_cstate
iwlmvm
intel_uncore
intel_rapl_perf
mac80211
joydev
uvcvideo
videobuf2_vmalloc
cdc_mbim
serio_raw
pcspkr
efivars
cdc_wdm
videobuf2_memops
videobuf2_v4l2
cdc_ncm
cdc_acm
videobuf2_core
intel_pch_thermal
usbnet
videodev
mii
media
iwlwifi
sg
btusb
btrtl
rtsx_pci_ms
btbcm
snd_hda_codec_realtek
btintel
snd_hda_codec_hdmi
snd_hda_codec_generic
memstick
lpc_ich
bluetooth
cfg80211
snd_hda_intel
thinkpad_acpi
snd_hda_codec
snd_hda_core
snd_hwdep
nvram
rfkill
battery
snd_pcm
snd_timer
snd
ac
mei_me
soundcore
mei
shpchp
evdev
coretemp
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
fscrypto
ecb
mbcache
btrfs
algif_skcipher
af_alg
dm_crypt
dm_mod
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
sd_mod
hid_generic
usbhid
hid
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
rtsx_pci_sdmmc
mmc_core
aesni_intel
aes_x86_64
crypto_simd
glue_helper
cryptd
ahci
libahci
psmouse
libata
scsi_mod
i2c_i801
rtsx_pci
mfd_core
i915
i2c_algo_bit
xhci_pci
drm_kms_helper
ehci_pci
xhci_hcd
ehci_hcd
e1000e
ptp
usbcore
pps_core
drm
usb_common
thermal
wmi
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI 
[8086:1604] (rev 09)
Subsystem: Lenovo Broadwell-U Host Bridge -OPI [17aa:2223]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: bdw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 
[8086:1616] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo HD Graphics 5500 [17aa:2223]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller 
[8086:160c] (rev 09)
Subsystem: Lenovo Broadwell-U Audio Controller [17aa:2223]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI 
Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI])
Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller [17aa:2223]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication cont

Re: CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE

[Laurent Bigonville]

Le 11/04/17 à 16:53, Christian Göttsche a écrit :

I am using the boot flag *checkreqprot=0* without any complications or
policy changes.

@Laurent
if you are willing, one could alter the selinux-activate script to set
the boot flag


I think it's too late now to do that (and I don't know all the 
implications).


I prefer that this is changed in the kernel itself TBH



@Ben

Maybe we'll go with the new default for buster.

if there are no objections from the Debian SELinux team or users, please do so

Re: CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE

[Laurent Bigonville]

Le 02/04/17 à 03:25, cgzones a écrit :
Is there any reason why the standard Debian kernel sets the value for 
checkreqprot to 1, while the default[1] is 0?
RedHat[2] seems also to use 0 and from the documentation 0 seems to be 
the stricter setting.




To be honest I've no idea and the RH bug seems to miss some messages and 
refers to other private bug(s) but I can confirm that on centos 7.3 the 
value is set to 0.


The kernel configuration is done by the kernel team, I'm forwarding your 
question to them on their ML. Maybe they didn't saw the default value 
has changed?


Dear kernel maintainer, do you have an idea about this?

Kind regards,




[1] 
https://github.com/torvalds/linux/commit/2a35d196c160e352fa56eabb7952f78f4c85f577

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1264977

Bug#848423: mkdir: cannot create directory '/main': Permission denied

[Laurent Bigonville]

Package: initramfs-tools-core
Version: 0.126
Severity: normal
File: /usr/bin/unmkinitramfs

Hi,

When running lsinitramfs, I see the following message on stderr:

mkdir: cannot create directory '/main': Permission denied

Regrads,

Laurent Bigonville

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages initramfs-tools-core depends on:
ii  cpio 2.11+dfsg-6
ii  klibc-utils  2.0.4-9
ii  kmod 23-1
ii  udev 232-8

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.22.0-19

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.1-4.3

-- no debconf information

Bug#847071: firmware-nonfree has no binaries on any arch

[Laurent Bigonville]

Le 05/12/16 à 17:45, Ben Hutchings a écrit :

On Mon, 2016-12-05 at 11:58 +0100, Laurent Bigonville wrote:

Source: firmware-nonfree
Version: 20161130-1
Severity: serious

Hi,

It seems that the last upload of firmware-nonfree package has no binary
packages and that the buildd are not allowed to build them from the
(non-free) sources.

I guess a new upload should be done.

*sigh* I keep forgetting that non-free is special and this won't be
auto-built.


Maybe you could ask that the package are built even if they are non-free:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd

Bug#847071: firmware-nonfree has no binaries on any arch

[Laurent Bigonville]

Source: firmware-nonfree
Version: 20161130-1
Severity: serious

Hi,

It seems that the last upload of firmware-nonfree package has no binary
packages and that the buildd are not allowed to build them from the
(non-free) sources.

I guess a new upload should be done.

Regards,

Laurent Bigonville

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing

[Laurent Bigonville]

On Wed, 23 Dec 2015 10:48:01 +0900 Mike Hommey 
<mh+report...@glandium.org> wrote:

> Package: firmware-iwlwifi
> Version: 20151207-1
> Severity: normal
>
> # dmesg | grep iwlwifi | head -5
> [ 7.473576] iwlwifi :06:00.0: enabling device ( -> 0002)
> [ 7.475332] iwlwifi :06:00.0: firmware: failed to load 
iwlwifi-7260-17.ucode (-2)
> [ 7.475337] iwlwifi :06:00.0: Direct firmware load for 
iwlwifi-7260-17.ucode failed with error -2
> [ 7.479873] iwlwifi :06:00.0: firmware: direct-loading firmware 
iwlwifi-7260-16.ucode
> [ 7.480478] iwlwifi :06:00.0: loaded firmware version 16.242414.0 
op_mode iwlmvm

>

According to this website[0], the latest maintained versions are 
-19.ucode and -21.ucode.


The -16 which is currently in the package is marked as "end-of-life". 
Might be the time to upgrade the firmware-iwlwifi package?


Cheers,

Laurent Bigonville

[0]https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release

Bug#805155: Add try_failure_hooks function

[Laurent Bigonville]

unmerge 805155
thanks

Hi,

Well this is not the same bug IMVHO, the try_failure_hooks is an other 
mechanism where the system can try to automatically recover from a 
failure. OTOH the panic hook is when something is really broken and 
cannot be recovered.

Bug#783410: [PATCH] Support fsck.mode= and fsck.repair= parameters as known by systemd-fsck

[Laurent Bigonville]

From: Laurent Bigonville <bi...@bigon.be>

This is also fixing the fact that fsckfix parameter was not honored

Note that -n is apparently not supported by fsck.minix

Closes: #783410 #792557
Signed-off-by: Laurent Bigonville <bi...@bigon.be>
---
 init  | 11 +++
 scripts/functions |  5 -
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/init b/init
index abf7f25..6f41a7b 100755
--- a/init
+++ b/init
@@ -61,7 +61,7 @@ export resume_offset=
 export drop_caps=
 export fastboot=n
 export forcefsck=n
-export fsckfix=n
+export fsckfix=
 
 
 # Bring in the main config
@@ -169,15 +169,18 @@ for x in $(cat /proc/cmdline); do
BOOTIF=*)
BOOTIF=${x#BOOTIF=}
;;
-   fastboot)
+   fastboot|fsck.mode=skip)
fastboot=y
;;
-   forcefsck)
+   forcefsck|fsck.mode=force)
forcefsck=y
;;
-   fsckfix)
+   fsckfix|fsck.repair=yes)
fsckfix=y
;;
+   fsck.repair=no)
+   fsckfix=n
+   ;;
esac
 done
 
diff --git a/scripts/functions b/scripts/functions
index 8c1bb1f..a347264 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -358,9 +358,12 @@ _checkfs_once()
force=""
fi
 
-   if [ "$fsckfix" = yes ]
+   if [ "$fsckfix" = "y" ]
then
fix="-y"
+   elif [ "$fsckfix" = "n" ]
+   then
+   fix="-n"
else
fix="-a"
fi
-- 
2.6.2

Bug#602331: [PATCH] Run new panic scripts just before dropping to a shell

[Laurent Bigonville]

From: Laurent Bigonville <bi...@bigon.be>

These panic scripts are run just before dropping to a shell, these can
be use for example to disable a splash screen.

Taken from Ubuntu

Closes: #602331
Signed-off-by: Laurent Bigonville <bi...@bigon.be>
---
 debian/initramfs-tools-core.dirs | 1 +
 scripts/functions| 3 +++
 2 files changed, 4 insertions(+)

diff --git a/debian/initramfs-tools-core.dirs b/debian/initramfs-tools-core.dirs
index 0f63f2f..bcb978b 100644
--- a/debian/initramfs-tools-core.dirs
+++ b/debian/initramfs-tools-core.dirs
@@ -7,6 +7,7 @@ etc/initramfs-tools/scripts/local-top
 etc/initramfs-tools/scripts/nfs-bottom
 etc/initramfs-tools/scripts/nfs-premount
 etc/initramfs-tools/scripts/nfs-top
+etc/initramfs-tools/scripts/panic
 etc/initramfs-tools/hooks
 etc/initramfs-tools/conf.d
 usr/share/initramfs-tools/conf.d
diff --git a/scripts/functions b/scripts/functions
index 8c1bb1f..b15b63d 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -53,6 +53,9 @@ panic()
modprobe -v uhci-hcd || true
modprobe -v ohci-hcd || true
modprobe -v usbhid || true
+
+   run_scripts /scripts/panic
+
REASON="$@" PS1='(initramfs) ' /bin/sh -i /dev/console 
2>&1
 }
 
-- 
2.6.2

Bug#805710: nfs-common: NFS mounts don't work because nfs-common starts before rpcbind.service

[Laurent Bigonville]

On Sat, 21 Nov 2015 08:38:09 +0100 =?utf-8?q?Michal_Ka=C5=A1par?= 
 wrote:

> Dear Maintainer,

Hi,

> NFS mounts don't work on systemd enabled systems because nfs-common is
> started before rpcbind. If nfs-common is restarted after boot, the
> mounts start to work fine. In log files I see:
> nfs-common[1301]: Not starting: portmapper is not running ... (warning).

Since rpcbind version 0.2.3-0.2, it is using systemd socket activation. 
I'm a bit surprised that the daemon is not activated during boot.

Bug#783410: Please add support for fsck.mode= parameters as known by systemd-fsck

[Laurent Bigonville]

tag 783410 + patch
thanks

On Sun, 26 Apr 2015 21:36:39 +0200 Michael Biebl <bi...@debian.org> wrote:

Hi,

> systemd-fsck [1] knows the following kernel command line parameters
>
> fsck.mode=
>
> One of "auto", "force", "skip". Controls the mode of operation. The 
default
> is "auto", and ensures that file system checks are done when the file 
system
> checker deems them necessary. "force" unconditionally results in full 
file

> system checks. "skip" skips any file system checks.
>
> fsck.repair=
>
> One of "preen", "yes", "no". Controls the mode of operation. The 
default is
> " preen", and will automatically repair problems that can be safely 
fixed. "yes

> " will answer yes to all questions by fsck and "no" will answer no to all
> questions.
>
>
> Please consider adding support for those kernel command line parameters
> in initramfs-tools. Otherwise it's pretty confusing for users if the
> documentation as shipped by systemd doesn't really have the effect they
> expect.

Please find a patch that should fix this bug (not tested). The patch 
also fixes #792557.


Cheers,

Laurent Bigonville
>From a936e4dc397020d2c1db0cd0d70f08a9cf22b7da Mon Sep 17 00:00:00 2001
From: Laurent Bigonville <bi...@bigon.be>
Date: Sun, 15 Nov 2015 09:59:59 +0100
Subject: [PATCH] Support fsck.mode= and fsck.repair= parameters as known by
 systemd-fsck

This is also fixing the fact that fsckfix parameter was not honored

Note that -n is apparently not supported by fsck.minix

Closes: #783410 #792557
---
 init  | 11 +++
 scripts/functions |  5 -
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/init b/init
index abf7f25..6f41a7b 100755
--- a/init
+++ b/init
@@ -61,7 +61,7 @@ export resume_offset=
 export drop_caps=
 export fastboot=n
 export forcefsck=n
-export fsckfix=n
+export fsckfix=
 
 
 # Bring in the main config
@@ -169,15 +169,18 @@ for x in $(cat /proc/cmdline); do
 	BOOTIF=*)
 		BOOTIF=${x#BOOTIF=}
 		;;
-	fastboot)
+	fastboot|fsck.mode=skip)
 		fastboot=y
 		;;
-	forcefsck)
+	forcefsck|fsck.mode=force)
 		forcefsck=y
 		;;
-	fsckfix)
+	fsckfix|fsck.repair=yes)
 		fsckfix=y
 		;;
+	fsck.repair=no)
+		fsckfix=n
+		;;
 	esac
 done
 
diff --git a/scripts/functions b/scripts/functions
index 8c1bb1f..a347264 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -358,9 +358,12 @@ _checkfs_once()
 		force=""
 	fi
 
-	if [ "$fsckfix" = yes ]
+	if [ "$fsckfix" = "y" ]
 	then
 		fix="-y"
+	elif [ "$fsckfix" = "n" ]
+	then
+		fix="-n"
 	else
 		fix="-a"
 	fi
-- 
2.6.2

Bug#602331: plymouth does not allow to enter maintenance shell

[Laurent Bigonville]

tag 602331 + patch
thanks

On Sat, 30 Aug 2014 23:27:47 +0200 Michael Prokop <m...@debian.org> wrote:
> Hi,

Hi,

> * Laurent Bigonville [Fri Aug 01, 2014 at 03:55:17PM +0200]:
>
> > An idea on how this could be fixed? In Ubuntu they have added a "panic"
> > hook to initramfs-tools that is being called in the "panic()" function.
> > Do you think it's the way to go here?
>
> > Otherwise I can also provide a patch for the same function to directly
> > call the needed plymouth command ("plymouth quit")
>
> I just took a look at Ubuntu's i-t and their try_failure_hooks
> function with features related to plymouth etc totally makes sense
> for me, I'd love to see that in Debian's i-t as well, so if anyone
> is willing to work on it you'd have my full support for that.

I think we could split that in two different issues, I've cloned this 
bug, see: #805155


The attached patch is calling the new "panic" scripts just before 
dropping to a shell, this can be then used by plymouth package to ensure 
the plymouth daemon is killed/the splash hidden


Cheers,

Laurent Bigonville


>From e666c9f267d73f5b3d434369d9efc5b7f9210e66 Mon Sep 17 00:00:00 2001
From: Laurent Bigonville <bi...@bigon.be>
Date: Sun, 15 Nov 2015 12:58:27 +0100
Subject: [PATCH] Run new panic scripts just before dropping to a shell

These panic scripts are run just before dropping to a shell, these can
be use for example to disable a splash screen.

Taken from Ubuntu

Closes: #602331
---
 debian/initramfs-tools.dirs | 1 +
 scripts/functions   | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/debian/initramfs-tools.dirs b/debian/initramfs-tools.dirs
index 0f63f2f..bcb978b 100644
--- a/debian/initramfs-tools.dirs
+++ b/debian/initramfs-tools.dirs
@@ -7,6 +7,7 @@ etc/initramfs-tools/scripts/local-top
 etc/initramfs-tools/scripts/nfs-bottom
 etc/initramfs-tools/scripts/nfs-premount
 etc/initramfs-tools/scripts/nfs-top
+etc/initramfs-tools/scripts/panic
 etc/initramfs-tools/hooks
 etc/initramfs-tools/conf.d
 usr/share/initramfs-tools/conf.d
diff --git a/scripts/functions b/scripts/functions
index a347264..33fddcf 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -53,6 +53,9 @@ panic()
 	modprobe -v uhci-hcd || true
 	modprobe -v ohci-hcd || true
 	modprobe -v usbhid || true
+
+	run_scripts /scripts/panic
+
 	REASON="$@" PS1='(initramfs) ' /bin/sh -i /dev/console 2>&1
 }
 
-- 
2.6.2

Bug#792557: initramfs-tools functions doesn't honour "fsckfix" kernel command line option

[Laurent Bigonville]

Hello,

On Thu, 16 Jul 2015 11:42:52 +0200 Alessandro Pazzaglia 
<jackdro...@gmail.com> wrote:

> Passing "fsckfix" kernel command line option currently does not force
> (as it should) fsck run at initramfs time to fix errors (using -y
> option).
>
> This is caused by a (wrong) equality check against the string "yes" on
> the fsckfix script variable, instead of "y" (which is what the init
> script set it to if it sees the kernel command line option).
>
> This seems to have been introduced along with the fsck in intramfs
> feature (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708000#10)
> in version 0.117.
>
> Attached a patch which fixes the problem.

I was just looking at the code and saw this in the code, could somebody 
merge this patch?


Cheers,

Laurent Bigonville

Bug#779515: Should enable the qxl kernel driver when installed

[Laurent Bigonville]

Le 07/11/15 02:23, Ben Hutchings a écrit :

On Sat, 2015-11-07 at 00:24 +0100, Laurent Bigonville wrote:

reassign 779515 linux-image-4.2.0-1-amd64
severity 779515 important
thanks

On Sun, 01 Mar 2015 18:47:54 + Ben Hutchings <b...@decadent.org.uk>
wrote:

  > I've enabled the kernel's qxl driver, but disabled by default so that
  > it doesn't conflict with wheezy's version of xserver-xorg-video-qxl.
  >
  > Please install a modprobe configuration file with the line:
  >
  > options qxl modeset=1
  >
  > (When I tried this on a VM host with virt-manager and QEMU from sid,
  > the qxl driver complained of missing features, so KMS still didn't
  > work. However, the fall-back to UMS still worked.)

Shouldn't the qxl kernel module be enabled by default in unstable now
that the xserver-xorg-video-qxl package has been updated?

[...]

Only if xserver-xorg-video-qxl in jessie works properly with KMS.  Is
that the case?
OK, so I tried on a jessie VM with jessie kernel and it gave me a 
backscreen.


I updated to the kernel from bpo (4.2) and now gdm is starting properly.

How can I verify if the issue you got is now fixed? I see this in the 
Xserver logs:


[KMS] Kernel modesetting enabled.

BTW, without qxl kernel driver, I see some ugly yellowish vt.

Cheers,

Laurent Bigonville

Bug#622394: nfs-common: breaks systemd - dependency cycle in require-start leads to removal of critical jobs

[Laurent Bigonville]

severity 622394 serious
thanks

Hello,

Now that systemd is the default init system I guess the severity of this
bugs should be RC as it seems to still be an issue for some people.

Cheers,

Laurent Bigonville


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019134558.615aa...@fornost.bigon.be

Bug#602331: plymouth does not allow to enter maintenance shell

[Laurent Bigonville]

Hello,

An idea on how this could be fixed? In Ubuntu they have added a panic
hook to initramfs-tools that is being called in the panic() function.
Do you think it's the way to go here?

Otherwise I can also provide a patch for the same function to directly
call the needed plymouth command (plymouth quit)

Cheers,

Laurent Bigonville


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140801155517.2bf2b...@soldur.bigon.be

Bug#751955: initramfs-tools: Warning: error while trying to store keymap file - ignoring request to install /etc/boottime.kmap.gz

[Laurent Bigonville]

Package: initramfs-tools
Version: 0.115
Severity: normal
File: /usr/share/initramfs-tools/hooks/keymap

Hello,

Since one or two days, the keymap on my laptop is wrong at really early
boot when I need to input the password for my cryptsetup partion.

Today when running update-initramfs -u I saw the following message:

Warning: error while trying to store keymap file - ignoring request to install 
/etc/boottime.kmap.gz

Running setupcon --save-keyboard by hand here is indeed returning 1

According to the manpage, the --save-keyboard doesn't seems to exist at all

Cheers,

Laurent Bigonville

-- Package-specific info:
-- initramfs sizes
-rw-r--r--. 1 root root 18M Jun 18 10:32 /boot/initrd.img-3.14-1-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.14-1-amd64 root=/dev/mapper/soldur-root ro 
acpi_osi=!Windows 2009 quiet selinux=1 security=selinux audit=1

-- resume
RESUME=/dev/mapper/soldur-swap_1
-- /proc/filesystems
btrfs
ext3
ext2
ext4
fuseblk
vfat

-- lsmod
Module  Size  Used by
cpuid  12663  0 
joydev 17063  0 
xt_CHECKSUM12471  1 
ipt_MASQUERADE 12594  3 
xt_tcpudp  12527  6 
ipt_REJECT 12465  4 
xt_conntrack   12681  3 
ebtable_nat12580  0 
ebtable_broute 12541  0 
bridge 97129  1 ebtable_broute
stp12437  1 bridge
llc12745  2 stp,bridge
ebtable_filter 12591  0 
ebtables   30026  3 ebtable_broute,ebtable_nat,ebtable_filter
ip6table_nat   12649  0 
nf_conntrack_ipv6  13605  1 
nf_defrag_ipv6 29262  1 nf_conntrack_ipv6
nf_nat_ipv612920  1 ip6table_nat
ip6table_mangle12540  0 
ip6table_security  12548  0 
ip6table_raw   12528  0 
ip6table_filter12540  0 
ip6_tables 26024  5 
ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw
iptable_nat12646  1 
nf_conntrack_ipv4  18455  4 
nf_defrag_ipv4 12483  1 nf_conntrack_ipv4
nf_nat_ipv412912  1 iptable_nat
nf_nat 18156  5 
ipt_MASQUERADE,nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat
nf_conntrack   70938  9 
ipt_MASQUERADE,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6
iptable_mangle 12536  1 
iptable_security   12544  1 
iptable_raw12524  1 
iptable_filter 12536  1 
ip_tables  21915  5 
iptable_security,iptable_filter,iptable_mangle,iptable_nat,iptable_raw
x_tables   23015  16 
iptable_security,ip6table_filter,ip6table_mangle,xt_CHECKSUM,ip_tables,xt_tcpudp,ipt_MASQUERADE,ip6table_security,xt_conntrack,iptable_filter,ip6table_raw,ebtables,ipt_REJECT,iptable_mangle,ip6_tables,iptable_raw
bnep   17388  2 
snd_hda_codec_hdmi 40955  4 
pci_stub   12429  1 
vboxpci18981  0 
vboxnetadp 25443  0 
binfmt_misc16949  1 
vboxnetflt 23324  0 
vboxdrv   261792  3 vboxnetadp,vboxnetflt,vboxpci
uinput 17372  1 
nfsd  254693  2 
auth_rpcgss51240  1 nfsd
oid_registry   12419  1 auth_rpcgss
nfs_acl12511  1 nfsd
nfs   183672  0 
lockd  79321  2 nfs,nfsd
fscache45542  1 nfs
sunrpc228923  6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
nls_utf8   12456  1 
x86_pkg_temp_thermal12951  0 
nls_cp437  16553  1 
intel_powerclamp   17159  0 
vfat   17135  1 
fat53794  1 vfat
tpm_rng12422  0 
rng_core   12688  2 tpm_rng
iTCO_wdt   12831  0 
iTCO_vendor_support12649  1 iTCO_wdt
loop   26605  0 
fuse   78839  3 
arc4   12536  2 
efi_pstore 12805  1 
uvcvideo   78960  0 
videobuf2_vmalloc  12816  1 uvcvideo
videobuf2_memops   12519  1 videobuf2_vmalloc
videobuf2_core 35303  1 uvcvideo
btusb  25576  0 
videodev  117963  2 uvcvideo,videobuf2_core
bluetooth 243391  21 bnep,btusb
media  18303  2 uvcvideo,videodev
6lowpan_iphc   16588  1 bluetooth
iwldvm126927  0 
dell_wmi   12477  0 
dell_laptop17077  0 
snd_hda_codec_idt  48668  1 
sparse_keymap  12818  1 dell_wmi
mac80211  464019  1 iwldvm
dcdbas 13313  1 dell_laptop
snd_hda_codec_generic59065  1 snd_hda_codec_idt
intel_rapl 17356  0 
coretemp   12854  0 
kvm_intel 134712  0 
kvm   388171  1 kvm_intel
psmouse90422  0 
efivars17257  1 efi_pstore
serio_raw  12849  0 
iwlwifi87837

Bug#648207: Please add support for newest Dell touchpad

[Laurent Bigonville]

Package: linux-2.6
Version: 3.0.0-6
Severity: wishlist
Tag: patch

Hi,

I own a Dell Latitude E6510 and unfortunately, the touchpad is not
recognized properly, causing the vertical scrolling to not work.

A series of patches that fix this issue has hit the linux-next branch,
could you please apply them to the debian kernel.

d4b347b29b4d14647c7394f7167bf6785dc98e50
fa629ef5222193214da9a2b3c94369f79353bec9
b46615fe9215214ac00e26d35fc54dbe1c510803
25bded7cd60fa460e520e9f819bd06f4c5cb53f0
01ce661fc83005947dc958a5739c153843af8a73
7cf801cfc0774b777aa6861cf4a43a90b112b1ed

LKML discussion: https://lkml.org/lkml/2011/11/7/433


dmesg output:

[24882.653635] input: PS/2 Generic Mouse as 
/devices/platform/i8042/serio1/input/input24

dmesg output with the patches:

[25082.856695] alps.c: E6 report: 00 00 64
[25082.875809] alps.c: E7 report: 73 02 64
[25083.323105] alps.c: E6 report: 00 00 64
[25083.341946] alps.c: E7 report: 73 02 64
[25083.455720] alps.c: trackstick E7 report: 42 02 14
[25083.843342] input: DualPoint Stick as 
/devices/platform/i8042/serio1/input/input25
[25083.858236] input: AlpsPS/2 ALPS DualPoint TouchPad as 
/devices/platform/i8042/serio1/input/input26


/proc/bus/input/devices:

I: Bus=0011 Vendor=0002 Product=0001 Version=
N: Name=PS/2 Generic Mouse
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input24
U: Uniq=
H: Handlers=mouse1 event9 
B: PROP=0
B: EV=7
B: KEY=7 0 0 0 0
B: REL=3

/proc/bus/input/devices (With patches)

I: Bus=0011 Vendor=0002 Product=0008 Version=7326
N: Name=AlpsPS/2 ALPS DualPoint TouchPad
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input26
U: Uniq=
H: Handlers=mouse2 event22 
B: PROP=8
B: EV=b
B: KEY=e420 7 0 0 0 0
B: ABS=2608103



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2009170823.3a8e6...@eldamar.bigon.be

Bug#248234: sarge installer

[Laurent Bigonville]

Hi,

Sorry for this late answer... I try today with the sarge r0a netinstall 
and the kernel still hang during boot... I'm not sure it was at the 
same moment than before.


If nobody has the same problem, it's because I have a bad karma..


PGP.sig
Description: Ceci est une signature électronique PGP