[arch-general] coping with damaging updates
Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether. Is there some way to be fore-warned of these updates coming online and avoid them or be ready with clear info on how to repair the damage they are set to create. mick
On Thu, Oct 27, 2011 at 9:49 AM, Mick <bareman@tpg.com.au> wrote:
Is there some way to be fore-warned of these updates coming online and avoid them or be ready with clear info on how to repair the damage they are set to create.
mick
Read the mailing list.
On Thu, 27 Oct 2011 10:09:48 +0200 Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
On Thu, Oct 27, 2011 at 9:49 AM, Mick <bareman@tpg.com.au> wrote:
Is there some way to be fore-warned of these updates coming online and avoid them or be ready with clear info on how to repair the damage they are set to create.
mick
Read the mailing list.
I have just scanned the last 18 months of arch-general and arch-announce list archives and found nothing that looked even vaguely like "if you install this-package-update you will remove the ability to mount your USB stick" or "this update will prevent you from rebooting from within xfce" next idea mick
On Fri, Oct 28, 2011 at 01:43:11AM +1000, Mick wrote:
On Thu, 27 Oct 2011 10:09:48 +0200 Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
I have just scanned the last 18 months of arch-general and arch-announce list archives and found nothing that looked even vaguely like "if you install this-package-update you will remove the ability to mount your USB stick" or "this update will prevent you from rebooting from within xfce"
next idea
mick
You wont have any problems if you are using a proper login manager or have "exec ck-launc-session dbus-launch startxfce" in ya .xinitrc ^^
On 27-10-2011 17:24, Jesse Juhani Jaara wrote:
On Fri, Oct 28, 2011 at 01:43:11AM +1000, Mick wrote:
On Thu, 27 Oct 2011 10:09:48 +0200 Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
I have just scanned the last 18 months of arch-general and arch-announce list archives and found nothing that looked even vaguely like "if you install this-package-update you will remove the ability to mount your USB stick" or "this update will prevent you from rebooting from within xfce"
next idea
mick
You wont have any problems if you are using a proper login manager or have "exec ck-launc-session dbus-launch startxfce" in ya .xinitrc ^^
You only need 'exec ck-launch-session startxfce4' in .xinitrc because startxfce4 will call dbus-launch itself. And yes, I'm using xfce and everything works just fine, I don't use any login manager though, don't see the need for it :p -- Mauro Santos
Am Thu, 27 Oct 2011 17:49:13 +1000 schrieb Mick <bareman@tpg.com.au>:
Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.
Remove ck-launch-session from your ~/.xinitrc again. Change "exec ck-launch-session startxfce4" back to "exec startxfce4" and your user should be able to shut down from Xfce4 again. I don't know if this will fix your USB issues. Heiko
On 10/27/2011 04:15 AM, Heiko Baums wrote:
Am Thu, 27 Oct 2011 17:49:13 +1000 schrieb Mick<bareman@tpg.com.au>:
Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.
Remove ck-launch-session from your ~/.xinitrc again.
Change "exec ck-launch-session startxfce4" back to "exec startxfce4" and your user should be able to shut down from Xfce4 again. I don't know if this will fix your USB issues.
Is that true? I don't see it in the Arch announcements (also shown as news on the website), which I would hope it would be if it was a newly required change. (Also I last updated two days ago, still am using "exec ck-launch-session startxfce4", and haven't noticed anything being broken. Of course, I manually mounted my USB sticks with "sudo mount" anyway so I might not have noticed...) ~isaac
Am Thu, 27 Oct 2011 11:14:26 -0400 schrieb Isaac Dupree <ml@isaac.cedarswampstudios.org>:
Is that true? I don't see it in the Arch announcements (also shown as news on the website), which I would hope it would be if it was a newly required change.
(Also I last updated two days ago, still am using "exec ck-launch-session startxfce4", and haven't noticed anything being broken. Of course, I manually mounted my USB sticks with "sudo mount" anyway so I might not have noticed...)
It is true. Well, once in the past I suddenly only could logout with Xfce's logout dialog. After adding ck-launch-session I got the other options like "Reboot", "Shutdown", "Standby" and "Hibernation" back. After one of the latest updates I again could only logout with Xfce's logout dialog. Every other option was grayed out. After removing ck-launch-session from ~/.xinitrc I got the other options back again. I didn't change anything else in both cases. My user is in the right groups and has the correct rights. Heiko
On Thu, 27 Oct 2011 10:15:32 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
Am Thu, 27 Oct 2011 17:49:13 +1000 schrieb Mick <bareman@tpg.com.au>:
Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.
Remove ck-launch-session from your ~/.xinitrc again.
Change "exec ck-launch-session startxfce4" back to "exec startxfce4" and your user should be able to shut down from Xfce4 again. I don't know if this will fix your USB issues.
Heiko
made the change but it didn't work, if I can't find what they butchered this time before the night freight train to Cairns grinds past in half an hour I'll give up and re-install tomorrow. mick
On Thu, Oct 27, 2011 at 10:36 AM, Mick wrote:
... made the change but it didn't work, if I can't find what they butchered this time before the night freight train to Cairns grinds past in half an hour I'll give up and re-install tomorrow.
If you can't fix it in the current install, how is a re-install going to just "magically" fix things? Did you check .pacnew files? Have you messed up files that are changing the behavior of your system? You likely did not. The default behavior of stuff does often change. This is often due to upstream changes of packages. Many other distros try hard to shield you from those changes by over tweaking the defaults and always finding alternatives to upstream changes. They can become distanced with where the upstream really is. Arch is a lot more transparent in that regard, the end user is less shielded by the continual change within the free software community that provides the upstream for GNU/Linux and BSD systems. If you can't deal with being so exposed to upstream changes and are willing to adapt (like by learning udev rules to automatically let you use common usb media as a regular use) then Arch is likely not for you. If a re-install to fix your system you are doing it wrong. Fix the problems in your existing install or they will just come right back. Ok, if you have tweaked all your settings to no avail and have broken the system yourself, then yes, a re-install would give you a clean slate. Arch is not like windows was 10 years ago where you had to reinstall every 6 months just to get a stable system again. There is no "registry" in arch that one has to continually clean. With Arch you research problems and get to the bottom of what is causing it, and fix it, and learn a lot in the process. In the past year I can only think of only two updated packages that made me have to intervene BEFORE things broke: 1) changes in network configuration 2) changes in kernel naming There were other changes, but they were easy enough to just deal with as they happened. USB stuff did change, but since I'd already been writing udev rules for other stuff, it did not really affect me. Arch Linux should not be promoted as a system that will just work for you if you are not willing to get your hands dirty and research things to fix them. In my opinion Arch Linux is really for those who really would be better off running Linux From Scratch http://www.linuxfromscratch.org/ if they had the time and energy to do so, but want to use a distribution that takes care of all the laborious stuff so they can other stuff with their system(s). Arch is for experienced Linux users alreeady proficient at a nitty gritty configuration level, or those who want to become that type of user, and Arch goes out of it way to cater towards that type of user, and help you become that type of user.
On Thu, Oct 27, 2011 at 9:49 AM, Mick <bareman@tpg.com.au> wrote:
Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.
hello Indeed recent updateds did fuck around with group memberships, I had to add myself again to disk, camera and iirc video groups in /etc/group. I could swear I was a member in those groups before. There is no way to be forewarned about this stuff, but if you could please find out which updates are causing this stuff, we could inform the devs about it in a more precise fashion. The other fact is that recent udev changes modified many of the group-based permissions, which you can only solve with manual intervention. Solving these problems: USB sticks, cameras etc are basically represented as device nodes in /dev, eg. /dev/usb respectively. You can display those device nodes and their owner and group easily enough by printing them with ls -l: martti@deepthought:~$ ls -l /dev/sr0 brw-rw---- 1 root disk 11, 0 Oct 27 05:33 /dev/sr0 so, I have to check if I'm a member in group disk: martti@deepthought:~$ groups disk lp wheel video audio optical camera power vboxusers wireshark martti Oh, I am a member in that group and may access/mount that device. If I happen not to be, I can add myself to groups like so: # usermod -G <groups,comma,delimited> <user> cheers! mar77i
On Thu, 27 Oct 2011 16:45:20 +0200 Martti Kühne <mysatyre@gmail.com> wrote:
On Thu, Oct 27, 2011 at 9:49 AM, Mick <bareman@tpg.com.au> wrote:
Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.
hello
Indeed recent updateds did fuck around with group memberships, I had to add myself again to disk, camera and iirc video groups in /etc/group. I could swear I was a member in those groups before.
There is no way to be forewarned about this stuff, Somebody, probably upstream, made a decision to code this behaviour into the updated package therefore they can and should be documenting it.
but if you could please find out which updates are causing this stuff, we could inform the devs about it in a more precise fashion. If I manage to track it down I will be putting in bug reports.
The other fact is that recent udev changes modified many of the group-based permissions, which you can only solve with manual intervention.
Solving these problems: USB sticks, cameras etc are basically represented as device nodes in /dev, eg. /dev/usb respectively. You can display those device nodes and their owner and group easily enough by printing them with ls -l: martti@deepthought:~$ ls -l /dev/sr0 brw-rw---- 1 root disk 11, 0 Oct 27 05:33 /dev/sr0
so, I have to check if I'm a member in group disk: martti@deepthought:~$ groups disk lp wheel video audio optical camera power vboxusers wireshark martti
Oh, I am a member in that group and may access/mount that device. If I happen not to be, I can add myself to groups like so: # usermod -G <groups,comma,delimited> <user>
Just checked and I can't see any changes to what I set myself. [mick@cave ~]$ groups lp,wheel,log,locate,http,video,audio,optical,storage,scanner,camera,power,users,wireshark oops disk is missing, no, group disk exists and I am a member of it, its just the group command telling fibs. Sometimes this breakage is silently fixed at a subsequent update, otherwise I have stumbled on a fix by accident. mick
On (10/27/11 17:49), Mick wrote: -~> Following yet another update that has disabled user control of USB -~> sticks, cameras, etc. and blocked user from shutting down from the -~> desktop (in my case xfce4), I am at the end of my tether. -~> -~> Is there some way to be fore-warned of these updates coming online and -~> avoid them or be ready with clear info on how to repair the damage they -~> are set to create. -~> -~> mick OK, which update you are talking about? Shutdown problems probably come from upower. Your user would loose control of external devices only if you were in the storage/disk groups. Adding youself to these groups was your mistake, since unless you understand what you are doing, you should let console-kit do the permission granting. In fact, on a modern linux system you only have to be a member of 1 group: users. How do you start your desktop and do you have ck-launch-session running? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 10/27/11 at 11:24am, Leonid Isaev wrote:
you should let console-kit do the permission granting. In fact, on a modern linux system you only have to be a member of 1 group: users.
And wheel?
On (10/27/11 18:48), Manolo Martínez wrote: -~> On 10/27/11 at 11:24am, Leonid Isaev wrote: -~> > you should let console-kit do the permission granting. In fact, on a modern -~> > linux system you only have to be a member of 1 group: users. -~> -~> And wheel? Wheel has to done manually, of course. What *kit does, in a nutshell, is just elevate priviledges of local users over remote, so you can have control over devices attached to your machine. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 10/27/11 at 12:25pm, Leonid Isaev wrote:
On (10/27/11 18:48), Manolo Martínez wrote: -~> On 10/27/11 at 11:24am, Leonid Isaev wrote: -~> > you should let console-kit do the permission granting. In fact, on a modern -~> > linux system you only have to be a member of 1 group: users. -~> -~> And wheel?
Wheel has to done manually, of course. What *kit does, in a nutshell, is just elevate priviledges of local users over remote, so you can have control over devices attached to your machine. -- Should this be added to the Beginners' Guide at the wiki? I'm thinking of something ecumenical along the lines of "do it the usergroup way, or you may consider adding yourself to users and wheel and allow *kit to take care of the rest by launching your wm under a *kit-session.
Manolo --
On (10/27/11 21:34), Manolo Martínez wrote: -~> On 10/27/11 at 12:25pm, Leonid Isaev wrote: -~> > On (10/27/11 18:48), Manolo Martínez wrote: -~> > -~> On 10/27/11 at 11:24am, Leonid Isaev wrote: -~> > -~> > you should let console-kit do the permission granting. In fact, on a modern -~> > -~> > linux system you only have to be a member of 1 group: users. -~> > -~> -~> > -~> And wheel? -~> > -~> > Wheel has to done manually, of course. What *kit does, in a nutshell, is just -~> > elevate priviledges of local users over remote, so you can have control over -~> > devices attached to your machine. -~> > -- -~> Should this be added to the Beginners' Guide at the wiki? I'm thinking of -~> something ecumenical along the lines of "do it the usergroup way, or you may -~> consider adding yourself to users and wheel and allow *kit to take care of the -~> rest by launching your wm under a *kit-session. -~> -~> Manolo -~> -~> -~> -~> -- Well, there is a (probably outdated) section "Groups" at https://wiki.archlinux.org/index.php/Users_and_Groups, which can hold this note. But I completely miss the appeal of the wheel group. If you want root use su -, otherwise why do you need special priveledges? I would say, don't even mention it. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 10/27/2011 02:34 PM, Manolo Martínez wrote:
On 10/27/11 at 12:25pm, Leonid Isaev wrote:
Wheel has to done manually, of course. What *kit does, in a nutshell, is just elevate priviledges of local users over remote, so you can have control over devices attached to your machine.
Should this be added to the Beginners' Guide at the wiki? I'm thinking of something ecumenical along the lines of "do it the usergroup way, or you may consider adding yourself to users and wheel and allow *kit to take care of the rest by launching your wm under a *kit-session.
im not sure it's that cut-n-dry, or even a 1-to-1 relation. CK (which IIRC will be obsoleted altogether eventually by systemd facilities) offers finer grained access control than coarse FS groups can offer. i don't know a tremendous amount about CK, but i believe it works alongside polkit, which many applications now look to for authorization ... in a nutshell, apps may not *care* about FS perms because it is expected you are running an auth agent. the fact is people/users expect better/cleaner ... and actually *MORE* flexible ... ways to delegate both access and administration duties. this is what the "*kits" try to achieve, with dbus playing mediator. it's not all that different from pam_* modules -- sure, we could all be using /etc/passwd forever and a day, and many still are, but many contexts/installtions demand more ... OT example: https://fedorahosted.org/sssd/wiki/HOWTO_Configure http://fedoraproject.org/wiki/Features/SSSD ... depends polkit. i'd like to get that/freeipa2 up on arch. im afraid(?) the *kits are here to stay, desktop or server. -- C Anthony Risinger
On 27-10-2011 17:48, Manolo Martínez wrote:
On 10/27/11 at 11:24am, Leonid Isaev wrote:
you should let console-kit do the permission granting. In fact, on a modern linux system you only have to be a member of 1 group: users.
And wheel?
And video, uucp, kvm, just to name a few. -- Mauro Santos
On (10/27/11 19:29), Mauro Santos wrote: -~> On 27-10-2011 17:48, Manolo Martínez wrote: -~> > On 10/27/11 at 11:24am, Leonid Isaev wrote: -~> >> you should let console-kit do the permission granting. In fact, on a modern -~> >> linux system you only have to be a member of 1 group: users. -~> > -~> > And wheel? -~> > -~> -~> And video, uucp, kvm, just to name a few. -~> -~> -- -~> Mauro Santos Fine: s/modern linux system/modern linux desktop system/. But, are you sure you understand the difference between local and remote users? In fact, you don't need to be a member of video (at least my webcam works fine). Kvm is useful, but I wouldn't be surprised if in fedora 16 (and then in all other distros), kvm would be managed by ck as well. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 27-10-2011 19:59, Leonid Isaev wrote:
Fine: s/modern linux system/modern linux desktop system/. But, are you sure you understand the difference between local and remote users?
According to the documentation, local users are the ones that have access to a physical keyboard, mouse and display. I can see the benefits of not granting full privileges to a remotely connected user, but that's not what I was on about.
In fact, you don't need to be a member of video (at least my webcam works fine). Kvm is useful, but I wouldn't be surprised if in fedora 16 (and then in all other distros), kvm would be managed by ck as well.
Webcam also works fine here without me being in video group, must have been a leftover before *kit took care of it, I stand corrected on that one. The others still stand and the thing is you can't be only part of the users group and do everything, in time maybe you can but right now you can't. -- Mauro Santos
On Thu, Oct 27, 2011 at 6:24 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
OK, which update you are talking about?
Shutdown problems probably come from upower. Your user would loose control of external devices only if you were in the storage/disk groups. Adding youself to these groups was your mistake, since unless you understand what you are doing, you should let console-kit do the permission granting. In fact, on a modern linux system you only have to be a member of 1 group: users.
How do you start your desktop and do you have ck-launch-session running?
Personally I'm not using neither gui file browser nor consolekit session and make use of the group based permission because I know how to handle things, and I can look up eventual barriers in my way quickly and reliably enough. I mount usb drives manually and generally lay hands on my system to keep things running, I mean, in a sane way. This is the first time I hear that this way of treating things would be discouraged, and I'm asking myself if this is just a sysadmin's gripe and if it will be possible in the future. Let's say I'm pretty sure it will be possible, since I guess I'm not the only one who avoids these additional sources of errors aka. software layers like ck/dbus/stuff. I left $certain-other-distro for some reason, and don't want to be forced back on this layer cake again. Also reminds me of this morning's xorg-xdm bug report I wrote which made dbus on a system level necessary, all of a sudden... Things go on like this and I'll remove my Xorg and run frambuffer only from now on. :-) cheers! mar77i
On 10/27/2011 12:14 PM, Martti Kühne wrote:
On Thu, Oct 27, 2011 at 6:24 PM, Leonid Isaev<lisaev@umail.iu.edu> wrote:
OK, which update you are talking about?
Shutdown problems probably come from upower. Your user would loose control of external devices only if you were in the storage/disk groups. Adding youself to these groups was your mistake, since unless you understand what you are doing, you should let console-kit do the permission granting. In fact, on a modern linux system you only have to be a member of 1 group: users.
How do you start your desktop and do you have ck-launch-session running?
Personally I'm not using neither gui file browser nor consolekit session and make use of the group based permission because I know how to handle things, and I can look up eventual barriers in my way quickly and reliably enough. I mount usb drives manually and generally lay hands on my system to keep things running, I mean, in a sane way. This is the first time I hear that this way of treating things would be discouraged, and I'm asking myself if this is just a sysadmin's gripe and if it will be possible in the future. Let's say I'm pretty sure it will be possible, since I guess I'm not the only one who avoids these additional sources of errors aka. software layers like ck/dbus/stuff. I left $certain-other-distro for some reason, and don't want to be forced back on this layer cake again.
the sources of error are likely not a thin smear of software that, imo, makes the entire experience much better and enables fine-grained access control ... i mean group perms are nice and all, but they are incredibly coarse, and over the years have forced all sorts of odd/convoluted application hierarchies + access patterns to cope. unfortunately, error sources are probably human, ie. stuff isn't being launched/ran/used properly. the stack is layers -- i for one think the linux experience has improved 1000 fold over the last few years alone -- and we continue to demand more, albeit indirectly at times.
Also reminds me of this morning's xorg-xdm bug report I wrote which made dbus on a system level necessary, all of a sudden... Things go on like this and I'll remove my Xorg and run frambuffer only from now on. :-)
doubtful ;-). im a professional sysadmin too ATM (though, i'm traditionally an applications developer, and am trying my hand at larger scale administration), and honestly, i'd like to see dbus and other tools that enhance discovery/transparency/communication/free-time embed themselves like a tick in everything possible. this idea of actually *wanting* to micromanage everything makes me shudder ... yuck ... the cleanest fastest version with a healthy scoop of Just Works beats uber-unnecessary flexibility any day in my book. there are more interesting problems to solve than helping my computer be a computer. -- C Anthony Risinger
On Thu, 27 Oct 2011 12:30:50 -0500 C Anthony Risinger <anthony@xtfx.me> wrote:
the sources of error are likely not a thin smear of software that, imo, makes the entire experience much better and enables fine-grained access control ... i mean group perms are nice and all, but they are incredibly coarse, and over the years have forced all sorts of odd/convoluted application hierarchies + access patterns to cope.
unfortunately, error sources are probably human, ie. stuff isn't being launched/ran/used properly.
Its not easy for the user to keep up-to-date with the stream of changes that pour in until one day you update and a deprecated method is busted. A thought that just occurred to me is for these kind of updates to be segregated so that you can see them and research the procedures needed to implement them safely.
Also reminds me of this morning's xorg-xdm bug report I wrote which made dbus on a system level necessary, all of a sudden... Things go on like this and I'll remove my Xorg and run frambuffer only from now on. :-)
doubtful ;-). im a professional sysadmin too ATM (though, i'm traditionally an applications developer, and am trying my hand at larger scale administration), and honestly, i'd like to see dbus and other tools that enhance discovery/transparency/communication/free-time embed themselves like a tick in everything possible.
this would be fantastic EXCEPT a lot of the new inclusions break things, hence this thread. mick
On Fri, Oct 28, 2011 at 11:02 AM, Mick <bareman@tpg.com.au> wrote:
On Thu, 27 Oct 2011 12:30:50 -0500 C Anthony Risinger <anthony@xtfx.me> wrote:
the sources of error are likely not a thin smear of software that, imo, makes the entire experience much better and enables fine-grained access control ... i mean group perms are nice and all, but they are incredibly coarse, and over the years have forced all sorts of odd/convoluted application hierarchies + access patterns to cope.
unfortunately, error sources are probably human, ie. stuff isn't being launched/ran/used properly.
Its not easy for the user to keep up-to-date with the stream of changes that pour in until one day you update and a deprecated method is busted.
A thought that just occurred to me is for these kind of updates to be segregated so that you can see them and research the procedures needed to implement them safely.
Am I the only one reading this thread who sees the inherent contradiction of wanting complete control over your system, wanting things not to break, yet wanting software to be (relatively frequently) updated? The devs run the software, by the time it gets to [testing] it has passed through their machines without (visibly) breaking anything, by the time it gets to [core]/[extra] it has passed through the machines of whoever runs [testing]. If a system breaks because of an update in [core]/[extra], its because the system differs from all the previous machines in its hardware and/or software. To summarize, if your answer to 'what package broke it?' is simply 'I don't know, too many packages got updated at one time' then there's no real possible solution to this problem.
On Fri, 28 Oct 2011 11:34:50 +0800 Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
Am I the only one reading this thread who sees the inherent contradiction of wanting complete control over your system, wanting things not to break, yet wanting software to be (relatively frequently) updated?
All I'm asking for is a way to cope with the REGULAR breaking of a few functions by updates. Unless I have missed something in the pacman docs there is no way I can conveniently pick and choose which updates to install, I can only install either all or none of the bundle that pacman offers. Yes I know I can exclude packages via pacman.conf but for that I need to be able to isolate the offending package(s). My primary desire for updates is for: 1.) security fixes 2.) bug fixes I don't need to update for new features unless its a feature I need, in which case I am happy to chase it myself and expect problems. The fact that these particular issues keep on occurring, not only to me, and there seems to be no consistency in the solution suggest to me that something needs to be done, maybe just clearer docs. I did make a mistake when I chose Arch. I asked friends on yahoo chat for suggestions for a replacement my then distro when it focused on eye-candy to the detriment of function and several suggested Arch. It was only when the problems I raised here struck the first time that I found Arch made no pretensions to being fit for production. By that time I had come to like most of what Arch is.
To summarize, if your answer to 'what package broke it?' is simply 'I don't know, too many packages got updated at one time' then there's no real possible solution to this problem. going back to the pacman log I could narrow it down to one of: synchronizing package lists starting full system upgrade upgraded glib2 (2.28.8-1 -> 2.30.0-1) upgraded gdl (3.0.2-1 -> 3.2.0-1) upgraded libsasl (2.1.23-7 -> 2.1.23-8) upgraded libldap (2.4.26-3 -> 2.4.26-4) upgraded coreutils (8.13-2 -> 8.14-1) upgraded filesystem (2011.08-1 -> 2011.10-1) upgraded dbus-core (1.4.14-1 -> 1.4.16-1) upgraded dbus-glib (0.94-2 -> 0.98-1) upgraded gconf (2.32.4-1 -> 3.2.0-1) upgraded nettle (2.2-1 -> 2.4-1) upgraded gnutls (3.0.3-1 -> 3.0.4-2) upgraded gsettings-desktop-schemas (3.0.1-2 -> 3.2.0-1) upgraded glib-networking (2.28.7-5 -> 2.30.0-1) upgraded libsoup (2.34.3-1 -> 2.36.0-1) upgraded libwebkit3 (1.4.3-1 -> 1.6.1-1) installed json-glib (0.14.0-1) upgraded libgnome-keyring (3.0.3-1 -> 3.2.0-1) upgraded libgda (4.2.9-1 -> 4.99.4-1) upgraded vala (0.12.1-1 -> 0.14.0-1) upgraded dbus (1.4.14-1 -> 1.4.16-1) upgraded dconf (0.8.0-1 -> 0.10.0-1) upgraded exiv2 (0.21.1-2 -> 0.22-1) upgraded x264 (20110617-1 -> 20111001-1) upgraded gobject-introspection (0.10.8-1 -> 1.30.0-1) upgraded libpeas (1.0.0-1 -> 1.2.0-1) installed pygobject-devel (3.0.1-1) installed python2-gobject (3.0.1-1) upgraded glibmm (2.28.2-1 -> 2.30.0-1) installed libgdu (3.0.2-2) installed libcap-ng (0.6.6-1) upgraded python2-egg (2.25.3-10 -> 2.25.3-11) upgraded python2-gksu2 (2.25.3-10 -> 2.25.3-11) upgraded python2-gtkhtml2 (2.25.3-10 -> 2.25.3-11) upgraded python2-gtkspell (2.25.3-10 -> 2.25.3-11) upgraded gnome-python-extras (2.25.3-10 -> 2.25.3-11) upgraded python2-bsddb (5.2.0-1 -> 5.2.0-2) upgraded libsoup-gnome (2.34.3-1 -> 2.36.0-1) upgraded gvfs (1.8.2-1 -> 1.10.0-2) upgraded strigi (0.7.5-4 -> 0.7.6-1) upgraded krb5 (1.9.1-3 -> 1.9.1-4) installed libplist (1.4-1) installed usbmuxd (1.0.7-2) installed libimobiledevice (1.1.1-2) upgraded upower (0.9.12-1 -> 0.9.14-1) upgraded libcanberra (0.28-1 -> 0.28-2) installed lib32-libffi (3.0.10-1) upgraded lib32-glib2 (2.28.8-1 -> 2.30.0-1) upgraded lib32-ncurses (5.7-6 -> 5.9-1) upgraded lib32-openssl (1.0.0.e-1 -> 1.0.0.e-2) upgraded libass (0.9.13-1 -> 0.10.0-1) upgraded libburn (1.1.4-1 -> 1.1.6-1) upgraded libgweather (3.0.2-1 -> 3.2.0-1) upgraded libisofs (1.1.4-1 -> 1.1.6-1) installed json-c (0.9-1) upgraded libpulse (0.9.23-1 -> 1.0-3) upgraded libwebkit (1.4.3-1 -> 1.6.1-1) upgraded mkinitcpio (0.7.2-1 -> 0.7.4-1) upgraded linux (3.0.4-1 -> 3.0.6-2) upgraded mpfr (3.0.1.p4-2 -> 3.1.0.p1-1) upgraded mtr (0.80-2 -> 0.81-1) upgraded net-tools (1.60-18 -> 1.60.20110819cvs-1) upgraded pygobject2-devel (2.28.6-1 -> 2.28.6-4) upgraded python2-gobject2 (2.28.6-1 -> 2.28.6-4) upgraded python2-pyenchant (1.6.3-5 -> 1.6.5-1) upgraded python-nose (1.0.0-4 -> 1.1.2-2) upgraded tumbler (0.1.22-1 -> 0.1.22-2) upgraded xfce4-settings (4.8.2-1 -> 4.8.3-1) upgraded xorg-xinit (1.3.0-3 -> 1.3.1-1) upgraded xfce-utils (4.8.2-1 -> 4.8.3-1) upgraded xfwm4 (4.8.1-1 -> 4.8.2-1)
the other 200ish packages I'm confident were not responsible. If anyone can clear any of the remaining suspects please do. The point I was trying to make when I started this thread was that there are a small group of features frequently being broken for a not insignificant number of users and if packages that could be doing the damage where set to require a more assertive update process they could be deferred until users have time to get it right life would be sweeter. mick
My primary desire for updates is for: 1.) security fixes 2.) bug fixes
I don't need to update for new features unless its a feature I need,
Well we dont do backporting so it is FIXES+FEATURES or nothing. Cherrypicking updates is no sollution, as soname bumps are reality.
can clear any of the remaining suspects please do. mick
This particular set of problems is caused by the udev update, wich told you everything you need to know after it had been updated. Update frequently atleast once a week. Take care of any pacnew files and follow the instructions on install messages.
On Fri, 28 Oct 2011 08:48:21 +0300 Jesse Jaara <jesse.jaara@gmail.com> wrote:
My primary desire for updates is for: 1.) security fixes 2.) bug fixes
I don't need to update for new features unless its a feature I need,
Well we dont do backporting so it is FIXES+FEATURES or nothing. Cherrypicking updates is no sollution, as soname bumps are reality.
can clear any of the remaining suspects please do. mick
This particular set of problems is caused by the udev update, wich told you everything you need to know after it had been updated.
where did it tell, there was nothing in pacman.log and nothing as far as I could scroll the xterm back
On 2011-10-27 11:14 PM, Mick wrote:
My primary desire for updates is for: 1.) security fixes 2.) bug fixes
I don't need to update for new features unless its a feature I need, in which case I am happy to chase it myself and expect problems.
The fact that these particular issues keep on occurring, not only to me, and there seems to be no consistency in the solution suggest to me that something needs to be done, maybe just clearer docs.
I did make a mistake when I chose Arch. I asked friends on yahoo chat for suggestions for a replacement my then distro when it focused on eye-candy to the detriment of function and several suggested Arch. It was only when the problems I raised here struck the first time that I found Arch made no pretensions to being fit for production. By that time I had come to like most of what Arch is.
You should try a different distro, like Debian maybe. Being a rolling-release distro is one of Arch's main selling points, and seems to be completely the opposite of what you want.
On Fri, 28 Oct 2011 12:39:35 -0600 Brendan Long <korin43@gmail.com> wrote:
On 2011-10-27 11:14 PM, Mick wrote:
My primary desire for updates is for: 1.) security fixes 2.) bug fixes
I don't need to update for new features unless its a feature I need, in which case I am happy to chase it myself and expect problems.
You should try a different distro, like Debian maybe. Being a rolling-release distro is one of Arch's main selling points, and seems to be completely the opposite of what you want.
Rolling release isn't the problem, its the regular chase to fix udev changes to how USB devices are automounted. While trying to apply a recommended 'solution' all the hidden files in my home directory disappeared so I have now gone back to ubuntu. -- mick <bareman@tpg.com.au>
On Fri, Oct 28, 2011 at 12:14 AM, Mick wrote:
I did make a mistake when I chose Arch. I asked friends on yahoo chat for suggestions for a replacement my then distro when it focused on eye-candy to the detriment of function and several suggested Arch. It was only when the problems I raised here struck the first time that I found Arch made no pretensions to being fit for production. By that time I had come to like most of what Arch is.
I run Arch on production systems. Yikes you might think. However, I run Arch Linux on more than 10 systems, and about 6 or 7 of those are at work. I've been running Arch since 2007 and used it for several months at home before using it at work. I update non-critical systems first, but since I update them daily, any breakage is easy to fix, and usually I've gotten a heads up as I track arch-general, arch-announce, arch-releng, and arch-dev-public. I have cron set to automatically download all updates so when I get around to updating, it is fast. The installs I've set up for others they typcially never update, but when I get back with them to help them on something (might even be a few months) I go ahead and update and while the update is taking place I open another terminal and pre-fix any issues. I've not had downtime with Arch, and it is a breeze to update compared to Gentoo, which I ran for a many years before I found Arch. And yes, I'll even update while working on a critical job related issue with a co-worker. I run a very custom installer, and use it to create cookie cutter installs that I already have everything set up the way we need to for our work environment, but of course adding a needing tool or two later is fairly easy. I've not had much success with the official provided installers, I think my pre partitioning and other choices mess it up. I had to fix the boot loader on my first few installs of Arch so I ended up just installing arch gentoo style on subsequent systems. I don't install base anymore, it has several packages I never use. Since the provided installer has only worked for me maybe once or twice, I just use my custom installer, which is much easier anyways for me, as I just change the hostname and default username/pass, change the architecture if need be, and do a make all. I try out he installs first in qemu-kvm for a quick sanity check, then transfer the filesystem images to the target system. Using a custom installer is fast, as I use the cached packages on my host. I have a custom xfce4 desktop setup in /etc/skel, so the install is ready to use. I've run Debian and Ubuntu but fought with package management and custom kernel deployment too much on them so I found Arch much easier to manage. Arch is much simpler than those and so much easier for me to wrap my head around it and fix issues. When I do have a question about something a quick email here about it and it is answered quickly. Most of the time there is no need to ask. All the relevant issues are already being discussed here or in arch-dev-public. All that being said, Arch is certainly not for everyone. But I disagree about it not being production worthy. I have the lts kernel installed on every system, but only the most critical ones use it by default. For any system to be production worthy, you have to be able to maintain it and fix any issues fast that come up. The only real mess up I've had was my fault, not a damaging update from an Arch developer. I mistakenly put an x86_64 bit repo path at the top of the mirrorlists of two i686 boxes and updated them. Yikes. I've since switched to using $arch in the mirrorlists rather than hardcoding the architecture. They were not out of commission long, a boot of the livecd, a quick $(awking) of /var/log/pacman.log in a pacman command line reinstalled the invalid packages and I had working systems back. Ok, the updated networking setup broke some of my systems earlier this year, but it was easy enough to fix. Arch is easy to manage if you insist on having the system set up the way you want it and you want to be on top of every issue. Distros like OpenSUSE, Fedora, Ubuntu, and to a lesser extent Debian are too daunting and confusing to me. Most Linux users I know would not tolerate Arch Linux if they had to install and setup it up themselves. But at the same time I have no real like for the distros they prefer to install and manage for themselves. A rolling update based distro that is mostly minimal and lightweight is not without it's issues and problems. All distros have serious issues and problems, it is mainly a matter of which have the issues/problems that are easiest for you to manage. I may not be the typical Arch user, dunno. Especially since I use joe instead if vi, and was a not amused when joe went to the AUR. But I have a repo for work stuff, so I just put it there so it is ready on new systems. You may have made a mistake when you chose Arch, and I'm not going to disagree with on your reasoning. Arch does have major/serious issues if you don't want to stay on top of things. And being a rolling update distro, you need to stay on top of changes. If you think Arch is bad though as far as damaging updates, you should maybe spend some time to spend some time with Gentoo or Sabayon. One thing though, I use yaourt, so I notice every time a package gets dropped of the main repos and ends up in the aur. Most of the time that is an indication to me that I know longer need that package. So yeah, if you use packages that get orphaned, they might eventually stop working if you had them installed, and one would might blame an update for killing those packages.
On Fri, 28 Oct 2011 23:56:11 -0500 Dwight Schauer <dschauer@gmail.com> wrote:
On Fri, Oct 28, 2011 at 12:14 AM, Mick wrote:
I did make a mistake when I chose Arch. I asked friends on yahoo chat for suggestions for a replacement my then distro when it focused on eye-candy to the detriment of function and several suggested Arch. It was only when the problems I raised here struck the first time that I found Arch made no pretensions to being fit for production. By that time I had come to like most of what Arch is.
All that being said, Arch is certainly not for everyone. But I disagree about it not being production worthy. I have the lts kernel installed on every system, but only the most critical ones use it by default. For any system to be production worthy, you have to be able to maintain it and fix any issues fast that come up. I think you need better Sys-Admin skills than I have but that isn't arch's fault.
The only real mess up I've had was my fault, not a damaging update from an Arch developer. I mistakenly put an x86_64 bit repo path at the top of the mirrorlists of two i686 boxes and updated them. Yikes. I've since switched to using $arch in the mirrorlists rather than hardcoding the architecture. They were not out of commission long, a boot of the livecd, a quick $(awking) of /var/log/pacman.log in a pacman command line reinstalled the invalid packages and I had working systems back. I'm not saying is the Arch developers fault, just that it keep on happening.
I've had the odd 'blond-moments' that were suprisingly easy to fix and been bitten by updates to libraries that have been released before all apps that needed the superceeded version had been fixed. I also got caught out when xfce4.8 came out and the mirror I was using hadn't got all of the updated packages available.
Ok, the updated networking setup broke some of my systems earlier this year, but it was easy enough to fix.
The only problem I had with that was messages flashing by to fast to read and not making it into the logs so I could do something about them.
Arch is easy to manage if you insist on having the system set up the way you want it and you want to be on top of every issue. Distros like OpenSUSE, Fedora, Ubuntu, and to a lesser extent Debian are too daunting and confusing to me.
Ubuntu dumbs everything down then gets in the way when you need to use setting beyond the basic. I was using Debian for a while, until they bound selinux in, after which I couldn't get any custom kernel to boot and the default kernel was too slow and missing h/w support I needed.
Most Linux users I know would not tolerate Arch Linux if they had to install and setup it up themselves. But at the same time I have no real like for the distros they prefer to install and manage for themselves. A rolling update based distro that is mostly minimal and lightweight is not without it's issues and problems. All distros have serious issues and problems, it is mainly a matter of which have the issues/problems that are easiest for you to manage.
I may not be the typical Arch user, dunno. Especially since I use joe instead if vi, and was a not amused when joe went to the AUR. But I have a repo for work stuff, so I just put it there so it is ready on new systems.
You may have made a mistake when you chose Arch, and I'm not going to disagree with on your reasoning. Arch does have major/serious issues if you don't want to stay on top of things. And being a rolling update distro, you need to stay on top of changes.
If you think Arch is bad though as far as damaging updates, you should maybe spend some time to spend some time with Gentoo or Sabayon.
One thing though, I use yaourt, so I notice every time a package gets dropped of the main repos and ends up in the aur. Most of the time that is an indication to me that I know longer need that package. So yeah, if you use packages that get orphaned, they might eventually stop working if you had them installed, and one would might blame an update for killing those packages.
-- mick <bareman@tpg.com.au>
On Fri, Oct 28, 2011 at 00:14, Mick <bareman@tpg.com.au> wrote:
On Fri, 28 Oct 2011 11:34:50 +0800 Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
Am I the only one reading this thread who sees the inherent contradiction of wanting complete control over your system, wanting things not to break, yet wanting software to be (relatively frequently) updated?
All I'm asking for is a way to cope with the REGULAR breaking of a few functions by updates. Unless I have missed something in the pacman docs there is no way I can conveniently pick and choose which updates to install, I can only install either all or none of the bundle that pacman offers. Yes I know I can exclude packages via pacman.conf but for that I need to be able to isolate the offending package(s).
My primary desire for updates is for: 1.) security fixes 2.) bug fixes
I don't need to update for new features unless its a feature I need, in which case I am happy to chase it myself and expect problems.
The fact that these particular issues keep on occurring, not only to me, and there seems to be no consistency in the solution suggest to me that something needs to be done, maybe just clearer docs.
I did make a mistake when I chose Arch. I asked friends on yahoo chat for suggestions for a replacement my then distro when it focused on eye-candy to the detriment of function and several suggested Arch. It was only when the problems I raised here struck the first time that I found Arch made no pretensions to being fit for production. By that time I had come to like most of what Arch is.
To summarize, if your answer to 'what package broke it?' is simply 'I don't know, too many packages got updated at one time' then there's no real possible solution to this problem. going back to the pacman log I could narrow it down to one of: synchronizing package lists starting full system upgrade upgraded glib2 (2.28.8-1 -> 2.30.0-1) upgraded gdl (3.0.2-1 -> 3.2.0-1) upgraded libsasl (2.1.23-7 -> 2.1.23-8) upgraded libldap (2.4.26-3 -> 2.4.26-4) upgraded coreutils (8.13-2 -> 8.14-1) upgraded filesystem (2011.08-1 -> 2011.10-1) upgraded dbus-core (1.4.14-1 -> 1.4.16-1) upgraded dbus-glib (0.94-2 -> 0.98-1) upgraded gconf (2.32.4-1 -> 3.2.0-1) upgraded nettle (2.2-1 -> 2.4-1) upgraded gnutls (3.0.3-1 -> 3.0.4-2) upgraded gsettings-desktop-schemas (3.0.1-2 -> 3.2.0-1) upgraded glib-networking (2.28.7-5 -> 2.30.0-1) upgraded libsoup (2.34.3-1 -> 2.36.0-1) upgraded libwebkit3 (1.4.3-1 -> 1.6.1-1) installed json-glib (0.14.0-1) upgraded libgnome-keyring (3.0.3-1 -> 3.2.0-1) upgraded libgda (4.2.9-1 -> 4.99.4-1) upgraded vala (0.12.1-1 -> 0.14.0-1) upgraded dbus (1.4.14-1 -> 1.4.16-1) upgraded dconf (0.8.0-1 -> 0.10.0-1) upgraded exiv2 (0.21.1-2 -> 0.22-1) upgraded x264 (20110617-1 -> 20111001-1) upgraded gobject-introspection (0.10.8-1 -> 1.30.0-1) upgraded libpeas (1.0.0-1 -> 1.2.0-1) installed pygobject-devel (3.0.1-1) installed python2-gobject (3.0.1-1) upgraded glibmm (2.28.2-1 -> 2.30.0-1) installed libgdu (3.0.2-2) installed libcap-ng (0.6.6-1) upgraded python2-egg (2.25.3-10 -> 2.25.3-11) upgraded python2-gksu2 (2.25.3-10 -> 2.25.3-11) upgraded python2-gtkhtml2 (2.25.3-10 -> 2.25.3-11) upgraded python2-gtkspell (2.25.3-10 -> 2.25.3-11) upgraded gnome-python-extras (2.25.3-10 -> 2.25.3-11) upgraded python2-bsddb (5.2.0-1 -> 5.2.0-2) upgraded libsoup-gnome (2.34.3-1 -> 2.36.0-1) upgraded gvfs (1.8.2-1 -> 1.10.0-2) upgraded strigi (0.7.5-4 -> 0.7.6-1) upgraded krb5 (1.9.1-3 -> 1.9.1-4) installed libplist (1.4-1) installed usbmuxd (1.0.7-2) installed libimobiledevice (1.1.1-2) upgraded upower (0.9.12-1 -> 0.9.14-1) upgraded libcanberra (0.28-1 -> 0.28-2) installed lib32-libffi (3.0.10-1) upgraded lib32-glib2 (2.28.8-1 -> 2.30.0-1) upgraded lib32-ncurses (5.7-6 -> 5.9-1) upgraded lib32-openssl (1.0.0.e-1 -> 1.0.0.e-2) upgraded libass (0.9.13-1 -> 0.10.0-1) upgraded libburn (1.1.4-1 -> 1.1.6-1) upgraded libgweather (3.0.2-1 -> 3.2.0-1) upgraded libisofs (1.1.4-1 -> 1.1.6-1) installed json-c (0.9-1) upgraded libpulse (0.9.23-1 -> 1.0-3) upgraded libwebkit (1.4.3-1 -> 1.6.1-1) upgraded mkinitcpio (0.7.2-1 -> 0.7.4-1) upgraded linux (3.0.4-1 -> 3.0.6-2) upgraded mpfr (3.0.1.p4-2 -> 3.1.0.p1-1) upgraded mtr (0.80-2 -> 0.81-1) upgraded net-tools (1.60-18 -> 1.60.20110819cvs-1) upgraded pygobject2-devel (2.28.6-1 -> 2.28.6-4) upgraded python2-gobject2 (2.28.6-1 -> 2.28.6-4) upgraded python2-pyenchant (1.6.3-5 -> 1.6.5-1) upgraded python-nose (1.0.0-4 -> 1.1.2-2) upgraded tumbler (0.1.22-1 -> 0.1.22-2) upgraded xfce4-settings (4.8.2-1 -> 4.8.3-1) upgraded xorg-xinit (1.3.0-3 -> 1.3.1-1) upgraded xfce-utils (4.8.2-1 -> 4.8.3-1) upgraded xfwm4 (4.8.1-1 -> 4.8.2-1)
the other 200ish packages I'm confident were not responsible. If anyone can clear any of the remaining suspects please do.
The point I was trying to make when I started this thread was that there are a small group of features frequently being broken for a not insignificant number of users and if packages that could be doing the damage where set to require a more assertive update process they could be deferred until users have time to get it right life would be sweeter.
mick
Mick Since some of your loss was usb mounting etc, you may have missed a package to consider [udev]. [2011-10-19 22:39] ATTENTION UDEV: [2011-10-19 22:39] ---------- [2011-10-19 22:39] We now use upstream rules for assigning devices to the 'disk', 'optical', [2011-10-19 22:39] 'scanner' and 'video' groups. Beware of any changes. [2011-10-19 22:39] -- [2011-10-19 22:39] We no longer create symlinks from /dev/<dev> to /dev/<dev>0. [2011-10-19 22:39] -- [2011-10-19 22:39] For security reasons, we no longer add devices to the 'storage' group. Use [2011-10-19 22:39] udisks and friends, or add custom rules to /etc/udev.d/rules/, if you want [2011-10-19 22:39] this functionality back. The message above is from my pacman.log. It clearly notes there were changes made to the way things were handled by udev and those rules were changed to match the "upstream rules". That makes Arch closer to the other distros. There are times when moving closer to upstream causes problems and complaints because it changes/modifies the Arch Way. However the Arch Way of KISS, Keep It Simple Stupid - where I come from, still works the best. About shutting down from the desktop, view this page in the Arch wiki ( https://wiki.archlinux.org/index.php/Allow_Users_to_Shutdown ). It gives different ways to make this work. I have to agree with Oon-Ee Ng, Dwight Schauer and others who make the point about updating. You have to update more often than every three weeks otherwise you're asking for a broken system. I disagree with your statement "I did make a mistake when I chose Arch". You just have to accept not everything is set up to hold ones hand like Debian and its' spawn. With Arch I can fix a broken system without reinstalling. I'm currently running a system where I blew the pacman database away and recovered from it thanks to the Arch Way and the Arch wiki. Dis'ing Arch for these types of errors is just wrong. I've seen plenty of comments around the web about the Arch Wiki being the best place to find information. Please don't complain when the answers you get aren't the ones you want, try to use them to work through your problems. Myra -- Life's fun when your sick and psychotic!
Am I the only one reading this thread who sees the inherent contradiction of wanting complete control over your system, wanting things not to break, yet wanting software to be (relatively frequently) updated?
I think the source of the problem is the lack of communication and documentation - not necessarly by Arch devs. I'm yet to find good documentation about what should Polkit, ConsoleKit and all the other *kits actually do, how to debug when they don't do that, how to test and check their state etc... -- дамјан
On (10/27/11 19:14), Martti Kühne wrote: -~> On Thu, Oct 27, 2011 at 6:24 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote: -~> > -~> > OK, which update you are talking about? -~> > -~> > Shutdown problems probably come from upower. Your user would loose control of -~> > external devices only if you were in the storage/disk groups. Adding youself to -~> > these groups was your mistake, since unless you understand what you are doing, -~> > you should let console-kit do the permission granting. In fact, on a modern -~> > linux system you only have to be a member of 1 group: users. -~> > -~> > How do you start your desktop and do you have ck-launch-session running? -~> > -~> -~> -~> Personally I'm not using neither gui file browser nor consolekit -~> session and make use of the group based permission because I know how -~> to handle things, and I can look up eventual barriers in my way -~> quickly and reliably enough. I mount usb drives manually and generally -~> lay hands on my system to keep things running, I mean, in a sane way. -~> This is the first time I hear that this way of treating things would -~> be discouraged, and I'm asking myself if this is just a sysadmin's -~> gripe and if it will be possible in the future. Let's say I'm pretty -~> sure it will be possible, since I guess I'm not the only one who -~> avoids these additional sources of errors aka. software layers like -~> ck/dbus/stuff. I left $certain-other-distro for some reason, and don't -~> want to be forced back on this layer cake again. -~> -~> Also reminds me of this morning's xorg-xdm bug report I wrote which -~> made dbus on a system level necessary, all of a sudden... Things go on -~> like this and I'll remove my Xorg and run frambuffer only from now on. -~> :-) -~> -~> cheers! -~> mar77i And how exactly does xfce4 run for you w/o console-kit? And what's wrong with dbus? If you want functionality beyond 1987, you'll have to have software layers: yes or yes. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Thu, Oct 27, 2011 at 07:14:36PM +0200, Martti Kühne wrote:
Personally I'm not using neither gui file browser nor consolekit session and make use of the group based permission because I know how to handle things, and I can look up eventual barriers in my way quickly and reliably enough. I mount usb drives manually and generally lay hands on my system to keep things running, I mean, in a sane way. This is the first time I hear that this way of treating things would be discouraged, and I'm asking myself if this is just a sysadmin's gripe and if it will be possible in the future. Let's say I'm pretty sure it will be possible, since I guess I'm not the only one who avoids these additional sources of errors aka. software layers like ck/dbus/stuff. I left $certain-other-distro for some reason, and don't want to be forced back on this layer cake again.
Exactly the same here. If and when Arch leaves no option but to use the kit family (or being faced with hours of uninstall & reconfigure tedium) it will have lost all appeal and there's nothing that would make me prefer it over anything else. Ciao, -- FA
Personally I'm not using neither gui file browser nor consolekit session and make use of the group based permission because I know how to handle things, and I can look up eventual barriers in my way quickly and reliably enough. I mount usb drives manually and generally lay hands on my system to keep things running, I mean, in a sane way. This is the first time I hear that this way of treating things would be discouraged, and I'm asking myself if this is just a sysadmin's gripe and if it will be possible in the future. Let's say I'm pretty sure it will be possible, since I guess I'm not the only one who avoids these additional sources of errors aka. software layers like ck/dbus/stuff. I left $certain-other-distro for some reason, and don't want to be forced back on this layer cake again.
Since I started using Linux way back in the days of RedHat 5.2 there has been a massive amount of abstraction and obfuscation of even basic functions without easily found and understood (by me at least) explanation and/or how to make it work. Most of this is well done and sneaks past because it just works but there are some cases where substantial, from the end-user perspective, changes to relatively basic functions, like USB sticks, halt/reboot from within GUI. Of course "the Arch way" forbids a simple script within the package to fix these issues. mick
On Thu, 27 Oct 2011 11:24:13 -0500 Leonid Isaev <lisaev@umail.iu.edu> wrote:
On (10/27/11 17:49), Mick wrote: -~> Following yet another update that has disabled user control of USB -~> sticks, cameras, etc. and blocked user from shutting down from the -~> desktop (in my case xfce4), I am at the end of my tether. -~> -~> Is there some way to be fore-warned of these updates coming online and -~> avoid them or be ready with clear info on how to repair the damage they -~> are set to create. -~> -~> mick
OK, which update you are talking about? I'm not sure, I usually run pacman -Syu about 3 weeks apart and there are usually many updates to apply.
Shutdown problems probably come from upower. Your user would loose control of external devices only if you were in the storage/disk groups. Adding youself to these groups was your mistake, since unless you understand what you are doing, you should let console-kit do the permission granting. In fact, on a modern linux system you only have to be a member of 1 group: users.
I'm currently in the following groups: disk - not sure why lp - to get around printer problems wheel - the beginners guide insisted log - after an update destroyed my root GUI session locate - I had some reason, can't remember now http - facilitate editing of website video - don't know audio - couldn't play music until I added optical, storage no usbstick or cd/dvd access without it scanner camera - same thing with camera and scanner power - fixed a previous occurrence of this problem users - default wireshark - obvious
How do you start your desktop and do you have ck-launch-session running?
ininttab runlevel 5 ==> xdm exec ck-launch-session startxfce4 This has been a frequently recurring problem since I first install Arch about feb 2009, and the solution has never been the same mick PS I apologize if my inherent paranoia is showing.
On 2011-10-27 8:24 PM, Mick wrote:
On Thu, 27 Oct 2011 11:24:13 -0500 Leonid Isaev <lisaev@umail.iu.edu> wrote:
On (10/27/11 17:49), Mick wrote: -~> Following yet another update that has disabled user control of USB -~> sticks, cameras, etc. and blocked user from shutting down from the -~> desktop (in my case xfce4), I am at the end of my tether. -~> -~> Is there some way to be fore-warned of these updates coming online and -~> avoid them or be ready with clear info on how to repair the damage they -~> are set to create. -~> -~> mick
OK, which update you are talking about? I'm not sure, I usually run pacman -Syu about 3 weeks apart and there are usually many updates to apply. That's part of your problem right there -- Updates go much more smoothly if you apply them in small pieces. The people running [testing] aren't going to wait 3 weeks between running updates, so you shouldn't either.
I do updates every time I get home, which means: * I get them in small pieces, so if something broke, it's obvious what was the cause * It's easy to read any install messages (generally if something is going to break, the install message will tell you what to do to avoid it) * If something big is changing, I'll get the arch announce message that same day (much easier to remember today's announcements than this month's announcements)
On (10/28/11 12:24), Mick wrote: -~> On Thu, 27 Oct 2011 11:24:13 -0500 -~> Leonid Isaev <lisaev@umail.iu.edu> wrote: -~> -~> > On (10/27/11 17:49), Mick wrote: -~> > -~> Following yet another update that has disabled user control of USB -~> > -~> sticks, cameras, etc. and blocked user from shutting down from the -~> > -~> desktop (in my case xfce4), I am at the end of my tether. -~> > -~> -~> > -~> Is there some way to be fore-warned of these updates coming -~> > online and -~> avoid them or be ready with clear info on how to -~> > repair the damage they -~> are set to create. -~> > -~> -~> > -~> mick -~> > -~> > OK, which update you are talking about? -~> I'm not sure, I usually run pacman -Syu about 3 weeks apart and there -~> are usually many updates to apply. -~> -~> > -~> > Shutdown problems probably come from upower. Your user would loose -~> > control of external devices only if you were in the storage/disk -~> > groups. Adding youself to these groups was your mistake, since unless -~> > you understand what you are doing, you should let console-kit do the -~> > permission granting. In fact, on a modern linux system you only have -~> > to be a member of 1 group: users. -~> -~> I'm currently in the following groups: -~> So, basically, you added your user to every group possible? -~> disk - not sure why You'd better figure it out. -~> lp - to get around printer problems -~> wheel - the beginners guide insisted Beginners' guide is not a bible. -~> log - after an update destroyed my root GUI session -~> locate - I had some reason, can't remember now Makes no sense, because your user must not touch update DB, it's the job for cron or occasionally root. -~> http - facilitate editing of website -~> video - don't know The same as for disk. -~> audio - couldn't play music until I added Totally wrong reason, since you have console-kit running. -~> optical, storage no usbstick or cd/dvd access without it Again, the reasoning makes no sense. -~> scanner camera - same thing with camera and scanner I have to check, but I don't think that you need to be a member of scanner unless you want to scan over a network. -~> power - fixed a previous occurrence of this problem Membership in power lets you hibernate/suspend (pm-utils), but not shutdown/reboot. You seem to have policykit issues. -~> users - default -~> wireshark - obvious -~> > -~> > How do you start your desktop and do you have ck-launch-session -~> > running? -~> ininttab runlevel 5 ==> xdm -~> -~> exec ck-launch-session startxfce4 -~> Do you have dbus in your DAEMONS, like this: DAEMONS=(syslog-ng microcode irqbalance cpufreq dbus...)? Otherwise xfce4 will not work. -~> This has been a frequently recurring problem since I first install Arch -~> about feb 2009, and the solution has never been the same -~> Because you have to clean your installation once in a while. I am quite surprised your system even booted. -~> mick -~> -~> PS I apologize if my inherent paranoia is showing. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Thu, Oct 27, 2011 at 9:49 AM, Mick <bareman@tpg.com.au> wrote:
Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.
Is there some way to be fore-warned of these updates coming online and avoid them or be ready with clear info on how to repair the damage they are set to create.
Regarding the device permissions, the messages you should have received at install time can be found here: <http://projects.archlinux.org/svntogit/packages.git/tree/trunk/udev.install?h=packages/udev>. I don't know about not being able to shut down. Can you reproduce the problem if you start xfce via a desktop manager? If so, please file a bug, if not then you'll need to figure out what services the DM starts for you, and start them manually instead. Cheers, Tom
On Thu, 27 Oct 2011 17:49:13 +1000 Mick <bareman@tpg.com.au> wrote:
Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.
Is there some way to be fore-warned of these updates coming online and avoid them or be ready with clear info on how to repair the damage they are set to create.
mick
I obviously haven't expressed myself clearly enough all I wanted was a procedure to be prepared these issues, I wasn't the developers. My mistake in choosing Arch was that arch is much more "hands-on" than I was prepared for. My fault, not Arch's. My system had built up a lot of crap over the years from trying packages that looked like they would do something I wanted. Unfortunately while trying to fix the USB issue I somehow managed to delete all the hidden files in my home directory and couldn't recover them from backup. Rather than spending weeks rebuilding arch I have installed ubuntu. mick
participants (19)
-
Brendan Long
-
C Anthony Risinger
-
Damjan
-
Dwight Schauer
-
Fons Adriaensen
-
Heiko Baums
-
Isaac Dupree
-
Jesse Jaara
-
Jesse Juhani Jaara
-
Karol Blazewicz
-
Leonid Isaev
-
Manolo Martínez
-
Martti Kühne
-
Mauro Santos
-
Mick
-
mick
-
Myra Nelson
-
Oon-Ee Ng
-
Tom Gundersen