Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

[Mikhail Morfikov]

On 17/03/2024 5.18 pm, Andrea Bolognani wrote:

On Wed, Mar 06, 2024 at 08:34:59AM +0100, Mikhail Morfikov wrote:

Take a look for example at the thunderbird email client package. They ship
the apparmor profile for the app in the thunderbird package (I also asked them
to do the move, but no one cared, see #949649 from 23 Jan 2020 -- no one ever
answered).


That bug report looks identical to the one you've filed against
libvirt, so it doesn't provide any additional information.


So I use thunderbird and I have my own separate profile for this app because
I have different rules, aiming different security policy. Each time the
thunderbird package is updated, the apparmor profile is also installed, and
I have no option to forbid that. So the apparmor policy is rewritten, which
requires me to manually remove the newly installed thunderbird profile (the
physical file), remove non exising profiles from apparmor (aa-remove-unknown),
reload my own profile, update initramfs (since I load the apparmor policy during
initramfs phase).


That does indeed sound very annoying.

I wonder why you have to go through that whole process though. The
AppArmor configuration is in /etc, so everything is marked as
conffiles. If you make local customizations, shouldn't you at worst
be prompted to confirm whether you want your changes to be preserved
or overwritten?


It's because of the naming scheme. Some time ago, apparmor changed the naming
scheme from the path (like usr.bin.thunderbird) to just the name of the 
app/binary
(thunderbird). And most of the app still have the old naming.

So as you can see, even when apps have apparmor profiles, no one even cares 
about
having them updated -- this is the main reason I wanted them in separate 
packages.

I have many profiles and all of them have the new naming scheme, and in such
case, apps like thunderbird simply install new files with each update, which I 
have
to remove and do all the stuff I described earlier.




Most of people don't even use apparmor, so they don't care whether the profile 
is
in the core package, or in some app-apparmor-profile package.


I don't think this is a fair assessment: AppArmor is enabled by
default in Debian and has been for several releases, so people *are*
in fact using AppArmor unless they go out of their way to disable it.


Even when it's enabled by default, it doesn't really matter when people don't 
know
what apparmor is and when all profiles are in the complain mode. Try to enforce 
all
of the installed profiles by default and see what happens. :]




The all issues/problems call for a separate apparmor profile packages, but 
someone
has to make that move first, so others would follow. 4 years has passed and no 
one
did this, because no one care, and no one really use apparmor. And I bet no one 
will
make that first step and in the next 4 years the problems will still persist.


Have you raised the topic on a project-wide forum, such as
debian-devel? That would IMO be the best way forward. Convince the
project that AppArmor profiles should be packaged separately, and
make that into a (mini-)policy that is officially adopted.

Opening bug reports against individual packages when no project-wide
consensus has been reached is unlikely to result in much progress.



No I haven't. At that time (several years ago) there were just a couple of apps 
which
were shipping apparmor profiles in the core app package. Since no one really 
answered me
at that time, I just let it go because I had the feeling that no one really 
cares of
such thing like apparmor, so I stopped asking people and simply got over it.

Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

[Mikhail Morfikov]

On 05/03/2024 10.53 pm, Andrea Bolognani wrote:

On Sun, Jul 19, 2020 at 08:08:15PM +0200, Mikhail Morfikov wrote:

Dear Maintainer,

Currently when the package is installed, it also installs files under
/etc/apparmor.d/ . There are two issues with this:

1) some people want to use their own profile (the local profile under
/etc/apparmor.d/local/ may not be an option for many reasons),
2) some of the names of the files are path based, and some users could use just
the exec/binary name (or whatever) for the profile/file name, which leads to
having two different sets of rules (two different apparmor profiles loaded at
the same time confining the same app).

The only way to fix this is to manually remove the provided apparmor profile
files after each package update, which is a little bit annoying.

Please reconsider creating a separate package for the apparmor profile files
(something similar to package_name-apparmor-profile), and just
suggest/recommend it in deps of the main package, so the user could decide
whether he wants the profiles to be installed in his system or not.


Hi Mikhail,

I am currently working on a big refactoring of the libvirt package,
which I thought could be the perfect opportunity to implement the
split that you're suggesting here.

However, looking at the contents of the archive, it seems that the
practice of shipping AppArmor profiles as separate package from the
software that they're intended for is far from widespread:

   $ apt-cache search -n apparmor
   apparmor - user-space parser utility for AppArmor
   apparmor-notify - AppArmor notification system
   apparmor-profiles - experimental profiles for AppArmor security policies
   apparmor-utils - utilities for controlling AppArmor
   dh-apparmor - AppArmor debhelper routines
   libapache2-mod-apparmor - changehat AppArmor library as an Apache module
   libapparmor-dev - AppArmor development libraries and header files
   libapparmor1 - changehat AppArmor library
   libpam-apparmor - changehat AppArmor library as a PAM module
   python3-apparmor - AppArmor Python3 utility library
   python3-libapparmor - AppArmor library Python3 bindings
   apparmor-profiles-extra - Extra profiles for AppArmor Security policies
   fwknop-apparmor-profile - FireWall KNock OPerator - Apparmor profile
   uwsgi-plugin-apparmor - apparmor plugin for uwsgi

If we exclude apparmor-profiles(-extra), which by definition don't
count as they are maintained separately from the corresponding
applications, the only example I can see is fwknop.

This gives me pause, and makes me not particularly keen on going down
such a lonesome path.

I'd like to understand your use case better though. Can you please
provide concrete examples of the problematic scenarios you've
mentioned in your original message, along with the steps that you
currently have to perform to work around them?

Thanks in advance!




Yes, I know that only few projects provide a separate package with apparmor
profiles.

I tried to change that by requesting people to do the change. But I failed,
so I stopped asking people to do this a long time ago.

Why I wanted the change?

Take a look for example at the thunderbird email client package. They ship
the apparmor profile for the app in the thunderbird package (I also asked them
to do the move, but no one cared, see #949649 from 23 Jan 2020 -- no one ever
answered).

So I use thunderbird and I have my own separate profile for this app because
I have different rules, aiming different security policy. Each time the
thunderbird package is updated, the apparmor profile is also installed, and
I have no option to forbid that. So the apparmor policy is rewritten, which
requires me to manually remove the newly installed thunderbird profile (the
physical file), remove non exising profiles from apparmor (aa-remove-unknown),
reload my own profile, update initramfs (since I load the apparmor policy during
initramfs phase).

Why to do this all the time when a package is updated? The solution is
simple -- not to force users to use the provided apparmor profile for the app
and allow them to decide.

That's why I tried to convince people to make a separate packages for apparmor
profiles, so users could decide whether they want the apparmor profile installed
in their systems or not.

Most of people don't even use apparmor, so they don't care whether the profile 
is
in the core package, or in some app-apparmor-profile package. But there are 
people
who use apparmor (and I use it extensively), for instance:

# aa-status | grep -v ^" "
apparmor module is loaded.
1042 profiles are loaded.
918 profiles are in enforce mode.
124 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
406 processes have profiles defined.
94 processes are in enforce mode.
312 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.

That's a lot o

Bug#993526: thunderbird: Movemail support removed in Thunderbird v91

[Mikhail Morfikov]

On 02/09/2021 19.41, Carsten Schoenert wrote:
> You need to keep the BTS within the mail loop so others can follow
> the conversion too!

I know, I just miss-clicked the wrong button -- I think they should 
work on this instead of removing the useful features. :]

> 
> Am 02.09.21 um 19:34 schrieb Mikhail Morfikov:
>> At least to notify people about this change with upgrade to v91
>> because I was really surprised when one of my accounts disappeared
>> without any info.
> 
> Did you have read the official release notes?
> 
> https://www.thunderbird.net/en-US/thunderbird/91.0/releasenotes/
> 
> It's listed under changes. I see no gain to duplicate this
> information somewhere in Debian.

Most people don't read the official release notes if they don't have 
to. So if there's no one who would speak about some important change 
at the Debian lvl, no one will even bother with the official release 
notes, and it's not just for TB, but it's a general rule. That's why 
the Debian news/changelogs files are so important.

> 
>> Maybe if more people will complain about the feature removal, the 
>> upstream will bring it back.
> 
> Maybe, but I expect no return of this feature.
> 

It's sad that people think in this way. But if TB wants to have 
less and less user base, I think it's on the right way. And we all 
know where it ends.

Bug#993526: thunderbird: Movemail support removed in Thunderbird v91

[Mikhail Morfikov]

Package: thunderbird
Version: 1:91.0~b5-1
Severity: important

Dear Maintainer,

It looks like that with the version of 91, Thunderbird removed support for
Movemail accounts. There's no way to setup such account anymore with this
version, and all already present account are removed without any info or
warning. At least the mail stayed intact. I had to install the previous version
(1:78.13.0-1) to revert the unpleasant change.

More info at:

https://developer.thunderbird.net/planning/roadmap
https://bugzilla.mozilla.org/show_bug.cgi?id=1625741

Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile

[Mikhail Morfikov]

On 24/10/2020 14.42, intrigeri wrote:
> Control: tag -1 + moreinfo
> 
> Hi,
> 
> Mikhail Morfikov (2020-07-20):
>> currently when the apparmor-profiles package is installed, it installs 
>> several
>> apparmor profile files. In this way users can have all or none of the 
>> profiles
>> installed in their systems. Sometimes a user wants only a specific profile 
>> (or
>> profiles) installed and doesn't really want the other profiles to be 
>> installed
>> as well because:
>>  - he doesn't need the other profiles,
>>  - he has his own alternative profiles, which differ in rule sets,
>>  - the other profiles simply cause some issues with applications they 
>> confine.
> 
>> What do you think about another approach, which is to create separate 
>> packages
>> containing individual apparmor profiles? For instance, there's the
>> usr.sbin.dnsmasq file which is related to the dnsmasq package. In this case
>> there could be a package named dnsmasq-apparmor-profile which would include 
>> the
>> usr.sbin.dnsmasq file. If a user wanted to install dnsmasq and also wanted it
>> to be confined by the default apparmor profile provided by Debian, he could
>> also install dnsmasq-apparmor-profile, which wouldn't affect any other app
>> functionality.
> 
> The profiles shipped by the apparmor-profiles package are installed in
> complain mode. Then the user may choose to enforce the profiles they
> need. To me, it seems to already provide the kind of flexibility
> you're wishing for, with a much lower overhead on the package
> maintenance side. What did I miss?
> 
> Apart of this, the way the Debian archive works, having many tiny
> packages is problematic, so I don't think your proposal would be
> acceptable by the project. I'm not closing this bug report just yet as
> I'd like to first better understand what the current setup is lacking
> for you.
> 
> Cheers!
> 

There are three ways of installing apparmor profiles in debian:
- an app's package contains some apparmor profile
- some packages contain lots of apparmor profiles
- there are a few packages which contain an app's apparmor profile itself, for 
  instance fwknop-apparmor-profile

So it's a mess.

It would be better to have just one way of installing official debian apparmor 
profiles for apps, i.e. the 3rd option above.  Of course a user doesn't 
have to install the big package with all the profiles, but when I see bunch of 
apparmor profiles that I don't really need, I simply skip the package or 
extract the needed profile and forget about the package. So basically having 
multiple profiles in one package makes people less likely to test any of 
the profiles included in it and hence less likely to report any issues. It 
would 
be nice to have profiles in individual packages, so users could decide what 
they want to install. 

What if I had my own profile that would match to a specific one that is 
provided 
by apparmor-profiles? What would I have to do in order to install/upgrade the 
rest of the profiles from the package and leave my profile intact? It's very 
inconvenient and problematic for the end user to handle such packages.

BTW: Why having many small packages is a problem for debian archive? 


OpenPGP_0x32D9CB634796CCA1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#968323: Since conky 1.11.6-1 following error: conky: unknown variable '$tcp_portmon'

[Mikhail Morfikov]

Package: conky
Version: 1.11.6-1
Followup-For: Bug #968323

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've also hit this issue.

It looks like it's because conky in Debian is built with:

COMMON_CONF_ARGS= ...
 -DBUILD_PORT_MONITORS=OFF \
  ...




-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXzlmKQAKCRAy2ctjR5bM
oeyFAQDPCLWPfDRz/ttB3TPLn8LQAPawlg97bcJJkfVz3D+6FgEAr5eRrq5L/m7O
JbqWA0tafwUXj40BybXP6R1jBUdlEgw=
=sFHA
-END PGP SIGNATURE-

Bug#967114: libinput10: Multimedia keys stopped working after libinput10/libinput-bin upgrade to 1.16.0-1

[Mikhail Morfikov]

Package: libinput10
Version: 1.15.5-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I have the following external keyboard connected to my laptop:

# lsusb  | grep -i logi
Bus 002 Device 005: ID 046d:c30f Logitech, Inc. Logicool HID-Compliant Keyboard
(106 key)

After the libinput10/libinput-bin packages upgrade from 1.15.5-1 to 1.16.0-1,
the multimedia keys stopped working. The only way to make them work again is to
downgrade the aforementioned packages to their previous versions.



- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'buildd-unstable'), (500, 'testing'),
(130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libinput10 depends on:
ii  libc6 2.31-2
ii  libevdev2 1.9.1+dfsg-1
ii  libinput-bin  1.15.5-1
ii  libmtdev1 1.1.6-1
ii  libudev1  245.7-1
ii  libwacom2 1.4.1-1

libinput10 recommends no packages.

libinput10 suggests no packages.




-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXyke4QAKCRAy2ctjR5bM
oU8oAQCyH/581i8+b0LpO1f/nCGy/caZGZJF67frscyc/In24AD/Zizcqrii/Jqx
9LVVmBczC0nsHPeP9zCfOSRa7JnLSgU=
=Eb89
-END PGP SIGNATURE-

Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile

[Mikhail Morfikov]

Package: apparmor-profiles
Version: 2.13.4-3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

currently when the apparmor-profiles package is installed, it installs several
apparmor profile files. In this way users can have all or none of the profiles
installed in their systems. Sometimes a user wants only a specific profile (or
profiles) installed and doesn't really want the other profiles to be installed
as well because:
 - he doesn't need the other profiles,
 - he has his own alternative profiles, which differ in rule sets,
 - the other profiles simply cause some issues with applications they confine.

What do you think about another approach, which is to create separate packages
containing individual apparmor profiles? For instance, there's the
usr.sbin.dnsmasq file which is related to the dnsmasq package. In this case
there could be a package named dnsmasq-apparmor-profile which would include the
usr.sbin.dnsmasq file. If a user wanted to install dnsmasq and also wanted it
to be confined by the default apparmor profile provided by Debian, he could
also install dnsmasq-apparmor-profile, which wouldn't affect any other app
functionality.

Also, there are many profiles under /usr/share/apparmor/extra-profiles/ which
aren't enabled, and probably no one uses them at all. If there was a package,
for instance, postfix-apparmor-profile containing all the usr.lib.postfix*
files installed under /etc/apparmor.d/ , I think more people would test the
profiles, which would contribute to better development of the profiles
themselves.

Probably not all of the files included currently in the apparmor-profiles
package can be separated in the way described above, but there are cases where
this can be done, and I think it should be done.

Tell me what do you think about this solution.




-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXxVrFAAKCRAy2ctjR5bM
oUuSAP9vC0YwQpOCkhvml75GWrKVeWRNtxsLcDmG0G4qi/DhpQEA6Sqw0tiaYwve
1rgG46iE976oC6uVliwRSba/rkBEkAs=
=5jJs
-END PGP SIGNATURE-

Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

[Mikhail Morfikov]

Package: libvirt-daemon-system
Version: 6.4.0-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Currently when the package is installed, it also installs files under
/etc/apparmor.d/ . There are two issues with this:

1) some people want to use their own profile (the local profile under
/etc/apparmor.d/local/ may not be an option for many reasons),
2) some of the names of the files are path based, and some users could use just
the exec/binary name (or whatever) for the profile/file name, which leads to
having two different sets of rules (two different apparmor profiles loaded at
the same time confining the same app).

The only way to fix this is to manually remove the provided apparmor profile
files after each package update, which is a little bit annoying.

Please reconsider creating a separate package for the apparmor profile files
(something similar to package_name-apparmor-profile), and just
suggest/recommend it in deps of the main package, so the user could decide
whether he wants the profiles to be installed in his system or not.

Thanks.




-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXxSMBgAKCRAy2ctjR5bM
odAhAP9nxR4hoy6y0r8GuBSuxqIlbXqiCxPbIow07x/fxhX7KQEAp2a4uLOX1pNv
J8SQQxy6L8t4DdoKFrFKuzJ3C525agI=
=Hj2o
-END PGP SIGNATURE-

Bug#963805: efibootmgr: Could not parse device path: Invalid argumen

[Mikhail Morfikov]

Package: efibootmgr
Version: 17-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

it looks like that efibootmgr works well, but when the "-v" flag is used, I get
the following output:

# efibootmgr -v
BootCurrent: 001A
Timeout: 0 seconds
BootOrder:
001A,001B,0019,0018,0001,0002,0003,0007,0008,0009,000A,000D,000B,000C,000E,000F,0010,0011,0012
Boot  SetupCould not parse device path: Invalid argument

The list is returned when the "-v" option is omitted:

# efibootmgr
BootCurrent: 001A
Timeout: 0 seconds
BootOrder:
001A,001B,0019,0018,0001,0002,0003,0007,0008,0009,000A,000D,000B,000C,000E,000F,0010,0011,0012
Boot  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash Screen
Boot0003  Lenovo Diagnostics
Boot0004  Startup Interrupt Menu
Boot0005  ME Configuration Menu
Boot0006  Rescue and Recovery
Boot0007  USB CD
Boot0008  USB FDD
Boot0009  ATAPI CD0
Boot000A* ATA HDD0
Boot000B* ATA HDD1
Boot000C* ATA HDD2
Boot000D* USB HDD
Boot000E  PCI LAN
Boot000F  ATAPI CD1
Boot0010  Other CD
Boot0011* ATA HDD3
Boot0012  Other HDD
Boot0013* IDER BOOT CDROM
Boot0014* IDER BOOT Floppy
Boot0015* ATA HDD
Boot0016* ATAPI CD:
Boot0017* PCI LAN
Boot0018* SHIM MS
Boot0019* SHIM Debian
Boot001A* REFIND
Boot001B* GRUB

The last four entries were added manually. I removed them, but that didn't
help.



- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'buildd-unstable'), (300, 'stable'),
(130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.5-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_RANDSTRUCT
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages efibootmgr depends on:
ii  libc62.30-8
ii  libefiboot1  37-2.1
ii  libefivar1   37-2.1
ii  libpopt0 1.18-1

efibootmgr recommends no packages.

efibootmgr suggests no packages.




-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXveMKQAKCRAy2ctjR5bM
oQtEAP92aa3tUk14z56bpArSiiMktoxjpORxqpr5e8rhN3IyLwD/cCqIn764cAxJ
2JzUZjum2U20HjF0niXGUcSlcdX86wg=
=XTrq
-END PGP SIGNATURE-

Bug#949062: ifupdown: Bonding interface gets the wrong MAC address when configured for the first time

[Mikhail Morfikov]

Package: ifupdown
Version: 0.8.35+b1
Followup-For: Bug #949062

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It looks like systemd is the one to blame. I've managed to solve the issue by
creating the following file:

# cat /etc/systemd/network/99-default.link
[Match]
OriginalName=bond*

[Link]
MACAddressPolicy=none

See this link[1] for more info.

[1]: https://bugzilla.suse.com/show_bug.cgi?id=1136600



- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-amd64+ (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_RANDSTRUCT
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  5.5.0-1
ii  libc6 2.30-4
ii  lsb-base  11.1.0

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2.1+b2

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-2+4.1+b1
pn  rdnssd  

- -- Configuration Files:
/etc/default/networking changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXoTVOwAKCRAy2ctjR5bM
oe2+AP9aVF/Tz4uQ1HuugWjxXhmMWMUnG4UfPJb3C46i45BCWAEAo7Df5SbUfOKz
DyrsIPTZceTmzXnwlzLDse4QUSLTSAw=
=9XVO
-END PGP SIGNATURE-

Bug#954754: remaster-iso: Missing isolinux as dependency

[Mikhail Morfikov]

Package: remaster-iso
Version: 0.9.2-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I recently installed remaster-iso package, but when I issued the
remaster-compose command, I got this:

- -
# remaster-compose
...
Drive current: -outdev
'stdio:/home/morfik/Desktop/debian/202003222304-remaster-iso.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 25.4g free
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
xorriso : NOTE : -as mkisofs: Ignored option '-cache-inodes'
Added to ISO image: directory '/'='/home/morfik/Desktop/debian/iso-extract'
xorriso : UPDATE :1083 files added in 1 seconds
xorriso : FAILURE : Given path does not exist on disk: -boot_image
system_area='/usr/lib/ISOLINUX/isohdpfx.bin'
xorriso : UPDATE :1083 files added in 1 seconds
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
I: ... 202003222304-remaster-iso ISO composition attempt is now complete.
I: Creating a MD5SUM of the completed iso file ...
md5sum: /home/morfik/Desktop/debian/202003222304-remaster-iso.iso: No such file
or directory
I: ... iso MD5SUM completed.
- -

This ERROR is because the /usr/lib/ISOLINUX/isohdpfx.bin file doesn't exist in
my system -- I didn't have the **isolinux** package installed. After I
installed
it, everything works well now:

- -
# remaster-compose
...
Drive current: -outdev
'stdio:/home/morfik/Desktop/debian/202003222340-remaster-iso.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 25.4g free
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
xorriso : NOTE : -as mkisofs: Ignored option '-cache-inodes'
Added to ISO image: directory '/'='/home/morfik/Desktop/debian/iso-extract'
xorriso : UPDATE :1083 files added in 1 seconds
xorriso : UPDATE :1083 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 432 bytes from file
'/usr/lib/ISOLINUX/isohdpfx.bin'
libisofs: NOTE : Automatically adjusted MBR geometry to 1019/152/32
libisofs: NOTE : Aligned image size to cylinder size by 509 blocks
xorriso : UPDATE :  1.18% done
...
xorriso : UPDATE :  99.10% done
ISO image produced: 1239104 sectors
Written to medium : 1239104 sectors at LBA 0
Writing to 'stdio:/home/morfik/Desktop/debian/202003222340-remaster-iso.iso'
completed successfully.

I: ... 202003222340-remaster-iso ISO composition attempt is now complete.
I: Creating a MD5SUM of the completed iso file ...
I: ... iso MD5SUM completed.
- -



- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.11-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_RANDSTRUCT
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages remaster-iso depends on:
ii  rsync   3.1.3-8
ii  squashfs-tools  1:4.4-1
ii  xorriso 1.5.2-1

remaster-iso recommends no packages.

remaster-iso suggests no packages.




-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXnfqiQAKCRAy2ctjR5bM
oXHUAP9IUZhM+SyC2UDEMuOEF3O3SKyDCm4csBiTT0X27rFgcgD+O99UWMkl2r7x
deX0T2v2aFYvZX1sSqKN/6CcIx4ODwU=
=K1YU
-END PGP SIGNATURE-

Bug#949649: thunderbird: Please make a separate package for the thunderbird apparmor profile

[Mikhail Morfikov]

Package: thunderbird
Version: 1:68.4.1-1+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Currently when the thunderbird package is installed, it also installs the
apparmor profile under /etc/apparmor.d/usr.bin.thunderbird . There are two
issues with this:
1) some people want to use their own profile (a local profile, the one under
local/usr.bin.thunderbird isn't an option),
2) the name of this file is "usr.bin.thunderbird" and some users use just
"thunderbird", which leads to having two different sets of rules (two different
files).

The only way to fix this is to manually remove the "usr.bin.thunderbird"
file after each thunderbird update, which is a little bit annoying.

Please reconsider creating a separate package for the apparmor profile (for
instance thunderbird-apparmor-profile), so the user could decide whether he
wants the profile to be installed in his system or not. Thanks.




-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXilV3gAKCRAy2ctjR5bM
oW9WAQCrDxTZWfml6vLW+u655+6WZ9oFjdxKJ7BLla9yHmu6wwD+I0u42UcOX4HB
UabZ6mtFjTxnT4XUBm87+8hWpaERwg4=
=dro9
-END PGP SIGNATURE-

Bug#949062: ifupdown: Bonding interface gets the wrong MAC address when configured for the first time

[Mikhail Morfikov]

Package: ifupdown
Version: 0.8.35+b1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I'm using a Debian Sid, and the network configuration is managed by the
/etc/network/interface file. Basically my laptop has the eth0 and wlan0
interfaces configured in the file in the following way:

auto eth0
iface eth0 inet dhcp

iface wlan0 inet dhcp
wpa-driver wext
wpa-debug-level -1
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Here's the eth0 status when I set it up:

# ip addr show dev eth0
5: eth0:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 3c:4a:92:00:4c:5b brd ff:ff:ff:ff:ff:ff
inet 192.168.1.150/24 brd 192.168.1.255 scope global dynamic
eth0
   valid_lft 85964sec preferred_lft 85964sec
inet6 fdb0:1a5d:ca34:0:3e4a:92ff:fe00:4c5b/64 scope global
dynamic mngtmpaddr
   valid_lft forever preferred_lft forever
inet6 fe80::3e4a:92ff:fe00:4c5b/64 scope link
   valid_lft forever preferred_lft forever

And here's the wlan0 status:

# ip addr show dev wlan0
6: wlan0:  mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether c0:cb:38:01:f0:f5 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.193/24 brd 192.168.1.255 scope global dynamic
wlan0
   valid_lft 43193sec preferred_lft 43193sec
inet6 fdb0:1a5d:ca34:0:c2cb:38ff:fe01:f0f5/64 scope global
dynamic mngtmpaddr
   valid_lft forever preferred_lft forever
inet6 fe80::c2cb:38ff:fe01:f0f5/64 scope link
   valid_lft forever preferred_lft forever

So the eth0 MAC address is 3c:4a:92:00:4c:5b, and wlan0 MAC address is
c0:cb:38:01:f0:f5. But I don't want to switch between the wire and wireless
interfaces manually (depending whether the cable is plugged in or not), so I'm
using a bond0 virtual interface to manage my laptop's network connection.

My home router uses the eth0 MAC to set the same IP address via DHCP for my
laptop whenever it connects to the network.

For many years I have the following configuration of the bond0 interface (and
the above entries commented out):

auto bond0
iface bond0 inet dhcp
metric 10
bond-mode active-backup
bond-miimon 100
bond-downdelay 500
bond-updelay 500
bond-primary eth0
bond-primary-reselect always
bond-fail-over-mac none
bond-slaves eth0 wlan0

allow-bond0 wlan0
iface wlan0 inet manual
bond-give-a-chance 2
wpa-driver nl80211
wpa-debug-level -1
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

So according to this setup, all the three interfaces (bond0, eth0 and wlan0)
should have assigned the same MAC address, and it should be the same as the
original MAC of the eth0 interface. That worked fine for many years.

When I set the bond0 interface up, I get the following info from the
/proc/net/bonding/bond0 file and via the ip tool:

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth0 (primary_reselect always)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 500
Down Delay (ms): 500
Peer Notification Delay (ms): 0

Slave Interface: eth0
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 3c:4a:92:00:4c:5b
Slave queue ID: 0

Slave Interface: wlan0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: c0:cb:38:01:f0:f5
Slave queue ID: 0

# ip addr show
...
2: bond0:  mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether ca:16:91:ae:9a:ba brd ff:ff:ff:ff:ff:ff
inet 192.168.1.127/24 brd 192.168.1.255 scope global dynamic
bond0
   valid_lft 43058sec preferred_lft 43058sec
inet6 fdb0:1a5d:ca34:0:c816:91ff:feae:9aba/64 scope global
dynamic mngtmpaddr
   valid_lft forever preferred_lft forever
inet6 fe80::c816:91ff:feae:9aba/64 scope link
   valid_lft forever preferred_lft forever
5: eth0:  mtu 1500 qdisc
pfifo_fast master bond0 state UP group default qlen 1000
link/ether ca:16:91:ae:9a:ba brd ff:ff:ff:ff:ff:ff
6: wlan0:  mtu 1500 qdisc mq
master bond0 state UP group default qlen 1000
link/ether ca:16:91:ae:9a:ba brd ff:ff:ff:ff:ff:ff


So the bond0, eth0 and wlan0 interfaces have now the ca:16:91:ae:9a:ba MAC
addresses assigned. And the questions is why? None of my laptop's 

Bug#944679: extlinux: Visual bugs while editing a long kernel command line

[Mikhail Morfikov]

On 23/12/2019 19:30, Lukas Schwaighofer wrote:
> I'll look into this and try to reproduce this within the next few days.
> To speed things up, can you provide me with your configuration?

Here's my config:


DEFAULT debian
PROMPT 0
TIMEOUT 200
UI vesamenu.c32
MENU MARGIN 10
MENU WIDTH 80
MENU ROWS 10
MENU HELPMSGROW 25
MENU CMDLINEROW 25
MENU TABMSGROW 25
MENU HSHIFT 0
MENU VSHIFT 0
MENU TITLE !!! BOOT !!!
MENU BACKGROUND background_640x480.png
MENU COLOR border   30;44   #40ff #a000 std
MENU COLOR title1;36;44 #9033ccff #a000 std
MENU COLOR sel  7;37;40 #e0ff #20ff all
MENU COLOR unsel37;44   #50ff #a000 std
MENU COLOR help 37;40   #c0ff #a000 std
MENU COLOR timeout_msg  37;40   #80ff # std
MENU COLOR timeout  1;37;40 #c0ff # std
MENU COLOR msg0737;40   #90ff #a000 std
MENU COLOR tabmsg   31;40   #30ff # std

LABEL debian
MENU LABEL Debian 5.4.6-amd64
KERNEL ../vmlinuz-5.4.6-amd64
APPEND root=/dev/mapper/wd_black_label-root net.ifnames=0 biosdevname=0 
audit_backlog_limit=2048 log_buf_len=32M systemd.log_target=kmsg 
systemd.unified_cgroup_hierarchy=0 printk.devkmsg=on swapaccount=1 
luks.crypttab=no page_poison=1 slab_nomerge slub_debug=FZP pti=auto mds=full 
vsyscall=none spec_store_bypass_disable=on lockdown=none apparmor=1 
security=apparmor ro loglevel=4
INITRD ../initrd.img-5.4.6-amd64
TEXT HELP
Debian (/dev/sda1).
ENDTEXT

MENU CLEAR


> 
> If you're able to perform some test, can you check whether the
> behavior is consistent when using a different UI modules (menu.c32 or
> vesamenu.c32).
I tested both menu.c32 and vesamenu.c32, and they have the same issue. 

Bug#944679: extlinux: Visual bugs while editing a long kernel command line

[Mikhail Morfikov]

Package: extlinux
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

My current kernel command line is about 400-character long. When it was
shorter, I didn't have any issues when I wanted to edit this line in the
bootloader screen by selecting some entry and pressing "E".

I recently added some other kernel parameters to the cmd line, and I noticed
many visual bugs in the bootloader screen. Basically with each cursor movement
(back and forth), I get an extra text line in the screen output (copy of the
current line scrolled up). Also characters in the cmd line disappear or change
when I move the cursor back. The visual bugs make it almost impossible to edit
the kernel cmd line. Also When I press the backspace key (or the back arrow
key)
for a longer period of time (let's assume I want to delete some parameters
entirely from the line), I hear the hardware beeper which is really annoying.

I found out that the problem appears when I have more than 4 lines of text on
the screen when editing the cmd line. So fifth (and next ones) will trigger the
visual bugs, while 4 (and less) won't.

So what to do with it?



- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.11-amd64 (SMP w/2 CPU cores; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages extlinux depends on:
ii  libc6  2.29-3

Versions of packages extlinux recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-1

extlinux suggests no packages.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAl3MNmEACgkQzQRoEHcb
ZSCybg/+LbzriiSLoPsLRK9iW+GmMD4U82YnK6OoEjz7YMIWi8yJzzzgsRgoSJs5
yOpXTdbMQchScmbrloMb7jBDWkaK594+2RvL+ZOyeYt7SNAwIyZEv4AdA1DiNArn
moKQk48WPKV4gNqVXnjlvs+Eab6nFh7AokzMSG7TxHiZ283s1aQYOdUjiVWdU2YH
pLgd1qRsKf7tz1kJfTmTx4tx8w8dR7Qxe6vuesShEr+QHwb4PjliroXzxrTJYBAe
WVikkk6aYkWrDJHmn2SOmrXdwzUOpkIOuSludoP2ctDZfjsHbigNMI40smQI/t0F
qnLwZ0QscOybxE1z4l4WHnpr3opl3EyLg2XNvbdDCXBZdFP+YmVHG06sZrEwJktc
UALj5pTAytB87vK7p77kMsAOniZJj2T47mdh8ggJmYiGby4JkGWr3Ya9YTWRoQxX
v1ohflHg8OC88iXWaAQPzi/gtpcM17IkeR5EDWV+/FtOzSVReqjpXwI37DvJ0CUp
BcB/ZBdLJ2MTAU5D7UKm/0OIjPcfE110ICXrbCn+oBvhZ+Tn1GeYrQje4nW1Rfb5
dWU2Ue4FzGPun/d/M1zVmVSUYocPpY6nLOn6Qh5+t6yK0vKzkuyhFgsrURrJwLQ8
qFEjFQfep4vpM0NF+JHriPGglyVpkaEHklCl9IqxcPVbIEL7AjQ=
=QWGV
-END PGP SIGNATURE-

Bug#935753: FATAL:memory_linux.cc Out of memory

[Mikhail Morfikov]

Package: chromium
Version: 76.0.3809.100-1
Followup-For: Bug #935753

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It looks like the problem is in the libgl1-mesa-dri package as described here:
https://bugs.archlinux.org/task/63945

Currently, the 19.2.0-1 version is in SID, which causes the OOM issue.
Downgrading it to 19.1.6-1
fixes the problem.



- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.1-amd64 (SMP w/2 CPU cores; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  76.0.3809.100-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.34.0-3
ii  libatk1.0-0  2.34.0-1
ii  libatomic1   9.2.1-8
ii  libatspi2.0-02.34.0-3
ii  libavcodec58 7:4.1.4-1+b2
ii  libavformat587:4.1.4-1+b2
ii  libavutil56  7:4.1.4-1+b2
ii  libc62.29-2
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.3.0-5
ii  libdbus-1-3  1.12.16-2
ii  libdrm2  2.4.99-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.9-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-8
ii  libgdk-pixbuf2.0-0   2.38.2+dfsg-1
ii  libglib2.0-0 2.62.0-3
ii  libgtk-3-0   3.24.11-1
ii  libharfbuzz0b2.6.2-1
ii  libicu63 63.2-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3+b1
ii  liblcms2-2   2.9-4
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.21-2
ii  libnss3  2:3.45-1
ii  libopenjp2-7 2.3.0-3
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpci3  1:3.6.2-2
ii  libpng16-16  1.6.37-1
ii  libpulse013.0-1
ii  libre2-5 20190901+dfsg-1
ii  libsnappy1v5 1.1.7-1+b1
ii  libstdc++6   9.2.1-8
ii  libvpx6  1.8.1-2
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.8-1
ii  libx11-xcb1  2:1.6.8-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages chromium recommends:
ii  chromium-sandbox  76.0.3809.100-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox76.0.3809.100-1
ii  fonts-liberation1:1.07.4-10
ii  libgl1-mesa-dri 19.1.6-1
pn  libu2f-udev 
ii  plasma-workspace [notification-daemon]  4:5.14.5.1-2
pn  system-config-printer   
ii  upower  0.99.11-1
ii  xfce4-notifyd [notification-daemon] 0.4.4-1+b1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  9.2.1-8
ii  libc6   2.29-2
ii  libgcc1 1:9.2.1-8
ii  libstdc++6  9.2.1-8




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAl2WXAIACgkQzQRoEHcb
ZSC6YxAAvYUZPPEKAFZ6iaIU+Yz2pU9QOhNPApy6inM1oU/KGkZRuF1LOJ0wlbbW
kJSERKuXZOvbAETYzhUHETEUVzW5rxjvdbJNzbkjwxXKdaHwP7TNjC1xS9BjBBgn
Pf3/yo5L9PQNNH5ahokk4AE386fB4RXk9mJCz3x9yERO3W/ilSFDIHOefz0BWoxa
osGkbpG5yS4QxvyiE73ExgKp2moIweChc8XNWGPHC/hByeQ71o3ev07Q+vHlWeAT
35ijik6YOZg82UpDDL7ezs62jmYOCXpzZQ4LMvujT8AcONNqz6s42aDKyKAvc9QI
fsvQbCUY3Cn2Oth2NK+Er04ZGLQv4dzf9Kh11V+ZSfZjTW9poBQTNMgObAedWuGj
eYnEFmawDpq3fClDKWUMRjk8Qq1/m5CJzdm7xfNWxPoMZZzU835/21nOJLCYGskU
KZGJaFP00bFVmclYBAR7rVacBbQHZXVxefbRUeD0PQhDxNgjDH9/F82jEvUjtrBW
kC/KW6TRfvNCk+KAM3QzjRE6GvbK79pwu7IghLaKV9mTKr7Yn6bD2GIE5G0GIipW
llrOp2c5i/a3dV44oyIH6QJHBwue03vhqtJMaOmyJTJjiYAPzPNQgjc6HXZI1qTf
SA5UmzOei2VXIdfbE8elDHRYt2AUtura/2vwcaaU/hjcbndfLIA=
=8PIL
-END PGP SIGNATURE-

Bug#935009: e2fsprogs: e2scrub_all doesn't work when vg_free>${snap_size_mb}

[Mikhail Morfikov]

Package: e2fsprogs
Version: 1.45.3-4
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I have 4 GiB of free space in each of my PVs:

# pvscan
  PV /dev/mapper/sdb1_crypt   VG wd_blue_labellvm2 [820.30 GiB / 4.00 GiB
free]
  PV /dev/mapper/sda2_crypt   VG wd_black_label   lvm2 [<230.88 GiB / 4.00 GiB
free]
  Total: 2 [<1.03 TiB] / in use: 2 [<1.03 TiB] / in no VG: 0 [0   ]

I also have snap_size_mb=4096 set in the /etc/e2scrub.conf file, but nothing
happens when I issue as root the following command:

# e2scrub_all

There's no error indicating what could be wrong.

Looking through the /usr/sbin/e2scrub_all file, I noticed the following line:

local devices=$(lvs -o lv_path --noheadings -S
"lv_active=active,lv_role=public,lv_role!=snapshot,vg_free>${snap_size_mb}")

There's vg_free>${snap_size_mb} which causes the problem -- the above lvs
command returns nothing. It should be ">=" instead of ">", or the value in
/etc/e2scrub.conf should be less than what pvscan returns as "free" to make it
work.





- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.9-amd64-morficzny+ (SMP w/2 CPU cores; PREEMPT)
Kernel taint flags: TAINT_RANDSTRUCT
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages e2fsprogs depends on:
ii  libblkid12.34-0.1
ii  libc62.28-10
ii  libcom-err2  1.45.3-4
ii  libext2fs2   1.45.3-4
ii  libss2   1.45.3-4
ii  libuuid1 2.34-0.1
ii  logsave  1.45.3-4

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.2-25+b1

- -- Configuration Files:
/etc/e2scrub.conf changed:
periodic_e2scrub=1
recipient=root
snap_size_mb=4096
scrub_all=1



- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAl1YtPEACgkQzQRoEHcb
ZSCg5Q/9HHg254TnJ+yug2jPiFPgyzp59nHrZ25CSZjmoCvl0IvmSDtmzgIzj9Kw
F6jMC23+rewK9kjFjcZrGzz3pNblwx5z6QIPOm7m6Xob9gPV0EXIURI4sqeo2u76
ZmZjOeTd+1hjq2w6XKVElbVcB04qC36hCIN7apyZVdW6TVhZGFBHSA95xz9rTSa6
7i2o9Z9PSlsyKVBC7+Bf/ucTpzNQG/avOm5GuHl2++KSl3+gIeHZqgvOWdfd28pg
L5H58uafWn2RqrHkIbJVZCUTsuJzYTV/Kk5c3/KytR2OpOTfpCxj0QQ44NOHnrzx
EdzGkLD5XJVe8MB62OzCHWP/6iJWD8SfnsmMn705TankVjWMzZyKkXUVIAEK/ijq
MWcCvlONJxYEWk0NcoM0NQ1XAycfqdxOWx0mdCHV7fnM4qah+RxZgufi8iMoySXG
7MwqFWvtWiS7MMkBN6KVAMx88JXSmsc9WCOw0GjV4UrUDv3G2rdAfA6BCFejA4IR
dm1vX1xedDBDFZBNkdTvYYsr237Ro/PNyL+slZdh/2woMgliaez02/CzeeA7BAK5
MzS2sVCtIXrXxzfxqbPwaHkMJO4lXLQGcroY1pEt6RljUbCYx35/eeH9dwp6NWDH
P/burk6Fey3Nn7/YB+XiI9UVjOGZQbiuti3E1gxVW0Dz/1zJGPc=
=ZvAz
-END PGP SIGNATURE-

Bug#918097: initramfs-tools-core: Error while building DKMS modules when kernel has all its modules built in

[Mikhail Morfikov]

It looks like the DKMS error was because of my mistake and not the initramfs
one -- the ARCH=x86_64 env variable caused the issue, so just ignore the info 
about 
DKMS.



signature.asc
Description: OpenPGP digital signature

Bug#918097: initramfs-tools-core: Error while building DKMS modules when kernel has all its modules built in

[Mikhail Morfikov]

Package: initramfs-tools-core
Version: 0.132
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I wanted to build a custom kernel using the linux-source package from the
Debian repository. I haven't changed much, the only thing I wanted to do is to
build in all the modules my machine needs and remove all the others. Such
kernels don't have modules in *.ko files and it looks like mkinitramfs has some
issues with that.

Basically, the problem is in the /usr/share/initramfs-tools/hook-functions
script file with the following line:

find "${DESTDIR}/lib/modules/${version}/kernel" -name '*.ko*'

Since none of the modules listed above in the file were copied to the temp
destination folder, the kernel/ subdir doesn't exist and hence the above
command returns error. The initramfs image is building fine, but DKMS packages
return something similar to the following:

# dpkg --configure -a
Setting up sysdig-dkms (0.24.1-1) ...
Removing old sysdig-0.24.1 DKMS files...

-  Uninstall Beginning 
Module:  sysdig
Version: 0.24.1
Kernel:  4.19.13-amd64-morficzny (x86_64)
- -

Status: Before uninstall, this module version was ACTIVE on this kernel.

sysdig-probe.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.19.13-amd64-morficzny/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod...

DKMS: uninstall completed.

- --
Deleting module version: 0.24.1
completely from the DKMS tree.
- --
Done.
Loading new sysdig-0.24.1 DKMS files...
Building for 4.19.13-amd64-morficzny 4.20.0-amd64-morficzny
Building initial module for 4.19.13-amd64-morficzny
Error! Bad return status for module build on kernel: 4.19.13-amd64-morficzny
(x86_64)
Consult /var/lib/dkms/sysdig/0.24.1/build/make.log for more information.
dpkg: error processing package sysdig-dkms (--configure):
 installed sysdig-dkms package post-installation script subprocess returned
error exit status 10
Errors were encountered while processing:
 sysdig-dkms

I changed my kernel config a little bit:

# egrep \=m /boot/config-4.19.13-amd64-morficzny
CONFIG_BTRFS_FS=m
CONFIG_XOR_BLOCKS=m
CONFIG_RAID6_PQ=m

And after rebuilding the kernel when I want to created the initramfs image I
can see the the kernel/ subdir:

# tree
/var/tmp/mkinitramfs_p7rDVj/usr/lib/modules/4.19.13-amd64-morficzny/kernel/
/var/tmp/mkinitramfs_p7rDVj/usr/lib/modules/4.19.13-amd64-morficzny/kernel/
├── crypto
│   └── xor.ko
├── fs
│   └── btrfs
│   └── btrfs.ko
└── lib
└── raid6
└── raid6_pq.ko

5 directories, 3 files

Will this qualify as bug or should I fix this in some way myself since it's not
the Debian distribution's kernel?



- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.13-amd64-morficzny (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.30-1
ii  cpio 2.12+dfsg-6
ii  e2fsprogs1.44.5-1
ii  klibc-utils  2.0.4-14
ii  kmod 25-2
ii  udev 240-2

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.27.2-3

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.8-5




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwt2AAACgkQzQRoEHcb
ZSDrjg//X6cMtoFjEw3BOAg+1EpKTQ1/yfJSAW611NgsgfvvPurncPx5X3XtQ0sH
/I47mXSB4ds3/KuGIJb96SXgOChBqvfdS/7ajirGL11Ou4Ujfmb9CC0sOpUe3uba
OKNdB+QiwHMDlfKdvDMk0LXN4i7fx9hCUukAkhE1s9xbqCk+veTmHpnv5BomIoX/
AqfdmeN2Y08MDdd5K8S/g1/4fVg9QUSE8+9dP9r1Bw7nqdp4EpSj7ZSKtifSayRb
k+AENOn0nMoXQP9zTYbzIv8k3LvB6+rTBf67ST1uMGGIljuf78VveJqMvJfBgS8P
8VNDdx8O5J2U2Dn9S4j4NOiKJLkQIBELyR+hTF4AQrPJ8BHquPvvCbUyVLL9SV4S
Wz8gylSP9uWwYlEjN/9vfFtMhZIiJ5Maloow4SKYgjw6+5w7BDtpp/f35Vji2+cc
9JKf+xTVuMRmMQn43NAj6a+JcUv6i9n9wy9C9HsC2qt6NnVdTx2+YGdx+vqwAz/0
QewOxkeuHgqLrRD4aUSkrZ4Z2vcfW+5ccXiej0+QsMyHt1gWgMU3DbZcNdpK/k2+
JioqBC2aLN37FfQzAhB/KDFwJ1XmJCqi1GKdk431Z/urtAFlPB/X08aDRUf/QfVq
wwD8hUwzLB3hSHqGDmKCuY0Z/y/uz1tW7B79tPgZIiIneX3loIY=
=G9Xp
-END PGP SIGNATURE-

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Mikhail Morfikov]

On 22/12/2018 16:48, Guilhem Moulin wrote:
> Disk images, key files, and detached headers can reside on arbitrarily
> complicated file systems and block device stack, and setting up these
> stacks to make the files available prior to unlocking is really not the
> job of our initramfs boot scripts.  I'm thus closing this bug as
> ‘wontfix’, sorry.
> 
I don't get it -- I didn't post it as an initramfs issue, only as cryptsetup
one. I'm not sure, but isn't the /etc/crypttab file a debian specific? If not, I
can ask about this problem upstream, but I thought it is debian specific, so
that's why I opened the issue here.

It's not about accessing as many devices at initramfs phase as possible, only to
open as many devices as possible at boot time using the /etc/crypttab file
instead of mixing debian/systemd (and probably some other) specific solutions. I
didn't see any info that the /etc/crypttab file is used only in initramfs stage
or should be used only in that stage (am I wrong?). I have always been using the
cryptdisks_{start,stop} scripts to open devices specified in the /etc/crypttab
in my system, and it was working just fine.

There's the "initramfs" parameter, which takes care of setting the encrypted
root file system in the initramfs stage. I have this parameter set to all real
devices, because without it the decrypt_keyctl script can't read the password
from the kernel keyring and hence my system it's not able to open the rest of
the encrypted containers. That's why I thought it could work also with the LUKS
file images, but it doesn't.

If the LUKS file images were real devices, there wouldn't be an issue since all
of the listed devices would be opened using the same password at boot/initramfs
time. But when you deal with LUKS containers in a file, you have to use
different solution. That's why I asked if there's a way to use  only the
/etc/crypttab file to make it work.

If this can't/won't be done, I stick with the systemd service I have already,
because it works just fine, though if I moved from systemd to other init, it
would stop.





signature.asc
Description: OpenPGP digital signature

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Mikhail Morfikov]

On 22/12/2018 16:11, Guilhem Moulin wrote:
> If having a key file is acceptable to you, the following crypttab(5)
> snippet should be enough for systemd to map the device once /home has
> been mounted:
> 
> some_img  /home/me/luks/some.img  /path/to/key/file  luks
> 
I don't really want to use keyfiles.

Actually my current setup is pretty good, I mean the real devices are opened
without any issues (using the /etc/crypttab file). I also have the following
systemd service for the LUKS images:

---
[Unit]
Description=Cryptography Setup for %I
DefaultDependencies=no
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=media-luksimg.mount
Before=umount.target shutdown.target
Conflicts=umount.target shutdown.target
RequiresMountsFor=/home/me/luks/some.img

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=30
KeyringMode=shared
ExecStart=/usr/sbin/cryptdisks_start luksimg
ExecStop=/usr/sbin/cryptdisks_stop luksimg
---

This simply waits for /home/me/luks/some.img to be accessible, and then it uses
cryptdisks_start to unlock the image using the password from the kernel keyring,
and I don't have to type the password again when the service is started.

Anyways I think crypttab should have such functionality built it (if possible),
so everything could be set up in the /etc/crypttab file.



signature.asc
Description: OpenPGP digital signature

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Mikhail Morfikov]

On 22/12/2018 12:57, Guilhem Moulin wrote:

> The cryptroot initramfs boot scripts won't try to mount anything; if an
> extra file-system (other than / and /usr) needs to be mounted at early
> boot stage, you'll need to arrange for it yourself, for instance with a
> local-block script.
So unlocking the LUKS image using only the /etc/crypttab file won't work. I
think I could play with the scripts and see what can be done.

> If you remove ‘keyscript=decrypt_keyctl’ systemd should be able to
> unlock the device later in the boot process, once /home has been
> mounted.  (systemd doesn't support ‘keyscript=’ currently, cf. #618862.)
> To preserve unattended unlocking you could use a key file instead.
In the past I was using systemd to unlock all the LUKS containers and that was
working well. But I had to remove plymouth, and hence I have to type the same
password multiple times at boot stage. That's why I added the "luks.crypttab=no"
option to the kernel cmd line, and I want to use only the /etc/crypttab 
solution.



signature.asc
Description: OpenPGP digital signature

Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Mikhail Morfikov]

Package: cryptsetup-bin
Version: 2:2.0.6-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have several LUKS containers, and all of them use the same password. Some of
the containers are regular disk partitions, but I also have some file images.
An example file image is stored under /home/me/luks/some.img . Here's the
/etc/crypttab file:

- ---
#
sda2_crypt  UUID=some-uuid-1c1
luks,header=/boot/headers/sda2,keyscript=decrypt_keyctl,initramfs
sdb1_crypt  UUID=some-uuid-2c1
luks,header=/boot/headers/sdb1,keyscript=decrypt_keyctl,initramfs
some_img/home/me/luks/some.img  c1 luks,keyscript=decrypt_keyctl
- ---

All of the containers should be opened at boot time, but only the first two
are.

When I add "initramfs" to the third container, I get the following error:

- ---
cryptsetup: ERROR: Couldn't resolve device /home/me/luks/some.img
- ---

And if that message is ignored, system is unable to boot because it waits for
the "device", but since the "device" is inside of the /home/ partition, and the
/home/ partition is inside of an encrypted LVM setup, it can't be read. So I
can't
use "initramfs" in the case of the LUKS file images, but without it, I can't
open the file image along with the rest of the drives at boot time.

For now, I use a systemd service which uses cryptdisks_start and
cryptdisks_stop scripts. In this way the file image can be opened using the
same
password in the kernel keyring, but is there a way to make it work using only
the /etc/crypttab file?



- -- Package-specific info:

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup-bin depends on:
ii  libblkid12.33-0.2
ii  libc62.28-3
ii  libcryptsetup12  2:2.0.6-1
ii  libpopt0 1.16-11
ii  libuuid1 2.33-0.2




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwdqsQACgkQzQRoEHcb
ZSBKMg/+PTFKL0K8Fi+rm+5pUAAX4qOUExjiaj75NQu1hfP8fxoZf+g3PaMBX7kl
9byFi/eQQ/kAHP2NfukyOqrpwc6nZt/Gv90ozxNDaZ/THTby6er8g7fDPaM09u28
aZJJM0jC2OoBejilOWrkoQxEPeWwk6+OC5hL3p41RjBNNdgCqyym6NgmDO0ZhjRs
0lqHnXJKWsdkKAHc4ETf/rRIpjvY5KrB5ybpFDXsQgmY284Es7J1TPfdkZ5Ev4Sf
ouGI+C+8Lx3lNAqXD6t1a2UNVqggHHwFs9rZqM+OQkTJPtykGq3Nylh2tbKflKH4
lUfKmdKFDgMidy/LyD6QZJRLD7cqv7HOAyDX5JOKYXDVj8rzU2kYHsfBmno/fyUY
ipnlZiG1oLY1gX3fAekbnnI2YPOH1tMqKxLTsQDgNCfSMReQUj3dZC+18Hb9/Opq
GG0TuvZbj7c+S3pJLrtfoXY+0a9kXkirYsVX7Riiefva6uM4P5KW04jLEs2f4N8P
2sc+pBC4/+PhhiUPhVNuHEQBzSfz/jpnIcTkf2Twy22/cu+Y+Yheqhd+9V5B9rQQ
2fxD5fJRX/RHCDuYho/MX3AhRAZrIYvbXT8kpkecpHvyxhdJZepsLqeOyjWdD+gB
f1PWWTNu1t43dH8omwz/tlpD9az6SPsDr5L29SRk2J7dgAtpr+k=
=4RGF
-END PGP SIGNATURE-

Bug#908329: lightdm: LightDM shuts down the screen on lock and won't turn it on

[Mikhail Morfikov]

Package: lightdm
Version: 1.26.0-3
Followup-For: Bug #908329

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I think I have a similar (or the same) issue.

Basically, when I lock the screen (via light-locker), the screen goes black,
but it doesn't turn off. Keystrokes and mouse seem to dead because they don't
turn the screen on. When I press ctrl+alt+F7, then I get the message: "This
session is locked, you'll be redirected to the login dialog in a few sec", and
after a few seconds I get the login screen. I don't even have to wait for the
redirect -- I can simply press ctrl+al+F7 and ctrl+alt+F8 (I have to press both
of them).  One curious thing --  when I start typing while the screen is black,
the login form can be filled with password, and after pressing enter I can log
in.



- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.12-1
ii  debconf [debconf-2.0]  1.5.69
ii  libaudit1  1:2.8.4-2
ii  libc6  2.28-2
ii  libgcrypt201.8.4-4
ii  libglib2.0-0   2.58.1-2
ii  libpam-systemd 239-15
ii  libpam0g   1.1.8-3.8
ii  libxcb11.13.1-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.5-1
ii  lsb-base   10.2018112800

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
ii  accountsservice  0.6.45-1
ii  upower   0.99.9-2
pn  xserver-xephyr   




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwMLF4ACgkQzQRoEHcb
ZSCrLBAAnKNwEOvm6h8rlswrETfZmK7yJvryo1s61EMWvjzXP88ZWH9zJvyIN4uQ
7SBpeDceh58ZtDG6zA2ieAPqkGFjnZIPmz/Pn0wWCHpmdRrL1eDIywKIHBV8X5eY
2E/kQ6d6TZll4ChrlIf9YabQn7g1ZqWEb+d80T7KThmM5kK1OEti1GY5F+zUIh5f
YOrF/9P9eJrWSa+zFR+Omzc6uSlBiQ3oLjlw3lBNznCfMW2Q6rOX/Pp0MTIwUK9V
+XJjV9930Pcc5faOetlBKKYSqFOLHioNUHXADqT/NoRyFzzM9uHc5Y3Xlg54CU5O
iIScVbgQ3AHZyu3fVtoGzeBs60HqmU3VhFKjmd3/lNmxsCvTo/sJp8VGtpoqAZ/P
Ia3zIqiEPQCCgC/9oFkbhR7kDrPrRnsAxEGIVcMJ+rP8GAcPgF4xqsAa6LHQu+rS
IUxkAtfgmFgTRjDnjPcFq+dis0v6IW2+3a63rf+eUGYaoLg+pVvH0i9svjD1EJ+m
1BcWerMakeO6xFrQnNogt8yFHNu57vtlMIejuSUZu0x78y5h1cskR9Aj5fogti7G
jvbkYKbHW47lxkkyywcwzYk8M1qxB8UXz6ycHe2cnGmCH3USZRA0QSYQLhBisHPs
X0Q9uwGUtJ9cFdAV/TR9wVT/+QvHYthz4ogJS0AvmWfOpYFZoRA=
=hMsp
-END PGP SIGNATURE-

Bug#915192: volumeicon-alsa: Sound can't be unmuted

[Mikhail Morfikov]

Package: volumeicon-alsa
Version: 0.5.1+git20170117-1
Followup-For: Bug #915192

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It looks like volumeicon-alsa doesn't detect PulseAudio correctly, but when the
following is set in the file ~/.config/volumeicon/volumeicon :

- ---
card=pulse
- ---

everything works well again.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwIJBIACgkQzQRoEHcb
ZSBKCw//VuY9tcfHrkpugxIPLfadiInqY7hCqGnJwmWnPnoT6A2AqRUhMGwSlHID
el4jitluOuRBv4doFN9yQva7nd6V64KKJb2WIWpwTyvh6VFF7ypwEZH6NA9jPy/1
v5FLmh8aXgepGUEXgmXEhz0EJ9fzu0oy4T0iusHksTSTCFaAcCy3UDfF22Briul4
ItPBaFBmWopJ89jJzOlI9HxALseBn9whlu00BH7SkuxByM8OacIS8bYnQhC+gAJu
bXusoJgSayBP9vI5WTSzNkZMufB3vhcThQBWtGaIaeMFp+nrdCzGLaRNacgMR2N/
l26ZfhQPb6C/YHDQxYRMa2CxVxB8iVh0ynoZ8Fzhvw4wgBT0M8BciZAlrsu056D9
yjs4EU9qPpPDIQxvju8UNfRtATPP1uhRxiFCyQBsDIKn3afWalSBQN6mlfKxHCQJ
t8lwVDh2uJKlq08SlfrkiG/hjpNr5GCnUx2LP43FnnUOrxklqQqYm6UDhKDwqtd9
VTLM25b3RCr92x0aKDljN/GVgBcXvzf6PoxsIP7ex/yXzZ3tHBh7Vf+3d4mwUVoR
/jorqe1eIsVtJ/A/2Nhp9wp//xXTtw6G+WMWxCTesBPAVXSmNgZIvTJrxB24eBap
yalv/2RGiqrB0QzVfuHh+pc58Kte5Vdwg5f3WQQg/hLbPT8aqZ8=
=ATvn
-END PGP SIGNATURE-

Bug#915192: volumeicon-alsa: Sound can't be unmuted

[Mikhail Morfikov]

Package: volumeicon-alsa
Version: 0.5.1+git20170117-1
Followup-For: Bug #915192

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It looks like it's an old bug:
https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/1026331



- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages volumeicon-alsa depends on:
ii  libasound2  1.1.7-1+b1
ii  libc6   2.28-1
ii  libcairo2   1.16.0-1
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgtk-3-0  3.24.1-2
ii  libnotify4  0.7.7-3
ii  libx11-62:1.6.7-1

volumeicon-alsa recommends no packages.

Versions of packages volumeicon-alsa suggests:
pn  alsamixergui | aumix-gtk | kmix | gnome-alsamixer  
ii  plasma-workspace [notification-daemon] 4:5.14.3-1+b1
ii  xfce4-notifyd [notification-daemon]0.4.2-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwFSpUACgkQzQRoEHcb
ZSC/3g//bOcU0Q+u2ai+X4c6XDzaiE1daNCcabBKyDtEuk+svPeNus2PgsaGO9J6
oqgdJ0/5jBzcil/UI475CV69m2kVuJqZlHaRd5zp3P5+814bf6OSotvQHShbhdCw
tgGS3ZyDHmMO7O76x6hosIrnjRw3a6YTRG3PK2so1JyXdnEAJX1puLomvHRhCv2v
Ihu4UIvj6kirSwEdQIKUcSEALCZk3OtQzsSlrHlwNEKtt9wEsz7MKQElPNyZ8Vzy
Mw5hNb4JqMq/AuWWefl8Yqm2wG5Lkn7rMLV8ntmTUMvy7LxHHpnHBkcaeJGmXREC
1Ga0fFwSuBM3etkcc2w27xeJ2e+uD01iZ74ZMJqeUQFGhQx9se39Mg+lpJraF/m9
KpFiF4I32NWna87rxHOaAEbYDzbzmndiDauYDQ4KLsL9VZt9Mm8tdt6NTreYEWTV
P6+ty06q5Csas46ssy0PS/vjF8E1niCFoDf6IXRQ5154GupqDh3T1B8EEMtRY9RX
lMX7OM5E/O454rjWMHHXZAuwJSYY+NJdvYli7fHx5j4dGxv10hXXAOPhOqsapAU0
4/G/aXqxMSpAufXH7R6LSXMBjyw147MNjfcJvnmn7zLOiOFkdxXgfwykfZ4aRT47
Uollgi8b2Yz6wBcS6mII9nFQCmkKO11dXJZ8D4XNV30SuB/Wc+8=
=5md5
-END PGP SIGNATURE-

Bug#915214: cryptsetup-initramfs: Scripts from /usr/share/initramfs-tools/hooks/ don't add files to initramfs when /tmp/ and /var/tmp/ are mounted with noexec

[Mikhail Morfikov]

Package: cryptsetup-initramfs
Version: 2:2.0.5-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

The /usr/share/initramfs-tools/hooks/cryptkeyctl file has the following lines:

- 
# Check whether cryptroot hook has installed decrypt_keyctl script
if [ ! -x "$DESTDIR/lib/cryptsetup/scripts/decrypt_keyctl" ]; then
exit 0
fi
- 

My system has the /tmp/ and /var/tmp/ mounted with the "noexec" flag. In such
case, it looks like the check returns false and the /bin/keyctl binary isn't
added to the initramfs. Everything backs to normal when the tmp dirs are
remounted with the "exec" flag.

Also, the rest of files in /usr/share/initramfs-tools/hooks/crypt* have similar
check.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwC22MACgkQzQRoEHcb
ZSACUg//b4htZ5M0L6QE+ZSYITIn+QezaGSsVJHE/eZJbqwxQ99+8arL8XzbMl+b
6R//FKQHng6Z0HCTmWFdSifr1KjcG6251URBNcnjk8WrIse2H2QmYlUK4nROSGnh
xdLms0KgwV4rgfb03UAHKqoRUJyUtF5+lp+KFXERTCXM8TtckJIFxClpK+lHYe05
3/4h5U34tiNh62N7ufZOHWBn5rEG4uRwYetu5oVNHqH4iHZDF/SawfvWoQlrVDkB
FKrSwvVMWBkMlY/IRpmiWav8Ti5k4jldvoBkXF5h0XDjy9C1R0G4PkKTDbjR0KQU
XdPs3Ve8RfalPzc4TS7oRPhxE6K4aP++B2DsERSsp3kIpLuO7W4iHko5pgnhcMxv
Hr/JAi6sdu8HQKzetpN3CKL+YtMXMFYLBICzS2pzq3bSCSjx6Pk63weoEDAzNi/U
QS3EWz+73IzjktIkFv3Zu3pXnJD2JkZGRpfVzGPztMbsrLc/vR/QwLr6w5TSxL7h
8chKvBCB8Dg1OJ6HnTFmIrU/XLFJODBh1l7TxZAZB54mWm++1PBH6+hG4B9brbbx
6V3eSSUHtT5KYGicnttcevDlr0KR/vkCBAS+qk+SAS0knSquIe1+0N3HgM5S8pP1
/sOJ+O87ExKj+jA7oiLLH4V33YCuE3vEYzh8OAkSTIRqU/XxX50=
=H5V0
-END PGP SIGNATURE-

Bug#915192: volumeicon-alsa: Sound can't be unmuted

[Mikhail Morfikov]

Package: volumeicon-alsa
Version: 0.5.1+git20170117-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

When I mute sounds in my system, everything works well, but when I try to
unmute them, it doesn't work. Basically, there are channels settings in the
volumeicon preferences, and my current setup is:
Device:default
Channel:Master

When I press the mute button, I can see in the alsamixer that both Master and
Speaker channels are being muted. But after pressing the button again, only
Master is being unmuted. So to make the sound work again, I have to manually
unmute Speaker.

When I change the settings to:
Device:default
Channel:Speaker

It mutes also both channels, but it unmutes only Speaker.




- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages volumeicon-alsa depends on:
ii  libasound2  1.1.7-1+b1
ii  libc6   2.28-1
ii  libcairo2   1.16.0-1
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgtk-3-0  3.24.1-2
ii  libnotify4  0.7.7-3
ii  libx11-62:1.6.7-1

volumeicon-alsa recommends no packages.

Versions of packages volumeicon-alsa suggests:
pn  alsamixergui | aumix-gtk | kmix | gnome-alsamixer  
ii  plasma-workspace [notification-daemon] 4:5.14.3-1+b1
ii  xfce4-notifyd [notification-daemon]0.4.2-1




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwCtAoACgkQzQRoEHcb
ZSAi8RAAvKcDuIa+S0ao4Iw9v/5+5hKyL9Jp5/qyiO9ojnQzHR6A7ukj105Gwqcs
YeyexWKYxL8Ai2ols9jyqh2D+p98kTRJocmhtYOmYWJaD+W0T4pblil0kFtOriKk
zyad7YMXl7XL0dy0CC6IsbfsK6Fjllv8o83p/YXssLA++PujLnDWK5jJCGIfhTVf
t+pxoDeM161dtgEG3nAfsuqxWGTk+IYXcdz7TtdpmYMZWvmwYbplZeDiiZOgjsaM
whNZANtoRrEum0izfzrPgSQHXQ77ODacjgd4P2agWWijPmPJDr4yWdFkQxjcUvWv
V4iNTTvUR83hapA92maAouI0V41/PidB7vlL0WxENpssXK1tMiIYZN3PrQAwXT9q
TgF1UHJmkSkJR8yRE0EwjdZ8fyD84m++5i9rU/75QNdbc4QPY4uYqgy03LpfGKfj
Ow8JOTBl6RfV6JstNRqpw7R+ggpQp+ly0ps1lS3GU5RdE1atfVqBEJOSC7RVuxHt
5QaQRxzuj79A0NIkSfYIqhs92BV3thinweARjFTsTaZ0jvH2NziKruTs2kg+CDg2
wbTTJwKZRWQsy6RrudRzMkMcodX2U3YCtYrtsLJXxnzRwjkN/wlF9UGyta9v7vg+
eZrgZjhM8pSmSE3tGAs8QZGy0Y85taCS5jNNJphXcQ3cb+YhzKA=
=QlF1
-END PGP SIGNATURE-

Bug#915139: linux-image-4.18.0-2-amd64: Please set CONFIG_MEMCG_SWAP_ENABLED

[Mikhail Morfikov]

Package: src:linux
Version: 4.18.10-2+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Some processes in my system need to be limited when it comes to memory
consumption. I wanted to use cgroup v1 along with tools from the cgroup-tools
package to achieve the goal. Everything works well, but the limits can be
applied to RAM only. My machine has also a SWAP partition, and in such case,
when the limit is reached, kernel starts to use SWAP, and it does that without
any control. For instance, if I've set a limit of 1GiB of memory for firefox,
after reaching this limit, all the data would go to SWAP and fill it up slowing
also the system down. There's an option that could prevent this from happening:
CONFIG_MEMCG_SWAP_ENABLED , but it's not set and all the memory.memsw.* files
under /sys/fs/cgroup/memory/ don't exist. Could you set this option?




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwBsqkACgkQzQRoEHcb
ZSB7JQ/9EY0WKSPpGpnoWhXSOEsKHZHFPHl9Pf8b9OqVyuopFQSHZZ2IidiqUfWO
qgXkU72ZJAwNTQVZPC10HScYuM6y7Us1Q4fLjk6FeLu5E+kttJmvxZt6D0DAM5zi
t4TttDwWIeybT7KF8ST6OcCzs3fq/EqzeL3WINq+QE/1PcMnWgI+4Rp3tj5pYbZH
owdXdN9+d065qIypdrIJHhxJ/ZfCbUonslQPh8En+8ml+tPBNWslpCkx5AFWp/Cw
cdrmqqmY3nEXeQAgy6MfSHhGytD01Fki/BmX9mIE+cAodNTVSz8/1oc+vk2sQRVh
yBnv5uuDmCgh2Fr81/Iz8yOJ5bcf9XTT9oAdHbdQ5FsHgLfdthOC7Y73hNLtoTXH
95gNO9D/iHSzH2U8isq2R57VD9G/TSX79y8jIp3eUmAEXJfJ75qNN7Q4T3R89Z1q
Yq1Qo1WWduy/8nlQNNcay4bAaHuD0qdBqqeQ1BGNhO7VIcVtgxfcd2y0fHx4CpOx
Y2xE3qOlatl2G9GwKHRoDZaciMUfmfc32c/25FstGsys4x9QpsUtNnZc5LISAT36
jiibihHLUA5pj0xbeWet0/ao8JW/hSxyOtiezv8WKwubOd0SO6NG2iAUEHRfei7I
j0ZPF+yGr8MEf24AgHAXYHl/nxwFfJLvmata2eTTlJWcamBjCtU=
=WmNH
-END PGP SIGNATURE-

Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times

[Mikhail Morfikov]

On 23/11/2018 22:02, Guilhem Moulin wrote:
> On Fri, 23 Nov 2018 at 21:41:42 +0100, Mikhail Morfikov wrote:
>> On 23/11/2018 20:37, Guilhem Moulin wrote:
>>> Did you also add a loop to wait for the block device holding the LUKS
>>> header?  Since the device is discovered asynchronously you need to wait
>>> for it in order to eliminate the race.
>>
>> What exactly should I add?
> 
> Something along the lines (you might want to add a timeout too) of
> 
> DEVICE=/path/to/block/device
> if [ ! -b "$DEVICE" ]; then
> echo "Waiting for device..." >&2
> until [ -b "$DEVICE" ]; do
> sleep 1
> done
> fi
> 
> mount -t ext4 -o ro "$DEVICE" /boot
> 
That actually worked! I took just one pass to detect the device. All errors I
had even before, now disappeared, and everything works as it should now. Thank
you for fixing this. :)



