<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 3/26/23 16:33, Ram Ramesh wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c64ae7a8-a787-effb-c949-3881608e0977@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 3/26/23 11:21, Ram Ramesh wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3c91cf30-ff9b-11ea-b7ba-f35ad5832398@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">On 3/25/23 22:08, Stephen
Worthington wrote:<br>
</div>
<blockquote type="cite"
cite="mid:gicv1i5c9e9ugtjngu730j54m45a0vf7p0@4ax.com"><br>
<pre class="moz-quote-pre" wrap="">To diagnose shut down and power off problems, you could enable a
systemd early debug shell:
<a class="moz-txt-link-freetext" href="https://freedesktop.org/wiki/Software/systemd/Debugging" moz-do-not-send="true">https://freedesktop.org/wiki/Software/systemd/Debugging</a>
Early debug shells also linger around late during shut down, so you
can do Ctrl-Alt-F9 and do commands like "systemctl list-jobs" and
"systemctl list-jobs | grep running" to see what is going on and what
is holding up the shut down. My usual culprits are SMB mounts that
are still trying to connect to a VM that was running on the same PC
and has already been shut down.
Systemd will also often post messages about what it is waiting for,
which should show on the console after the GUI shuts down.
Having a zombie process waiting for some combination of events that is
never going to happen before it will shut down is another common
culprit - network problems are the usual cause of these for me, with
the program in question trying to access a remote file it can not see
any more. This will cause a long delay, but not ultimately prevent a
shut down. It is best to wait at least 10 minutes before using the
reset or power button, to see if it will eventually shut down, and
hopefully allow it to log something about what happened.
And if you are having to use the power or reset button, it is a good
idea to enable all the SysRq keystrokes, so you can do Alt-SyqRq
REISUB to shut down the filesystems safely before forcing a reboot.
That prevents the usual filesystem corruption you get when using reset
or the power button while the filesystems are still up.
<a class="moz-txt-link-freetext" href="https://linuxconfig.org/how-to-enable-all-sysrq-functions-on-linux" moz-do-not-send="true">https://linuxconfig.org/how-to-enable-all-sysrq-functions-on-linux</a>
On Ubuntu, I have this towards the end of my /etc/sysctl.conf file:
###################################################################
# Magic system request Key
# 0=disable, 1=enable all, >1 bitmask of sysrq functions
# See <a class="moz-txt-link-freetext" href="https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html" moz-do-not-send="true">https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html</a>
# for what other values do
#kernel.sysrq=438
kernel.sysrq=1
_______________________________________________
mythtv-users mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:mythtv-users@mythtv.org" moz-do-not-send="true">mythtv-users@mythtv.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" moz-do-not-send="true">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a>
<a class="moz-txt-link-freetext" href="http://wiki.mythtv.org/Mailing_List_etiquette" moz-do-not-send="true">http://wiki.mythtv.org/Mailing_List_etiquette</a>
MythTV Forums: <a class="moz-txt-link-freetext" href="https://forum.mythtv.org" moz-do-not-send="true">https://forum.mythtv.org</a>
</pre>
</blockquote>
Thanks for the guidance. Like I said, shutdown (on the new
machine with old system kernel copied over) was working just
fine until I added sas 9211 hba card and a couple disks that
were on my old system. Now it completes every step and comes to
reboot target and then reports that some one is trying to do
some extra work that kernel is ignoring. I will get the exact
message and post it here. I am almost sure that if I take out
the hba card, everything will work fine. However, I do not have
enough SATA ports that I need this card. Apparently, this is one
of the cards that has excellent (long time) support on the linux
side. Since my backend is always on machine, I am not too
inconvenienced by this limitation as of now. Still it bothers me
that I have to push the power button and hold it to force the
situation. <br>
<br>
I will try to post on one of the kernel threads or debian-user
to see what I get. I doubt there are any filesys corruption
issues because on screen log shows everything except actual
power off or reboot is done. So, I am less worried about pushing
the power button. However, I will try all of your above
suggestions and will learn what internal system state is and go
from there.<br>
<br>
Regards<br>
Ramesh<br>
</blockquote>
<br>
Here is what the screen says when it goes into an infinite loop
reporting some event and stays there (I only waited 5 min)<br>
<blockquote>[OK] Reached tagget Power-off<br>
[67652.NNNNNN] block device autoloading is deprecated and will
be removed<br>
<repeat 9 more times with different numbers for NNNN><br>
[67667.NNNNNN] blkdev_get_no_open: 119 callbacks suppressed<br>
<messge repeats endlessly from block device autoloading line
with different NNNN><br>
</blockquote>
I assume by "[OK]..." line that we are really at the end of shut
down process. When I turn off and reboot, no fsck messages. So, I
assume that filesystems are safe and kernel is somehow lost in
some thread.<br>
<br>
Regards<br>
Ramesh<br>
<br>
<br>
<br>
</blockquote>
Apparently this is a known kernel bug that got fixed in 6.0.2. I
upgraded to 6.1 from debian bullseye-backports and everything is
good. My migration is successful and backend is working as usual.<br>
<br>
Thanks for everyone's help.<br>
<br>
Regards<br>
Ramesh<br>
<br>
</body>
</html>