Bug#972580: dpkg-query throw error when asking for field "source:Upstream-Version"

[Brian Wengel]

Package: dpkg
Version: 1.19.7

Command example throwing the error:
dpkg-query --show --showformat '${Package} ${source:Upstream-Version}\n' s*

Error message:
dpkg-query: error: version '' has bad syntax: version string is empty

>From the manual per 1.19.7 / 2019-06-03
"source:Upstream-Version
   It contains the source package upstream version for this binary
package (since dpkg 1.18.16)"

Bug#952508: Cannot call external script in rule CMD option

[Brian Wengel]

Yes, exec bit is set and script also tested directly in console.
How does your cmd option lines look like in the config-file?
Now I start to suspect  that not even the default cmd line "logger..." is
running. I don't see the message in syslog it should create.

Enabled debug in config-file and restored the original cmds:
Feb 25 11:00:46 debiansdk sshd[9115]: Invalid user test from 10.0.1.104
port 62729
Feb 25 11:00:47 debiansdk pam-abl[9115]: /etc/security/pam_abl.conf:
host_purge=1d
Feb 25 11:00:47 debiansdk pam-abl[9115]: /etc/security/pam_abl.conf:
user_purge=1d
Feb 25 11:00:47 debiansdk pam-abl[9115]: /etc/security/pam_abl.conf:
limits=100-300
Feb 25 11:00:47 debiansdk pam-abl[9115]: /etc/security/pam_abl.conf:
user_db=/var/lib/abl/users.db
Feb 25 11:00:47 debiansdk pam-abl[9115]: /etc/security/pam_abl.conf:
host_db=/var/lib/abl/hosts.db
Feb 25 11:00:47 debiansdk pam-abl[9115]: /etc/security/pam_abl.conf:
user_whitelist=
Feb 25 11:00:47 debiansdk pam-abl[9115]: /etc/security/pam_abl.conf:
host_whitelist=localhost
Feb 25 11:00:47 debiansdk pam-abl[9115]: /etc/security/pam_abl.conf:
db_home=/var/lib/abl
Feb 25 11:00:47 debiansdk pam-abl[9115]: debug   = 1
Feb 25 11:00:47 debiansdk pam-abl[9115]: db_home = /var/lib/abl
Feb 25 11:00:47 debiansdk pam-abl[9115]: host_db =
/var/lib/abl/hosts.db
Feb 25 11:00:47 debiansdk pam-abl[9115]: host_rule   = */sshd:3/5h
Feb 25 11:00:47 debiansdk pam-abl[9115]: host_purge  = 86400
Feb 25 11:00:47 debiansdk pam-abl[9115]: host_block_cmd  = [logger] [block]
[host] [%h]
Feb 25 11:00:47 debiansdk pam-abl[9115]: host_clear_cmd  = [logger] [clear]
[host] [%h]
Feb 25 11:00:47 debiansdk pam-abl[9115]: user_db =
/var/lib/abl/users.db
Feb 25 11:00:47 debiansdk pam-abl[9115]: user_rule   = */sshd:2/1h
Feb 25 11:00:47 debiansdk pam-abl[9115]: user_purge  = 86400
Feb 25 11:00:47 debiansdk pam-abl[9115]: user_block_cmd  = [logger] [block]
[user] [%u]
Feb 25 11:00:47 debiansdk pam-abl[9115]: user_clear_cmd  = [logger] [clear]
[user] [%u]
Feb 25 11:00:47 debiansdk pam-abl[9115]: lower limit = 100
Feb 25 11:00:47 debiansdk pam-abl[9115]: upper limit = 300
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde918d0] =
db_home=/var/lib/abl
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde918a0] =
host_whitelist=localhost
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde91880] =
user_whitelist=
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde91850] =
host_db=/var/lib/abl/hosts.db
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde91820] =
user_db=/var/lib/abl/users.db
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde91800] =
limits=100-300
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde917e0] = user_purge=1d
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde917c0] = host_purge=1d
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde81ad0] = debug
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde91780] =
user_block_cmd=[logger] [block] [user] [%u]
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde91740] =
user_clear_cmd=[logger] [clear] [user] [%u]
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde91700] =
host_block_cmd=[logger] [block] [host] [%h]
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde916c0] =
host_clear_cmd=[logger] [clear] [host] [%h]
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde7d770] =
host_rule=*/sshd:3/5h
Feb 25 11:00:47 debiansdk pam-abl[9115]: str[0x5590bde7e1b0] =
user_rule=*/sshd:2/1h
Feb 25 11:00:48 debiansdk pam-abl[9115]: state opened
Feb 25 11:00:48 debiansdk pam-abl[9115]: state opened
Feb 25 11:00:48 debiansdk pam-abl[9115]: Check 10.0.1.104/sshd against
*/sshd:3/5h(1)
Feb 25 11:00:48 debiansdk pam-abl[9115]: Name part matches, **rp = '/'
Feb 25 11:00:48 debiansdk pam-abl[9115]: match('sshd', 'sshd:3/5h', 4)
Feb 25 11:00:48 debiansdk pam-abl[9115]: Match!
Feb 25 11:00:48 debiansdk pam-abl[9115]: Name matched, next char is ':'
Feb 25 11:00:48 debiansdk pam-abl[9115]: matchperiod(0x5590bde95b20, 1,
'3/5h')
Feb 25 11:00:48 debiansdk pam-abl[9115]: count is 3, **rp='/'
Feb 25 11:00:48 debiansdk pam-abl[9115]: period is 18000, **rp='#000'
Feb 25 11:00:48 debiansdk pam-abl[9115]: Checking 3/18000
Feb 25 11:00:48 debiansdk pam-abl[9115]: howmany(18000) = 1
Feb 25 11:00:48 debiansdk sshd[9115]: pam_unix(sshd:auth): check pass; user
unknown
Feb 25 11:00:48 debiansdk sshd[9115]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.1.104
Feb 25 11:00:50 debiansdk sshd[9115]: Failed password for invalid user test
from 10.0.1.104 port 62729 ssh2
Feb 25 11:00:53 debiansdk sshd[9115]: Connection closed by invalid user
test 10.0.1.104 port 62729 [preauth]
Feb 25 11:00:53 debiansdk pam-abl[9115]: In cleanup, err is 0007
Feb 25 11:00:53 debiansdk pam-abl[9115]: record returned 0

