Bug#1068310: network-manager-openvpn: regression in 1.10.2-4+ does not accept a saved password from network-manager.
Package: network-manager-openvpn Version: 1.10.2-2 Severity: important Dear Maintainer, * What led up to the situation? Upgraded to network-manager-openvpn to 1.10.2-4 in testing which resulted in network-manager not accepting a saved password for setting up a openvpn connection. (password-flags=0). Syslog error message: NetworkManager[415994]: [1712096590.8934] vpn[]: secrets: failed to request VPN secrets #4: No agents were available for this request. * What exactly did you do (or not do) that was effective (or ineffective)? Upgraded to 1.10.2-4+b1 in unstable which also had the same issue. Eventually downgraded back to 1.10.2-2 which resolved the issue. * What was the outcome of this action? Downgrading to 1.10.2-2 resolved the issue and allowed for saved passwords to work in network-manager for openvpn connections. * What outcome did you expect instead? Expected password-flags=0 with username and password defined to work. -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 network-manager-openvpn depends on: ii adduser 3.137 ii libc6 2.37-15 ii libglib2.0-0t64 [libglib2.0-0] 2.78.4-6 ii libnm0 1.46.0-1 ii network-manager 1.46.0-1 ii openvpn 2.6.7-1 network-manager-openvpn recommends no packages. network-manager-openvpn suggests no packages. -- no debconf information
Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk
Copying /boot/grub/grub.cfg to /boot/efi/EFI/debian/ to replace the grub.cfg that was located there does allow for a complete boot. This does result in having to type in the unlock password a second time which is different than before. The contents of the /boot/efi/EFI/debian/grub.cfg was: cryptomount -u 707fed618803485ea28d54b3b229be77 cryptomount -u 2ef006b2262c49b5bac3a51ddefcbfe6 search.fs_uuid 904c1ede-e04b-4102-a982-2333af179474 root cryptouuid/707fed618803485ea28d54b3b229be77 cryptouuid/2ef006b2262c49b5bac3a51ddefcbfe6 set prefix=($root)'/activeroot/boot/grub' configfile $prefix/grub.cfg So I have 2 work arounds though for some reason when pasting from a pikvm after grub has loaded results in characters not always pasting correctly which make it more difficult to enter the password. - Adam Hough On Sun, May 14, 2023 at 12:06 AM Adam Hough wrote: > Package: grub-efi-amd64-bin > Version: 2.06-12 > Followup-For: Bug #924151 > > Dear Maintainer, > >* What led up to the situation? > Upgraded to the latest grub2 packages on 2023-05-02 and then had a > power outage today resulting in a reboot. > > grep grub dpkg.log | grep upgrade > 2023-05-02 16:44:00 upgrade grub-efi:amd64 2.06-8 2.06-12 > 2023-05-02 16:44:00 upgrade grub-efi-amd64:amd64 2.06-8 2.06-12 > 2023-05-02 16:44:01 upgrade grub2-common:amd64 2.06-8 2.06-12 > 2023-05-02 16:44:01 upgrade grub-efi-amd64-bin:amd64 2.06-8 2.06-12 > 2023-05-02 16:44:03 upgrade grub-ieee1275-bin:amd64 2.06-8 2.06-12 > 2023-05-02 16:44:05 upgrade grub-emu:amd64 2.06-8 2.06-12 > 2023-05-02 16:44:07 upgrade grub-common:amd64 2.06-8 2.06-12 > 2023-05-02 16:44:08 upgrade grub-efi-amd64-signed:amd64 1+2.06+8 1+2.06+12 > 2023-05-02 16:44:09 upgrade grub-firmware-qemu:amd64 2.06-8 2.06-12 > 2023-05-13 19:18:55 upgrade grub-efi:amd64 2.06-12 2.06-12 > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Current setup is a fully encrypted via luks1 BTRFS based root > partition spanning 2 SSD devices in a raid1 configuration. Each drive has a > ESP EFI partition on partition 2 and a Mdraid 10 on partition 3 with the > BTRFS root on partition 4. The first partition is a vfat partition to store > bios firmware updates and some recovery scripts information to make > recovery easier. > > On reboot, grub will ask for my password to decrypt the btrfs root > partitions. This is successful and will will load the grub screen. When > trying to boot the linux kernel entry there is an error as grub cannot find > the linux kernel. > > The command "search.fs_uuid 904c1ede-e04b-4102-a982-2333af179474 root > cryptouuid/707fed618803485ea28d54b3b229be77 > cryptouuid/2ef006b2262c49b5bac3a51ddefcbfe6" fails to find t > he uuid "904c1ede-e04b-4102-a982-2333af179474" so cannot find the vmlinuz > and initrd files. > > I have not tried the previous work around listed here yet. > >After a few hours switch to systemd-boot but would prefer to switch > back to a fully encrypted boot as the linux and initrd images are not in > the ESP partition. > >* What was the outcome of this action? > >The systemd-boot boot method did work. > >* What outcome did you expect instead? > >Expect it to work like it did previously as it did on the last boot on > Sat Mar 25 12:32:12 CET 2023 which was with grub 2.06-8. > > > -- Package-specific info: > > *** BEGIN /proc/mounts > /dev/mapper/crypt_samsung870evo / btrfs > rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/activeroot 0 0 > /dev/mapper/crypt_samsung870evo /mnt/btrfsrootencrypted btrfs > rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/ 0 0 > /dev/mapper/crypt_samsung870evo /timemachine_ahough01 btrfs > rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/timemachine_ahough01 0 0 > /dev/mapper/crypt_8tb1 /btrfs_pool btrfs > rw,relatime,compress=zlib:3,space_cache,subvolid=5,subvol=/ 0 0 > /dev/mapper/crypt_8tb1 /virt btrfs > rw,relatime,compress=zlib:3,space_cache,subvolid=263,subvol=/virt_machines > 0 0 > /dev/mapper/crypt_8tb1 /data btrfs > rw,relatime,compress=zlib:3,space_cache,subvolid=258,subvol=/data 0 0 > /dev/mapper/crypt_samsung870evo /var/lib/docker/btrfs btrfs > rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/activeroot 0 0 > /dev/nvme0n1p2 /boot/efi vfat > rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro > 0 0 > /dev/sdb2 /boot/efi2 vfat > rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro > 0 0 > /dev/nvme0n1p1 /mnt/VFATNVME vfat > rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro > 0 0 > /dev/sdb1 /
Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk
Package: grub-efi-amd64-bin
Version: 2.06-12
Followup-For: Bug #924151
Dear Maintainer,
* What led up to the situation?
Upgraded to the latest grub2 packages on 2023-05-02 and then had a power
outage today resulting in a reboot.
grep grub dpkg.log | grep upgrade
2023-05-02 16:44:00 upgrade grub-efi:amd64 2.06-8 2.06-12
2023-05-02 16:44:00 upgrade grub-efi-amd64:amd64 2.06-8 2.06-12
2023-05-02 16:44:01 upgrade grub2-common:amd64 2.06-8 2.06-12
2023-05-02 16:44:01 upgrade grub-efi-amd64-bin:amd64 2.06-8 2.06-12
2023-05-02 16:44:03 upgrade grub-ieee1275-bin:amd64 2.06-8 2.06-12
2023-05-02 16:44:05 upgrade grub-emu:amd64 2.06-8 2.06-12
2023-05-02 16:44:07 upgrade grub-common:amd64 2.06-8 2.06-12
2023-05-02 16:44:08 upgrade grub-efi-amd64-signed:amd64 1+2.06+8 1+2.06+12
2023-05-02 16:44:09 upgrade grub-firmware-qemu:amd64 2.06-8 2.06-12
2023-05-13 19:18:55 upgrade grub-efi:amd64 2.06-12 2.06-12
* What exactly did you do (or not do) that was effective (or
ineffective)?
Current setup is a fully encrypted via luks1 BTRFS based root
partition spanning 2 SSD devices in a raid1 configuration. Each drive has a ESP
EFI partition on partition 2 and a Mdraid 10 on partition 3 with the BTRFS root
on partition 4. The first partition is a vfat partition to store bios firmware
updates and some recovery scripts information to make recovery easier.
On reboot, grub will ask for my password to decrypt the btrfs root
partitions. This is successful and will will load the grub screen. When trying
to boot the linux kernel entry there is an error as grub cannot find the linux
kernel.
The command "search.fs_uuid 904c1ede-e04b-4102-a982-2333af179474 root
cryptouuid/707fed618803485ea28d54b3b229be77
cryptouuid/2ef006b2262c49b5bac3a51ddefcbfe6" fails to find t
he uuid "904c1ede-e04b-4102-a982-2333af179474" so cannot find the vmlinuz and
initrd files.
I have not tried the previous work around listed here yet.
After a few hours switch to systemd-boot but would prefer to switch back to
a fully encrypted boot as the linux and initrd images are not in the ESP
partition.
* What was the outcome of this action?
The systemd-boot boot method did work.
* What outcome did you expect instead?
Expect it to work like it did previously as it did on the last boot on Sat
Mar 25 12:32:12 CET 2023 which was with grub 2.06-8.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/crypt_samsung870evo / btrfs
rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/activeroot 0 0
/dev/mapper/crypt_samsung870evo /mnt/btrfsrootencrypted btrfs
rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/mapper/crypt_samsung870evo /timemachine_ahough01 btrfs
rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/timemachine_ahough01 0 0
/dev/mapper/crypt_8tb1 /btrfs_pool btrfs
rw,relatime,compress=zlib:3,space_cache,subvolid=5,subvol=/ 0 0
/dev/mapper/crypt_8tb1 /virt btrfs
rw,relatime,compress=zlib:3,space_cache,subvolid=263,subvol=/virt_machines 0 0
/dev/mapper/crypt_8tb1 /data btrfs
rw,relatime,compress=zlib:3,space_cache,subvolid=258,subvol=/data 0 0
/dev/mapper/crypt_samsung870evo /var/lib/docker/btrfs btrfs
rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/activeroot 0 0
/dev/nvme0n1p2 /boot/efi vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/sdb2 /boot/efi2 vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/nvme0n1p1 /mnt/VFATNVME vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/sdb1 /mnt/VFATSSD vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
insmod usb
insmod usb_keyboard
insmod ohci
insmod uhci
insmod ehci
insmod cryptodisk
insmod crypto
insmod search_fs_uuid
insmod search_label
insmod search
insmod btrfs
insmod part_gpt
insmod part_msdos
insmod luks
insmod disk
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function
Bug#891413: network-manager-pptp: PPTP connections fail on Authentication
Package: network-manager-pptp Version: 1.2.4-5+b1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? I did a normal apt upgrade which updated network-manager-pptp, network-manager, ppp, and pptp-linux to the latest testing versions as of 24Feb2018. This caused my PPTP vpn connection to fail to connect because of authentication issues with the MSCHAP and MSCHAPv2 protocals. Feb 25 02:10:11 localhost pppd[31955]: Plugin /usr/lib/pppd/2.4.7/nm-pptp-pppd-plugin.so loaded. Feb 25 02:10:11 localhost NetworkManager[16904]: Plugin /usr/lib/pppd/2.4.7/nm-pptp-pppd-plugin.so loaded. Feb 25 02:10:11 localhost pppd[31955]: pppd 2.4.7 started by root, uid 0 Feb 25 02:10:11 localhost systemd-udevd[31959]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Feb 25 02:10:11 localhost NetworkManager[16904]: [1519553411.5971] manager: (ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/6) Feb 25 02:10:11 localhost pppd[31955]: Using interface ppp0 Feb 25 02:10:11 localhost NetworkManager[16904]: Using interface ppp0 Feb 25 02:10:11 localhost NetworkManager[16904]: Connect: ppp0 <--> /dev/pts/7 Feb 25 02:10:11 localhost pppd[31955]: Connect: ppp0 <--> /dev/pts/7 Feb 25 02:10:11 localhost pptp[31960]: nm-pptp-service-31951 log[main:pptp.c:353]: The synchronous pptp option is NOT activated Feb 25 02:10:11 localhost NetworkManager[16904]: Error: either "to" is duplicate, or "uid" is a garbage. Feb 25 02:10:11 localhost NetworkManager[16904]: [1519553411.6134] devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0) Feb 25 02:10:11 localhost NetworkManager[16904]: [1519553411.6134] device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found. Feb 25 02:10:11 localhost pptp[32023]: nm-pptp-service-31951 log[ctrlp_rep:pptp_ctrl.c:259]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 25 02:10:11 localhost pptp[32023]: nm-pptp-service-31951 log[ctrlp_disp:pptp_ctrl.c:781]: Received Start Control Connection Reply Feb 25 02:10:11 localhost pptp[32023]: nm-pptp-service-31951 log[ctrlp_disp:pptp_ctrl.c:815]: Client connection established. Feb 25 02:10:12 localhost pptp[32023]: nm-pptp-service-31951 log[ctrlp_rep:pptp_ctrl.c:259]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 25 02:10:12 localhost pptp[32023]: nm-pptp-service-31951 log[ctrlp_disp:pptp_ctrl.c:900]: Received Outgoing Call Reply. Feb 25 02:10:12 localhost pptp[32023]: nm-pptp-service-31951 log[ctrlp_disp:pptp_ctrl.c:939]: Outgoing call established (call ID 62435, peer's call ID 51712). Feb 25 02:10:13 localhost pppd[31955]: MS-CHAP authentication failed: Feb 25 02:10:13 localhost NetworkManager[16904]: MS-CHAP authentication failed: Feb 25 02:10:13 localhost NetworkManager[16904]: CHAP authentication failed Feb 25 02:10:13 localhost pppd[31955]: CHAP authentication failed Feb 25 02:10:13 localhost pppd[31955]: Connection terminated. Feb 25 02:10:13 localhost NetworkManager[16904]: Connection terminated. Feb 25 02:10:13 localhost charon-nm[31069]: 13[KNL] interface ppp0 deleted * What exactly did you do (or not do) that was effective (or ineffective)? Downgrading just pptp-linux was not effective so I also downgraded the following packages as well to get ppp to version 2.7.4-1+4: gir1.2-nma-1.0 libnma0 network-manager network-manager-gnome network-manager-pptp network-manager-pptp-gnome ppp pptp-linux pptpd * What was the outcome of this action? After downgrading the packages, The PPTP base vpn connection is working. * What outcome did you expect instead? I would have expected that the upgrade would not have broken MSCHAP and MSCHAPv2 authenthication. -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 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 network-manager-pptp depends on: ii libc62.26-6 ii libglib2.0-0 2.54.3-2 ii libnm0 1.10.4-1+b1 ii network-manager 1.10.4-1 ii ppp 2.4.7-2+1 ii pptp-linux 1.9.0+ds-2 network-manager-pptp recommends no packages. network-manager-pptp suggests no packages. -- no debconf information
