On 01/21/14 04:31, Joseph wrote: > On 01/20/14 19:49, Alan McKinnon wrote: >> On 01/20/14 19:41, Joseph wrote: >>> On 01/20/14 18:20, Helmut Jarausch wrote: >>> [snip] >>>> >>>> >>>> Hi, >>>> >>>> I have the same permissions and VirtualBox (4.3.6) runs just fine. >>>> VirtualBox is picky about the permission of the hard-disk image (VDI >>>> file) >>>> There it likes group vboxusers and group r/w permissions. >>>> >>>> Helmut >>> >>> Maybe I should recomplile VirtualBox after upgrading to "systemd" >>> >> >> >> That's worth a try - our devs don't make a habit of leaving you with >> broken systems they they didn't test :-) >> >> IOW, the software probably does work correctly out the box when built in >> the right order and etc-update run. >> >> we can look deeper into udev if that step doesn't work out >> >> -- >> Alan McKinnon >> [email protected] > > I recompile the VirtualBox-bin but it doesn't help it still complain > about the /dev/ttyS0 access > and upon rebooting the /dev/ttyS0 has permission and ownership as: > crw-rw---- 1 root dialout 4, 64 Jan 20 19:14 /dev/ttyS0 > > and it should be uucp:dialout (666) > > What is confusing me is that on one box systemd is upon reboot make > /dev/ttyS0: > crw-rw-rw- 1 uucp dialout 4, 64 Jan 20 14:30 /dev/ttyS0 > > and on another box it wirtes: > crw-rw---- 1 root dialout 4, 64 Jan 20 19:14 /dev/ttyS0 > > I don't remember writing any rules for ttyS0
There's a few ways this can come about. Most often you emerge something that wants to write new configs that are config-protected and you don't accept the changes. First step is to find what causes the difgfrent behaviour and you need to take a logical step-by-step approach Compare the udev rules files on both machines in /lib/udev and /etc/udev and make the non-working host the samne as the working one. Do these two machines run the same arch and have similar services running? -- Alan McKinnon [email protected]