I wonder what this cleanup error means: " pam-abl[9115]: In cleanup, err is
0007"

Bug#952512: vsftpd stalls when host has been blocked by PAM

[Brian Wengel]

Package: vsftpd
Version: 3.0.3-12

Description:
When an authentication is blocked by PAM (module: pam_abl.so) because of
the remote-host is blocked the vsftpd service is stalled and doesn't accept
connection until service is restarted (reload is not enough).
I guess vsftpd have a bug when it gets the communication.
This doesn't happen when an authentication is rejected because of the user
is blocked (I assume vsftpd understand the communication is this case).
I assume it's related to the bug submit:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952421


Content of "/etc/security/pam_abl.conf"
 user_rule=*/:3/1h
 host_rule=*:5/5h
 host_purge=1d
 user_purge=1d
 limits=100-300
 user_db=/var/lib/abl/users.db
 host_db=/var/lib/abl/hosts.db
 host_clear_cmd=[logger] [clear] [host] [%h]
 host_block_cmd=[logger] [block] [host] [%h]
 user_clear_cmd=[logger] [clear] [user] [%u]
 user_block_cmd=[logger] [block] [user] [%u]
 user_whitelist=
 host_whitelist=localhost
 db_home=/var/lib/abl

Bug#952508: Cannot call external script in rule CMD option

[Brian Wengel]

Package: libpam-abl
Version: 0.6.0-5

Description:
I cannot run a simple shell script:
I have the following options in my "/etc/security/pam_abl.conf":
  user_rule=*:3/1h
  host_rule=*:5/5h
  host_purge=1d
  user_purge=1d
  limits=100-300
  user_db=/var/lib/abl/users.db
  host_db=/var/lib/abl/hosts.db
  user_clear_cmd=[logger] [clear] [user] [%u]
  host_clear_cmd=[/tmp/brute.sh]
  host_block_cmd=[/tmp/brute.sh]
  user_clear_cmd=[/tmp/brute.sh]
  user_block_cmd=[/tmp/brute.sh]
  host_whitelist=localhost
  user_whitelist=
  db_home=/var/lib/abl

The result of the command "pam_abl -d" is:
  host_block_cmd: "/tmp/brute.sh"
  host_clear_cmd: "/tmp/brute.sh"
  user_block_cmd: "/tmp/brute.sh"
  user_clear_cmd: "/tmp/brute.sh"

The content of "/tmp/brute.sh"
  #!/bin/bash
  echo START >> /tmp/PAM_abl_env.txt
  env >> /tmp/PAM_abl_env.txt

Is this a bug or am I missing something?

Bug#952421: Cannot use PAM modules which call subprocess e.g. pam_exec

[Brian Wengel]

Package: vsftpd
Version: version 3.0.3

Description:
It seems vsftpd blocks/hang if you use a PAM module which call a subprocess
like pam_exec.
See this thread on StackExchange, which also claim the CentOS package have
fixed the bug.
https://askubuntu.com/questions/406486/vsftpd-hanging-when-using-pam-exec-or-pam-script#answer-778448

Bug#951480: Misleading status message when lock password with "--lock"

[Brian Wengel]

Package: passwd
Version: 1:4.5-1.1

When using the option "--lock", passwd will print the following status
message:
"passwd: password expiry information changed."

I assume the "--lock" option only lock the password (sing !) and neither
change the expiration date of the account or any of the other date
attributes of a local account, an as such, should not use the word
"expiry", or the like,  in the status message, as the user will be in doubt
of what was actually changed, and not only locking the password as one will
expect.
I would suggest the status message is changed to something like "passwd:
password was locked"

If it does change some of the date attributes then please update the
manual, as it only says it only lock the password with "!"