signature.asc
Description: OpenPGP digital signature

Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times

[Mikhail Morfikov]

On 23/11/2018 20:37, Guilhem Moulin wrote:
> Did you also add a loop to wait for the block device holding the LUKS
> header?  Since the device is discovered asynchronously you need to wait
> for it in order to eliminate the race.
What exactly should I add?



signature.asc
Description: OpenPGP digital signature

Bug#914458: [pkg-cryptsetup-devel] Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times

[Mikhail Morfikov]

> cryptsetup-initramfs' ‘cryptroot’ is run (last) is local-top, so before
> your own script.  So ‘cryptroot’ is bound to fail after trying to open
> the device a couple of times.  Please move your script to local-top, and
> maybe add a loop to make it block when the device is not present.
I moved the script to local-top/ and now I'm unable to unlock the system
container. I tried 15 times, and it can't detect the USB device.

> I don't think it was ever working as it should.
It was working well. I even wrote this HowTo:
https://gist.github.com/morfikov/0bd574817143d0239c5a0e1259613b7d

Based on what they told me here:
https://lists.debian.org/debian-kernel/2018/03/msg00121.html

So something has been changed somewhere.




signature.asc
Description: OpenPGP digital signature

Bug#914446: [pkg-cryptsetup-devel] Bug#914446: cryptsetup-initramfs: Opening multiple drives with one password doesn't work without plymouth

