Le Mon, 10 Nov 2014 13:16:09 +0100, berenger.mo...@neutralite.org a écrit :
> Le 09.11.2014 05:05, Hendrik Boom a écrit : > > On Wed, 05 Nov 2014 09:32:57 -0500, Miles Fidelman wrote: > >> 1. What are your issues, reasons for doing so - general and/or > >> specific? > > > > I've had trouble with passwords in the network-manager starting a > > few months ago. I tried a few other wifi connectivity tools, and > > ended up > > with wicd. What was different about wicd was that (i) it worked, > > and (ii) it was independent of systemd. I don't know whether the > > introduction of expansion of systemd had anything to do with my > > problems. > > This might be a policykit-related issue. AFAIK, policykit has been > deprecated in favor of systemd-login0. > From what you describe, it seems the migration from policykit to > systemd-login0 (which is not systemd itself, but only a module. I > hope I'm not wrong here, since I do not really understand the > language used in systemd-world). Not exactly, polkit is still used by DE, but it now uses logind (instead of ConsoleKit) to track the users. You need to be sure that you have a logind session registered (see loginctl). If the session is not present, you need to check if pam_systemd.so is called in the PAM configuration (/etc/pam.d). > > > I've started to have trouble mounting the NTFS partition on my > > machine > > from Linux. No problem doing this in Windows, of course. I used > > to be > > able to mount it from the file manager after entering the root > > password. Starting a month or so ago, the file manager would > > tantalizingly show me the partition but refuse to let me mount it > > because > > I didn't have the proveleges. Finally, it stopped even showing me > > that > > partition. Of course I cann still log in as root and mount it from > > the > > command line, copy any files from it, and chown them to myself. > > But it > > is unnecessarily awkward. I understand systemd had involved itselg > > with > > permissions. Could this be relevant? I have the same problem with > > usb > > sticks -- having to be root to use them. Again, I have no idea > > whether > > the architecture changes caused by systemd has any relevance to > > this, but > > the general level of paranoia that is starting to exist makes me > > suspicious, perhaps unjustly. > > This could be udev-related. Udev is the part of the system which > fills /dev. > It does this at boot, and while your computer run. > > The current man-page says that, "the udev daemon, > systemd-udevd.service(8), receives device uevents directly from the > kernel whenever a device is added or removed from the system, or it > changes its state". > You can build rules in /etc/udev, which could eventually allow you to > fix your problem by yourself. I can't really help you about how to > write the rule, since I have never tried to build some myself. > Why things have stopped working, is a good question: maybe a change > in /dev/disk/by-uuid? Does things works anew if you create a user to > login with (and so, with a clear $HOME)? > > It seems that your problems seems to not be systemd-related, since > systemd is only the PID1 process' stuff. They are only related to > things which are parts of the systemd...hum... sorry, softwares which > shares the same source-code repository that systemd uses. > Yeah, some irony here, indeed. I won't argue about the fact that > udev/login0 are or are not parts of systemd. I do not mind, in facts. > IMHO the lack of permissions on a device could also be related to the lack of a logind session. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110140716.10142...@fornost.bigon.be