Bug#950577: And "allow_writeable_chroot=YES|NO"

[Brian Wengel]

Can't dind "allow_writeable_chroot" in the manual either.

Bug#950584: whitespace break "/etc/vsftpd.conf"

[Brian Wengel]

Package: vsftpd

Version: 3.0.3-12


If a whitespace surfix a option in the "/etc/vsftpd.conf" file, the service
fail to start.

E.g "guest_enable=YES "

I guess it depends of the eyes if this is a bug or a feature-request. But I
just wasted more than an hour because of this, so at the moment I feel it's
a bug ;-)

Bug#950577: Missing option in man (utf8_filesystem)

[Brian Wengel]

Package: vsftpd

Version: 3.0.3-12


The option "utf8_filesystem" in "/etc/vsftpd.conf" is not listed in the
manual.

I might be it's rather self-description, but the default value is not,
neither if the option is supported at all. One might think the remarked
option in the configfil is simple a left-over from an old version.

I hope you will add the option to the man :-)

Bug#948692: "postconf -d maillog_file" doesn't show actual value

[Brian Wengel]

Package: postfix

Version:  3.4.7


Value in my main.cf:

maillog_file = /var/log/postfix.log


Result of "postconf -d | grep log_file":

maillog_file =
maillog_file_compressor = gzip
maillog_file_prefixes = /var, /dev/stdout
maillog_file_rotate_suffix = %Y%M%d-%H%M%S

Content in master.cf

 postlog   unix-dgram n  -   n   -   1   postlogd


I did restart the Postfile service and I can confirm logning to the file is
active and working (it was not before I activated it in the mail.cf file)

Bug#948308: closed by Andreas Metzler (Re: Bug#948308: Macro AUTH_SERVER_ALLOW_NOTLS_PASSWORDS ignore true/false)

[Brian Wengel]

But I would expect "AUTH_SERVER_ALLOW_NOTLS_PASSWORDS = False" would disable 
it.
What I'm trying to say is that whatever value you insert after the "=" is 
ignored.

-Original Message-
From: Debian Bug Tracking System [mailto:ow...@bugs.debian.org]
Sent: 7. januar 2020 20:21
To: Brian Wengel
Subject: Bug#948308 closed by Andreas Metzler  (Re: 
Bug#948308: Macro AUTH_SERVER_ALLOW_NOTLS_PASSWORDS ignore true/false)

This is an automatic notification regarding your Bug report which was filed 
against the exim4-daemon-heavy package:

#948308: Macro AUTH_SERVER_ALLOW_NOTLS_PASSWORDS ignore true/false

It has been closed by Andreas Metzler .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a better one 
in a separate message then please contact Andreas Metzler  
by replying to this email.


--
948308: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948308
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


smime.p7s
Description: S/MIME cryptographic signature

Bug#948308: Macro AUTH_SERVER_ALLOW_NOTLS_PASSWORDS ignore true/false

[Brian Wengel]

Package: exim4-daemon-heavy

Version: 4.92-8+deb10u3


I've put the following in macro in "/etc/exim4/conf.d/main/000_localmacros":

It seem the activation on this macro is rather inconsistent:

"AUTH_SERVER_ALLOW_NOTLS_PASSWORDS" >  error
"AUTH_SERVER_ALLOW_NOTLS_PASSWORDS=" > OK

"AUTH_SERVER_ALLOW_NOTLS_PASSWORDS=whatever you write"  > OK


By "error" I mean update-exim4.conf will give following error:

2020-01-06 23:10:49 Exim configuration error in line 21 of
/var/lib/exim4/config.autogenerated.tmp:
  malformed macro definition
Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not
installing
/var/lib/exim4/config.autogenerated.tmp to
/var/lib/exim4/config.autogenerated


Best regards
Brian

Bug#936098: Buster test, error with fuse installing qemu-kvm

[Brian Wengel]

Package: qemu-kvm

Version: 1:3.1+dfsg-8


Error:



Setting up qemu-system-gui (1:3.1+dfsg-8) ...
Processing triggers for systemd (242-4) ...
Processing triggers for man-db (2.8.6.1-1) ...
Processing triggers for libc-bin (2.28-10) ...
Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.38.1+dfsg-1) ...

Errors were encountered while processing:
 fuse
E: Sub-process /usr/bin/dpkg returned an error code (1)



Debian version:

PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";
Kernel-release: 5.2.0-2-amd64
Kernel-version: #1 SMP Debian 5.2.9-2 (2019-08-21)

Installed from netinst.


I attach the log
root@debian:~# apt-get install qemu-kvm
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  fonts-droid-fallback libntfs-3g883
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  adwaita-icon-theme at-spi2-core dbus-user-session dconf-gsettings-backend 
dconf-service fontconfig fontconfig-config fonts-dejavu-core glib-networking 
glib-networking-common
  glib-networking-services gsettings-desktop-schemas gstreamer1.0-libav 
gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly 
gstreamer1.0-x
  gtk-update-icon-cache hicolor-icon-theme i965-va-driver ibverbs-providers 