[Mikhail Morfikov]

On 23/11/2018 17:48, Guilhem Moulin wrote:
> On Fri, 23 Nov 2018 at 17:27:11 +0100, Mikhail Morfikov wrote:
>> On 23/11/2018 17:20, Guilhem Moulin wrote:
>>> On Fri, 23 Nov 2018 at 17:09:24 +0100, Mikhail Morfikov wrote:
>>>> Should the script be used when systemd takes care of opening the
>>>> encrypted containers? Because it doesn't support those scripts.
>>>
>>> Indeed, but systemd isn't involved at initramfs stage.  At this stage
>>> unlocking is done by our own scripts from the ‘cryptsetup-initramfs’
>>> package (against which you filed this bug).
>>
>> So why when plymouth is installed, the system is able to use the kernel 
>> keyring
>> without problems and hence successfully decrypt both of the drives with only 
>> one
>> password?
> 
> Because plymouthd caches them, too.  See for instance
> https://lists.debian.org/debian-user/2018/08/msg00031.html .
> 
I think I get it now. Basically, what I wanted can't be done (the way I wanted).
If I had two encrypted containers (none of them was the system one), I would
open them via "systemctl start", and systemd would use the kernel keyring and
open both containers with one password. If plymouth caches once typed password,
it uses the password multiple times and that's why I don't have to type the
password manually again. But in this way plymouth doesn't use the kernel keyring
-- that's why the root keyring is empty after unlocking the system container.
So, there are 3 different mechanisms (crypttab, systemd, plymouth) and they
aren't compatible with each other. So the solution would be to use
systemd+plymouth or to disable systemd generator for encrypted devices and use
crypttab instead with the keyctl script. I could use either one, but I thought
this can be done by using only systemd.





signature.asc
Description: OpenPGP digital signature

Bug#914446: [pkg-cryptsetup-devel] Bug#914446: cryptsetup-initramfs: Opening multiple drives with one password doesn't work without plymouth

[Mikhail Morfikov]

On 23/11/2018 17:20, Guilhem Moulin wrote:
> On Fri, 23 Nov 2018 at 17:09:24 +0100, Mikhail Morfikov wrote:
>> Should the script be used when systemd takes care of opening the
>> encrypted containers? Because it doesn't support those scripts.
> 
> Indeed, but systemd isn't involved at initramfs stage.  At this stage
> unlocking is done by our own scripts from the ‘cryptsetup-initramfs’
> package (against which you filed this bug).
> 
So why when plymouth is installed, the system is able to use the kernel keyring
without problems and hence successfully decrypt both of the drives with only one
password?



signature.asc
Description: OpenPGP digital signature

Bug#914446: [pkg-cryptsetup-devel] Bug#914446: cryptsetup-initramfs: Opening multiple drives with one password doesn't work without plymouth

[Mikhail Morfikov]

On 23/11/2018 16:14, Guilhem Moulin wrote:
> Control: tag -1 moreinfo
> Control: severity -1 wishlist
> 
> Hi Mikhail,
> 
> On Fri, 23 Nov 2018 at 16:03:32 +0100, Mikhail Morfikov wrote:
>> I have to type the same password two times (one for each drive) when
>> the system boots.
> 
> Does ‘keyscript=decrypt_keyctl’ cover your needs?  Cf.
> /usr/share/doc/cryptsetup-run/README.keyctl .
> 
> Cheers,
> 
Should the script be used when systemd takes care of opening the encrypted
containers? Because it doesn't support those scripts.



signature.asc
Description: OpenPGP digital signature

Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times

[Mikhail Morfikov]

Package: cryptsetup-initramfs
Version: 2:2.0.5-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I have the whole /boot/ partition on an external USB drive. I also have LUKSv2
header detached from the system container and also placed inside of that
external
USB drive. So, to open my laptop, I have to connect the USB device (my phone)
first. In order to make this work, I had to write some script and put it in the
/etc/initramfs-tools/scripts/local-block/mount-boot file. Here's the file.

===
#!/bin/sh
PREREQ=""
prereqs()
{
   echo "$PREREQ"
}

case $1 in
prereqs)
   prereqs
   exit 0
   ;;
esac

# source for log_*_msg() functions, see LP: #272301
. /scripts/functions

# Default PATH differs between shells, and is not automatically exported
# by klibc dash.  Make it consistent.
export PATH=/sbin:/usr/sbin:/bin:/usr/bin

[ -d /boot ] || mkdir -m 0755 /boot

mount -t ext4 -o ro /dev/disk/by-uuid/6f3b0020-0491-4a12-98ca-c97a7a80f5b7
/boot

exit 0
===

This setup was working well for some time, but it's not working as well as
before, and I don't really know when it exactly sopped working. I thought the
situation was temporary, but it looks like it's not.

When I boot my system, I get prompt for password, so I type it correctly, and
my system is unable to open the encrypted system container. No matter what I
do, first 6 tries always fail -- I can type whatever, or even left it empty and
just press enter. The 7th time works, and everything backs to normal. For
some time I thought it's a really nice security feature, but I'm getting tired
of it. :D

Looking for some answers, I found this:
1. When the system with detached LUKS header boots, it looks for the external
USB device. The device isn't available when the first password prompt shows. In
the earlier version (when everything was working well), some errors were
printed on the screen when the system was probing for the external USB device
(because of the /etc/initramfs-tools/scripts/local-block/mount-boot file). It
was saying something about "Error LUKS header missing" several times, one after
another till I got the password prompt. Now, only the first error is printed,
but after that, it stops, and it doesn't probe for the USB device till I type
some password.
2. When I type 3x the password, I can see "Running /script/local-premount".
Some messages also are written to the screen, and then I see "Running
/scripts/local-block", and boot hangs again waiting for another password.
3. Also after those 3 bad passwords, I get the message "maximum numbers of
tries exceeded". Usually this should lock the user from typing another password
for 60s or something, but in this case it doesn't do that.
4. After another 3 tries, I can see another "Running /scripts/local-block" and
some other messages are displayed, including also another "maximum numbers of
tries exceeded" also without preventing the user from typing another password.
5. So, after those 6 tries, when I try for the 7th time, it finally works, and
my system is able to decrypt the encrypted system container.

So where's the problem? Why it's not working well now, and it was working in
the past?



- -- Package-specific info:

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages cryptsetup-initramfs depends on:
ii  busybox 1:1.27.2-3
ii  cryptsetup-run  2:2.0.5-1
ii  initramfs-tools [linux-initramfs-tool]  0.132

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.187
ii  kbd2.0.4-4

