Search results

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...

root@pve:~# pveversion -v proxmox-ve: 6.4-1 (running kernel: 5.4.124-1-pve) pve-manager: 6.4-13 (running version: 6.4-13/9f411e79) pve-kernel-5.4: 6.4-5 pve-kernel-helper: 6.4-5 pve-kernel-5.3: 6.1-6 pve-kernel-5.4.128-1-pve: 5.4.128-1 pve-kernel-5.4.124-1-pve: 5.4.124-2...

It seems to be stuck in the same position again now: INFO: starting new backup job: vzdump 104 --quiet 1 --node pve --storage local --mailnotification failure --compress zstd --all 0 --mode stop INFO: Starting Backup of VM 104 (lxc) INFO: Backup started at 2021-08-10 11:49:59 INFO: status =...

I completely forgot that it was set to stop mode. Now the new scheduled backup is using snapshot too which will of course show nothing new. I'll try another schedule, hopefully with the correct settings this time :oops:

Sure! :) And yes, I did test Stop manually and by using the failed command from the log (lxc-stop -n 104 --nokill --timeout 600) but I'm guessing those two methods are the same behind the scenes. I'm not sure it actually failed to stop unless I'm misunderstanding your question. It did stop (I...

Yes, it is 104 that hangs. It stops normally and it also run backup fine if I do so manually. I don't believe there's anything special about it. I just installed the Ubuntu 20.04.2 LTS CT and then PFELK. I took a snapshot after OS install, after install of PFELK and one later. I believe the only...