intel-media-va-driver ipxe-qemu liba52-0.7.4 libaa1 libaacs0 libaio1 libaom0 
libasound2
  libasound2-data libass9 libasyncns0 libatk-bridge2.0-0 libatk1.0-0 
libatk1.0-data libatspi2.0-0 libavahi-client3 libavahi-common-data 
libavahi-common3 libavc1394-0 libavcodec58
  libavfilter7 libavformat58 libavutil56 libbdplus0 libbluetooth3 libbluray2 
libbrlapi0.6 libbs2b0 libcaca0 libcacard0 libcairo-gobject2 libcairo2 
libcapstone3 libcdio18
  libcdparanoia0 libchromaprint1 libcodec2-0.8.1 libcolord2 libcroco3 libcups2 
libdatrie1 libdconf1 libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 
libdrm-radeon1
  libdrm2 libdv4 libdvdnav4 libdvdread4 libepoxy0 libfdt1 libfftw3-double3 
libflac8 libflite1 libfontconfig1 libfribidi0 libgbm1 libgdk-pixbuf2.0-0 
libgdk-pixbuf2.0-bin
  libgdk-pixbuf2.0-common libgl1 libgl1-mesa-dri libglapi-mesa libglib2.0-0 
libglib2.0-data libglvnd0 libglx-mesa0 libglx0 libgme0 libgomp1 libgpm2 
libgraphite2-3 libgsm1
  libgstreamer-plugins-base1.0-0 libgstreamer1.0-0 libgtk-3-0 libgtk-3-bin 
libgtk-3-common libgudev-1.0-0 libharfbuzz0b libibverbs1 libiec61883-0 
libigdgmm9 libjack-jackd2-0
  libjbig0 libjpeg62-turbo libjson-glib-1.0-0 libjson-glib-1.0-common 
liblcms2-2 liblilv-0-0 libllvm8 libmp3lame0 libmpeg2-4 libmpg123-0 libmysofa0 
libnl-3-200 libnl-route-3-200
  libnorm1 libnspr4 libnss3 libnuma1 libogg0 libopencore-amrnb0 
libopencore-amrwb0 libopenjp2-7 libopenmpt0 libopus0 liborc-0.4-0 
libpango-1.0-0 libpangocairo-1.0-0
  libpangoft2-1.0-0 libpciaccess0 libpcsclite1 libpgm-5.2-0 libpixman-1-0 
libpostproc55 libproxy1v5 libpulse0 libraw1394-11 librdmacm1 librest-0.7-0 
librsvg2-2 librsvg2-common
  librubberband2 libsamplerate0 libsensors-config libsensors5 libserd-0-0 
libshine3 libshout3 libsidplay1v5 libsnappy1v5 libsndfile1 libsodium23 
libsord-0-0 libsoup-gnome2.4-1
  libsoup2.4-1 libsoxr0 libspeex1 libspice-server1 libsratom-0-0 
libssh-gcrypt-4 libswresample3 libswscale5 libtag1v5 libtag1v5-vanilla 
libthai-data libthai0 libtheora0 libtiff5
  libtwolame0 libusbredirparser1 libv4l-0 libv4lconvert0 libva-drm2 libva-x11-2 
libva2 libvdeplug2 libvdpau-va-gl1 libvdpau1 libvidstab1.1 libvirglrenderer0 
libvisual-0.4-0
  libvorbis0a libvorbisenc2 libvorbisfile3 libvpx5 libvpx6 libvte-2.91-0 
libvte-2.91-common libwavpack1 libwayland-client0 libwayland-cursor0 
libwayland-egl1 libwayland-server0
  libwebp6 libwebpmux3 libx11-xcb1 libx264-155 libx265-176 libxcb-dri2-0 
libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-render0 libxcb-shm0 
libxcb-sync1 libxcb-xfixes0
  libxcomposite1 libxcursor1 libxdamage1 libxencall1 libxendevicemodel1 
libxenevtchn1 libxenforeignmemory1 libxengnttab1 libxenmisc4.11 libxenstore3.0 
libxentoolcore1
  libxentoollog1 libxfixes3 libxi6 libxinerama1 libxkbcommon0 libxrandr2 
libxrender1 libxshmfence1 libxtst6 libxv1 libxvidcore4 libxxf86vm1 libyajl2 
libzmq5 libzvbi-common
  libzvbi0 mesa-va-drivers mesa-vdpau-drivers ovmf qemu-system-common 
qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils seabios 
shared-mime-info va-driver-all
  vdpau-driver-all x11-common xdg-user-dirs
Suggested packages:
  gvfs i965-va-driver-shaders libasound2-plugins alsa-utils libbluray-bdj 
colord cups-common libdv-bin oss-compat libdvdcss2 libfftw3-bin libfftw3-dev 
gpm libvisual-0.4-plugins
  gstreamer1.0-tools jackd2 liblcms2-utils opus-tools pcscd pulseaudio 
libraw1394-doc librsvg2-bin lm-sensors serdi sidplay-base sordi speex samba 
vde2 qemu-block-extra sga