cryptsetup-initramfs suggests no packages.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlv4JTkACgkQzQRoEHcb
ZSBcQhAAzQYz4+h6a8MLX9yUoFJipoYq/PStms8goCiUI09e1HUDVpvt9dknJRBs
eZrijfd08VfSiMqz7CrHyIArvDwAtLCajW8k/TWKDH9wTSA+27GZXSJPPOUUnk9H
zXCeAuJAX4LUasyOrTHTMDrM9w842xyfKEs6TwZf/lxi+9EuIRFTLuJQnlpTT3bv
t5oKC5j+rFgOxsp7XKuZnxi82blb8EAsFNYTJb5f4ZKnP5qamUU1yaHV/o1tzisF
LgtFCRkP03NUh1M4lzGD70Tp6A+Bc8O9H/kMrBx2yWVg5AN/439uWsDIBk++4kTC
I4FuzPcWnChtZMjO5HlFME59k0ET4hEh53Vf9So3PSbcWEFxCcG9IKymOx7IWO64
v9Yb3CHDBB98UcdRw9Rbr9VexVi+EqsoywP2eUPjBExEjh9jDcdCYjac9rplZUOT
qS2vHfy93kWl7TOo//o5qvVjjYpIrOBQWItFR3UrQuZHdQbx0zoNL/GHXO0l2e81
yL7RZRwXlVk0A+XJODnZz4b+qsdfkCR3LKwfqdlhbLmpul9CwKlA3bhV3c55BqXL
oADUWk9ve5uzsu+9RLZ05hdmz361aXsIthky0D9S1PnohqpnvyvaAMYCyZR/DGa7
zsUQnqzEaYNqXxSqTWyFHaLGZV7DF3P/bwp6t0M1smHbWoOH+tU=
=szAv
-END PGP SIGNATURE-

Bug#914446: cryptsetup-initramfs: Opening multiple drives with one password doesn't work without plymouth

[Mikhail Morfikov]

Package: cryptsetup-initramfs
Version: 2:2.0.5-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I have two HDDs and each of them have one encrypted partition (LUKSv2). The
same password is set for both of the drives because I want to open them using
only the one password when the system is booting. This setup works well when
plymouth is installed -- I type just one password, and the sda drive is being
unlocked and shortly after the sdb drive will be also unlocked (automatically).
When I remove plymouth packages form my system and regenerate the initramfs
image, I have to type the same password two times (one for each drive) when the
system boots.

This is the /etc/crypttab file:

=
sda2_crypt  UUID=e017ac1c-c46f-4b3f-a319-e1f5ed15144a   none
luks,header=/boot/headers/sda2_wd_black_256g
sdb1_crypt  UUID=66861f93-9fc7-46f9-b969-1ade25dcb898   none
luks,header=/boot/headers/sdb1_wd_blue_1500g
=

Systemd-cryptsetup-generator generates files in /run/systemd/generator/ for the
two containers. The content of the two files is similar (only UUID and disk
numbers are different). Here's one of the files

=
# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-
cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
BindsTo=dev-disk-
by\x2duuid-e017ac1c\x2dc46f\x2d4b3f\x2da319\x2de1f5ed15144a.device
After=dev-disk-
by\x2duuid-e017ac1c\x2dc46f\x2d4b3f\x2da319\x2de1f5ed15144a.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
KeyringMode=shared
ExecStart=/lib/systemd/systemd-cryptsetup attach 'sda2_crypt' '/dev/disk/by-
uuid/e017ac1c-c46f-4b3f-a319-e1f5ed15144a' 'none'
'luks,header=/boot/headers/sda2_wd_black_256g'
ExecStop=/lib/systemd/systemd-cryptsetup detach 'sda2_crypt'
=

Since systemd v238, the option "KeyringMode=shared" was added, and hence the
service file has access to the kernel keyring. But for some reason the kernel
keyring is probably empty when plymouth is not used, and probably that's why I
have to type the same password two times.

When the above service is started manually via systemctl, I can see that it
uses the kernel keyring when I type the following command once the service was
started:

# keyctl list @u
1 key in keyring:
237476127: --alswrv 0 0 user: cryptsetup

Is plymouth needed to have this kind of functionality, or something is wrong
with... something?



- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages cryptsetup-initramfs depends on:
ii  busybox 1:1.27.2-3
ii  cryptsetup-run  2:2.0.5-1
ii  initramfs-tools [linux-initramfs-tool]  0.132

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.187
ii  kbd2.0.4-4

cryptsetup-initramfs suggests no packages.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlv4FsMACgkQzQRoEHcb
ZSAVvBAAjMcxDzoYSrdqJ4a63JkXz+u2heAP6wmcA7mYG/MA3HcfaKcPcd7DWlJk
W4yq2WsCaZC4A/yfVf/dCHBfQIBUFO/tf/je3HI7ietQWE7xXJ/zt/moXdjiZLin
TlklhRA8zxm/d/bgwidQa7hon1nexlXK9quoiElW7Htkrla2ezyMJsAWX8/nlbjH
w37qbFp7+5dRKfLEh9mh07ViqbSvuTcfjdHrVT7kZ5nFjBMDiu+3uVDY0FDehvVL
hu8PVayp6ypRUKXrPD0HKPmDsKBzY6LvKgwC5OfBW1itHGNeHctjCOmSdwFg+iiS
m2z5fRyvqmj1Z6y/9Kra+uy1usg8BacqRXNa25pKJi0+usqzWLdkMgGC7KhjXcFJ
Zechs0MUYUY0hO1ZjWxwf7cpTcJiPhG2DGSwgdfDUg+DfQnvzLmJ1UyNVlET8WG3
SgT26UeEDMkpZyG5+rzCUUXC1aijhQ6YwcgXtw0WyqSZmpvklf2E9NRAHcwf3HNd
UjuxzVeEfcwxZUBdYE/04CvSj9rk6pZoCZf/oUnUoGPGLIZt5xClqFkJwHTpeykE
6UvXcaaTsVZhDhKEBNq2Oia9JKKGUFwguaXS/qCatc5fE0vyAYIkWGiyUnpaT7hO
ElvG4eTg/yLqpQ1dCF9Cq1U1taPAr7a4QDi5s7x+2ITCpkbOXDs=
=lGpf
-END PGP SIGNATURE-

Bug#908037: usbguard: Please don't enable the usbguard service after the package installation

[Mikhail Morfikov]

Package: usbguard
Version: 0.7.2+ds-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Please don't enable the usbguard service after the package installation. When
enabled, usbguard simply cut off all usb devices and hence the keyboard/mouse
don't work anymore. The only way to recover from this situation is to reboot
the system (via the power button) and switch to rescue mode and then disable
the service manually. Other solution would be to allow all usb devices by
default.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAluPrvYACgkQzQRoEHcb
ZSABaQ//Z5WFbOU+XQqb7CauykXXCFgzBKfJynkv+0xVtk4JariC223W0pBX661V
Xsexb0xYUCrczO7ZDnx2848U6NQnX6L4vegYMWFZrdVwE9+iBgGhtynzXiLiw7Eb
9w9a0L1wW0UEnx4TC0LJfF3n7Fkyi4W4WdFVad71wwHcxSoZVpKHNaiEJOgayTgW
UBp+Git/x+2nkfwch0p1ackcuHjVEGYTocZNooVUt1Xajt4CdESakHXwYoh5EVA6
eDAHjxlWirN7KuN4DyG2CmuLrbxXzWdwu5zQcIsPFP4aZx2PLnWAb3dCqDHXGKHL
/hA2cPOnwbql/bKZBgofl/9ctGaXONL4IwvDhk2xOKdxXtTj2k9zSWCCFqu+tall
OuavFJpvcsWRWeinUQRQ+39CQZVS2R9MfLwi/iNNaPnTZxksALzBTil9AXReksok
6Ze0WCkuQWi3vWOXgNXnU3AfgdrT11BHg+fEqRypYKgda0Dgxls0WohtyKF2C7cv
rfB3Hm6KbIh3tdWot90O1fZb7MpqrdEb7LEHG/lgiEzxPj/SlSZjVYUXoJhs/h+E
+h/MHNTqmPnKEmUlsgu+6IAiehvrUNhV8Tgtcq6hwnPAv6sHI5kxQ3wJJqmHBchs
YZYk5pEyi806Co5OnyREya8L13skEu46b0QpxPDrPD46Fg//rHc=
=V8xR
-END PGP SIGNATURE-

Bug#902547: pulseaudio: Failed to open module sc4m_1916.so: sc4m_1916.so: cannot open shared object file: No such file or directory

[Mikhail Morfikov]

Package: swh-plugins
Version: 0.4.17-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

probably after the recent update of PulseAudio, the sc4m_1916 module can't be
loaded anymore for some reason. It was working fine before, now I just get the
following log in the terminal:

pulseaudio[2698]: Failed to open module sc4m_1916.so: sc4m_1916.so: cannot open
shared object file: No such file or directory
pulseaudio[2698]: Failed to load LADSPA plugin: file not found
pulseaudio[2698]: Failed to load module "module-ladspa-sink" (argument:
"sink_name=compressor plugin=sc4m_1916 label=sc4m
control=1,1.5,401,-30,20,5,12"): initialization failed.



- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages swh-plugins depends on:
ii  libc6 2.27-3
ii  libfftw3-single3  3.3.8-1
ii  libgsm1   1.0.13-4+b2

swh-plugins recommends no packages.

swh-plugins suggests no packages.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlszxpIACgkQzQRoEHcb
ZSAUpxAAwI/wQ35KB2vXo7C/+sRC7IiIVM9AhiyCOW8M3XRZpiev5RLuFmVivqqu
RFDEwyYNRwGo8OpRRvGjPw8xKQIOYLiXiRTHgr09SdlZAsrtKv/fO0hS5ni2oOwW
Greod+3WolxphzPr3KqYR9lhfwZtpuwsEwv7hIsjYez0hSqgRWKksHLBuIbAOJ/8
LIzeVKSZ8mxkTyxFYgWK9SPcp583RtVk3nYHM5xkdclofTojVWakY2GcaTDDWKgA
LXJheIDBYxc1vczZM1MvbBRemlEOyX7LKNFLpyt0F9arPk9rXljeSxPqj31N/L3a
wBJXi0tEz++fZJI2VwpAPB24ucg8BohYxIEtNhgz4kG4rpGBlvGTUZB/8vgiPFy8
CQpOpLzipvY0ILjANDWwEv4evrtOo/ITZne6ic8VZBWoD3siZKVE9BIiYAka3Mf/
xph/Js47A8QVItxBfg/p34iFnZfTo/W+9pUliO1N6tZ8tsvF2MqCM/gdkTjA9V8f
8kgl+0sY5KFizWfIAHmwisnN38BQbjO8fTFsEI7dt2gft1IFA9XFjBCfjs9ZP9dh
T9n8+JwdUsxHpc4UCEQw/J9I0ePtnFGYeCmYeBMwJNBU1MPaLtnYcszGoahtkGpi
fjUpU12QC/UaEUhh75CW4+FkC11Oq32F2wpSBIMaixukixbJjPA=
=0uhr
-END PGP SIGNATURE-

Bug#900101: udiskie doesn't start because of "No module named distutils.spawn" error

[Mikhail Morfikov]

Package: udiskie
Version: 1.7.5-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

When udiskie is started, it gives only the following error:

$ udiskie --automount --notify --tray --use-udisks2
Traceback (most recent call last):
  File "/usr/bin/udiskie", line 6, in 
from udiskie.cli import Daemon
  File "/usr/lib/python3/dist-packages/udiskie/cli.py", line 26, in 
import udiskie.mount
  File "/usr/lib/python3/dist-packages/udiskie/mount.py", line 8, in 
from distutils.spawn import find_executable
ModuleNotFoundError: No module named 'distutils.spawn'

This can be fixed by installing the python3-distutils package.



- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-1-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages udiskie depends on:
ii  python33.6.5-3
ii  python3-docopt 0.6.2-1
ii  python3-gi 3.28.2-1
ii  python3-pkg-resources  39.1.0-1
ii  python3-yaml   3.12-1+b1
ii  udisks22.7.6-3

Versions of packages udiskie recommends:
ii  gir1.2-gtk-3.0  3.22.30-1
pn  gir1.2-notify-0.7   
pn  gobject-introspection   
ii  plasma-workspace [notification-daemon]  4:5.12.5-1
pn  python3-keyutils
ii  xfce4-notifyd [notification-daemon] 0.4.2-1

udiskie suggests no packages.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlsJD8kACgkQzQRoEHcb
ZSBFSg//WZDN6Nd1bsEipQndVCXRHhyy88oofk1eWH1xQQPDXhNc3qF6sZFQW+42
spEfwxc/x0SUBxKjIa7paV+qlng5aPTXw/tr5UezS0vTF2s0hxyon3aDZC+zsOla
m3+Veshwl/Zyv9jLEveE5ogIbfuEESiy/piUBVrQCA9d95UUxudoABcrHhSuHFte
8pQi0IcxJzc2qfqWWAv/GVudygPkItfdaEpvZDPpLD4Gt9tsqryYTXPKuU5//aMQ
Yp3aWRIGcwKDZbyCZjkN4OpjHEYW9yF+F2cbS7ryoHaU5p1ibAQn21IiUtP5zXjs
mRDnybVVfHSL61uQ/FU9/X0NtLyJP2ieLE3eMkIc/cN6qZrOlnUnBsmLu8hSk8q9
XVQAAsXzF85wNok45zKDMYIf20K7NNKibyxWTAegZeLeLGxk0Ph4gN2oqOcqXQNA
xjZPdYsPFgzj1CQpVVBnkwX7V9K+JJm/y7Z9Cq8xz7SzofVDCEDX90MST39pu2qF
kdJcYahd3oA1m3Cf9C4yNLntvE02C/B5LJhpV60Na2jzwzLO2o+NmhcGDyAdXqL6
avJ1odqiSdo4249/bsYQqQuAWix3FyGLd5ey6em8Tmcw2kSJY6xZy/BUbOpnX8L/
ZpiEAauAtdtNKnibertCaKuKFpca30iGemBVb53HOSe2YCQlfzg=
=XhYI
-END PGP SIGNATURE-

Bug#897687: fixed in kwallet-pam 5.12.1-3)

[Mikhail Morfikov]

It looks like the issue is fixed for me, thanks!



signature.asc
Description: OpenPGP digital signature

Bug#897687: libpam-kwallet5: kwallet stopped working under Openbox after libpam-kwallet5 upgrade (5.12.1-1->5.12.1-2)

[Mikhail Morfikov]

Package: libpam-kwallet5
Version: 5.12.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I've been using kwallet on my Openbox for some time now. It was working well,
but after today's system upgrade, kwallet doesn't really work anymore. When the
libpam-kwallet5 package is downgraded to the previous version (5.12.1-1),
kwallet backs to life, and works as before.

This problem only concerns Openbox. When I checked whether Plasma5 has the same
issue, it turns out it doesn't and in the case of Plasma5 everything is just
fine.



- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-1-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages libpam-kwallet5 depends on:
ii  libc6  2.27-3
ii  libgcrypt201.8.2-2
ii  libpam-kwallet-common  5.12.1-1
ii  libpam0g   1.1.8-3.7

libpam-kwallet5 recommends no packages.

libpam-kwallet5 suggests no packages.




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlrsLjMACgkQzQRoEHcb
ZSC0Jw//cRMSwmkqN2YlLlJjzbd7xIodqxFE1F6mT2ml2BYmbIefNO1veNoIeB7I
GOuNU/2uGVyC4NgCO++ylAq2fouqGO6KLBSC3Av55F8iwQaDtvS1NvR50veWFOpp
WweGcKaJFIzzD20f+dQai6U4t1wC6me26RPH2QQzzBjC6xYipW0hPTM9xP1OPL0a
moUwh6ng80jx50WR7rUYEh/f9V/SmfkxJSLWSQVpJuBivuaTngR5hG0Muuadvpa5
90OQC9Vrt6ZAVV739L2K9gIzabY5qyAF5VXMfhcz6PbSMK4qvShUPYfJtoO3r9EO
4O7EYM5Q/al0eW7i27oaNvnEBzfWpbmHanKyNi/tQIMqg6bDRB2xX23rtAhS7a5k
1uVn0Ki8mTxwRAJaPbJNi9KzC+1IYFkj4xg6/1Hq8C771aG+iK35MBz6nYtlKvCU
ppDVThChgwqU7bIUkXUIX82PoG/WBcXdwI9n2Bu8VSxIB9QJn/fCDZ1XU73zfGer
cM8OhHx83/ARsihEaX4RbMkz9epTFYRPERwzPGYmXFkV72HmMPczORE9g4ItZ0LI
hGD4xDo3ED3Y3chqSmNIGsuEx1lbL2Nl566VfXnCiq2YpgrkRy3Q+hhgKOuD8K5J
brCz0XFjA7fzoovaIY5x/o+nNcA9JDpsV0iZxqk8IimmbQeyX/8=
=J/US
-END PGP SIGNATURE-

Bug#890798: cryptsetup: Using luks2 with argon2 PBKDF produces an unbootable system

[Mikhail Morfikov]

Package: cryptsetup
Followup-For: Bug #890798

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I just converted LUKS1 to LUKS2 and added another keyslot with Argon2i. I
tested the new keyslot, and it looks like it works without any issues now. I
also wiped the previous keyslot to be sure. I don't really know why it
failed before.





-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlqO7NsACgkQzQRoEHcb
ZSCFSBAAn3hI1lk/K1JeAaxNlV0OjDe9XtR52du+Jat+jo2uA7dTGEW22KmR+sur
4dW97i9AgbtoK0i61IlYbklsdhgcg4SC3cLrRt83400rQpV66mNmqL0H+mmMfjvj
9fqoHV98uEQMGxF7wig2EtGmvnV+2fYLXA3WmNAIfIfnfZBSYnDxa/J4BwKHdQYU
UDpKHyOZID7MgRGKINWEaReugN785YX2gnQg7UqIdETDfrCFlwAI96IxZOQqvNIT
AqggMHKaYNGZtb982wmnaBEwZIR+9l1D2GGgP+pMxUonb1aDQc+c5Ljbe2vwEGfW
JZa6W1QsJjx1DK1Jtfp1JUsH1rSL6dAHwHFQQ+Dxxm9pqT5dNpmre3Pkrgw2lDTn
Rk7kP5UHfZEv1btVYSh5BZI3x6Xlyly9GRlNnRdltMB+LCgGzLdXoY+chrN+7QWB
7BIcyeqZikXo9FM8HYmh2Ul9GGUfZCvaW2jtNQpk3JHW4i7My24+VcRjuEI4Eu23
QyV0/Ff5vZyX4N9l4r6NxFj/0nFnYgfQ0yipx2Tsnj2rWyzJ6Q7THSjaa5/LpCZg
OrY8CHyZt5ahEv9ObppWpCv/gnHmU0g9zMgAvinNbw2C8XQzUF73hCO/d+20kWWr
Ndva8h1uSU1V6l+VBeE5+aDswqIC/1xAuDW30X1US2ExnxGvezY=
=w7iq
-END PGP SIGNATURE-

Bug#890798: [pkg-cryptsetup-devel] Bug#890798: cryptsetup: Using luks2 produces an unbootable system

[Mikhail Morfikov]

On 2018-02-19 01:44, Guilhem Moulin wrote:
> Control: retitle -1 cryptsetup: Using luks2 with argon2 PBKDF produces an 
> unbootable system
> 
> On Mon, 19 Feb 2018 at 00:02:02 +0100, Mikhail Morfikov wrote:
>> Since in Debian Sid we have a cryptsetup v2 for some time, I wanted to
>> wipe my current system and install a fresh one in the  LUKS/LVM setup.
> 
> Note that LUKSv1 devices can be converted to LUKSv2, no need to wipe the
> whole device.  One needs to add a new slot to change the PBKDF from
> PBKDF2 to argon2i, though.
Yes, I know about this, but I wanted change the entire disk layout and needed a
fresh LUKS container anyway.

>> cryptsetup luksFormat /dev/sdb1 \
>> --type luks2 \
>> […]
>> --pbkdf argon2i \
>> […] 
>> The LUKS2 container could be easily opened using that livecd (with the
>> cryptsetup and lvm2 package from Sid), but system was unable to boot
>> with an error saying something about missing libgcc_s.so.1 .
> 
> Looks like we only tried unlocking luks2+PBKDF2 unlocking at initramfs
> stage.  argon2i and argon2id use pthread_cancel, so that file needs to
> be copied to the initrd.  Done in 9a70b2d.
>  
>> I tried to fix this locally and added the missing lib to the initramfs, but
>> unfortunately this step fixed the issue only partially -- the system was able
>> to detect the LVM volumes but it was asking to type password for the 
>> container
>> again and again, and the boot failed ultimately.
> 
> I was not able to reproduce that, even with libgcc_s.so.1 in the initrd.
> Could you start the boot script in debug mode so we see why it loops?
> 
> https://wiki.debian.org/CryptsetupDebug
> 
I had to create LUKS1 container because I needed my system to be fully
functional after the weekend, but I can try converting LUKS1 to LUKS2 and see
what's wrong there when I get some free time, if of course the problem still
persist.

>> I also found this link that describes the exact same issue.
>> https://bugs.archlinux.org/task/56771
> 
> cryptsetup auto-creates the lock directory (chosen at compile time)
> assuming its parent exists.  Your link mentions 2.0.0 which had
> /run/lock/cryptsetup for locking directory; it was a problem since
> /run/lock wasn't present at initramfs stage.  OTOH 2.0.1 uses
> /run/cryptsetup, which should be created automatically.  I just pushed a
> change (e31db51) to create it before calling cryptsetup, in order to
> avoid warnings.
> 




signature.asc
Description: OpenPGP digital signature

Bug#890798: cryptsetup: Using luks2 produces an unbootable system

[Mikhail Morfikov]

Package: cryptsetup
Version: 2:2.0.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Since in Debian Sid we have a cryptsetup v2 for some time, I wanted to wipe my
current system and install a fresh one in the  LUKS/LVM setup. I was using the
official Debian live images, and of course I installed cryptsetup and lvm2 from
the Sid branch. The next step was to create a LUKS2 container, and I did it
with the following command:

cryptsetup luksFormat /dev/sdb1 \
- --type luks2 \
- --cipher aes-xts-plain64 \
- --key-size 512 \
- --hash sha512 \
- --pbkdf argon2i \
- --pbkdf-force-iterations 2 \
- --pbkdf-memory 1048576 \
- --pbkdf-parallel 1 \
- --label debian \
- --subsystem "" \
- --use-random \
- --verify-passphrase \
- --verbose \

The container (and the rest of the setup) was created successfully, and I
installed a Debian Sid minimal system using debootstrap. I did everything as
usual when I install Debian in this way, but when the system was about to boot,
it failed. The LUKS2 container could be easily opened using that livecd (with
the cryptsetup and lvm2 package from Sid), but system was unable to boot with
an error saying something about missing libgcc_s.so.1 .

I tried to fix this locally and added the missing lib to the initramfs, but
unfortunately this step fixed the issue only partially -- the system was able
to detect the LVM volumes but it was asking to type password for the container
again and again, and the boot failed ultimately.

I also found this link that describes the exact same issue.
https://bugs.archlinux.org/task/56771




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlqKBd8ACgkQzQRoEHcb
ZSABGg/9F2w+h+WIByu2XrW2IEca99xTcW6wwoV9NRZrhZGe5+vqlucXXHfaOy5Z
pmwvhwW6yyM9huC2h6+WvvzUvAdTD53ip8WMavzvfNjhRtKjb2v8/oZTJty8qVdj
EenoWq9ddJeNHWzC6zC9OKcDfoNseDV9hIeCwHMmTPUIhGgEI7Aa8Ht9R4cNQ4ke
XDpd3Jes5vllO4GCmJfz9np+wU+Stw6znvr9ucfiwv0E/QefbXIICP9nqZKtScjI
BQ3QtWsmoobXNaqY7eWTO3ZrlHclq+IJ1Qd8Ya7bIAJN37RTlecnG6PoG10Zc/50
BLP9g9nQaeXQdbdd1Tuph3Ub+mzFQzFNKhdqD4LjNbdymqyl0q8xPNsThW8PhoxU
Z5DqJN4HOtWbwxW+F7zyF2nQGenjS+OpM9m15YKpKXyaqQpn5snTuHmqvVP4H0TT
5pP7XZVoSO5qHe3y603cCc1FwMSD2Tq0cucc4n34qQRFlAFPs63WNsmNNWj9GyNf
RFnbMUOycvRDHpN/UOBTZFMbkMHIKp53XOg6Ic/dGB0gPN72ky0zKVbIqnpRxBKS
AixfU0imRLMeB1VbJugbaF11KZ++ySD64vc/MqK7ci726qrISZ32AW1GgbUohQM8
4SUh5OseubrQW5yTTc6bF6eXMHZsLCZm9PewSDrwol//UL5Edq4=
=osB3
-END PGP SIGNATURE-

Bug#833448: libapache2-mod-evasive: Wrong prime number. Should be 3079 instead of 3097

[Mikhail Morfikov]

Package: libapache2-mod-evasive
Version: 1.10.1-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

In the documentation and in the evasive module config file, there's a directive
called DOSHashTableSize . According to the documentation, it should be a prime
number. But the default number is 3097, which isn't prime. I think it should be
3079 instead. This is a prime number, and it's similar to the 3097. I think
someone switched the last two digits accidentally.




-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXo0JPAAoJEM0EaBB3G2Ug1RsP/3nXxJsaUCDR78hdou+BqbIp
cDO6TpbCKNVojnWp/cPlA+cBWh6HndHFrtJsP5vgoZ2DV32HVSp9I4b5h5fb+xt6
K+X6gyQ6dnbaT9LNsB7JB0BLBGqzP2VUUu7sXq8n8Y3siGzVOzgyOjFaixPWIR6Z
N/y+wzPZ06EuxDTzvNWDzKFhxAPJ0KlmCvOfG4NJ+XGn/Jc1lidHJaPQQIlBu2fm
6HtXrnK6xoJnT6LUkZeghpwhmI9yG6wTRKL1s7gAzFnlJomLLrC6BVYkkSGtTTJ6
uRJUBeAOL+rfFGVFpIFMyJGbXt6QQXO06krdG1hniceGSD6LWycOUWEiI3W+NwdF
jml4ZuPh9w9kfJQJy1H3ma8tWh+d77VpxWGq6eFCFtcSw9lDVq7REAIalAQEPwMp
nYQrrPs8bCOrLk8LjZv/Fmk+P4wIXFgRcg/869nnUC084qRB+UgTProhqj+mITrf
EXaoELXnFbszIGtia5UbccuQwQRE5+jqk51qVlx86SNUVhhUH2GWw8yafSxrK+E4
XY5Efls8uu6LDsppJkCIjk/sN1pV4Qe7INKGaDuQ/yvq8jTngWEHVE92FQLZ+vyF
tnsILffPhizB2eInbCPDrwbVdgm9YFzpisvRUdIQWKvQBTUcNjgDO6mmv8V4+X4N
tz+pZdGIKKOJ4X7y/iRM
=crfH
-END PGP SIGNATURE-

Bug#830668: linux-headers-4.6.0-1-grsec-amd64: Add metapackage for linux-headers

[Mikhail Morfikov]

Package: linux-headers-4.6.0-1-grsec-amd64
Version: 4.6.3-1+grsec201607062159+1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Debian has two packages that can ease the upgrading process of its kernel:
linux-image-amd64 and linux-headers-amd64 . But in the case of the grsec kernel
there's only the linux-image-grsec-amd64 package. Please add linux-headers-
grsec-amd64 so the upgrading process of the linux-headers-*-grsec-amd64 package
would be easier.




-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXgfsQAAoJEM0EaBB3G2UgxgkQAJPFpZIOFEvySunoXAuAwwhY
Q30OMITfvWu8KvZ8P7yTA0O938jfiNKGhhKjWsF9NLrl4BC6Gy62ebZ52uw0tKTU
gWCMJtMKA9yjFpoXIF+JJ5Ul1Eu62H8T5o1UxQbotxcdoYsPGaZDQfVV8KnJcZTS
28vRgacGpUkQUf7k3xnr/be2kKQZ7scTxrN6IeSiVIeyuXjklk7OpHmV1Z4D9CeT
kkorRud4EPxm1ylCUl+js3cNUkgMrsLjMfHZKJxAPXGWgtRRNqHDObMWaOgbgMXZ
Z3sIj6OUaswLu4lwfCLrtqVcQUdeNV9Q5YO1p7GpPeuz2YpYx17dlGkyVRjs+yz3
lSrtqm9WjalCtf+ABPnW5ssQfxi1vjkUdcifBnxsf4mHMMGdODWSZilkAXKR1lbf
Afeo37UbbcIiSDn0zR8tevhalX/TwfPFZFfg5Qs6v+AF0JnsJ4z6fsv18MDqJ/rt
k2/3/QNgmOxsSGjW1Ynx6EBlG8zyVJ1Wjg8+0WE7QrjaUEZCcLW7SG5b0lEXCTsN
oXC5XE6znrsgVtq2jXlQ6ZXhKmIgJPbb4+LZiu1qmqhI1nymOVWoNRabs5sw0BHV
nAIijZNJqVlUslZlEx0PCIuDBWMbzt2km2emPIoEaAoLm7p0mBgjO0ymjvKMS99h
vPnjLxtxxYHbRGzUZWSM
=tqNU
-END PGP SIGNATURE-

Bug#823891: wget: segmentation fault when terminal width is small

[Mikhail Morfikov]

Package: wget
Version: 1.17.1-2
Followup-For: Bug #823891

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The bug actually occurs when the width of the terminal is less than 50 columns.
When the -q parameter is specified, wget works just fine even with small
windows.




-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXMcMyAAoJEM0EaBB3G2UgfNYP/Rodsn8nw/GRveAjT0zJ4JGk
G1VfKXeOAqSLYTNwLAxXWmOn67rDvIPWezTnyBF6MqUHFtCY9DaOyWWzGVQwh8GT
tDHawdEK9kFZ8QggXv+YWF7qCOvY5T+64E5tXE5wAYLI3QyncX6KrNYeLuqkzKB3
55KvJl6/dNFNNpiEfKk4EQ19yBcECF5AjXRGK3/+FtSZnzgmiROFWIS5jeBOeiG7
4SyPqFNCOixS8oqGZaRwHq0oRRDkMacvleB0nObg9yp8CElGjZa/qT5uZ1F99A86
eePaY23ysZxqA2t0U3Tj7IGhUHunYiJsEIBLNH9MkNUKQYSVw87EU/7Gxzsutf2c
h5L4FQutu0+dAdoHdP3N0so/oCHCtL1uiaFaop+jkKEW0nANZ2LdazrpmkQFB3+z
mMpddvxQCAnMt6NmWks9dDG0l3q8JsKRM4lhS2+b/SCEl/iLVxDk9+H7lC8KVKSF
bWR1rfYHnWCYKnuHkaU2HN+UVoo2WGv6x+hAkz1x6d2R4XeC7SQhEmG9Sy0YPYjU
7gkcccJ4RMlptqmgvhmSUlR4bbiCFJEeXgri5EhEwozjy87QyGeYOTSwHhsT/vZZ
at+m2iFhVT2/mihlqi6EsF0vbHA9JtGjlvIsF7f0P6P3lgKBFLS5Zin6jk5KD64M
a7A8cf1KVPriGqMB5AuD
=hhPP
-END PGP SIGNATURE-

Bug#823485: kernel: brcmsmac bcma0:1: START: tid 1 is not agg'able

[Mikhail Morfikov]

Package: src:linux
Version: 4.5.2-1
Severity: normal
File: brcmsmac

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have the following WiFi hardware in my laptop:

03:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11bgn
Wireless Network Adapter [14e4:4727] (rev 01)
Subsystem: Hewlett-Packard Company BCM4313 802.11bgn Wireless Network
Adapter [103c:145c]
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at 9240 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [58] Vendor Specific Information: Len=78 
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [d0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-38-ff-ff-02-c1-c2
Capabilities: [16c] Power Budgeting 
Kernel driver in use: bcma-pci-bridge
Kernel modules: bcma

When I'm using the wireless connection, I get lots of the following errors:

...
kernel: brcmsmac bcma0:1: START: tid 2 is not agg'able
kernel: brcmsmac bcma0:1: START: tid 1 is not agg'able
...

The rate is about 150/h. I don't know what the errors mean, but I haven't
noticed any problems with my WiFi connection. I think it works just fine.

Is there a way to remove the message from the log? Does anyone know what the
message means, and maybe how to fix the problem?



- -- Package-specific info:
** Version:
Linux version 4.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1
20160424 (Debian 5.3.1-16) ) #1 SMP Debian 4.5.2-1 (2016-04-28)

** Command line:
BOOT_IMAGE=../vmlinuz-4.5.0-2-amd64 root=/dev/mapper/debian_laptop-root
acpi_osi="!Windows 2012" acpi=force acpi_enforce_resources=lax
cgroup_enable=memory net.ifnames=0 biosdevname=0 apparmor=1 security=apparmor
udev.children-max=64 plymouth.enable=1 quiet splash ro
initrd=../initrd.img-4.5.0-2-amd64

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded (currently expected).

** Kernel log:

** Model information
sys_vendor: Hewlett-Packard
product_name: HP G62 Notebook PC
product_version: 059411252710001020100
chassis_vendor: Hewlett-Packard
chassis_version: Chassis Version
bios_vendor: Hewlett-Packard
bios_version: F.48
board_vendor: Hewlett-Packard
board_name: 1439
board_version: 60.50

** Loaded modules:
uas(E)
option(E)
huawei_cdc_ncm(E)
usb_wwan(E)
cdc_wdm(E)
cdc_ncm(E)
usbnet(E)
usb_storage(E)
usbserial(E)
pci_stub(E)
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
bridge(E)
stp(E)
llc(E)
ctr(E)
ccm(E)
cpufreq_conservative(E)
cpufreq_userspace(E)
cpufreq_powersave(E)
cpufreq_stats(E)
cls_fw(E)
sch_ingress(E)
cls_u32(E)
sch_htb(E)
ip6t_REJECT(E)
nf_reject_ipv6(E)
nf_log_ipv6(E)
ip6table_filter(E)
ip6table_mangle(E)
ip6_tables(E)
nf_log_ipv4(E)
nf_log_common(E)
xt_LOG(E)
xt_limit(E)
xt_pkttype(E)
ipt_REJECT(E)
nf_reject_ipv4(E)
ipt_SYNPROXY(E)
nf_synproxy_core(E)
xt_conntrack(E)
iptable_filter(E)
ipt_MASQUERADE(E)
nf_nat_masquerade_ipv4(E)
iptable_nat(E)
nf_nat_ipv4(E)
nf_nat(E)
xt_TCPMSS(E)
xt_comment(E)
xt_owner(E)
xt_mark(E)
iptable_mangle(E)
xt_tcpudp(E)
xt_CT(E)
xt_multiport(E)
xt_set(E)
iptable_raw(E)
ip_tables(E)
hid_a4tech(E)
ip_set_hash_ip(E)
ip_set_hash_net(E)
ip_set(E)
nfnetlink(E)
nfs(E)
lockd(E)
grace(E)
sunrpc(E)
fscache(E)
arc4(E)
brcmsmac(E)
cordic(E)
brcmutil(E)
mac80211(E)
hp_wmi(E)
sg(E)
acpi_cpufreq(E)
bcma(E)
iTCO_wdt(E)
iTCO_vendor_support(E)
lpc_ich(E)
mfd_core(E)
mei_me(E)
mei(E)
sparse_keymap(E)
i2c_i801(E)
processor(E)
ac(E)
battery(E)
tpm_tis(E)
joydev(E)
serio_raw(E)
shpchp(E)
tpm(E)
cfg80211(E)
intel_powerclamp(E)
evdev(E)
rfkill(E)
eeprom(E)
snd_hda_codec_hdmi(E)
tun(E)
snd_hda_codec_realtek(E)
snd_hda_codec_generic(E)
xt_recent(E)
snd_hda_intel(E)
snd_hda_codec(E)
snd_hda_core(E)
snd_hwdep(E)
snd_pcm(E)
snd_timer(E)
snd(E)
soundcore(E)
act_mirred(E)
sch_fq_codel(E)
xt_connmark(E)
ifb(E)
nf_conntrack_ipv6(E)
nf_defrag_ipv6(E)
nf_conntrack_ipv4(E)
nf_defrag_ipv4(E)
nf_conntrack(E)
cls_cgroup(E)
xt_cgroup(E)
x_tables(E)
coretemp(E)
bonding(E)
ecryptfs(E)
cbc(E)
encrypted_keys(E)
parport_pc(E)
zram(E)
zsmalloc(E)
lz4_compress(E)
ppdev(E)
lp(E)
parport(E)
loop(E)
autofs4(E)
ext4(E)
ecb(E)
lrw(E)
glue_helper(E)
ablk_helper(E)
cryptd(E)
aes_x86_64(E)
crc16(E)
mbcache(E)
jbd2(E)
btrfs(E)
crc32c_generic(E)
xor(E)
raid6_pq(E)
hmac(E)
drbg(E)
ansi_cprng(E)
xts(E)
gf128mul(E)
algif_skcipher(E)
af_alg(E)
dm_crypt(E)
dm_mod(E)
hid_generic(E)
sr_mod(E)
cdrom(E)
sd_mod(E)
usbhid(E)
hid(E)
psmouse(E)
ahci(E)
libahci(E)
libata(E)
scsi_mod(E)
r8169(E)
mii(E)
wmi(E)
fjes(E)
ehci_pci(E)
i915(E)
video(E)
ehci_hcd(E)
usbcore(E)
usb_common(E)
i2c_algo_bit(E)
drm_kms_helper(E)
button(E)
drm(E)
thermal(E)



- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')

Bug#820979: dnscrypt-proxy: Compile with --enable-plugins

[Mikhail Morfikov]

Package: dnscrypt-proxy
Version: 1.6.1-1.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

dnscrypt-proxy can be extended via plugins as described in [1] . As you can
see, some of the plugins are really useful. The current debian version doesn't
support this. In order to use the plugins, dnscrypt-proxy has to be compiled
with --enable-plugins parameter. Also the libldns-dev package is needed. More
info in [2].

[1] https://dnscrypt.org/#plugins
[2] https://github.com/jedisct1/dnscrypt-proxy/blob/master/README-
PLUGINS.markdown




-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXD2FGAAoJEM0EaBB3G2UgmekQAJpeyJ98I9p6yhZoss6gAu6v
jiQyFkWmkaT4WoDHmwH402DnGgS9O/JsDqpbNyz0uYuraliUzbjZRTlvlK4UNHAA
Os5roIHpK9LJ84nCnDkbV20hhKIMWBgCj4B10gHfb8IATYIigGCt9te4XX3GYk+G
NNwXIu19tc/jVJCm2ZljzQ802qafCu4IXqaHTs0YxDtwqJlMC1E4qXlMshm3gEOE
oJ/mgmR1b6wl+UcdcGJiAy+bb+cQwCMoygKsMLuChoOr9iP06Y02Dk0ggt3qSipn
3ZcfHfJ3pBFZXPdbNejv+6HvVZ9QC7gGTklFMJDfZ2hsgNOLqJKW8Mukf2a/7Rq7
EgJTmpmRvNJ72PcUNtJ4n3Lw39wbEazpmsoGk1EenGxFfXtlU4tZQbu6HTuVQvmH
s/6MbyFeHRQ1S1/AH2fe18Ct0DY6G4oD/Z+qYiw+5xTwzPDfvlb2Zn5gqhyvH57G
qm7hkSX+r8+Y3jSgLAr1rkrxkpvaNQZ2+mvzHrz3C74BASSY9iKFIE6ZQ60rw1Kg
fF2nxP9lk9y2DDuYYd1jfX5mHBjRPTcf6+rvB8f2QkQUAESirbK44twckiRVYTHL
NICD2Ir/F0+2FO2Kgn1S3YXHmBQ9L7W8yJzBiseospEnXkv5rQ44FpbtT8UPtj55
dQUhCKYeVUjbzc+fVtgq
=xwrF
-END PGP SIGNATURE-

Bug#820620: minitube: Can't play any videos: driver not loaded

[Mikhail Morfikov]

Package: minitube
Version: 2.5.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

There's a bug in the current version of minitube. It prevents this app from
playing videos. This can be fixed by installing the following package:
libqt5sql5-sqlite .




-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXCopQAAoJEM0EaBB3G2Ugh/IQAMuvjjxmVu07jp4xC8iZdcNY
paeJy2X7DMUJE+6PaMVeZSoavQXMpLQRNQv3+yELIAOHy0hG+xSNjcTlwLeAOsZH
do3iCrkrSUJB7UVJJkLClrF9acKmIE1eroKGowcIMGeWa9H8Z+m9hutNkKcJ73t7
BjqZdt/RyROb4NGaKVb2B8mvwO42tPX+8UmroGSYiRGSX78hzzadgcye3FSk8w2Y
083/4ZjWwkdZSZDmQgCBme3wqhaIQ6tTJK8/pPV0LJdw2BgxDJJzjSjyBeT1o2jn
Ex3H9fT5NFByppXBFmiNZtdNaiNU9D2fMQXEmTab3gxIMhWeqm+9mq2qZ9R0TUML
J9joLgYuJpiW2bkRFiNz0EB9RWp2IgJlAeTACNWYa+eO2Ph/b98611qI73ick3Uu
y2PVPigVdm9akWEOOz0Y3n8K3sxfaDq0XcKBaxOXI1Yry8fMM1nzrnjdJbuRqqNg
Sp1fBNRqQ6zV2+N1DirCHAj4dd9nir8xbQQbQV5LHXHdXffkhZAFXVltmWoWHCBd
i7yliEsfMAKGRpLEQVQTLWf2b+KjZNZN6sDOkY8SxaC/jpSnxWz4166d+WowB31c
wuyJL5mhSR59limGHJPImz+ZuTJJGLcjI12EHOn9dzZwrISEhRcKpGjCLoYYFnIa
HVxRzxErCQqTJg29Ep0L
=+zIg
-END PGP SIGNATURE-

Bug#818325: xserver-xorg-core: Missing the mouse pointer after locking the screen

[Mikhail Morfikov]

Package: xserver-xorg-core
Version: 2:1.18.2-1
Severity: important

Dear Maintainer,

After upgrading the two following packages:


[UPGRADE] xserver-common:amd64 2:1.18.1-1 -> 2:1.18.2-1
[UPGRADE] xserver-xorg-core:amd64 2:1.18.1-1 -> 2:1.18.2-1


The mouse pointer simply disappears when I want to log into the system after
locking the screen. After restarting the Xserver, everything backs to normal,
but when I lock the screen again, I won't see the pointer after login. I'm
using lightdm as DM.

I can get the mouse pointer back also when I switch to TTY using ctl-alt-f1 and
then to xsession via ctrl-alt-f7.



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor
Integrated Graphics Controller [8086:0046] (rev 02)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 24
-rw-r--r-- 1 root root 1351 Jan 20 17:52 10-keyboard.conf
-rw-r--r-- 1 root root  820 Jan 24 16:09 10-mouse.conf
-rw-r--r-- 1 root root 2024 Mar  4 16:10 20-monitor-intel-dual.conf
-rw-r--r-- 1 root root  697 Jan 20 18:03 50-synaptics.conf
-rw-r--r-- 1 root root  852 Jan 20 17:51 90-serverlayout.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1
20160224 (Debian 5.3.1-10) ) #1 SMP Debian 4.4.4-2 (2016-03-09)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 15362 Feb 14 12:37 /var/log/Xorg.3.log
-rw-r--r-- 1 root root 30608 Mar 15 23:48 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 31519 Mar 15 23:49 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 30290 Mar 15 23:49 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 41041.245]
X.Org X Server 1.18.2
Release Date: 2016-03-11
[ 41041.245] X Protocol Version 11, Revision 0
[ 41041.245] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[ 41041.245] Current Operating System: Linux morfikownia 4.4.0-1-amd64 #1 SMP
Debian 4.4.4-2 (2016-03-09) x86_64
[ 41041.245] Kernel command line: BOOT_IMAGE=../vmlinuz-4.4.0-1-amd64
root=/dev/mapper/debian_laptop-root acpi_osi="!Windows 2012" acpi=force
acpi_enforce_resources=lax cgroup_enable=memory  net.ifnames=1 apparmor=1
security=apparmor udev.children-max=64 plymouth.enable=1 quiet splash ro
initrd=../initrd.img-4.4.0-1-amd64
[ 41041.245] Build Date: 12 March 2016  07:32:38AM
[ 41041.245] xorg-server 2:1.18.2-1 (http://www.debian.org/support)
[ 41041.245] Current version of pixman: 0.33.6
[ 41041.245]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 41041.245] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 41041.245] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Mar 15 23:49:18
2016
[ 41041.245] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 41041.245] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 41041.245] (**) Option "defaultserverlayout" "Main"
[ 41041.245] (**) ServerLayout "Main"
[ 41041.245] (**) |-->Screen "Screen0" (0)
[ 41041.245] (**) |   |-->Monitor "LVDS1"
[ 41041.246] (**) |   |-->Device "Device0"
[ 41041.246] (**) |-->Screen "Screen1" (1)
[ 41041.246] (**) |   |-->Monitor "VGA1"
[ 41041.246] (**) |   |-->Device "Device0"
[ 41041.246] (**) Option "DontVTSwitch" "off"
[ 41041.246] (**) Option "DontZap" "on"
[ 41041.246] (**) Option "DontZoom" "on"
[ 41041.246] (**) Option "BlankTime" "10"
[ 41041.246] (**) Option "StandbyTime" "10"
[ 41041.246] (**) Option "SuspendTime" "10"
[ 41041.246] (**) Option "OffTime" "10"
[ 41041.246] (**) Option "NoPM" "off"
[ 41041.246] (**) Option "Xinerama" "off"
[ 41041.246] (**) Option "RandR" "on"
[ 41041.246] (**) Option "AutoAddDevices" "on"
[ 41041.246] (**) Automatically adding devices
[ 41041.246] (==) Automatically enabling devices
[ 41041.246] (==) Automatically adding GPU devices
[ 41041.246] (==) Max clients allowed: 256, resource mask: 0x1f
[ 41041.246] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/cyrillic,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 41041.246] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 41041.246] (II) The server relies on udev to provide the list of input
devices.
If no 

