Recent content by TheForumTroll

That is way over my head, but I can add that I created all the containers in the Proxmox 7 and 8 web UI guide - including the root disks - so what you see is made by Proxmox by default.

I'm sorry, I cut out too much of the code for it to make sense. Yes, it is indeed fdisk -l that gives this warning. No, the original server with the containers are no longer around, and no, there are no errors on the actual disks. On the physical disks, yes, on the CTs themselves, no. So, I...

Hello experts :) I just upgraded to a new server and I'm currently restoring containers. Some of them have GPT corruption warnings. Example: Disk /dev/mapper/pve-vm--100--disk--0: 8 GiB, 8589934592 bytes, 16777216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical)...

As it seems I can't stop this warning from happening I need to turn it off until I find a fix as it spams my logging server and might hide more important alerts. However I can't seem to make it stop: /proc/sys/net/ipv4/conf/all/log_martians = 0 net.ipv4.conf.all.log_martians = 0...

Small update: Changing the ageing timeout didn't fix it. Still have a log full of IPv4: martian source 192.168.20.102 from 192.168.20.102, on dev eth1 Eth1 is 192.168.20.102 so why it is a martian package I don't know.

Oh, brainfart. Minutes vs seconds :oops:

300 seconds (5 hours) is the default in both Cisco and HP switches. It is much higher than the approx. 15-25 minutes intervals I'm seeing.

The switches are at 300 seconds timeout. I'm not sure where I see what timeout OPNsense use but a quick Google search tell me it is 20 minutes. I have no idea if that is correct though. I'll see what I can find.

I'm not very knowledgable in networking, but I interpret it as data is in fact between eth0 and eth1 on the same host. The header MAC addresses from the syslog fit the MAC addresses from the ip command. But I have no idea why this happens and why it isn't blocked when the firewall is turned on...

~# ip -details link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 2: eth0@if10...

As far as I can tell the network works fine. ~# ip -details a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535...

Hello experts! I'm seeing a lot of martian sources in my pve syslog log which has me rather confused as it seems to be from a host to the same host: IPv4: martian source 192.168.20.102 from 192.168.20.102, on dev eth1 ll header: 00000000: 4e a8 57 59 29 13 e4 11 5b 9b 99 81 08 00 IPv4: martian...

Bingo! Killing the Java process made the CT stop :) Edit: Well look at that, it even unlocked and booted up again by itself. Now, any idea what is going on? Just so if it is a bug I don't wipe the evidence..

4 0 25409 25406 20 0 6920 3348 do_wai Ss pts/8 0:00 \_ /bin/login -f 4 0 25433 25409 20 0 7648 4488 do_wai S pts/8 0:00 \_ -bash 4 0 25778 25433 20 0 11224 3672 - R+ pts/8 0:00 \_ ps faxl...

This one needs to be in multiple posts to fit in the limit! root@pve:~# ps faxl | grep -A30 104 1 0 104 2 20 0 0 0 smpboo S ? 0:00 \_ [ksoftirqd/15] 1 0 106 2 0 -20 0 0 worker I< ? 0:00 \_ [kworker/15:0H-kblockd] 5 0 107...