Bug#934070: Info received (Bug#934070 closed by Michael Tokarev (Re: Bug#934070: No support for HyperV synIC in machine type > pc-i440fx-3.0))

[Brian Wengel]

I withdraw my last mail...I've become wiser since! :-P
I was convinced I was using the correct  values in my Virt XML, but
I wasn't. The one listed on the linked bugzilla thread is of course the
correct ones.
Sorry for the noise.

On Thu, Aug 8, 2019 at 5:42 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian QEMU Team 
>
> If you wish to submit further information on this problem, please
> send it to 934...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 934070: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934070
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#934070: closed by Michael Tokarev (Re: Bug#934070: No support for HyperV synIC in machine type > pc-i440fx-3.0)

[Brian Wengel]

it's probably of my limit knowledge on the matter, but I still don't
understand why? I and would be very thankful if someone could explain the
issue?
If it is a needed hardware feature (CPU/Chipset), why does it work with
older machine types? Is it because QEMU is able to emulating this
*synic* feature
on those older machine types, and not the newer ones?



On Thu, Aug 8, 2019 at 5:18 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the qemu-kvm package:
>
> #934070: No support for HyperV synIC in machine type > pc-i440fx-3.0
>
> It has been closed by Michael Tokarev .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Michael Tokarev <
> m...@tls.msk.ru> by
> replying to this email.
>
>
> --
> 934070: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934070
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Michael Tokarev 
> To: Brian Wengel , 934070-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 8 Aug 2019 18:05:29 +0300
> Subject: Re: Bug#934070: No support for HyperV synIC in machine type >
> pc-i440fx-3.0
> 06.08.2019 20:31, Brian Wengel wrote:
> > Package: qemu-kvm
> > Version: 1:3.1+dfsg-7 (QEMU 3.1.0 / Kernel 4.19)
> []
> > "error: internal error: process exited while connecting to monitor:
> Hyper-V SynIC (requested by 'hv-synic' cpu flag) requires Hyper-V VP_INDEX
> > ('hv-vpindex')
> > 2019-08-06T13:29:14.114943Z qemu-system-x86_64: kvm_init_vcpu failed:
> Function not implemented"
>
> > https://bugzilla.redhat.com/show_bug.cgi?id=1738244
>
> As per https://bugzilla.redhat.com/show_bug.cgi?id=1738244#c6 (comment 6),
> this is expected behavour, so closing this bugreport.
>
> Thanks,
>
> /mjt
>
>
> -- Forwarded message --
> From: Brian Wengel 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 6 Aug 2019 19:31:56 +0200
> Subject: No support for HyperV synIC in machine type > pc-i440fx-3.0
>
> Package: qemu-kvm
> Version: 1:3.1+dfsg-7 (QEMU 3.1.0 / Kernel 4.19)
>
>
> Running Windows 10 guest build >= 1803 will give high host CPU usage (even
> though it's close to null in client) if you don't enable HyperV synIC which
> can i.a. be done in Virt XML:
>
> 
>
>
>
> *   *
>
> 
>
>
> But it seem only older machine types support this property.
> I've tested the following machine types:
>
>
> pc-i440fx-2.8 (OK)
> pc-i440fx-3.0 (OK)
> pc-i440fx-3.1 (Fail)
> pc-q35-3.1 (Fail)
>
>
> When starting the VM you get the error:
>
> "error: internal error: process exited while connecting to monitor:
> Hyper-V SynIC (requested by 'hv-synic' cpu flag) requires Hyper-V VP_INDEX
> ('hv-vpindex')
> 2019-08-06T13:29:14.114943Z qemu-system-x86_64: kvm_init_vcpu failed:
> Function not implemented"
>
> Attached a copy of a working XML. To reproduce just specify a newer
> machine type e.g. "pc-i440fx-3.1". I assume you don't need a working
> Windows image file, any qcow2 file will do.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1738244
>
>
> Best regards
> Brian
>

Bug#934070: No support for HyperV synIC in machine type > pc-i440fx-3.0

[Brian Wengel]

Package: qemu-kvm
Version: 1:3.1+dfsg-7 (QEMU 3.1.0 / Kernel 4.19)


Running Windows 10 guest build >= 1803 will give high host CPU usage (even
though it's close to null in client) if you don't enable HyperV synIC which
can i.a. be done in Virt XML:


   
   
   
*   *
   



But it seem only older machine types support this property.
I've tested the following machine types:


pc-i440fx-2.8 (OK)
pc-i440fx-3.0 (OK)
pc-i440fx-3.1 (Fail)
pc-q35-3.1 (Fail)


When starting the VM you get the error:

"error: internal error: process exited while connecting to monitor: Hyper-V
SynIC (requested by 'hv-synic' cpu flag) requires Hyper-V VP_INDEX
('hv-vpindex')
2019-08-06T13:29:14.114943Z qemu-system-x86_64: kvm_init_vcpu failed:
Function not implemented"

Attached a copy of a working XML. To reproduce just specify a newer machine
type e.g. "pc-i440fx-3.1". I assume you don't need a working Windows image
file, any qcow2 file will do.

https://bugzilla.redhat.com/show_bug.cgi?id=1738244


Best regards
Brian

  W10_tmp1
  eb67095c-f97b-4b98-8e88-635010602585
  Win10
  
http://libosinfo.org/xmlns/libvirt/domain/1.0";>
  http://microsoft.com/win/10"/>

  
  2097152
  2097152
  2
  
hvm
/usr/share/OVMF/OVMF_CODE.fd
/mnt/NVMe_OLD_ROOT/VMs/W10_tmpX.fd


  
  



  
  
  
  
  

  
  

  
  




  
  destroy
  restart
  destroy
  


  
  
/usr/bin/kvm

  
  
  
  


  
  
  
  


  


  


  



  


  


  
  
  
  


  

  


  


  
  


  




  


  
  


  

  

Bug#929508: ...and no model info the the actual LV where it would make sense

[Brian Wengel]

But It would make a lot of sense to assign a model value for LV device
itself, but this is omitted!
E.g. "LVM LV"

Bug#929508: lsblk doesn't show correct model when disk is converted to LVM Physical Volume

[Brian Wengel]

Package: util-linux
Version: 2.33.1



Example:

# lsblk -o +model
NAMEMAJ:MIN RM   SIZE RO TYPE MOUNTPOINT MODEL
sda   8:00 931.5G  0 diskLVM PV
8PrJ75-1Vo9-L9xM-TWAE-WRMn-Jcd3-G8oT9T on /dev/sda
└─VG_HDD-LV_HDD 253:00   300G  0 lvm  /mnt/VG_HDD-LV_HDD
sdb   8:16   0 465.8G  0 disk
HGST_HTS725050A7E630
sdc   8:32   0 298.1G  0 disk
WDC_WD3200BEKT-00F3T0
sdd   8:48   0 931.5G  0 disk
ST1000LM048-2E7172
nvme0n1 259:00 238.5G  0 diskSAMSUNG
MZVLB256HAHQ-0
├─nvme0n1p1 259:1071M  0 part /boot/efi
├─nvme0n1p2 259:20   1.4G  0 part
└─nvme0n1p3 259:30 4G  0 part /

It doesn't show the model, but a non-model property of the disk, in this
case some LVM informations.

The model is "*ST1000LM048-2E7172*" and it should show "*ST1000LM048-2E7172*"
for the model property!

If you want to know if the disk is a PV, put it in another lsblk
column/field or the user could use a LVM tool.

Don't hijack the model property! This is crazy, no matter how nice
something think it is to have this information in the model property. It's
just wrong!


Best regards

Brian Wengel

Denmark

Bug#925182: Feature request: Support for QEMU Virtio driver for CD-ROM

[Brian Wengel]

Package: debian-installer

Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16


When installing Debian as a guest in KVM/QEMU assigning the ISO to a CD-ROM
using Virtio or Virtio-SCSI as the bus type the debian-installer cannot see
the CD-ROM drive and ask for drivers.
I assume the Virtio drivers are not bundled/loaded in the installer. It
would be nice if it was :-)

In my benchmark of different bus types for CD-RO I got this read numbers:
-ata/ide: 541MB/s

-sata:  1,2GBs

-Virtio-SCSI:   3,6GB


Unfortunately I didn't test Virtio, but it should be at least just as fast
as the Virtio-SCSI
I've read from RHEL that Virtio is a little faster (at least for HDDs).

Bug#925105: closed by Steve McIntyre (Re: Bug#925105: CD-ROM is default repository, not mirror)

[Brian Wengel]

I would say It all depends if you select a mirror in the installation
process.
If you DO, I would claim must will prefer and expect it to be used as that
repository..
For those who don't select a mirror,of course the repository should be the
CD-ROM.
By the wayI believe the waste majority use ISO files -> USB flash, not
CD-ROM/DVD.
All in all, the current setup is for the few in favor of the majority, and
that's a wrong priority in my view (I don't have any facts and statistics
to back up my assertions, so I might be wrong).

