[arch-general] Shutdown and reboot not working after last weekend update

[Victor Silva]

2012/6/15 Don deJuan <donjuansjiz at gmail.com>

> On 06/15/2012 02:48 PM, Victor Silva wrote:
>
>> 2012/6/15 Don deJuan <donjuansjiz at gmail.com>
>>
>>  On 06/15/2012 08:29 AM, David C. Rankin wrote:
>>>
>>>  On 06/14/2012 03:12 PM, Victor Silva wrote:
>>>>
>>>>  I have no shares. Can I somehow try to umount everything in mtab? I'm
>>>>> not
>>>>> familiar with the internal workings of mtab. I will read a bit. Also
>>>>> the
>>>>> only thing I assume could be hanging is my external HD which I
>>>>> disconnected
>>>>> having no effect on the problem behavior. Still I reported that my
>>>>> /boot
>>>>> partition was being mounted and listed on kde file manager (forgot its
>>>>> name) which was not default behavior. So could be the case that /boot
>>>>> is
>>>>> hanging my shoutdown? I don't get the reason umount -a && shutdown -h
>>>>> now
>>>>> did not do the trick.
>>>>>
>>>>> I ask gently again if you could inform me why did the "magic reboot"
>>>>> did
>>>>> work while shutdown did not.
>>>>>
>>>>> Regards,
>>>>> Victor
>>>>>
>>>>>
>>>> Victor,
>>>>
>>>>   I am no expert in the shutdown logic that Arch uses, but it is fairly
>>>> easy to follow. During shutdown, /etc/rc.shutdown is called and the
>>>> 'umount_all' command is supposed to take care of unmounting all non-api
>>>> filesystems. If you have specific commands you need run in _addition to_
>>>> what is done by rc.shutdown, then you can put those commands in
>>>> /etc/rc.local.shutdown. The /etc/rc.local.shutdown must be executable to
>>>> be called (chmod +x) or (chmod 0755). The rc.local.shutdown file is
>>>> called close to the beginning of rc.shutdown.
>>>>
>>>>   Looking at your mtab file and comparing to mine, I do not have any
>>>> usb drives connected to my system. Somebody more familiar with issues
>>>> related to usb drives will need to comment. You might want to try
>>>> Guillermo's shutdown modified as follows:
>>>>
>>>> umount -arfl -t usbfs,fuseblk
>>>>
>>>>   I don't know if that will do it, but you have 5 fuseblk filesystems
>>>> and 1 usbfs mounted. I don't know how Arch handles their unmounting.
>>>>
>>>>   Lastly, I do not use the gnome gvfs-fuse-daemon. That is another
>>>> entry to look at and make sure it isn't the issue. Maybe try your
>>>> rc.local.shutdown with:
>>>>
>>>> umount -arfl -t usbfs,fuseblk
>>>> killall gvfs-fuse-daemon  # or whatever that process actually runs as
>>>>
>>>>
>>>>
>>>>  Well just tried reinstalling made no difference. So I guess I will be
>>> looking it why it is starting that way. It may or may not be related to
>>> the
>>> shutdown issues. But other than this one thing my symptoms seem to match
>>> this minus the screen turning red when freezing. I will post back here
>>> if I
>>> sort anything out that may help this problem.
>>>
>>> I wil try this at home but I'1m at work atm,
>>>
>> https://bugs.archlinux.org/**task/30136<https://bugs.archlinux.org/task/30136>
>> ry this kernel paramether reboot=pci
>> More info:
>> http://intosimple.blogspot.**com.br/2012/06/reboot-on-dell-**
>> latitude-e6520-with-arch.html<http://intosimple.blogspot.com.br/2012/06/reboot-on-dell-latitude-e6520-with-arch.html>
>>
>>
> After reading more into that parameter I found this
> http://linux.koolsolutions.**com/2009/08/04/howto-fix-**
> linux-hangfreeze-during-**reboots-and-restarts/<http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/>
>
> They show more options. I am going to try the one you suggested shortly
> and if that does not work do the other suggested option in the link I
> posted. Thanks for pointing out your findings.
>
> A new kernel update was avaliable fo me today. I hoped it could fix some
of the issues we were facing. In fact now I have tons of errors, dbus seems
screwd and many other things, among the problems I have now is that X fails
with no screen found (both nv and nvidia drivers)  and I have no network
interfaces I fail to get eth0 up. So
*DO NOT UPDATE YOUR KERNELS
*I'm quite sad as this is a even bigger mistake than the last one. So I
think I need to chroot again rever to the old kernel...
Anyone else expecting this kind of problem?
Btw the reboor parameters for the kernel (which I've tested before the
upgrade) also did not work.

Regards,
Victor