[Wolves] Fwd: Ubuntu 14.04 Nvidia upgrade woes

[Andy Wootton]

On 09/07/14 17:35, Adam Sweet wrote:
> On 09/07/14 16:51, Andy Wootton wrote:
>> On 09/07/14 15:09, Adam Sweet wrote:
>
>>>> I seem to have a half-installed nvidia-331 that I can't remove. I get
>>>> "stop: Unknown instance:
>>>> userdel: existing lock file /etc/subuid.lock without a PID
>>>> userdel: cannot lock /etc/subuid: try again later." from aptget remove
>>>> and I can't install because it already 'is'.
>
>>> I say this without any kind of warranty of course. Googling suggests
>>> that subiud.lock is created by useradd to prevent multiple useradd
>>> instances running at the same time. I can't believe that this should
>>> be happening so removing it should be fine in single user mode while
>>> you're not running anything. This may help explain:
>>>
>>> http://askubuntu.com/questions/459080/useradd-cannot-lock-etc-subuid-try-again-later 
>>>
>>>
>>>
>>> sudo lsof /etc/subuid
>>>
>>> should tell what is using the file. If nothing, then you can remove it
>>> then run an update and dist-upgrade.
>
>> Thanks. I've never had any trouble with Linux lock files so this is new
>> to me. I wasn't sure if they locked by being there or by being open so I
>> was afraid to delete it then not know what I needed to create. Now I
>> know they're safe(ish) to delete, I can have another look. It isn't a
>> problem to completely reinstall, as it's a spare machine but if I'm
>> going to do that I may as well give up and get Windows. I started using
>> Linux to get to know Unix but everything just works, so I've never
>> really had to. I may as well try to learn something while I have the
>> chance.
>
> Lock files aren't normally safe to remove, they're created by 
> application to make sure nothing interferes with what they're doing 
> while they're doin something and then should be removed when it's 
> finished without you needing to know about them. In this case I 
> suspect something weird has happened and one has got left lying 
> around. It may be a package bug that triggered during the upgrade or 
> something.
>
> If you can boot into single user mode and run the lsof line, before 
> you do anything else, nothing else should be running and nothing 
> should be using it, so you can probably safely remove it and then try 
> to finish your upgrade which hopefully will resolve the issue.
>
> Hope that fixes it for you.
>
> Regards,
>
> Adam Sweet
>
Adam,

Sorry, my language was ambiguous. I understand the theory of locks but 
VAXen had locking in hardware so you couldn't get into this kind of mess.

Thanks, that's helped. It was /etc/subgid that has been locked since 
June 15, so I mv(ed) it out of the way and have now removed the half 
installed driver successfully, so that's a step forward. This made the 
<Alt><F1> console session change from microscopic to a sensible font 
size, so that's an 'interesting' side effect but at least I can see what 
I'm doing. I've done the upgrade and dist-upgrade to the system's 
satisfaction now, even if it still doesn't work but I have several more 
binary driver versions to try out. I'll get beck to you if I ever get it 
working.

Cheers,
Woo