I had the same battle with the OPNsense community about the old mindset of
CD/DVD (even floppy images).very very few use CD/DVD today, today you
use USB-Flash and net installs.
*I'm not saying CD/DVD shouldn't  be supported*, just don't have a mindset
about this is what most people use. It's not.
This goes for the website, dokumentation and how solutions are designed.
Having CD-ROM as the main repository is a good example.

Best regards
Brian W, Denmark





On Wed, Mar 20, 2019 at 5:42 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the debian-installer package:
>
> #925105: CD-ROM is default repository, not mirror
>
> It has been closed by Steve McIntyre .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Steve McIntyre <
> st...@einval.com> by
> replying to this email.
>
>
> --
> 925105: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925105
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Steve McIntyre 
> To: Brian Wengel , 925105-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 20 Mar 2019 16:38:52 +
> Subject: Re: Bug#925105: CD-ROM is default repository, not mirror
> Hi Brian,
>
> Thanks for your comments!
>
> On Tue, Mar 19, 2019 at 09:35:28PM +0100, Brian Wengel wrote:
> >Package: debian-installer
> >
> >Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16
> >
> >
> >After a clean installation this in the content of the sources.list:
> >
> ># deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64
> DVD
> >Binary-1 20190311-05:00]/ buster contrib main
> >
> >deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD
> >Binary-1 20190311-05:00]/ buster contrib main
> >
> >deb http://deb.debian.org/debian/ buster main
> >
> >deb-src http://deb.debian.org/debian/ buster main
> >
> >deb http://security.debian.org/debian-security buster/updates main
> contrib
> >
> >deb-src http://security.debian.org/debian-security buster/updates main
> contrib
> >
> >
> >I guess you can always argue if this is a bug.
> >But I will claim that by far the waste majority of Debian users want to
> have
> >the selected mirror in the installation to be the primary repository, not
> the,
> >in many ways, useless CD-ROM.
> >Wouldn't it be more fair that the very few that actually want the CD-ROM
> to be
> >the primary repositor, are the one who has to modify the sources.list?
> And not
> >the waste majority of the users.
> >And if they don't, they can just skip selecting a mirror in the
> installation,
> >and then the CD-ROM should be the repository.
>
> We already have logic in the installer in this area. If the user is
> using a netinst image or a live image, then we will *not* keep that
> image as a primary source once the installation is finished. But for
> larger images (DVD, BD) we keep it in the sources.list. It's a
> difficult choice to make reliably for everybody here...
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
>   Mature Sporty Personal
>   More Innovation More Adult
>   A Man in Dandism
>   Powered Midship Specialty
>
>
> -- Forwarded message --
> From: Brian Wengel 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 19 Mar 2019 21:35:28 +0100
> Subject: CD-ROM is default repository, not mirror
>
> Package: debian-installer
>
> Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16
>
>
> After a clean installation this in the content of the sources.list:
>
> # deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64
> DVD Binary-1 20190311-05:00]/ buster contrib main
>
> deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD
> Binary-1 20190311-05:00]/ buster contrib main
&

