Here I've a strange behavior:
Virtualbox (version 5) with 6 shares to windows host system.
Four of them working fine, two of them are read-only. Configuration is similar.
/etc/fstab:
download /media/sf_Download/ vboxsf defaults,_netdev,uid=1000,gid=1000,rw 0 0
p80 /media/sf_p80/ vboxsf defaults,_netdev,uid=1000,gid=1000,rw 0 0
p40 /media/sf_p40/ vboxsf defaults,_netdev,uid=1000,gid=1000,rw 0 0
p20 /media/sf_p20/ vboxsf defaults,_netdev,uid=1000,gid=1000,rw 0 0
musik /media/sf_musik/ vboxsf defaults,_netdev,uid=1000,gid=1000,rw 0 0
filme /media/sf_filme/ vboxsf defaults,_netdev,uid=1000,gid=1000,rw 0 0
the upper four are mounted r+w, all fine. but the lower two are read-only. Tryed several things (chown, chmod, etc), but nothing helped.
In case musik and filme are not mounted, ls -l delivers:
user#virtualxubuntu:/media$ ls -l
insgesamt 44
drwxrwxrwx+ 2 root vboxsf 4096 Jun 16 13:55 user
drwxrwxrwx 2 root vboxsf 4096 Jun 16 15:42 sf_filme
drwxrwxrwx 1 user user 4096 Jun 16 15:35 sf_Download
drwxrwxrwx 2 root vboxsf 4096 Jun 16 15:43 sf_musik
drwxrwxrwx 1 user user 20480 Mai 29 04:34 sf_p20
drwxrwxrwx 1 user user 4096 Mai 29 04:34 sf_p40
drwxrwxrwx 1 user user 4096 Mai 29 04:34 sf_p80
After mount -a I get:
user#virtualxubuntu:/media$ ls -l
insgesamt 252
drwxrwxrwx+ 2 root vboxsf 4096 Jun 16 13:55 user
dr-xr-xr-x 1 user user 98304 Jun 15 17:39 sf_filme
drwxrwxrwx 1 user user 4096 Jun 16 15:35 sf_Download
dr-xr-xr-x 1 user user 122880 Mär 31 13:07 sf_musik
drwxrwxrwx 1 user user 20480 Mai 29 04:34 sf_p20
drwxrwxrwx 1 user user 4096 Mai 29 04:34 sf_p40
drwxrwxrwx 1 user user 4096 Mai 29 04:34 sf_p80
Do you have any idea, how to fix it? The strange thing: this configuration worked months, 'til yesterday. And "I didn't changed anything." ;-)
kind regards
Johannes
Strange...
I added fmode and dmode options to the failing mounts and this helped...
musik /media/sf_musik/ vboxsf defaults,_netdev,uid=1000,gid=1000,rw,fmode=0644,dmode=0750 0 0
filme /media/sf_filme/ vboxsf defaults,_netdev,uid=1000,gid=1000,rw,fmode=0644,dmode=0750 0 0
Don't know why these two need this options...
Related
I would like to program the (MB1355C and/or MB1293C) devices from an STM32WB55 Nucleo Pack on my (Ubuntu 18.04.3 LTS) machine - preferably with the convenience of an eclipse based IDE that supports debugging features.
I installed
STM32CubeProgrammer (version 2.2.1)
Atolic TrueStudio (version 9.3.0)
STM32CubeIDE (version 1.1.0)
and I now have the following udev rules
chandran#chandran-OptiPlex-9020:~$ ll /etc/udev/rules.d/
total 160
drwxr-xr-x 2 root root 4096 Dec 13 14:11 ./
drwxr-xr-x 4 root root 4096 Dec 4 13:44 ../
-rw-rw-r-- 1 root root 270 Oct 14 18:10 49-stlinkv1.rules
-rw-rw-r-- 1 root root 270 Oct 14 18:10 49-stlinkv1.rules.O
-rw-rw-r-- 1 root root 464 Oct 14 18:10 49-stlinkv2-1.rules
-rw-rw-r-- 1 root root 464 Oct 14 18:10 49-stlinkv2-1.rules.O
-rw-rw-r-- 1 root root 278 Oct 14 18:10 49-stlinkv2.rules
-rw-rw-r-- 1 root root 278 Oct 14 18:10 49-stlinkv2.rules.O
-rw-r--r-- 1 root root 458 Dec 11 17:26 49-stlinkv3loader.rules
-rw-rw-r-- 1 root root 845 Oct 14 18:10 49-stlinkv3.rules
-rw-rw-r-- 1 root root 845 Oct 14 18:10 49-stlinkv3.rules.O
-rw-r--r-- 1 root root 381 Dec 6 17:10 '#61-msp430uif.rules#'
-rw-r--r-- 1 root root 381 Dec 4 15:09 61-msp430uif.rules
-rwxr-xr-x 1 root root 2145 Dec 4 15:09 70-mm-no-ti-emulators.rules*
-rw-r--r-- 1 root root 58549 Dec 4 12:29 70-snap.core.rules
-rw-r--r-- 1 root root 79 Dec 5 12:11 77-msp430-blacklist.rules
-rw-r--r-- 1 root root 0 Dec 5 12:10 77-msp430-blacklist.rules~
-rw-rw-r-- 1 root root 18450 Oct 14 17:33 99-jlink.rules
-rw-rw-r-- 1 root root 18450 Oct 14 17:33 99-jlink.rules.O
I am in the dialout group
chandran#chandran-OptiPlex-9020:~$ groups chandran
chandran : chandran adm dialout cdrom sudo dip plugdev lpadmin sambashare
I downloaded an example project called STM32100E-EVAL_USART_IrDA_Transmit and it builds successfully, but I get the following error message when I connect the evaluation board(s) and click on debug to flash the micro controller
ST-Link enumeration failed
Error in initializing ST-Link device.
Reason: (2) ST-Link DLL error.
I get the same error message when I try the above with STM32CubeIDE.
I have tried shifting JP1 as described in section 7.6 of the users manual but to no avail.
A previous question on stack overflow deals with the same error message so I got STM32CubeProgrammer to launch and tried making the changes suggested by #IsaBostan, but the development boards don't seem to be detected
How can I proceed to resolve this problem and program the boards?
Debugging ideas or suggestions are welcome, even if they haven't been tested...
It was just a question of permissions as suggested by KamilCuk
Launching TrueStudio as root and then clicking on debug solved the problem.
This is what worked on my machine:
sudo su
/opt/Atollic_TrueSTUDIO_for_STM32_x86_64_9.3.0/ide/./TrueSTUDIO
STM32CubeIDE's debugger also works when launched as follows on my machine:
sudo su
/opt/st/stm32cubeide_1.1.0/./stm32cubeide
and STM32CubeProgrammer connects to the device straight away when launched as follows:
sudo su
/usr/local/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/./STM32CubeProgrammer
My device shows up under /dev/ttyACM0 with the following permissions:
crw-rw----+ 1 root dialout 166, 0 Dec 28 11:56 ttyACM0
openocd and st-flash were not required.
I'm using kubeadm 1.15.3, docker-ce 18.09 on Debian 10 buster 5.2.9-2, and seeing errors in journalctl -xe | grep kubelet:
server.go:273] failed to run Kubelet: mountpoint for cpu not found
My /sys/fs/cgroup contains:
-r--r--r-- 1 root root 0 Sep 2 18:49 cgroup.controllers
-rw-r--r-- 1 root root 0 Sep 2 18:50 cgroup.max.depth
-rw-r--r-- 1 root root 0 Sep 2 18:50 cgroup.max.descendants
-rw-r--r-- 1 root root 0 Sep 2 18:49 cgroup.procs
-r--r--r-- 1 root root 0 Sep 2 18:50 cgroup.stat
-rw-r--r-- 1 root root 0 Sep 2 18:49 cgroup.subtree_control
-rw-r--r-- 1 root root 0 Sep 2 18:50 cgroup.threads
-rw-r--r-- 1 root root 0 Sep 2 18:50 cpu.pressure
-r--r--r-- 1 root root 0 Sep 2 18:50 cpuset.cpus.effective
-r--r--r-- 1 root root 0 Sep 2 18:50 cpuset.mems.effective
drwxr-xr-x 2 root root 0 Sep 2 18:49 init.scope
-rw-r--r-- 1 root root 0 Sep 2 18:50 io.pressure
-rw-r--r-- 1 root root 0 Sep 2 18:50 memory.pressure
drwxr-xr-x 20 root root 0 Sep 2 18:49 system.slice
drwxr-xr-x 2 root root 0 Sep 2 18:49 user.slice
docker.service is running okay and has /etc/docker/daemon.json:
{
"exec-opts": [
"native.cgroupdriver=systemd"
],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
The kubeadm docs say if using docker the cgroup driver will be autodetected, but I tried supplying it anyway for good measure - no change.
With mount or cgroupfs-mount:
$ mount -t cgroup -o all cgroup /sys/fs/cgroup
mount: /sys/fs/cgroup: cgroup already mounted on /sys/fs/cgroup/cpuset.
$ cgroupfs-mount
mount: /sys/fs/cgroup/cpu: cgroup already mounted on /sys/fs/cgroup/cpuset.
mount: /sys/fs/cgroup/blkio: cgroup already mounted on /sys/fs/cgroup/cpuset.
mount: /sys/fs/cgroup/memory: cgroup already mounted on /sys/fs/cgroup/cpuset.
mount: /sys/fs/cgroup/pids: cgroup already mounted on /sys/fs/cgroup/cpuset.
Is the problem that it's at cpuset rather than cpu? I tried to create a symlink, but root does not have write permission for /sys/fs/cgroup. (Presumably I can change it, but I took that as enough warning not to meddle.)
How can let kubelet find my CPU cgroup mount?
I would say that something very weird with your docker-ce installation and not kubelet. You are looking into the right direction showing mapping problem.
I have tried 3 different docker versions on both GCP and AWS environments instances.
What I have noticed comparing our results - you have wrong folder structure under /sys/fs/cgroup. Pay attention that I have much more permissions in /sys/fs/cgroup comparing to your output. This is how my results looks like:
root#instance-3:~# docker version
Client: Docker Engine - Community
Version: 19.03.1
API version: 1.39 (downgraded from 1.40)
Go version: go1.12.5
Git commit: 74b1e89
Built: Thu Jul 25 21:21:24 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.1
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 4c52b90
Built: Wed Jan 9 19:02:44 2019
OS/Arch: linux/amd64
Experimental: false
root#instance-3:~# ls -la /sys/fs/cgroup
total 0
drwxr-xr-x 14 root root 360 Sep 3 11:30 .
drwxr-xr-x 6 root root 0 Sep 3 11:30 ..
dr-xr-xr-x 5 root root 0 Sep 3 11:30 blkio
lrwxrwxrwx 1 root root 11 Sep 3 11:30 cpu -> cpu,cpuacct
dr-xr-xr-x 5 root root 0 Sep 3 11:30 cpu,cpuacct
lrwxrwxrwx 1 root root 11 Sep 3 11:30 cpuacct -> cpu,cpuacct
dr-xr-xr-x 2 root root 0 Sep 3 11:30 cpuset
dr-xr-xr-x 5 root root 0 Sep 3 11:30 devices
dr-xr-xr-x 2 root root 0 Sep 3 11:30 freezer
dr-xr-xr-x 5 root root 0 Sep 3 11:30 memory
lrwxrwxrwx 1 root root 16 Sep 3 11:30 net_cls -> net_cls,net_prio
dr-xr-xr-x 2 root root 0 Sep 3 11:30 net_cls,net_prio
lrwxrwxrwx 1 root root 16 Sep 3 11:30 net_prio -> net_cls,net_prio
dr-xr-xr-x 2 root root 0 Sep 3 11:30 perf_event
dr-xr-xr-x 5 root root 0 Sep 3 11:30 pids
dr-xr-xr-x 2 root root 0 Sep 3 11:30 rdma
dr-xr-xr-x 5 root root 0 Sep 3 11:30 systemd
dr-xr-xr-x 5 root root 0 Sep 3 11:30 unified
root#instance-3:~# ls -la /sys/fs/cgroup/unified/
total 0
dr-xr-xr-x 5 root root 0 Sep 3 11:37 .
drwxr-xr-x 14 root root 360 Sep 3 11:30 ..
-r--r--r-- 1 root root 0 Sep 3 11:42 cgroup.controllers
-rw-r--r-- 1 root root 0 Sep 3 11:42 cgroup.max.depth
-rw-r--r-- 1 root root 0 Sep 3 11:42 cgroup.max.descendants
-rw-r--r-- 1 root root 0 Sep 3 11:30 cgroup.procs
-r--r--r-- 1 root root 0 Sep 3 11:42 cgroup.stat
-rw-r--r-- 1 root root 0 Sep 3 11:42 cgroup.subtree_control
-rw-r--r-- 1 root root 0 Sep 3 11:42 cgroup.threads
drwxr-xr-x 2 root root 0 Sep 3 11:30 init.scope
drwxr-xr-x 52 root root 0 Sep 3 11:30 system.slice
drwxr-xr-x 3 root root 0 Sep 3 11:30 user.slice
Encourage you completely reinstall docker from scratch(or recreate instance and install docker again). That should help.
Let me share with you my docker-ce installation steps:
$ sudo apt update
$ sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common
$ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
$ sudo apt update
$ apt-cache policy docker-ce
$ sudo apt install docker-ce=5:18.09.1~3-0~debian-buster
I have also seen a workaroung in Kubelet: mountpoint for cpu not found issue answer, but also dont have a permission under root to fix it:
mkdir /sys/fs/cgroup/cpu,cpuacct
mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct
The command mkdir creates a file rather than a directory on a mounted network drive on a windows 10 system operating under the Windows sub-system for linux, using the Ubuntu app.
After installing the ubuntu app and putting the windows machine into developer mode I successfully mounted a remote network drive using the command:
sudo mount -t drvfs '\\networkdrive\sharename' /mnt/U
which successfully mounts the network drive at the mount point. I can see the files on the remote drive. However when looking at a directory on the remote machine and issuing the command
mkdir Source
a file called Source is created on the remote drive rather than a directory.
I tried this on two completely different laptops running windows 10, which I set up in exactly the same way and the same problem happens. The windows 10 machines are in developer mode and running the latest version of the ubuntu app. This is a pretty fundamental thing to have go wrong so I'm guessing it's a bug of some sort.
The snippet below is the terminal output which illustrates the problem.
username#~$ pwd
/home/username
username#~$ sudo mount -t drvfs '\\networkdrive.host\sharename\' /mnt/U
[sudo] password for username:
username#~$ cd /mnt/U/People/username/projects/Vesiform
username#Vesiform$ ls -al
total 0
drwxrwxrwx 0 root root 512 Mar 29 2018 .
drwxrwxrwx 0 root root 512 Mar 28 12:04 ..
drwxrwxrwx 0 root root 512 Mar 28 11:12 Builder
drwxrwxrwx 0 root root 512 Mar 28 11:42 Library
drwxrwxrwx 0 root root 512 Mar 28 11:42 NPack
drwxrwxrwx 0 root root 512 Mar 28 11:42 PDBProc
drwxrwxrwx 0 root root 512 Mar 28 11:55 Projects
drwxrwxrwx 0 root root 512 Mar 28 11:55 SpacePack
drwxrwxrwx 0 root root 512 Mar 28 11:55 Utilities
username#Vesiform$ mkdir Source
username#Vesiform$ ls -al
total 0
drwxrwxrwx 0 root root 512 Mar 29 2018 .
drwxrwxrwx 0 root root 512 Mar 28 12:04 ..
drwxrwxrwx 0 root root 512 Mar 28 11:12 Builder
drwxrwxrwx 0 root root 512 Mar 28 11:42 Library
drwxrwxrwx 0 root root 512 Mar 28 11:42 NPack
drwxrwxrwx 0 root root 512 Mar 28 11:42 PDBProc
drwxrwxrwx 0 root root 512 Mar 28 11:55 Projects
-rwxrwxrwx 1 root root 0 Mar 29 2018 Source
drwxrwxrwx 0 root root 512 Mar 28 11:55 SpacePack
drwxrwxrwx 0 root root 512 Mar 28 11:55 Utilities
username#Vesiform$ cd Source
-bash: cd: Source: Not a directory
username#Vesiform$
When I run script as regular user manually, everything is OK. But if an email is received and piped into Go script, I can not open serial port because file does not exist.
postfix 1239 1025 0 13:20 ? 00:00:00 pipe -n watchParadox -t unix flags=F user=watch argv=/usr/local/bin/watch -paradox
watch 1240 1239 0 13:20 ? 00:00:00 /usr/local/bin/watch -paradox
Script is running under watch user who has been added to dialout group, postfix user, just to be sure, is in dialout also.
In my script I ran ls -la command to find out which files do truly exist:
drwxr-xr-x 6 root root 380 Feb 25 13:19 .
dr-xr-xr-x. 18 root root 4096 Feb 22 17:53 ..
lrwxrwxrwx 1 root root 11 Feb 25 13:19 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Feb 25 13:19 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Feb 25 13:19 full
drwxr-xr-x 2 root root 0 Feb 25 13:19 hugepages
lrwxrwxrwx 1 root root 28 Feb 25 13:19 log -> /run/systemd/journal/dev-log
drwxrwxrwt 2 root root 40 Feb 25 13:19 mqueue
crw-rw-rw- 1 root root 1, 3 Feb 25 13:19 null
lrwxrwxrwx 1 root root 8 Feb 25 13:19 ptmx -> pts/ptmx
drwxr-xr-x 2 root root 0 Feb 25 13:19 pts
crw-rw-rw- 1 root root 1, 8 Feb 25 13:19 random
drwxrwxrwt 2 root root 40 Feb 25 13:19 shm
lrwxrwxrwx 1 root root 15 Feb 25 13:19 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Feb 25 13:19 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Feb 25 13:19 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 Feb 25 13:19 tty
crw-rw-rw- 1 root root 1, 9 Feb 25 13:19 urandom
I am certain following file exists but is not shown when postfix pipe is executed.
crw-rw---- 1 root dialout 166, 0 25. úno 13.19 ttyACM0
I tried chmod 777 on the file but no luck in that department. Opening file via https://github.com/tarm/serial library which uses Go function:
os.OpenFile("ttyACM0", syscall.O_RDWR|syscall.O_NOCTTY|syscall.O_NONBLOCK, 0666)
results with
ttyACM0: no such file or directory
The problem is not the path because I tried relative (using chdir) and absolute with same exact outcome.
I even disabled SELinux which is not what I want to do but in search of solution I try anything.
Code is OK because manual execution of the script passes through properly. I think there is something wrong with Linux settings.
The correct path the ttyACM0 is /dev/ttyACM0. You define a udev rules to set the file mode when it attaches.
If that is not reachable from your program, it might be the case that your program runs chrooted().
It seems like it was truly Linux problem and some underlying fabrics of it which I do not understand. I was running Fedora25 but the problem does not occur on Debian8.
i'm trying to understand how linux device/driver model works and to do this i've written a little module. This module is simple, retrieves a pointer to a struct net_device (let's call it netdev) by the function dev_get_by_name(&init_net, "eth0"). Why the value of netdev->dev.bus is NULL? Should that pointer represent the bus_type structure on which my device is attached? The field netdev->parent->bus is however not NULL but it should represent the bus for eth controller...any explanation?
This is because your eth device, or better said its device "object" in the kernel, is not a bus and thus its bus value is left unitialized. But its parent device usually is on a bus and it is sufficient that the parent device knows the bus it is on, since both device eventually are linked during the driver initialization.
Let's have a look at an example: here is what I have in sysfs for my eth0 device (notice the device field):
$ ll /sys/class/net/eth0/
total 0
-r--r--r-- 1 root root 4096 May 20 11:10 address
-r--r--r-- 1 root root 4096 May 20 11:10 addr_len
-r--r--r-- 1 root root 4096 May 20 11:10 broadcast
-r--r--r-- 1 root root 4096 May 20 11:10 carrier
lrwxrwxrwx 1 root root 0 May 20 11:10 device -> ../../../devices/pci0000:00/0000:00:19.0
-r--r--r-- 1 root root 4096 May 20 11:10 dev_id
-r--r--r-- 1 root root 4096 May 20 11:10 dormant
-r--r--r-- 1 root root 4096 May 20 11:10 features
-rw-r--r-- 1 root root 4096 May 20 11:10 flags
-rw-r--r-- 1 root root 4096 May 20 11:10 ifalias
-r--r--r-- 1 root root 4096 May 20 11:10 ifindex
-r--r--r-- 1 root root 4096 May 20 11:10 iflink
-r--r--r-- 1 root root 4096 May 20 11:10 link_mode
-rw-r--r-- 1 root root 4096 May 20 11:10 mtu
-r--r--r-- 1 root root 4096 May 20 11:10 operstate
drwxr-xr-x 2 root root 0 May 20 11:10 power
drwxr-xr-x 2 root root 0 May 20 11:10 statistics
lrwxrwxrwx 1 root root 0 May 20 11:10 subsystem -> ../../net
-rw-r--r-- 1 root root 4096 May 20 11:10 tx_queue_len
-r--r--r-- 1 root root 4096 May 20 11:10 type
-rw-r--r-- 1 root root 4096 May 20 11:10 uevent
The link for the device is created from this code from the driver probe function, where netdev is the network device, and pdev the associated PCI device:
SET_NETDEV_DEV(netdev, &pdev->dev);
Which according to the documentation is:
/* Set the sysfs physical device reference for the network logical device
* if set prior to registration will cause a symlink during initialization.
*/
#define SET_NETDEV_DEV(net, pdev) ((net)->dev.parent = (pdev))
And here is what I have in the corresponding PCI device, that was set by SET_NETDEV_DEV (where you can notice the bus field):
$ ll /sys/devices/pci0000\:00/0000\:00\:19.0/
total 0
-rw-r--r-- 1 root root 4096 May 20 11:54 broken_parity_status
lrwxrwxrwx 1 root root 0 May 20 11:22 bus -> ../../../bus/pci
-r--r--r-- 1 root root 4096 May 20 11:07 class
-rw-r--r-- 1 root root 256 May 20 11:22 config
-r--r--r-- 1 root root 4096 May 20 11:54 device
lrwxrwxrwx 1 root root 0 May 20 11:22 driver -> ../../../bus/pci/drivers/e1000e
-rw------- 1 root root 4096 May 20 11:22 enable
-r--r--r-- 1 root root 4096 May 20 11:07 irq
-r--r--r-- 1 root root 4096 May 20 11:54 local_cpulist
-r--r--r-- 1 root root 4096 May 20 11:07 local_cpus
-r--r--r-- 1 root root 4096 May 20 11:22 modalias
-rw-r--r-- 1 root root 4096 May 20 11:22 msi_bus
lrwxrwxrwx 1 root root 0 May 20 11:22 net:eth0 -> ../../../class/net/eth0
drwxr-xr-x 2 root root 0 May 20 11:11 power
-r--r--r-- 1 root root 4096 May 20 11:22 resource
-rw------- 1 root root 131072 May 20 11:22 resource0
-rw------- 1 root root 4096 May 20 11:22 resource1
-rw------- 1 root root 32 May 20 11:22 resource2
lrwxrwxrwx 1 root root 0 May 20 11:22 subsystem -> ../../../bus/pci
-r--r--r-- 1 root root 4096 May 20 11:22 subsystem_device
-r--r--r-- 1 root root 4096 May 20 11:22 subsystem_vendor
-rw-r--r-- 1 root root 4096 May 20 11:22 uevent
-r--r--r-- 1 root root 4096 May 20 11:22 vendor
I hope this clarifies the situtation.