VPN l2tp+ipsec: not work with last kernel 4.11.3-200
by Dario Lesca
Yesterday I have update my fedora 25 and after reboot VPN l2tp+ipsec do
not work anymore.
The connection happens without problem, the routing are set correctly,
the DNS (UDP protocol) and ping (ICMP protocol) to remote host work.
Only the access to some server, like ssh or smb:// (TCP protocol) do
not work, in this case, if I monitoring on remote server with tcpdump,
none arrives.
If I reboot with previous kernel (4.10.17) all work fine.
Some suggest?
Many thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 25 Workstation)
3 years
Difficulties at very first steps with f25kde ...
by Walter H.
Hello,
my older computer is a Core2Quad with 4 GB RAM had a hard disk with a
Windows 10
what I did:
- I plugged this harddisk as harddisk 2 and added an empty harddisk as
harddisk 1
- I downloaded Fedora 25 KDE (Fedora-KDE-Live-x86_64-25-1.3.iso) and
burnt this to a DVD
- I installed this onto harddisk 1, the boot menu entry for the 2nd
harddisk with Windows 10 was added automatically
I gave fixed IPv4 (an RFC1918 addr) and IPv6 (my HE tunnel
range) addresses
- after the first login I had to enable sshd - why isn't this
automatically? - with
systemctl enable sshd
systemctl start sshd
now I could do SSH from my newer computer (Windows)
- I did an yum update and this updated more than 800 packages and
downloaded nearly 1 GByte
after this I rebootet
- I successfully installed postfix as MTA and logwatch, works as
expected - why is the logwatch mail 'precedence bulk'?
- I also needed the graphical connection and found this:
https://www.server-world.info/en/note?os=Fedora_24&p=desktop&f=7
there I have a strange phenomen
after the connection with mstsc, I get a window where I can select
between Xvnc and Xorg, when selecting Xvnc and entering userid and
password
the window is closed and session blown away ...
when I select Xorg and enter userid and password the window stays
'green' forever
/var/log/xrdp.log shows this:
[20170604-21:40:08] [INFO ] starting xrdp with pid 1406
[20170604-21:40:10] [INFO ] listening to port 3389 on 0.0.0.0
[20170604-21:42:07] [INFO ] Socket 12: AF_INET connection received from 172.23.2.7 port 4333
[20170604-21:42:07] [DEBUG] Closed socket 12 (AF_INET 172.23.1.7:3389)
[20170604-21:42:07] [DEBUG] Closed socket 11 (AF_INET 0.0.0.0:3389)
[20170604-21:42:07] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20170604-21:42:07] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20170604-21:42:07] [DEBUG] TLSv1.2 enabled
[20170604-21:42:07] [DEBUG] TLSv1.1 enabled
[20170604-21:42:07] [DEBUG] TLSv1 enabled
[20170604-21:42:07] [DEBUG] Security layer: requested 1, selected 1
[20170604-21:42:07] [INFO ] connected client computer name: XP64WALDI01-W01
[20170604-21:42:07] [INFO ] TLS connection established from 172.23.2.7 port 4333: TLSv1 with cipher DES-CBC3-SHA
[20170604-21:42:07] [DEBUG] xrdp_00000604_wm_login_mode_event_00000001
[20170604-21:42:07] [INFO ] Cannot find keymap file /etc/xrdp/km-00020409.ini
[20170604-21:42:07] [INFO ] Loading keymap file /etc/xrdp/km-00000409.ini
[20170604-21:42:07] [WARN ] local keymap file for 0x00020409 found and doesn't match built in keymap, using local keymap file
[20170604-21:42:16] [DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350
[20170604-21:42:17] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20170604-21:42:17] [DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait...
[20170604-21:42:17] [DEBUG] return value from xrdp_mm_connect 0
[20170604-21:42:17] [INFO ] xrdp_wm_log_msg: login successful for display 10
[20170604-21:42:17] [DEBUG] xrdp_wm_log_msg: VNC started connecting
[20170604-21:42:18] [DEBUG] xrdp_wm_log_msg: VNC connecting to 127.0.0.1 5910
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC tcp connected
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC security level is 2 (1 = none, 2 = standard)
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC password ok
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC sending share flag
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC receiving server init
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC receiving pixel format
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC receiving name length
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC receiving name
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC sending pixel format
[20170604-21:42:20] [DEBUG] xrdp_wm_log_msg: VNC sending encodings
[20170604-21:42:21] [DEBUG] xrdp_wm_log_msg: VNC sending framebuffer update request
[20170604-21:42:21] [DEBUG] xrdp_wm_log_msg: VNC sending cursor
[20170604-21:42:21] [DEBUG] xrdp_wm_log_msg: VNC connection complete, connected ok
[20170604-21:42:21] [INFO ] The following channel is allowed: rdpdr (0)
[20170604-21:42:21] [INFO ] The following channel is allowed: rdpsnd (1)
[20170604-21:42:21] [INFO ] The following channel is allowed: drdynvc (2)
[20170604-21:42:21] [INFO ] The following channel is allowed: cliprdr (3)
[20170604-21:42:21] [DEBUG] The allow channel list now initialized for this session
[20170604-21:42:21] [DEBUG] xrdp_wm_log_msg: connected ok
[20170604-21:42:21] [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
[20170604-21:42:21] [DEBUG] Closed socket 18 (AF_INET 127.0.0.1:55588)
[20170604-21:42:22] [DEBUG] VNC got clip data
[20170604-21:42:22] [DEBUG] Closed socket 12 (AF_INET 172.23.1.7:3389)
[20170604-21:42:22] [DEBUG] xrdp_mm_module_cleanup
[20170604-21:42:22] [DEBUG] VNC mod_exit
[20170604-21:42:23] [DEBUG] Closed socket 19 (AF_INET 127.0.0.1:57730)
[20170604-21:42:23] [DEBUG] Closed socket 20 (AF_UNIX)
[20170604-21:42:23] [ERROR] Listening socket is in wrong state, terminating listener
[20170604-21:42:23] [CORE ] shutting down log subsystem...
/var/log/xrdp-sesman.log shows this:
[20170604-21:40:08] [DEBUG] libscp initialized
[20170604-21:40:09] [INFO ] starting xrdp-sesman with pid 1405
[20170604-21:40:10] [INFO ] listening to port 3350 on 127.0.0.1
[20170604-21:42:16] [INFO ] A connection received from 127.0.0.1 port 55588
[20170604-21:42:17] [INFO ] ++ created session (access granted): username walter, ip 172.23.2.7:4333 - socket: 12
[20170604-21:42:17] [INFO ] starting Xvnc session...
[20170604-21:42:17] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:5910)
[20170604-21:42:17] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:6010)
[20170604-21:42:17] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:6210)
[20170604-21:42:17] [DEBUG] Closed socket 8 (AF_INET 127.0.0.1:3350)
[20170604-21:42:17] [DEBUG] Closed socket 7 (AF_INET 127.0.0.1:3350)
[20170604-21:42:17] [DEBUG] Closed socket 8 (AF_INET 127.0.0.1:3350)
[20170604-21:42:18] [INFO ] Xvnc :10 -auth .Xauthority -geometry 1600x1200 -depth 32 -rfbauth/home/walter/.vnc/sesman_walter_passwd:10 -bs -nolisten tcp -localhost -dpi 96
[20170604-21:42:18] [CORE ] waiting for window manager (pid 1552) to exit
the 1600x1200 is a little bit bigger as the monitor of the older
computer itself, the newer has a 2560x1440
/etc/xrdp/sesman.ini has some weird content
[Xvnc]
param=Xvnc
param=-bs
param=-nolisten
param=tcp
param=-localhost
param=-dpi
param=96
[Xorg]
param=Xorg
param=-config
param=xrdp/xorg.conf
param=-noreset
param=-nolisten
param=tcp
param=-logfile
param=.xorgxrdp.%s.log
shouldn't this look like
[Xvnc]
param=-bs
param=-nolisten tcp
param=-localhost
param=-dpi 96
[Xorg]
param=-config xrdp/xorg.conf
param=-noreset
param=-nolisten tcp
param=-logfile .xorgxrdp.%s.log
the next strange thing in connection with firefox ...
when setting a proxy with DNS name, I get errors, that the proxy is not
found;
entering the IPv4 or IPv6 address this works ...
(entering host proxy.local it gives the IPv4 and IPv6 address - my
DNS is working properly)
Thanks for help or some explanation
Walter
3 years
Dependency failed for session? WTF?
by Tom Horsley
Anyone know what this gibberish that shows up in my
logwatch means?
Dependency failed for Session 10084 of user nvtest.: 1 Time(s)
Dependency failed for Session 10363 of user nvtest.: 1 Time(s)
...
Dependency failed for User Manager for UID 25130.: 59 Time(s)
session-10084.scope: Job session-10084.scope/start failed with result 'dependency'.: 1 Time(s)
session-10363.scope: Job session-10363.scope/start failed with result 'dependency'.: 1 Time(s)
...
user-25130.slice: Start request repeated too quickly.: 118 Time(s)
user(a)25130.service: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory: 196 Time(s)
user(a)25130.service: Job user(a)25130.service/start failed with result 'dependency'.: 59 Time(s)
Notes: User nvtest is UID 25130
tomh> ls -l /usr/lib/systemd/systemd
-rwxr-xr-x 1 root root 1641008 Feb 7 08:05 /usr/lib/systemd/systemd*
The CGROUP error makes no sense because /usr/lib/systemd/systemd clearly
does exist.
User nvtest is used to run testbeds via ssh, all those errors almost
certainly happened when a test run was using my system as a remote
test target and logging in via ssh for each individual test to run
a specific remote program (not a normal shell, though that remote
program usually starts a shell).
Meanwhile, despite all these silly errors in the log, the actual
test run appeared to work fine.
What new nonsense hath systemd wrought?
3 years
Fw: Systemd keeps trying to re-open an already active LUKS volume
by stan
Begin forwarded message:
I forwarded this to test since F26 is still not released, and they are
deciding whether to release this week. You are much more likely to get
an answer to your question there.
Date: Mon, 29 May 2017 16:46:05 +0200
From: Andrej Podzimek <andrej(a)podzimek.org>
To: users(a)lists.fedoraproject.org
Subject: Systemd keeps trying to re-open an already active LUKS volume
Hi,
I need a piece of advice concerning an encrypted root partition on
Fedora 26. I'm running a custom manual setup created using dnf.
Further context:
* The installation procedure is outlined in this tread -- and quite
likely irrelevant to this question anyway:
https://lists.fedorahosted.org/archives/list/users@lists.fedoraproject.or...
* The disk layout is described in this comment:
https://bugzilla.redhat.com/show_bug.cgi?id=1297188#c2
Unlike Fedora 23 and 24, both of which booted just fine, Fedora 26 has
two glitches related to my encrypted LUKS root partition:
1. Dracut fails to automatically add the crypt module. It doesn't seem
to care about LUKS-related settings in /etc/default/grub and/or about
the fact that the system runs off an encrypted volume. I had to
manually add add_dracutmodules+="crypt" into /etc/dracut.conf, or else
I wouldn't get a password prompt on boot and the early systemd would
freeze waiting for the root partition to appear. It works normally with
add_dracutmodules+="crypt".
2. Possibly as a consequence of (1), systemd doesn't realize that the
root partition has been already activated and luksOpen'ed at boot time
and keeps trying to unlock it over and over. The consoles are spammed
by messages like this one, basically on every sudo invocation: Password
entry required for 'Please enter passphrase for disk cryptprdell-luks
(plainprdell)!' (PID 5492). Please enter password with the
systemd-tty-ask-password-agent tool!
Of course I tried to run the systemd-tty-ask-password-agent tool and
type in the password. But then systemctl --failed showed a failure in
systemd-cryptsetup(a)plainprdell.service, the auto-generated unit for the
LUKS volume. Presumably, journalctl revealed that the error message had
been "Failed to activate: Device or resource busy". Well, that's indeed
what happens when you try to open a LUKS volume that's already opened.
If I don't use systemd-tty-ask-password-agent at all, systemctl status
permanently shows "starting" and never reaches "running", because of
the LUKS volume it thinks it needs to activate. (I tried systemctl
disable, but nope, that had no effect.)
This appears to have something in common with an ancient bug from 2013:
https://bugzilla.redhat.com/show_bug.cgi?id=924581
Has anything changed (1) in the way Dracut finds out whether the crypt
module is needed (which worked at least up to Fedora 24) or (2) in the
way systemd generates its automatic units for encrypted volumes?
Something must have changed, but I have no idea what it is and how to
get the old behavior back. :-/
My /etc/default/grub and /etc/crypttab are attached. The current kernel
version is 4.11.0-2.fc26.x86_64.
Cheers,
Andrej
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
3 years
kernel errors after updating to 4.11.3-200.fc25.x86_64
by François Patte
What is the meaning of these error messages:
WARNING: Kernel Errors Present
WARNING: CPU: 1 PID: 3538 at drivers/net/wireles ...: 1 Time(s)
iwlwifi 0000:0c:00.0: FH_TSSR_TX_ERROR_REG:
0X00000000 ...: 1 Time(s)
iwlwifi 0000:0c:00.0: FW error in SYNC CMD REPL ...: 1 Time(s)
iwlwifi 0000:0c:00.0: Microcode SW error detected. Resta ...: 1
Time(s)
iwlwifi 0000:0c:00.0: Start IWL Error Log Dump: ...: 1 Time(s)
Thank you.
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
3 years
nfs problem
by Eyal Lebedinsky
I asked on AskFedora and got no response. Hoping this list is more active.
https://ask.fedoraproject.org/en/question/104010/nfs-showing-bad-data-f24/
I have a f24 workstation (nfs client). It is updated regularly.
The server is f19, so no updates there.
A problem started in the last few weeks. When I examine a file on the server it
looks OK. The file is updated every minute (collecting some stats) and 'tail' shows
the added lines as they arrive.
Examining the same file from the workstation is initially OK, but then, as the file
grows, I get binary zeroes at the end of the file. The same with tail, less, vi, etc.
The amount of zeroes seems to be the size of the extra data appended to the file.
'ls' shows the actual (full) size of the file. It looks like the utilities see the
correct size but bad data is delivered at the tail.
After a few minutes the full data is showing but then, as the file grows, again I get
zeroes for a few minutes.
Where do I look next?
TIA
--
Eyal Lebedinsky (eyal(a)eyal.emu.id.au)
3 years
repomd.xml cannot verified at repo openh264/F26
by Robert Lu
Hi,all.
I meet this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1445817
When I run dnf upgrade, it faild:
Cannot download 'https://codecs.fedoraproject.org/openh264/26/x86_64/':
repomd.xml GPG signature verification error: Bad GPG signature.
Error: Failed to synchronize cache for repo 'fedora-cisco-openh264'
So, I tried to verify repomd.xml manually, the result is:
$gpg --list-keys
$gpg --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-26-x86_64
gpg: key 64DAB85D: public key "Fedora 26 Primary (26) <fedora-26-primary@
fedoraproject.org>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
$gpg --list-keys
/home/rlu/.gnupg/pubring.gpg
----------------------------
pub 4096R/64DAB85D 2016-09-09
uid Fedora 26 Primary (26) <fedora-26-primary@
fedoraproject.org>
$gpg --verify repomd.xml.asc repomd.xml
gpg: Signature made Sat 25 Mar 2017 02:41:50 AM CST using RSA key ID
64DAB85D
gpg: Good signature from "Fedora 26 Primary (26) <fedora-26-primary@
fedoraproject.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: E641 850B 77DF 4353 78D1 D7E2 812A 6B4B 64DA B85D
I think this is a success result.
But why dnf is failed?
--
Robert Lu <robberphex(a)gmail.com>
About me: http://about.me/RobberPhex
3 years