Bug#925105: CD-ROM is default repository, not mirror

[Brian Wengel]

Package: debian-installer

Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16


After a clean installation this in the content of the sources.list:

# deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64
DVD Binary-1 20190311-05:00]/ buster contrib main

deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD
Binary-1 20190311-05:00]/ buster contrib main

deb http://deb.debian.org/debian/ buster main

deb-src http://deb.debian.org/debian/ buster main

deb http://security.debian.org/debian-security buster/updates main contrib

deb-src http://security.debian.org/debian-security buster/updates main
contrib

I guess you can always argue if this is a bug.
But I will claim that by far the waste majority of Debian users want to
have the selected mirror in the installation to be the primary repository,
not the, in many ways, useless CD-ROM.
Wouldn't it be more fair that the very few that actually want the CD-ROM to
be the primary repositor, are the one who has to modify the sources.list?
And not the waste majority of the users.
And if they don't, they can just skip selecting a mirror in the
installation, and then the CD-ROM should be the repository.

install log attached.


Debian_install_logs.7z
Description: Binary data

Bug#924760: logfiles...

[Brian Wengel]

Here it is...sorry

(one of many symptoms of this last century bug system...I have to use an
obscure webmail because the bug system doesn't follow good practice of NOT
showing email addresses to the public. Of all people, the Debian techies
should know that)

On Sun, Mar 17, 2019 at 10:37 PM Samuel Thibault 
wrote:

> Brian Wengel, le dim. 17 mars 2019 22:19:57 +0100, a ecrit:
> > The problem seem to be related to XFS filesystem (of the root partition).
> > I hereby attach syslog and partman from the installation.
>
> Mmm, nothing was attached?
>
> Samuel
>


logfiles.7z
Description: application/7z

Bug#924760: logfiles...

[Brian Wengel]

The problem seem to be related to XFS filesystem (of the root partition).
I hereby attach syslog and partman from the installation.

Bug#924760: Grub is extremely picky in regards to partition

[Brian Wengel]

it seems the issue is the XFS root partition. Thought XFS was support by
both Debian and GRUB2?


KVM guest, qcow2 file, 50GB

EFI partiton(1) 300MB

ROOT: 53,4GB, ext4
OK!

EFI partiton(1) 37MB

ROOT: 53,5GB, ext4
OK

EFI partiton(1) 37MB

ROOT: 10GB
ok

EFI: 37MB

ROOT: 10GB, XFS
fail


On Sun, Mar 17, 2019 at 11:50 AM Samuel Thibault 
wrote:

> Control: tags -1 + moreinfo
>
> Hello,
>
> It is hard to understand what issue exactly you had, so we can only try
> to guess...
>
> Brian Wengel, le dim. 17 mars 2019 01:52:17 +0100, a ecrit:
> > I hope the installer could be a little more flexible in regards to  EFI
> > partition,
> [...]
> > Why put a size limit which is way larger than the technical limit?
>
> Which size limit are you talking about?  Which error message do you
> get exactly, at which point of the installation? Please never assume
> anything is obvious in a bug report.
>
> The one I can find in partman-efi, the source code about EFI partitions, is
>
> “
> "EFI System Partitions on this architecture cannot be created with a size "
> "less than 35 MB. Please make the EFI System Partition larger."
> ”
>
> which corresponds to
>
> # Experimentally-verified minimum size for a FAT32 filesystem created using
> # libparted.
>
> i.e. a technical limitation.
>
> I can not find anything in grub-installer. Perhaps the error message you
> are mentioning actually comes from grub, but without knowing the exact
> error message you got, it's very hard to tell.
>
> > But the installer absolutely want a very big partition.
>
> How big did you see it require?
>
> > There might be a technical reason, but I assume is just a matter of
> opinion,
> > right?
>
> By default, assume technical reason, not opinion. Perhaps it's just a
> bug in computing sizes. But without more information of the case you
> encountered, it's hard to determine what went wrong, so we need more
> information.
>
> Samuel
>

Bug#924760: Grub is extremely picky in regards to partition

[Brian Wengel]

Package: debian-installer
Version: Buster, debian-testing-amd64-DVD-1.iso, downloaded 2019-03-16

I hope the installer could be a little more flexible in regards to  EFI
partition, or is it because it require a SWAP partition, haven't been able
to point down the problem. Can only make a successful installation using
automatic.

Why put a size limit which is way larger than the technical limit?
This is Linux, not Apple or Windows!

I believe you can install grub2 on a 5MB FAT16 partition if you prefer.
But the installer absolutely want a very big partition.
There might be a technical reason, but I assume is just a matter of
opinion, right?
It fine it give a warning, but please let the user decide what to do. He
know what is best for him, not you. It is a very paternalistic attitude and
very far from the Linux spirit.

Bug#924730: "No kernel modules were found" using the direct online installer (virsh)

[Brian Wengel]

Package: debian-installer
Version: From testing,
http://httpredir.debian.org/debian/dists/buster/main/installer-amd64/

Installing Debian 10 as KVM/QEMU guest, host Debian 9.

Virsh-install command:
SCIO virt-install \
--virt-type kvm \
--name "Debian10" \
--vcpus 2 \
--memory 2048 \
--boot uefi \
--cpu host \
--os-variant debiantesting \
--features acpi=on \
--location
http://httpredir.debian.org/debian/dists/buster/main/installer-amd64/ \
--disk device=cdrom,bus=scsi \--disk device=disk,path="
/vm/Debian10/disk1.qcow2",format=qcow2,cache=unsafe,discard=unmap,bus=scsi \
--controller type=virtio-serial \
--controller type=scsi,model=virtio-scsi \
--network bridge=brLAN,model=virtio, \
--graphics vnc,port=5904,keymap=local,listen=0.0.0.0 \
--noautoconsole


Error, see attached screen-dump.
The installation went better using the DVD iso file.

Bug#924699: su root, doesn't have /usr/sbin/ in path

[Brian Wengel]

Well, it seems using "su root" doesn't give you a root session
with /usr/sbin/ included in the path. Just tested this in Debian 9, it
works in 9.

Bug#924699: CANCEL / REMOVE THIS BUG-REPORT

[Brian Wengel]

Sorry, my mistake!

It's actually the same design in Debian 9

 

(how do you remove a bug? Couldn't find anything about it on
https://wiki.debian.org/HowtoUseBTS and
https://www.debian.org/Bugs/Reporting)



smime.p7s
Description: S/MIME cryptographic signature

Bug#924699: Additinal info

[Brian Wengel]

I only get this problem when logon by the ”normal” user I’ve created in the
installer doing install.

If I do a “su root” the /usr/sbin is not included in the path either.



It works fine if I logon specific with root



I found this in /etc/profile



if [ "`id -u`" -eq 0 ]; then

  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

else

  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

Fi



I might be by design, but I believe this was not the design in Debian 9.

I my view it’s a problem, I wasted some time on this….I assume I’ll not be
the only one.
I first thought some packages were not installed correctly.

Bug#924699: installer doesn't include "/usr/sbin/" in the PATH environment

[Brian Wengel]

Package: debian buster installer (debian-testing-amd64-DVD-1.iso,
2019-03-16)

I assume it's not on purpose not to include "/usr/sbin/" in the PATH.
(I assume it's the installer that setup the path?)

On my new installed Debian Buster directly from DVD iso:

/# echo $PATH
*/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games*

Best regards
Brian W., Denmark

Bug#917051: Debian test (10) installer, storage issues

[Brian Wengel]

Package: installer (debian-testing-amd64-DVD-1.iso

2018-12-17)
Version: test

I experience two issues in regards to the Detect disk and Modify partitions
parts of the installer.
I have an Samsung NVMe PM981 500GB, the installer couldn't see the drive at
all!
Secondly I could not any option to delete an existing partition.

I think to recall I could do this in ver <= 9.6

Boot from USB flash, EFI.
CPU i3 6100
Chipset: Intel C236