I'm starting to use CoreOS (on AWS ECS). After having it launch my first container, I see this in journalctl:
Could not generate persistent MAC address for vethXXXX: No such file or directory
Here's more context. I've removed the time and instance information, but this is all within the same second. Note there are two distinct veth entries. I don't know if that means anything.
systemd[1]: Started docker container 1234
systemd[1]: Starting docker container 1234
dockerd[595]: time="2015-07-23T23:30:52Z" level=info msg="GET /v1.17/containers/1234/json"
dockerd[595]: time="2015-07-23T23:30:52Z" level=info msg="+job container_inspect(1234)"
systemd-timesyncd[473]: Network configuration changed, trying to establish connection.systemd-udevd[7501]: Could not generate persistent MAC address for vethYYYY: No such file or directory
kernel: device vethXXXX entered promiscuous mode
kernel: IPv6: ADDRCONF(NETDEV_UP): vethXXXX: link is not ready
systemd-udevd[7508]: Could not generate persistent MAC address for vethXXXX: No such file or directory
systemd-networkd[497]: vethXXXX: Configured
kernel: eth0: renamed from vethYYYY
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethXXXX: link becomes ready
kernel: docker0: port 2(vethXXXX) entered forwarding state
kernel: docker0: port 2(vethXXXX) entered forwarding state
systemd-networkd[497]: vethXXXX: Gained carrier
I found a discussion of this error on Ubuntu and it comes down to removing a udev rule, which doesn't seem to exist on CoreOS. There's a discussion about iptables with OpenVPN, which again doesn't seem to apply. Here's a bridge rule for LXC on Ubuntu. Again, I don't see how to apply that.
I haven't done anything with the networkd or flannel configuration. If the problems are in that area, I need specific steps on how to fix it for use in AWS ECS.
I had similar issue with a systemd service which creates a dev, then I figured out service type was "simple" fixed by changing this to "forking" (Type=forking)
I found this problem at own ubuntu 18.4 at 2021 year.
Problem was: /etc/docker/daemon.json { "iptables" : false }
after changing to { "iptables" : true } and restart docker - no more problems.
Related
I am currently working on the ARM Cortex-M4 inside the NXP i.MX8M Mini.
I am able to compile a project for M4 on Eclipse IDE on an Ubuntu VM.
I would now like to debug on the M4 via a SEGGER Flasher ARM probe, still from Ubuntu.
My probe is well recognized by Ubuntu, and I can launch the J-Link GDB server by simply typing the command :
$ sudo ./JLinkGDBServerCLExe
However, if I type the same command without sudo, I get :
$ ./JLinkGDBServerCLExe
SEGGER J-Link GDB Server V7.58b Command Line Version
JLinkARM.dll V7.58b (DLL compiled Nov 16 2021 15:04:27)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: yes
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: Unspecified
Target interface: JTAG
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
Connecting to J-Link failed. Connected correctly?
GDBServer will be closed...
Shutting down...
Could not connect to J-Link.
Please check power, connection and settings.
My problem is that when I start eclipse, I get the same result as starting the GDB server without sudo.
It seems that this is a rights issue, how can I solve it?
As #KamilCuk said, the problem came from the udev rules.
So you just have to copy the rules provided by Segger with J-Link Software on the system:
$ sudo cp 99-jlink.rules /etc/udev/rules.d
Then you have to reboot the system:
$ reboot
I have a VM backed by vCenter.
vCenter ESXi have physical adapter "Broadcom BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller" and SR-IOV enabled on this.
VM is connected to 1mgmt network (vmxnet3) and 2 SR-IOV adapters (SRIOVPassthrough).
Upon booting of the VM, only 2 networks shown up. (1mgmt and 1SR-IOV).
Journalctl -k logs showed following error.
[ 4832.408471] bnxt_en 0000:13:00.0 (unnamed net_device) (uninitialized): Error (timeout: 500015) msg {0x0 0x0} len:0
[ 4832.408930] bnxt_en: probe of 0000:13:00.0 failed with error -1
Reboot of machine did not help at all.
For the successful one adapter
bnxt_en 0000:03:00.0 eth1: NIC Link is Up, 25000 Mbps full duplex, Flow control: ON - receive & transmit
bnxt_en 0000:03:00.0 eth1: FEC autoneg off encodings: None
I did rescan of the pci devices and did multiple times reboot without any success.
Any pointers would be really helpful
We've got a similar issue and were able to fix it.
In our case we had the same error message on Debian 10, 11 and Oracle Linux 8 but we installed it directly on hardware without an hypervisor.
But it could be the same issue cause you're using passthrough.
There are two ways to fix it:
Usage of UEFI Boot
Disable PXE Boot and keep Bios / Legacy Boot
Both options fixed it.
Disabling PXE didn't work for us, but we can get the ports back online, by running
echo 0000:af:00.0 > /sys/bus/pci/drivers/bnxt_en/bind
Where 0000:af:00.0 is the PCI number for the port, which can be gotten from dmesg | grep bnxt_en and looking for the port or ports that failed.
I have the error "no drm device found" as shown below.
I thinks the mail error is fatal: failed to create compoitor backend.
I have the following in my lib
desktop-shell.so drm-backend.so fbdev-backend.so fullscreen-shell.so gl-renderer.so hmi-controller.so ivi-shell.so wayland-backend.so x11-backend.so
root#salvator-x:/etc/systemd/system/multi-user.target.wants# /usr/bin/weston-launch \
-u root -- --idle-time=0 --config=/etc/xdg/weston/weston-drm-hdmi.ini $OPTARGS
Date: 2018-02-26 UTC
[21:29:08.949] weston 1.11.0
http://wayland.freedesktop.org
Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.11.0
Build: a9df8430-dirty v4l2-renderer: Fix calcluation of clip region (2017-04-13 18:25:00 +0900)
[21:29:08.949] OS: Linux, 4.9.0-yocto-standard, #1 SMP PREEMPT Mon Feb 26 17:46:03 EST 2018, aarch64
[21:29:08.949] Using config file '/etc/xdg/weston/weston-drm-hdmi.ini'
[21:29:08.950] Output repaint window is 34 ms maximum.
[21:29:08.950] Loading module '/usr/lib/weston/drm-backend.so'
[21:29:08.954] initializing drm backend
[21:29:08.954] logind: failed to get session seat
[21:29:08.954] logind: cannot setup systemd-logind helper (-61), using legacy fallback
[21:29:08.955] no drm device found
[21:29:08.955] fatal: failed to create compositor backend
failed to restore keyboard mode: Bad file descriptor
failed to set KD_TEXT mode on tty: Bad file descriptor
could not reset vt handling
How do I launch weston on linux yocto?
Here is the image:
So.. I found the answer to my question
it has three errors logind (systemd) was having trouble access the input keyboard type
second one is drm device is not found which implies that you have trouble accesing your output port. try to troubleshoot the port make it accessible to the board and then try to launch weston with correct config.
NOTE: Weston wayland wont launch if you dont have keyboard or a mouse connected preferably a usb
Where are my iptables logging Blocked messages? I wonder if this is an OpenVZ issue or something from the scripted install. Note, I'm highly technical, but not a server admin. Could the OpenVZ host be blocking and logging outside of my VSP?
I have two newly installed machines running running text-mode CentOS 7 x64, yum up to date packages, and with iptables/CSF.
Also, I ensured machine #2 has all the packages that are on machine #1, though #2 has some extras.
OpenVZ VPS (installed with their image of CentOS 7 x64)
VMware VM (installed with official CentOS 7 x64 minimal mode)
I performed my extra installs/configs exactly the same on both machines, and I have these lines in /etc/csf/csf.conf
TESTING = "0"
TCP_IN = "22,80,443"
UDP_IN = ""
On the VM, I'm getting these /var/log/messages when I nmap scan it:
Apr 12 17:25:23 mach kernel: Firewall: *UDP_IN Blocked* IN=ens192 OUT= ...
Apr 12 17:25:55 mach kernel: Firewall: *TCP_IN Blocked* IN=ens192 OUT= ...
On the VPS, I'm NOT getting any Firewall /var/log/messages when I nmap scan it... but I think it is properly blocking traffic.
How do I even proceed/diagnose this?
I create an VM instance. I can connect to it as soon ad the SSH Daemon is started. But this is too early because kernel startup is only at approx. 30%. Is there a gcloud or other API to get the VM state when the kernel has finished startup?
Nov 18 10:58:51 image-name google: No startup script found in metadata.
Nov 18 10:58:53 image-name kernel: [ 27.491829] aufs au_opts_verify:1570:docker[2414]: dirperm1 breaks the protection by the permission bits on the lower branch
Nov 18 10:58:53 image-name kernel: [ 27.703142] aufs au_opts_verify:1570:docker[2414]: dirperm1 breaks the protection by the permission bits on the lower branch
Nov 18 10:58:53 image-name kernel: [ 27.735867] aufs au_opts_verify:1570:docker[2414]: dirperm1 breaks the protection by the permission bits on the lower branch
Nov 18 10:58:53 image-name kernel: [ 27.771732] aufs au_opts_verify:1570:docker[2260]: dirperm1 breaks the protection by the permission bits on the lower branch
Nov 18 10:58:53 image-name kernel: [ 27.797540] device vethfa3ab85 entered promiscuous mode
Nov 18 10:58:53 image-name kernel: [ 27.804420] IPv6: ADDRCONF(NETDEV_UP): vethfa3ab85: link is not ready
Nov 18 10:58:53 image-name kernel: [ 28.028306] IPv6: ADDRCONF(NETDEV_CHANGE): vethfa3ab85: link becomes ready
Nov 18 10:58:53 image-name kernel: [ 28.035505] docker0: port 1(vethfa3ab85) entered forwarding state
Nov 18 10:58:53 image-name kernel: [ 28.041963] docker0: port 1(vethfa3ab85) entered forwarding state
Nov 18 10:58:53 image-name kernel: [ 28.048532] IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready
Nov 18 10:58:54 image-name kernel: [ 28.980082] IPv6: eth0: IPv6 duplicate address fe80::42:acff:fe11:1 detected!
->>> about here I can SSH to the server
Nov 18 10:59:08 image-name kernel: [ 43.068094] docker0: port 1(vethfa3ab85) entered forwarding state
Nov 18 10:59:53 image-name kernel: [ 87.944452] aufs au_opts_verify:1570:docker[2864]: dirperm1 breaks the protection by the permission bits on the lower branch
Nov 18 10:59:53 image-name kernel: [ 88.001012] aufs au_opts_verify:1570:docker[2864]: dirperm1 breaks the protection by the permission bits on the lower branch
Nov 18 10:59:53 image-name kernel: [ 88.049510] aufs au_opts_verify:1570:docker[2815]: dirperm1 breaks the protection by the permission bits on the lower branch
->>> I want to know about this point in the startup process
My problem is that I can connect to it using SSH when kernel progress is below 30% and some processes are not yet started. I want to detect somehow if the server has completed startup. Or is there a script that can push to the server (through the GCE APIs) to notify me when a server is completely up?
gcloud compute instances describe image-name does return the same output from the moment the instance is started till the kernel startup is complete.
(In my case I use the Node.js GCE API, but this should not make any difference.)
Presently I am not aware of any such google native API that can provide a progress of instance start.
However this is a quick workaround check if this fits your requirement.
You can either use the Google Startup script or the native linux rc.local. The concept is the same, so explaining it for the case of rc.local [as it is generic and not tied to google]
We know that the last process in a bootup sequence that runs is rc.local. Any command or script or call that is in this rc.local [which is a sh or bash script by itself] will be executed at the end of boot process.
So the idea would be in the google image in case of rc.local, have a script or a call which send your a notification or writes a output to central system like KV or cloud storage the state that bootup is all done.
Similar to Kamran, but here is how I get this done. It depends on using a google startup script and an image where gcloud is installed by default (though you could rework this to just use curl and API calls)
On instance creation/configuration, I set a custom metadata flag: serverready=False
At the end of my google startup script, I have this:
sudo gcloud compute instances add-metadata $(hostname) \
--metadata serverready=True \
--zone $(curl \
"http://metadata.google.internal/computeMetadata/v1/instance/zone" \
-H "Metadata-Flavor: Google"|cut -d/ -f4)
When I run the instance creation, I can just poll the metadata for the serverready key, and set my app to wait until it sees serverready=True