Bug#816001: ifupdown: IPv6, DHCP, RA and forwarding

[Mikhail Morfikov]

On 02/26/2016 06:55 PM, Guus Sliepen wrote:
> On Fri, Feb 26, 2016 at 05:40:32PM +0100, Mikhail Morfikov wrote:
> 
>>> That begs the question though: could it be that you are getting your
>>> IPv6 address via DHCP, but the IPv6 gateway via router advertisements?
>>> To me that is a very strange situation.
>>
>> I think that's the case. In the lease above, there's just the IPv6 address. 
>> I'm configuring the IPv6 for the very first time, so I don't know all the 
>> things yet.
> 
> Ok, I've never used DHCPv6 myself, and trying to Google for others with
> similar problems to yours, it appears that it is in fact normal that the
> DHCPv6 server doesn't give any route information, and that this is
> instead always conveyed using route advertisement messages. So there is
> nothing wrong with your setup, just that you need to set accept_ra to 2
> because you have forwarding enabled.
> 
Ok, thanks.



signature.asc
Description: OpenPGP digital signature

Bug#816001: ifupdown: IPv6, DHCP, RA and forwarding

[Mikhail Morfikov]

> Hm, could it be that your DHCP6 server does advertise a default route?

This is the DHCPv6 lease I get from the router when I use "dhcp" in the 
/etc/network/interfaces file:

---
default-duid "\000\001\000\001\036c8> This is documented in interfaces(5). The reason is that in general, when
> forwarding is enabled, you are a router, in which case it is more likely
> that you want to set your own gateway route than to have one assigned by
> DHCP. But you can change it in /etc/network/interfaces like this:
> 
> iface bond0 inet6 dhcp
>   accept_ra 2

Thanks for the this!

> That begs the question though: could it be that you are getting your
> IPv6 address via DHCP, but the IPv6 gateway via router advertisements?
> To me that is a very strange situation.

I think that's the case. In the lease above, there's just the IPv6 address. I'm 
configuring the IPv6 for the very first time, so I don't know all the things 
yet.




signature.asc
Description: OpenPGP digital signature

Bug#816001: ifupdown: IPv6, DHCP, RA and forwarding

[Mikhail Morfikov]

Package: ifupdown
Version: 0.8.10
Severity: normal
Tags: ipv6

I wanted to implement IPv6 in my network, but my debian machine has some issues
with it. The IPv6 connection works just fine when configured statically via the
/etc/network/interfaces file in the following way:

iface bond0 inet6 static
address 2001:470:71:1234::150
netmask 64
gateway 2001:470:71:1234::1

It also works fine when I use the following line instead:

iface bond0 inet6 auto

But there's some issues when I want to use DHCP:

iface bond0 inet6 dhcp

In the last case, there's no default route, and the connection simply doesn't
work.

I tried to configure the network without IPv6 (only IPv4) via the
/etc/network/interfaces file, and then manually start dhclient so it could get
the IPv6 lease. In this case, the routes were added without problems.

I'm using some LXC containers, and I have one bridge interface. Here's the
sysctl configuration:

net.ipv4.ip_forward = 0
net.ipv4.conf.all.forwarding = 0
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.bond0.forwarding = 1
net.ipv4.conf.br-lxc.forwarding = 1
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.default.forwarding = 0
net.ipv6.conf.bond0.forwarding = 1
net.ipv6.conf.br-lxc.forwarding = 1

When forwarding is set only in the case of the br-lxc interface, the LXC
containers can't reach the internet. I had to enable forwarding also on the
bond0 interface. I'm not sure whether it's required, but it doesn't work
otherwise. And here's the problem with DHCPv6. When I set "dhcp" in the
/etc/network/interfaces file, and restart the network service, in the log I can
see the following message:

ifup[75305]: /sbin/sysctl -q -e -w net.ipv6.conf.bond0.accept_ra=1

According to the kernel documentation on this sysctl parameter, there's
something like this:

0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements even if
forwarding is enabled.

I've set this option manually to 2. That's why when I run dhclient manually,
the routes are filled properly. When I try to configure the IPv6 connection via
the /etc/network/interfaces file, ifup changes the value of the bond0.accept_ra
to 1, and the interface can't simply accept RA packets because of forwarding.

So the question is, how to prevent ifup from changing the value of accept_ra
sysctl parameter?



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ifupdown depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.28
ii  iproute2 4.3.0-1+b1
ii  libc62.21-9
ii  lsb-base 9.20160110

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.3-8

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.1-1
Followup-For: Bug #800617

I can confirm that the behavior has changed with the new version of the gnome-
keyring package. I downgraded the gnupg packages as well, so I could check
whether the new version of gnome-keyring works.

I still get the following messages when I type ssh command into a terminal:

Oct 19 13:23:41 morfikownia gnome-keyring-daemon[5140]: The Secret Service was
already initialized
Oct 19 13:23:41 morfikownia org.freedesktop.secrets[5189]:
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

There's also the lag.

The order of issuing commands (ssh or gajim) doesn't matter now, and ssh
command always gets the lag, whereas gajim works just fine all the time.

That't the only difference I can observe.

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Followup-For: Bug #800617

I can do it.

Bug#801906: /etc/systemd/journald.conf: Journal defaults to non-persistent across boots.

