Here we go:

-Mint does use upstart,being an Ubuntu spinoff
-the only display manager (at least in Mint Mate,which is what I'm using) is mdm
-in sfgxi.log dmanCommand occurs two times after unpacking the driver,here are the relevant lines:





of course I can post the entire log if need be.

The command sudo service mdm stop || echo failed $ shuts down the display manager successfully and it does not respawn,interestingly if you issue that command in console 2 (I mean CTRL+ALT+F2),it will immediately switch on its own to console 1.

According to this thread forums.linuxmint.com/viewtopic.php?f=59&t=86154&p=497881&hilit=sgfxi#p497881,in order to not run into issues like this,you should unlock the root account in Mint and run sgfxi as root,not as a normal user with sudo-and I totally forgot about this,so I'll have to eventually remove and reinstall the driver again if we want to verify this.

And now back to the original topic,have you any idea of why Apparmor won't play along with this 3.10-19.dmz.1 kernel either?

Here's what I am getting:



On a side note,the upgrade to this new kernel didn't break anything except the cpu frequency applet,which is now stuck at 0 MHZ (although the cpu frequency governor probably works as before)-any ideas on why this happened?

And well,yes,I've just recently put Debian stable on another partition to see what's what,and eventually move everything there.
Back to top

user32, gold star, you are the first mint/ubuntu user to ever actually post the relevant data, and the exact location in the logs where the issue occurs.

mdm is respawning because the stop mdm command failed because I guess sudo only applies to the thing that started it, not sub events. sgfxi expects this command to work, and as a last step to kill x, will directly kill x itself, not via upstart/sysv, but that event is detected and then mdm respawns, so that's not a bug in that part of upstart.

Because sgfxi runs a lot of sub events inside of itself, the actual permanent solution is to see what started sgfxi, root or sudo, but how to do that, I do not know, I'll figure it out and add an early test to sgfxi to exit with error if it's been started by sudo.

Since debian doesn't really use default sudo, and I never do, this issue and cause would simply never have occurred to me, not in a decade of bug reports would it have crossed my mind. Debian users of course joke about sudo this and sudo that, but I never realized sudo priviliges were not maintained throughout the operation of a script/program, no matter what it was doing.

Obviously nothing will work, or only a subset, unknown, will work, with sudo. Since NO instructions anywhere that are valid say to use sudo sgfxi, I'll have to update some docs here and there to note to NOT use it, ever, for any reason.

Disabling root on a linux system of course is just silly, particularly when you own the box/device, so it's simply not something I would have ever considered as happening.

So things to test for are:

is sgfxi started by sudo
is root disabled?

I'm unclear if sudo su will work or not, I believe it won't following this page:
stackoverflow.com/questions/3522341/identify-user-in-a-bash-script-called-by-sudo
So that's the answer to all these weird ubuntu/mint issue reports, user error coupled with a non standard debian configuration which allowed that error to occur.

thanks user32, many have posted, but none have followed through on this issue.
Back to top

After testing, sgfxi will now detect sudo starts, and exit with a pretty clear error message if a sudo anything started it.

note that if you use:


(note the dash) then sgfxi does not detect sudo user because a sudo user didn't start it, su did.

However, if you use a simple: sudo su
then sgfxi will detect that sudo started it since $SUDO_USERS is set.

I do not know if that case will work, we'll see.

I also am testing a simple output that will tell users that they started sgfxi with sudo su -
just as information.

Dealing with process parents of parents of parents is a trick that isn't always reliable but it should work in most cases.
Back to top

that's an interesting one too, but I'm not going to check it, things like that in my opinion are bugs, not features, and should be fixed upstream.

I can note that users of upstart etc should run sgfxi in ctrl alt f1, default that is for system console, in the manual pages, though that doesn't matter at all as far as I know with non upstart systems.
Back to top

Thanks for your words,in reality I did nothing special aside of looking at the logs and try keeping track of what was happening:this is still Linux after all,it does not hide stuff from you...

And to be fair,the thing about running sgfxi in Mint as root has been in the Mint forums for a while,only no one bothered to inform you-unfortunately.

The thing is,the root account as far as I understand is disabled by default in Ubuntu/Mint,nor is recommended to unlock it:given that Ubuntu likes to do thing its own way,one should maybe consider if unlocking the root account may eventually trigger some problems?
They give you,aside of sudo,the root terminal to deal with the lack of a root account,but I can't see how it can be effective in a virtual console.

On the other hand,I may note that it sure isn't elegant and may throw off some users,but the reality is that -if you only care about installing the driver one way or another- sgfxi actually works even with this issue:if you log in when mdm respawns,and immediately switch back to the same console where sgfxi was running,it will be still there and the installation will keep going-at least,I've done this twice and the driver was successfully installed in the end.
Back to top

Now,as far as apparmor goes,does it work in Debian with a Liquorix kernel,in other words is this issue another Ubuntu/Mint quirk?

I would lean towards no this time,because apparmor works in Ubuntu 10.04 with an Ubuntu kernel and also in Mint 13 (based on Ubuntu 12.04) with a non-Liquorix kernel-I know becasue I've briefly tried in a console and if I boot this very same system on another kernel,apparmor works as expected,no error messages are shown and profiles are loaded normally.What's your take on this matter?
Back to top

I really see no reason why users shouldn't have a root login, I mean, it's your computer after all. I do see disabling it for offices and business desktops etc, but not for personal computers.

I believe, that: sudo su -
gives you an admin root shell, so sgfxi lets you do that, but it will tell you when you did that. The error message for sudo otherwise says, use root login or use sudo su -

sudo su too might work, but I block that because the method I'm using is to detect for $SUDO_USER being non null, that's easy, and relatively simple to implement. The 'sudo su -' test is more complicated, a trick I learned from inxi hacking over the years, but all sgfxi/smxi now do with that information is print out a message at start up telling you you are doing it, then later logging that fact so I can see from logs if failures are happening when that was used..

I've wasted a lot of my time on this bug over the years, never could find the actual cause, except to note that in almost all cases the users with issues were mint users, which made me want to terminate support for mint/ubuntu to be honest, but with this sudo block maybe that won't be necessary.

While what you did may seem basic to you, it was more than any other mint user since ikey was in lmde did, ie, follow basic linux steps of debugging/analysis, then follow through. The latter step seems to have caused the most problems for mint bug reporters, ie, they didn't follow through on it to explain what fixed it. Always very annoying, since that makes all the time you spent with them essentially wasted except as a data point you may remember the next time a mint bug report comes around.

I did a quick google search of 'sudo sgfxi' and was distressed by how many pages I got back in results, no idea who started that idea, it certainly was not me, smxi/sgfxi were always designed and created around systems that are debian standard, ie, no root shell disabled, and always assumed (assuming here was the problem) that of course users would be in a root shell. If you think of it, it's all kind of pointless using sudo, except maybe for single commands that are simple, it takes no longer to login as root or su to root than it does to type in sudo [password] so the entire thing never made any sense to me.

The sgfxi error message also suggests correcting distro how to documentation etc.
Back to top

It works in Debian/Sid with Liquorix kernel 3.12-3

but it didn't work with kernels 3.11
Back to top

I can confirm that apparmor works for me with the 3.13-11.dmz.3-liquorix-amd64 kernel from the "past" liquorix repo,whilst it didn't with the previous 3.10-19.dmz.1-liquorix-amd64 I had before.
So,apparently a kernel version higher than 3.11 is required to have apparmor working properly.
Back to top