[Mikhail Morfikov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-10-15 22:48, Ben Longbons wrote:
> Package: systemd
> Version: 227-2
> Severity: normal
> File: /etc/systemd/journald.conf
> 
> Dear Maintainer,
> 
> The default configuration of journald loses logs whenever the system is
> rebooted. This is both a regression compared to non-systemd systems as
> well as breaking most systemd-specific debugging tutorials.
> 
> The trivial fix is to set Storage=persistent in /etc/systemd/journald.conf
> 
> Interestingly, after the next boot, Storage=auto does the same thing
> once /var/log/journal exists. This is mainly of interest to avoid the
> "config file changed" problem when running `aptitude upgrade`, since
> a config option that silently fails to work depending on not-in-/etc
> files is kind of scary.
> 
> Note that when journald creates /var/log/journal, it has
> permissions drwxr-sr-x and owner:group root:systemd-journal,
> which is not what users would probably create it with manually.
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (600, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages systemd depends on:
> ii  adduser 3.113+nmu3
> ii  libacl1 2.2.52-2
> ii  libapparmor12.10-2+b1
> ii  libaudit1   1:2.4.4-4
> ii  libblkid1   2.27-3
> ii  libc6   2.19-22
> ii  libcap2 1:2.24-12
> ii  libcap2-bin 1:2.24-12
> ii  libcryptsetup4  2:1.6.6-5
> ii  libgcrypt20 1.6.3-2
> ii  libkmod221-1
> ii  liblzma55.1.1alpha+20120614-2.1
> ii  libmount1   2.27-3
> ii  libpam0g1.1.8-3.1
> ii  libseccomp2 2.2.3-2
> ii  libselinux1 2.3-2+b1
> ii  libsystemd0 227-2
> ii  mount   2.27-3
> ii  sysv-rc 2.88dsf-59.2
> ii  udev227-2
> ii  util-linux  2.27-3
> 
> Versions of packages systemd recommends:
> ii  dbus1.10.0-3
> ii  libpam-systemd  227-2
> 
> Versions of packages systemd suggests:
> ii  systemd-container  227-2
> pn  systemd-ui 
> 
> -- no debconf information
> 
In the manual 
(http://www.freedesktop.org/software/systemd/man/journald.conf.html),
there's explicitly said that:

Storage=
Controls where to store journal data. One of "volatile",
"persistent", "auto" and "none". If "volatile", journal log data
will be stored only in memory, i.e. below the /run/log/journal
hierarchy (which is created if needed). If "persistent", data will
be stored preferably on disk, i.e. below the /var/log/journal
hierarchy (which is created if needed), with a fallback to
/run/log/journal (which is created if needed), during early boot
and if the disk is not writable. "auto" is similar to "persistent"
but the directory /var/log/journal is not created if needed, so
that its existence controls where log data goes. "none" turns off
all storage, all log data received will be dropped. Forwarding to
other targets, such as the console, the kernel log buffer, or a
syslog socket will still work however. Defaults to "auto".

So if you have "auto", the logs go to the /var/log/journal/ directory only
when the directory already exists. So, in your case, when you've set
"persistent", the system created the directories for you, and when you
switched to "auto" again, the journal was using the directory because it
exists.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWIMoAAAoJEM0EaBB3G2UgpisP/RZN9ekregScGTsnrF63sP0d
IuIz/Pc7dEUOFeteQZsNAFpt55mdbchXmWsm5c4NRU54aU2XJIngTJ0Lu8WvLj18
WZ+m/6Q9nbL9PL6rS/wabftHT47UklChtNI2Gm2Zx/8PGz+uD8mI3zehdHZMRYe6
Fgq87yEM/q7Ezuwv/1Y49vMWOgXpQkH1DQyPyI/366CqL45/1QuYyRh9lkaipORD
uq0G/XT52+7kq40y0elLDaflSV9lWAYgs8j0gMq2gCzbCMIqJ/GK73jBWeUZ0rMI
uoVQ2jV8ZkA0Lm2tOWr2VxuMBTnzomC7C1MVUgWaYSoPT6ig1eaguF1DEn4hWxcy
Ptl21xpYZPJTdQqXh9Aq9EwpGSsI/7yLEb09Vp5dpMkbj293myT4J7EfVHx610J5
Z4ZqX9z+KiR9uFzdleyN023LC3+onPah8aHOoHBw1m0nySDvng7g2dtrpxrggB7K
QyM/1YXH5uwA2Or3U84mAaJhIa9DIAr5FKCJbN2HyP9MNhGm6v3FtcBrrkeb7U1j
9FSH2I/4Wpvwtz4T3jsSHDEe0NdFQ4foOzmkWi05BC6UPQ7mbRCIMDvfU0vCarHC
GpbjZKJvjtBMCd2dNYI6xK2F5un31J0ZvZnTtW25nU1FSk38EoRvH5JoPC5mv0EX
nb7fR1VFELCFMkbMZJtd
=E7eV
-END PGP SIGNATURE-

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-4
Followup-For: Bug #800617

It looks like the patch doesn't work either -- it's the exact same situation.
But there's another thing that can be helpful.

There's another bug (#796931) in debian concerning the gnupg-agent package.
When I first installed the sid version of that package, I was unable to access
my ssh keys at all. After switching to the testing version of the following
packages: gnupg-agent gnupg2 gpgsm scdaemon , the issue disappeared, so I was
using the testing version of the packages all the time.

When I noticed the problems with gnome-keyring, I didn't even realize that the
two things could be connected in some way. But it looks like they are.

First of all, I upgraded the packages in question. Then I did the trick
described in the aforementioned bug, which was to add some code to the
..bashrc/.zshrc file:

if [ "$PS1" ]; then
unset GPG_AGENT_INFO
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"
fi
fi
export GPG_TTY=`tty`

After reboot, the message "The Secret Service was already initialized" in the
log disappeared. Running gajim and ssh command in the same session no longer
gives the lag when executing the second application. There's no error/messages
in the log, and my ssh keys work just fine.

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-2
Followup-For: Bug #800617

Another observation that can prove useful.

First of all, the process that spawns along with my openbox (/usr/bin/gnome-
keyring-daemon --daemonize --login) lives about 2 minutes, not one minute --
I've just measured it. When it's gone, the /run/user/1000/keyring/ directory
also disappears.

The next thing concerns opening, for instance gajim, when the process
disappeared. In that case, I get a password prompt in order to unlock the
keyring, and also bunch of logs (http://pastebin.com/GrqQA6gy).

After entering the password, the keyring is unlocked and the app starts
normally without asking for any other passwords. There's just one process
concerning gnome-keyring:

$ ps aux | grep gnome
morfik98603  0.0  0.3 216092  5784 ?Sl   14:14   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session
morfik   100411  0.0  0.4 352536  8096 ?SLl  14:17   0:00 /usr/bin
/gnome-keyring-daemon --start --foreground --components=secrets

The rest of issues that I described earlier stay the same.

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-2
Followup-For: Bug #800617

I've just upgraded the gnome-keyring package, and I think that didn't solve my
issues. I think it's the same situation as it was before, but there's another
thing worth mentioning.

When my openbox starts I have the following processes:

$ ps aux | grep gnome
morfik16743  0.0  0.0 122748   516 ?Sl   09:52   0:00 /usr/bin
/gnome-keyring-daemon --daemonize --login
morfik16891  0.0  0.2 216104  5676 ?Sl   09:52   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session

When I do nothing, after a minute or so, the first process disappears. I'm not
sure whether this should happen or not, so I'm just sharing my observations
with you.

Anyways, I have two apps that I often use: gajim and ssh. When I type in a
terminal "gajim" after logging into my system, everything works just fine. I
mean the above processes stay the same, and there's no lag when the app starts.
I don't have to type any passwords manually in order to log into my jabber
accounts, so the keyring works. When I close the app and reopen it again, it
also works as expected. The problem is when I want to issue ssh command -- I
get lag here and the message in the log:

Oct 08 09:53:47 morfikownia gnome-keyring-daemon[16743]: The Secret Service was
already initialized

Still, gajim (when restarted) works just fine, but issuing ssh command again
gives the lag. It looks like they're separated somehow.

The funniest thing is that when I switch the order of issuing the two commands,
so in this case the ssh command would be the fist one after login, it works
just fine, with no lag and any message in the log. But when I start gajim after
that, there's a lag and the message in the log, and of course password prompts.

So it looks like there's just only one process (the first one started after
login) that can work just fine with gnome-keyring, and the others get a lag
when started.

Another observation is that I get doubled process when the lagged application
is starting:

$ ps aux | grep gnome
morfik16743  0.0  0.3 205072  7292 ?Sl   09:52   0:00 /usr/bin
/gnome-keyring-daemon --daemonize --login
morfik16891  0.0  0.2 216104  5676 ?Sl   09:52   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session
morfik17825  0.0  0.2  48992  4260 ?S09:53   0:00 /usr/bin
/gnome-keyring-daemon --start --foreground --components=secrets
morfik17933  0.0  0.2  48992  4268 ?S09:53   0:00 /usr/bin
/gnome-keyring-daemon --start --foreground --components=secrets

The doubled process (17933) disappears after a minute or so.

I was testing this with and without the autostart files, and it's the same in
both cases.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-12
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.6-2

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-2

gnome-keyring suggests no packages.

-- Configuration Files:
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop [Errno 2] No such file or 
directory: u'/etc/xdg/autostart/gnome-keyring-pkcs11.desktop'
/etc/xdg/autostart/gnome-keyring-secrets.desktop [Errno 2] No such file or 
directory: u'/etc/xdg/autostart/gnome-keyring-secrets.desktop'
/etc/xdg/autostart/gnome-keyring-ssh.desktop [Errno 2] No such file or 
directory: u'/etc/xdg/autostart/gnome-keyring-ssh.desktop'

-- no debconf information

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-2
Followup-For: Bug #800617

I explicitly said: "I was testing this with and without the autostart files,
and it's the same in both cases."



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-12
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.6-2

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-2

gnome-keyring suggests no packages.

-- no debconf information

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-1
Followup-For: Bug #800617

I had similar issue after today's upgrade. The package gnome-keyring
was upgraded as well, so I thought it could be involved. The first
thing I noted after upgrade was the lag when I was running ssh command
-- after 10-15s I was able to enter password unlocking my ssh keys. Besides
that, everything seemed to be right except the following log in the
journal:

gnome-keyring-daemon[2185]: The Secret Service was already initialized
org.freedesktop.secrets[2234]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

I downgraded the gnome-keyring package to the testing version, but the
lag didn't disappear. I tried to downgrade every package with the
version of 3.18.0-1, but that also didn't help.

So I upgraded everything to sid version as it was before, and then I
noticed that there's a new version of config files in
/etc/xdg/autostart/ -- those with gnome* in their name. I had also
some files in the ~/.config/autostart/ directory, so I removed them
completely. After reboot, everything seems to be working as it supposed
to.

I get the following processes, when my openbox starts:

$ ps aux | grep gnome
morfik 2223  0.0  0.1 122748  2776 ?Sl   21:39   0:00 /usr/bin
/gnome-keyring-daemon --daemonize --login
morfik 2401  0.0  0.3 216104  5780 ?Sl   21:39   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session

When I issue ssh command, I get the prompt for the password without any
lag. There's also another process:

$ ps aux | grep gnome
morfik 2223  0.0  0.3 205072  6520 ?Sl   21:39   0:00 /usr/bin
/gnome-keyring-daemon --daemonize --login
morfik 2401  0.0  0.3 216104  5780 ?Sl   21:39   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session
morfik 3322  0.0  0.2  48992  4172 ?S21:40   0:00 /usr/bin
/gnome-keyring-daemon --start --foreground --components=secrets



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-12
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.6-1

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-1

gnome-keyring suggests no packages.

-- no debconf information

Bug#785542: viewnior: Behavior setting doesn't work corectly

[Mikhail Morfikov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-07-20 12:52, Dariusz Dwornikowski wrote:
 after upgrading viewnior from 1.4-2+b1 to 1.5-1 , I noticed that basically 
 all
 options that can be set via the behavior tab simply don't work as expected.
 You can set, for instance, on mouse wheel to navigate images, but you get
 zoom image instead, etc. On the previous version everything works just fine

 
 I can't seem to reproduce this problem on my two computers. Is it
 still occurring ? 
 
 

Yes, it happens all the time. It looks like the On double click
option is completely ignored when I set On mouse wheel to Zoom
image, I mean, no matter what is set in On double click, it doesn't
change the behavior when I double click -- all of the three options
that I can set just maximize the image.

When I start playing with the On mouse wheel option and set it to
Navigate images, then the behavior of On double click changes, but
not to the one that is selected in its field.

When I set the On mouse wheel option to Scroll image up/down and
the other option to Switch zoom modes, then after double click, the
next image is shown, so it looks like this works as Navigate images,
but it's not set at all.

There's many combinations I can get by playing with the two options,
but when I installed the previous version of viewnior then everything
was just fine, so clearly something is wrong with the newest version.

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVrUO5AAoJEM0EaBB3G2UgmGYP/2qj0LNLsVmvabyUwir1sYAB
zlHfrLNsDgn/Z225KcOguF0MJvX4k022k1lZEHNvpnvNDe30vcRq3vtOG1AaHfrT
y3+m4dcFkJNhpP3j2V89s40gQIyw3tU928qU5c3GpqLy5X+UBC/qeXEXkOfJnHsT
pzYFivcrpJhXynUfRIHarouUIzbFW/6atNRjeBQRlVfAkaDWz7ISZeWXl9yUM0kJ
hbeKWtDE/3xKNojBpK1YBhSLdLywoIO7PzP9zumuT89uv867cn06K3xUpRaocCaN
eUx9rVcn5gVMlOKtiv8QyEsetSijOtgi5/UYtXtuQS73//5Lvx5p11ZGAi6qXSVT
QLCBZSr7MEgyLmqQj3E5IFGHmGj/HmvlXRo70lpEajtx1k0rKfD1nPrysYVHfMko
do14ACEF+kSMkSmH/K8hUwIbGP1VvUwsihTsZIhYkxgj9e9fGMhNpIUgHKepyOuw
g2TCdhL1rR34X1EBOYNoMQcOC+D8DVrQfqegbNLd4iQf8h5A3fjvdb0fbY427ZTT
MtEaFJGOUTOsgPRWhDyy7UhderuThuMhuZsAGyr7EO1/lRjHjuqQ1m6ETcuhOWEF
F7D/804GxYWMu7i9nEASaRI6NF0C02XVjtuWK50hO7oB2gobALZqHEKXeuDf3wFx
Y2Fwhc2CN1cMlq/LGT84
=Cw9Q
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785542: viewnior: Behavior setting doesn't work corectly

[Mikhail Morfikov]

Package: viewnior
Version: 1.5-1
Severity: normal

Dear Maintainer,

after upgrading viewnior from 1.4-2+b1 to 1.5-1 , I noticed that basically all
options that can be set via the behavior tab simply don't work as expected.
You can set, for instance, on mouse wheel to navigate images, but you get
zoom image instead, etc. On the previous version everything works just fine



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages viewnior depends on:
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-18
ii  libcairo21.14.2-2
ii  libexiv2-13  0.24-4.1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-4
ii  libgcc1  1:5.1.1-5
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.44.0-3
ii  libgtk2.0-0  2.24.25-3
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libstdc++6   5.1.1-5

viewnior recommends no packages.

viewnior suggests no packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783401: smplayer should use mpv instead of mplayer|mplayer2 as playback engine by default

[Mikhail Morfikov]

Package: smplayer
Version: 14.9.0.6887-1~vivid1
Severity: wishlist

Dear Maintainer,

on the official website we can read the following:

SMPlayer 14.9.0.6812 has been released
Summary of changes:

We are very happy to announce that this version has added support for
mpv, which provide very interesting new features.

http://smplayer.sourceforge.net/en/changes

Considering that the mplayer and mplayer2 are a little bit obsolete, and that
the smplayer has added support for mpv, I would suggest to use mpv as a default
smplayer playback engine.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618862: systemd: ignores keyscript in crypttab

[Mikhail Morfikov]

Source: systemd
Followup-For: Bug #618862

Is there a solution to this issue?

I'm currently using debian sid + sysvinit because I can't switch to systemd.

This is my setup:

root:~# lsblk -f
NAME FSTYPE  LABEL   UUID
MOUNTPOINT
sda
├─sda1   ntfswindows 36442BAC442B6E35
├─sda2   ext4boot4c67dff5-3d8e-4b3f-
9cf1-49b88d5f67a9   /boot
├─sda3   crypto_LUKS 9e03ae84-2f10-4f88-bf1c-
d7507ad30f78
│ └─debian_laptopLVM2_member 1f7G9n-hwJ4-hD20-N9GP-3l77
-8tCi-uM7LZG
│   ├─debian_laptop-root ext4rootdfdc8fb7-d9d4-4cd4-869c-
0f1910a3a17e   /
│   ├─debian_laptop-home ext4home
27632431-fa15-49ba-8354-9c193e321aa6   /home
│   ├─debian_laptop-tmp  ext4tmp be5e9b14-4f41-462a-
b3c6-8502e88cc0c7
│   └─debian_laptop-swap swapc4f58930-bfda-4f4e-
bad0-2be8d1b5bc9e
├─sda4
├─sda5   crypto_LUKS d314ed20-ffaf-
4a18-98a7-91538e79d981
│ └─grafiext4grafi
990d110a-1310-4ab2-8a03-c952a408be11   /media/Grafi
└─sda6   crypto_LUKS f3c10054-0583-4e10-937b-
dcdc9a05a25c
  └─kabi ext4kabib47e6dcd-924e-40fa-
a8b1-7593419f86d7   /media/Kabi

As you can see I have encrypted LVM, which works just fine. I have also two
other
encrypted volumes, and here's the problem. Take a look at /etc/crypttab
and /etc/fstab files:

root:~# egrep -v ^# /etc/crypttab
debian_laptop   UUID=9e03ae84-2f10-4f88-bf1c-d7507ad30f78   noneluks
kabiUUID=f3c10054-0583-4e10-937b-dcdc9a05a25c   debian_laptop
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived
grafi   UUID=d314ed20-ffaf-4a18-98a7-91538e79d981   debian_laptop
luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived,noauto

root:~# egrep -v ^# /etc/fstab

UUID=dfdc8fb7-d9d4-4cd4-869c-0f1910a3a17e   /
ext4defaults,errors=remount-ro,commit=100 1
UUID=4c67dff5-3d8e-4b3f-9cf1-49b88d5f67a9   /boot   ext4
defaults,errors=remount-ro,commit=100 2
UUID=27632431-fa15-49ba-8354-9c193e321aa6   /home   ext4
defaults,errors=remount-ro,commit=100 2
UUID=990d110a-1310-4ab2-8a03-c952a408be11   /media/Grafiext4
defaults,nofail,errors=remount-ro,commit=10 0 2
UUID=b47e6dcd-924e-40fa-a8b1-7593419f86d7   /media/Kabi ext4
defaults,errors=remount-ro,commit=100 2
UUID=c4f58930-bfda-4f4e-bad0-2be8d1b5bc9e   swapswap
defaults,pri=10 0 0

tmpfs /tmp tmpfs defaults,noatime,nosuid,noexec,nodev,mode=1777,size=512M 0 0

Both of the encrypted volumes use decrypt_derived script. I don't want to open
one
of them at boot time, that's why I used also the noauto option.

This setup works, but only with sysvinit. I've been using it for several
years and I've never had a problem with it.
So how can I fix this in order to switch to systemd?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729522: cp: cannot stat '/root/syslinux/libcom32.c32': No such file or directory

[Mikhail Morfikov]

Package: live-build
Followup-For: Bug #729522

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I removed the aptosid kernel from the config file, and the image was created
successfully. That's weird because you know, I've been using this setup for
several months and everything was fine. Besides, isn't aptosid kernel a debian
kernel? I thought it wouldn't cause any problems.




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJShU1xAAoJEM0EaBB3G2UgBcgP/iIoGNsE6ntljbFGjV/gOCFO
QwcS4OZmm9NhWgbMCz2hYbrwwwt7h3UU60sAWTiR5PtT1PGzBqgMJcSlGg/TNRzh
ic4zBtugGphHb/Vuj0Oz2oygzthHnph82KFODGLtWTG2L35NFMXMR+iN5D5ZKJke
/2su5kdkYbb0WTxpDO4ZV0rZJ5OGerYT8u1ryLfIzXMpqvUxTz0DLJzpljYxBhxg
x7n/fULvudcpSrwRv9fwfzVPKhB50ARH2O31BTO4JcoPcPlWLY4Nx1WHGh8q+hDa
ADbRtL4ii0rtOhD821nogEJLChROounT+SY2I3VTEqm8rLU8o+FA3rJ8pztotfhs
hUuEXPBvN/39gQdlIf/PAfux3N95Wvzk8bM/7X2IdqMNMlQANYfVv7d98bRe62xi
I4G3dSG+AdZHhNbM4EWs99jmapYBP79uAX14Dfr6kevjg14Xk+spBBV9g/IyonIr
VCqXHNtfTsArcw6Qd5k8uEg8yu0eesz4TrawH0QBOSOeY6bq6glQGtcddxXMVJIu
BV88yzMsMLDaZhcjxecCfjWqtpy8v+m5y98eoe5HUfMOgUuuGLqlkroC3XrciPUJ
wPxaFqfmomyJJ9w7FL1KQLO5qMZoi08vrkL0XpVDUvPyEUVMUnJDS7Nf8mTxj4eZ
ykzAw6dSYeyKqjuW12Ti
=mzA1
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729522: cp: cannot stat '/root/syslinux/libcom32.c32': No such file or directory

[Mikhail Morfikov]

Package: live-build
Version: 4.0~alpha30-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: live-build
Version: 4.0~alpha30-1

I've been trying to build a testing live hdd image using experimental
live-build package, but unfortunately something went wrong.

Following is my lb config:

root:/media/Server/live# cat auto/config
#!/bin/sh

set -e

lb config noauto \
--apt aptitude \
--apt-recommends true \
--apt-secure true \
--distribution jessie \
--binary-image hdd \
--archive-areas main contrib non-free \
--bootappend-live \
boot=live \
config \
components \
locales=pl_PL.UTF-8,en_US.UTF-8 \
keyboard-layouts=pl \
timezone=Europe/Warsaw \
persistence \
persistence-encryption=luks \
persistence-media=removable \
persistence-label=data \
nottyautologin \
noeject \
swapon \
hostname=livemor \
 \
--bootstrap debootstrap \
--mirror-bootstrap http://ftp.pl.debian.org/debian/ \
--mirror-binary http://ftp.pl.debian.org/debian/ \
--architecture amd64 \
--linux-flavours amd64 aptosid-amd64 \
--linux-packages linux-image linux-headers \
--bootloader syslinux \
${@}

I have configured two additional repositories -- aptosid and debian
experimental, the former is for aptosid kernel, and the latter for live-*
packages. Here's configuration:

root:/media/Server/live# cat config/archives/aptosid.pref.chroot
Package: *
Pin: origin aptosid.office-vienna.at
Pin-Priority: 120

Package: *
Pin: origin ftp.spline.de
Pin-Priority: 120

Package: *
Pin: origin debian.tu-bs.de
Pin-Priority: 120

root:/media/Server/live# cat config/archives/aptosid.list.chroot
# AptoSID #
#deb http://debian.tu-bs.de/project/aptosid/debian/ sid main fix.main
#deb-src http://debian.tu-bs.de/project/aptosid/debian/ sid main fix.main

#   deb ftp://ftp.spline.de/pub/aptosid/debian/ sid main fix.main
#   deb-src ftp://ftp.spline.de/pub/aptosid/debian/ sid main fix.main

deb http://aptosid.office-vienna.at/aptosid/debian/ sid main
fix.main
deb-src http://aptosid.office-vienna.at/aptosid/debian/ sid main
fix.main

root:/media/Server/live# cat config/archives/experimental.list.chroot
# EXPERIMENTAL #
deb http://ftp.pl.debian.org/debian/ experimental main contrib non-free
deb-src http://ftp.pl.debian.org/debian/ experimental main contrib non-free

root:/media/Server/live# cat config/archives/experimental.pref.chroot
Package: live-*
Pin: release o=Debian,a=experimental
Pin-Priority: 600

I also have some custom packages to include in the building image:

cat config/package-lists/*
vim
mc
cryptsetup
lvm2
smplayer
vlc
spacefm
keepass2
gparted
gajim
geany
convertall
disk-manager
filezilla
gsmartcontrol
meld
ntp
hddtemp
lm-sensors
fancontrol
terminator
task-gnome-desktop
task-laptop
task-desktop

Now time for build:

root:/media/Server/live# lb clean --all
[2013-11-13 18:13:21] lb clean --all
P: Executing auto/clean script.
[2013-11-13 18:13:21] lb clean noauto --all
P: Cleaning chroot
root:/media/Server/live# ls -al
total 20K
drwxr-xr-x  5 root   root   4.0K Nov 13 18:13 ./
drwxr-xr-x 16 morfik morfik 4.0K Nov 12 23:30 ../
drwxr-xr-x  2 root   root   4.0K Nov 13 18:13 auto/
drwxr-xr-x  7 root   root   4.0K Nov 12 21:48 cache/
drwxr-xr-x 17 root   root   4.0K Nov 13 18:13 config/
root:/media/Server/live# lb config
[2013-11-13 18:14:08] lb config
P: Executing auto/config script.
[2013-11-13 18:14:08] lb config noauto --apt aptitude --apt-recommends true
- --apt-secure true --distribution jessie --binary-image hdd --archive-areas 
main
contrib non-free --bootappend-live boot=live config components
locales=pl_PL.UTF-8,en_US.UTF-8 keyboard-layouts=pl timezone=Europe/Warsaw
persistence persistence-encryption=luks persistence-media=removable
persistence-label=data nottyautologin noeject swapon hostname=livemor
- --bootstrap debootstrap --mirror-bootstrap http://ftp.pl.debian.org/debian/
- --mirror-binary http://ftp.pl.debian.org/debian/ --architecture amd64 --linux-
flavours amd64 aptosid-amd64 --linux-packages linux-image linux-headers
- --bootloader syslinux
P: Updating config tree for a debian/jessie/amd64 system
W: WARNING: THIS VERSION OF LIVE-BUILD IS EXPERIMENTAL!
W: IT IS UNFINISHED AND CHANGES HEAVILY WITHOUT PRIOR NOTICE.
W: USER DISCRETION IS ADVISED.
W:
W: Please also note that you are running a live-build development version
W: and that we are only supporting the newest development version.
W:
W: Make sure you are using the newest version at all times.
P: Symlinking hooks...
root:/media/Server/live# lb build

Everything goes according to plan to this moment:

Reading state information...
[2013-11-13 19:31:40] lb binary_manifest
P: Begin creating manifest...
[2013-11-13 19:31:41] lb binary_package-lists
P: Begin installing local package lists...
[2013-11-13 19:31:41] lb binary_linux-image
P: Begin install linux-image...
[2013-11-13 19:31:42] lb binary_memtest