Mailing List Archive: Please help me move my backend to new host/hardware.

Please help me move my backend to new host/hardware.

Mar 24, 2023, 8:26 AM

Post #1 of 12 (266 views)

All,

I have a mythtv setup with one backend and several frontends. The
backend machine also runs a frontend to test any issues locally. They
all run some version of debian with mythtv packages installed over
standard release. Currently they all are on debian bullseye with
possibily running more recent kernels due to the need to support more
modern processors. My tuners are HDhomerun networked on the same subnet.
There are two - one 2-tuner and another 4-tuner with static IP
assignment from my home DHCP server. My current backend is also on a
static IP assignment. Other frontends are on dynamic assignment.

However, my backend is old (10+ years) and in need of HW upgrade.
Towards this, I have built a new machine with intel z690 MB and a core
i3-13100. I installed debian testing and ran a complete check to make
sure key hardware components work as expected. I also checked kernel
5.19 supports all that care about in my new machine. I am at a point to
move my backend SW setup to this machine. To support this I have a new
and unused partition of correct size in the new machine's disk. Both
current and new hardware use UEFI boot and I do not have any legacy BIOS
boot in any of my home machines.

My plan is to make image copy of the current installation, restore on
the partition created for this purpose and set it up.
Let us call the test installation (debian testing to check the hardware)
as _new-base_ and backend image copy restored on new hardware as
_new-backend_. We will use _current-backend_ to refer to the system that
is currently running and serving from the older hardware that I want to
replace. I plan to proceed this way and please let me know if I am
making any mistakes. (These steps are inspired by this:
https://www.mythtv.org/wiki/Backend_migration)

1. Shut down all frontends
2. On the current-backend, make a fresh db backup and disable backend
service (systemctl disable mythtv-backend)
3. Reboot current-backend machine using some rescue boot usb and make
image copy of the current install on to a spare disk. Shutdown the
backend machine completely and do not boot it at all again.
4. Boot new-backend hardware, bootup new-base installation, image
restore backend on to its designated partition
5. Fsck this restore to make sure everything is ok, mount it, fix
fstab, hostname and few other essential items in the restore image.
Also make sure using symlinks storage directories now point to local
disk.
6. Run update-grub on new-base install so that new-backend image
becomes a choice up on grub prompt on a reboot.
7. Reboot the image copy (new-backend) update-grub and update-initramfs
-u and reboot back into new-backend
8. Since backend.service was disabled before image copy, note backend
is running yet. Run mythtv-setup and fix master-backend name and IP
and any other essential items.
9. Transfer storage drives from current-backend machine to new-backend
drive and make sure symlinks made in step 5 are adjusted to point to
correct directories.
10. After double checking, enable backend-service and start it. Go to a
nonfrontend host, pull up mythweb and check that you can
connect/view the status on the new-backend. Ensure all tuners are
visible and you can see the listing.
11. Add a recording to see if things work as expected.
12. Start the frontend on new-backend machine enter setup and point it
to new-backend. Watch live-tv and pull up the new recording made to
check everything is ok
13. Review status of backend recordings/rules etc to make sure
everything is in order.
14. Boot up other frontends and point to the new-backend and test it.
15. Wait a week for this new setup to work as expected and then
permanently wipe the current-backend install so that it can never be
booted to cause any confusion.

Please let me know if I missed any step.

Since I used UUID for all mounting (or partition reference), I chose
image copy/restore instead of tar to create and restore the
installation. Let me know if you think that is a bad choice also.

Regards
Ramesh

Re: Please help me move my backend to new host/hardware. [ In reply to ]

stephen_agent at jsw

Mar 24, 2023, 10:01 AM

Post #2 of 12 (266 views)

Permalink

On Fri, 24 Mar 2023 10:26:07 -0500, you wrote:

>All,
>
> ?I have a mythtv setup with one backend and several frontends. The
>backend machine also runs a frontend to test any issues locally. They
>all run some version of debian with mythtv packages installed over
>standard release. Currently they all are on debian bullseye with
>possibily running more recent kernels due to the need to support more
>modern processors. My tuners are HDhomerun networked on the same subnet.
>There are two - one 2-tuner and another 4-tuner with static IP
>assignment from my? home DHCP server. My current backend is also on a
>static IP assignment. Other frontends are on dynamic assignment.
>
> ? However, my backend is old (10+ years) and in need of HW upgrade.
>Towards this, I have built a new machine with intel z690 MB and a core
>i3-13100. I installed debian testing and ran a complete check to make
>sure key hardware components work as expected. I also checked kernel
>5.19 supports all that care about in my new machine. I am at a point to
>move my backend SW setup to this machine. To support this I have a new
>and unused partition of correct size in the new machine's disk. Both
>current and new hardware use UEFI boot and I do not have any legacy BIOS
>boot in any of my home machines.
>
> ?My plan is to make image copy of the current installation, restore on
>the partition created for this purpose and set it up.
>Let us call the test installation (debian testing to check the hardware)
>as _new-base_ and backend image copy restored on new hardware as
>_new-backend_. We will use _current-backend_ to refer to the system that
>is currently running and serving from the older hardware that I want to
>replace.? I plan to proceed this way and please let me know if I am
>making any mistakes. (These steps are inspired by this:
>https://www.mythtv.org/wiki/Backend_migration)
>

Make sure the new system has the correct packages installed for the
filesystem you are using on your recording drives, if it is not ext4.
I always manage to forget to install JFS on my new systems.

> 1. Shut down all frontends
> 2. On the current-backend, make a fresh db backup and disable backend
> service (systemctl disable mythtv-backend)

Shut down and disable mythbackend before making the database backup:

systemctl --now disable mythtv-backend

> 3. Reboot current-backend machine using some rescue boot usb and make
> image copy of the current install on to a spare disk. Shutdown the
> backend machine completely and do not boot it at all again.

If you have enough space on one of your recording drives, just use a
bootable clonezilla image to create the boot drive image on one of
them. Then move that drive to the new PC and boot clonezilla there
and restore the image. Clonezilla normally copies the UUID values of
the original partitions - other backup software often will be
"helpful" and give you new UUIDs.

Clonezilla can also do image backups over your network to other
systems, but that is rather slower than doing it directly to a drive.

If the new system partition is larger than the old one, I am not sure
if clonezilla has an option to expand the system image to fill the new
partition when it does the restore. If it does not, just run gparted
and do that. Make sure the new system partition is not exactly the
same size as the old one, as that usually means the restore will fail
because the partition is too small, due to the change in size of
blocks and disk layout. If you want close to the same size, just make
it a little bit bigger than the old one.

> 4. Boot new-backend hardware, bootup new-base installation, image
> restore backend on to its designated partition
> 5. Fsck this restore to make sure everything is ok, mount it, fix
> fstab, hostname and few other essential items in the restore image.
> Also make sure using symlinks storage directories now point to local
> disk.
> 6. Run update-grub on new-base install so that new-backend image
> becomes a choice up on grub prompt on a reboot.
> 7. Reboot the image copy (new-backend) update-grub and update-initramfs
> -u and reboot back into new-backend
> 8. Since backend.service was disabled before image copy, note backend
> is running yet. Run mythtv-setup and fix master-backend name and IP
> and any? other essential items.

If the new backend has a different hostname, then run
mythconverg_restore.pl with its option to change the hostname in the
database.

> 9. Transfer storage drives from current-backend machine to new-backend
> drive and make sure symlinks made in step 5 are adjusted to point to
> correct directories.
>10. After double checking, enable backend-service and start it. Go to a
> nonfrontend host, pull up mythweb and check that you can
> connect/view the status on the new-backend. Ensure all tuners are
> visible and you can see the listing.
>11. Add a recording to see if things work as expected.
>12. Start the frontend on new-backend machine enter setup and point it
> to new-backend. Watch live-tv and pull up the new recording made to
> check everything is ok
>13. Review status of backend recordings/rules etc to make sure
> everything is in order.
>14. Boot up other frontends and point to the new-backend and test it.
>15. Wait a week for this new setup to work as expected and then
> permanently wipe the current-backend install so that it can never be
> booted to cause any confusion.
>
>Please let me know if I missed any step.
>
>Since I used UUID for all mounting (or partition reference), I chose
>image copy/restore instead of tar to create and restore the
>installation. Let me know if you think that is a bad choice also.
>
>Regards
>Ramesh

If you have not met it yet, the best way to make bootable images on
USB sticks is to use Ventoy, which allows you to have many different
bootable images on one USB:

https://ventoy.net

Once you have Ventoy installed, all you have to do to add a new Linux
image is to copy the live image .iso file onto the USB. I always have
copies of the live images of my distros, a clonezilla image and my
current Windows install image on my Ventoy USB.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: Please help me move my backend to new host/hardware. [ In reply to ]

rramesh2400 at gmail

Mar 24, 2023, 10:22 AM

Post #3 of 12 (266 views)

Permalink

On 3/24/23 12:01, Stephen Worthington wrote:

Stephen, thanks for taking the time.
>
> Make sure the new system has the correct packages installed for the
> filesystem you are using on your recording drives, if it is not ext4.
> I always manage to forget to install JFS on my new systems.
As I am making image copy of the entire install from old machine.
Everything should be in there. I am not creating a new install from
scratch. I am simply restoring image which should have everything and as
long as the old system is capable of using new hardware I should be good
to go. I will simply move the storage disks across to the new machine.
So, recordings and videos do not change at all except that they are part
of new machine after the switch.
>
>> 1. Shut down all frontends
>> 2. On the current-backend, make a fresh db backup and disable backend
>> service (systemctl disable mythtv-backend)
> Shut down and disable mythbackend before making the database backup:
>
> systemctl --now disable mythtv-backend

Thanks for specifying the order. Yes, I will do the backup after
disabling backend.
>
>> 3. Reboot current-backend machine using some rescue boot usb and make
>> image copy of the current install on to a spare disk. Shutdown the
>> backend machine completely and do not boot it at all again.
> If you have enough space on one of your recording drives, just use a
> bootable clonezilla image to create the boot drive image on one of
> them. Then move that drive to the new PC and boot clonezilla there
> and restore the image. Clonezilla normally copies the UUID values of
> the original partitions - other backup software often will be
> "helpful" and give you new UUIDs.
>
> Clonezilla can also do image backups over your network to other
> systems, but that is rather slower than doing it directly to a drive.
>
> If the new system partition is larger than the old one, I am not sure
> if clonezilla has an option to expand the system image to fill the new
> partition when it does the restore. If it does not, just run gparted
> and do that. Make sure the new system partition is not exactly the
> same size as the old one, as that usually means the restore will fail
> because the partition is too small, due to the change in size of
> blocks and disk layout. If you want close to the same size, just make
> it a little bit bigger than the old one.
I simply create partitions of exact same size and dd the old partition
on to new drive/partition. It is byte-by-byte identical to the original
on a different disk. So, the only difference will be partition number
and disk (hardware) id. I do not use either of these anywhere in the
system files. I always use UUID and not /dev/xxx naming.
> If the new backend has a different hostname, then run
> mythconverg_restore.pl with its option to change the hostname in the
> database.
If I do an image copy to create new install. So, do I have do a
restore? I can, but do I have to? I still have to fix hostname and IP in
the database which I intend to do before enabling backend.
> If you have not met it yet, the best way to make bootable images on
> USB sticks is to use Ventoy, which allows you to have many different
> bootable images on one USB:
>
> https://ventoy.net
>
> Once you have Ventoy installed, all you have to do to add a new Linux
> image is to copy the live image .iso file onto the USB. I always have
> copies of the live images of my distros, a clonezilla image and my
> current Windows install image on my Ventoy USB.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums:https://forum.mythtv.org

I kind of missed out one detail in my message intentionally. I always
have a bare minimal second install in every machine to boot as a backup.
My current-backend also has one also (xubuntu 20.04). I simply boot into
it and make a dd copy of the mythtv-install disk partition (debian
bullseye). So, the whole system is copied while it is not running at
all. It should preserve every bit of state including host name and last
IP address. After image restore, I usually fix that part and the
new-image should be usable, I think.

Regards
Ramesh

Re: Please help me move my backend to new host/hardware. [ In reply to ]

rramesh2400 at gmail

Mar 25, 2023, 3:46 PM

Post #4 of 12 (263 views)

Permalink

On 3/24/23 10:26, Ram Ramesh wrote:
> All,
>
> I have a mythtv setup with one backend and several frontends. The
> backend machine also runs a frontend to test any issues locally. They
> all run some version of debian with mythtv packages installed over
> standard release. Currently they all are on debian bullseye with
> possibily running more recent kernels due to the need to support more
> modern processors. My tuners are HDhomerun networked on the same
> subnet. There are two - one 2-tuner and another 4-tuner with static IP
> assignment from my home DHCP server. My current backend is also on a
> static IP assignment. Other frontends are on dynamic assignment.
>
> However, my backend is old (10+ years) and in need of HW upgrade.
> Towards this, I have built a new machine with intel z690 MB and a core
> i3-13100. I installed debian testing and ran a complete check to make
> sure key hardware components work as expected. I also checked kernel
> 5.19 supports all that care about in my new machine. I am at a point
> to move my backend SW setup to this machine. To support this I have a
> new and unused partition of correct size in the new machine's disk.
> Both current and new hardware use UEFI boot and I do not have any
> legacy BIOS boot in any of my home machines.
>
> My plan is to make image copy of the current installation, restore on
> the partition created for this purpose and set it up.
> Let us call the test installation (debian testing to check the
> hardware) as _new-base_ and backend image copy restored on new
> hardware as _new-backend_. We will use _current-backend_ to refer to
> the system that is currently running and serving from the older
> hardware that I want to replace. I plan to proceed this way and
> please let me know if I am making any mistakes. (These steps are
> inspired by this: https://www.mythtv.org/wiki/Backend_migration)
>
> 1. Shut down all frontends
> 2. On the current-backend, make a fresh db backup and disable backend
> service (systemctl disable mythtv-backend)
> 3. Reboot current-backend machine using some rescue boot usb and make
> image copy of the current install on to a spare disk. Shutdown the
> backend machine completely and do not boot it at all again.
> 4. Boot new-backend hardware, bootup new-base installation, image
> restore backend on to its designated partition
> 5. Fsck this restore to make sure everything is ok, mount it, fix
> fstab, hostname and few other essential items in the restore
> image. Also make sure using symlinks storage directories now point
> to local disk.
> 6. Run update-grub on new-base install so that new-backend image
> becomes a choice up on grub prompt on a reboot.
> 7. Reboot the image copy (new-backend) update-grub and
> update-initramfs -u and reboot back into new-backend
> 8. Since backend.service was disabled before image copy, note backend
> is running yet. Run mythtv-setup and fix master-backend name and
> IP and any other essential items.
> 9. Transfer storage drives from current-backend machine to
> new-backend drive and make sure symlinks made in step 5 are
> adjusted to point to correct directories.
> 10. After double checking, enable backend-service and start it. Go to
> a nonfrontend host, pull up mythweb and check that you can
> connect/view the status on the new-backend. Ensure all tuners are
> visible and you can see the listing.
> 11. Add a recording to see if things work as expected.
> 12. Start the frontend on new-backend machine enter setup and point it
> to new-backend. Watch live-tv and pull up the new recording made
> to check everything is ok
> 13. Review status of backend recordings/rules etc to make sure
> everything is in order.
> 14. Boot up other frontends and point to the new-backend and test it.
> 15. Wait a week for this new setup to work as expected and then
> permanently wipe the current-backend install so that it can never
> be booted to cause any confusion.
>
> Please let me know if I missed any step.
>
> Since I used UUID for all mounting (or partition reference), I chose
> image copy/restore instead of tar to create and restore the
> installation. Let me know if you think that is a bad choice also.
>
> Regards
> Ramesh
>
>

Unfortunately, it appears that tuners are tied to either backend name or
IP address. So, unless you name your new hardware/host the same host
name as the old one and force DHCP to assign the same IP address, the
migration process has little chance of success. Of course, you can give
a new name, but capture card and input connections will be lost. You
will have to manually rebuild it, but I am not ready for that. So, I
caved in and used same hostname and IP address.

Are there any scripts available that will change host/IP entries in the
database as part of restore? BTW, mythweb also gets confused if IP changes.

I have moved to new hardware, and first recording is in progress. Old
recordings and mythweb works as before.

A couple of nonmyth issues related to sas9211 hba card. It nolonger has
the initial greeting message from its BIOS. It also seem to prevent
shutdown/reboots. I have to bruteforce power button poweroff. May be I
need a newer kernel or a video card with vesa vga bios. However this is
not a myth issue and therefore only FYI.

Regards
Ramesh

Re: Please help me move my backend to new host/hardware. [ In reply to ]

mikep at randomtraveller

Mar 25, 2023, 4:01 PM

Post #5 of 12 (263 views)

Permalink

On 25/03/2023 22:46, Ram Ramesh wrote:
>
> Are there any scripts available that will change host/IP entries in the database as part of restore?
> BTW, mythweb also gets confused if IP changes.
>
> I have moved to new hardware, and first recording is in progress. Old recordings and mythweb works
> as before.
>
> A couple of nonmyth issues related to sas9211 hba card. It nolonger has the initial greeting message
> from its BIOS. It also seem to prevent shutdown/reboots. I have to bruteforce power button
> poweroff. May be I need a newer kernel or a video card with vesa vga bios. However this is not a
> myth issue and therefore only FYI.
>
The database restore script has an option to change host names. I think you run that /after/ doing a
restore, but I haven't had to do that recently so check using --help.

With regard to powering off, make sure you have the connections to the motherboard correct! Putting
them the wrong way around can give that symptom as can missing a pin and putting the power switch
jumper offset. I know that some of those connectors can be in awkward places and it is easy to
misalign the jumpers.

Speaking of jumpers, there may also be a separate jumper for power switch function - this is rare
these days but I have such a jumper on a board which has a 12v power supply (rather than the usual
24-pin ATX plug). Look over your documentation carefully. It took me three goes to get mine right.
--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: Please help me move my backend to new host/hardware. [ In reply to ]

rramesh2400 at gmail

Mar 25, 2023, 7:05 PM

Post #6 of 12 (263 views)

Permalink

On 3/25/23 18:01, Mike Perkins wrote
>>
> The database restore script has an option to change host names. I
> think you run that /after/ doing a restore, but I haven't had to do
> that recently so check using --help.

Thanks. That is good to know. This time, I already fixed my DHCP to
assign old IP and changed the hostname to old name. So, I am good.
However, this is a must know before next migration (may be in another
10+ years). So, I will add to my notes.
>
> With regard to powering off, make sure you have the connections to the
> motherboard correct! Putting them the wrong way around can give that
> symptom as can missing a pin and putting the power switch jumper
> offset. I know that some of those connectors can be in awkward places
> and it is easy to misalign the jumpers.

Only this installation has the reboot issue. I have another parallel
install in the same disk (debian bookworm/testing) and that shutsdown
fine. Since mythtv migration is by image copy of the old installation,
something in it is getting confused with the new hardware. Further, I
only moved my sas 9211 HBA, but not the nvidia video card. I will
experiment by bringing that card to see if that fixes the problem. I
know it sounds strange, but I have a remote theory why the combo might
work but not just HBA. Let us see how correct I am.

Regards
Ramesh

Re: Please help me move my backend to new host/hardware. [ In reply to ]

stephen_agent at jsw

Mar 25, 2023, 8:08 PM

Post #7 of 12 (263 views)

Permalink

On Sat, 25 Mar 2023 21:05:08 -0500, you wrote:

>On 3/25/23 18:01, Mike Perkins wrote
>>>
>> The database restore script has an option to change host names. I
>> think you run that /after/ doing a restore, but I haven't had to do
>> that recently so check using --help.
>
>Thanks. That is good to know. This time, I already fixed my DHCP to
>assign old IP and changed the hostname to old name. So, I am good.
>However, this is a must know before next migration (may be in another
>10+ years). So, I will add to my notes.
>>
>> With regard to powering off, make sure you have the connections to the
>> motherboard correct! Putting them the wrong way around can give that
>> symptom as can missing a pin and putting the power switch jumper
>> offset. I know that some of those connectors can be in awkward places
>> and it is easy to misalign the jumpers.
>
>Only this installation has the reboot issue. I have another parallel
>install in the same disk (debian bookworm/testing) and that shutsdown
>fine. Since mythtv migration is by image copy of the old installation,
>something in it is getting confused with the new hardware. Further, I
>only moved my sas 9211 HBA, but not the nvidia video card. I will
>experiment by bringing that card to see if that fixes the problem. I
>know it sounds strange, but I have a remote theory why the combo might
>work but not just HBA. Let us see how correct I am.
>
>Regards
>Ramesh

To diagnose shut down and power off problems, you could enable a
systemd early debug shell:

https://freedesktop.org/wiki/Software/systemd/Debugging

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.

https://linuxconfig.org/how-to-enable-all-sysrq-functions-on-linux

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 https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
# for what other values do
#kernel.sysrq=438
kernel.sysrq=1
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: Please help me move my backend to new host/hardware. [ In reply to ]

jan.ceuleers at gmail

Mar 25, 2023, 10:47 PM

Post #8 of 12 (263 views)

Permalink

On 25/03/2023 23:46, Ram Ramesh wrote:
> Unfortunately, it appears that tuners are tied to either backend name or
> IP address. So, unless you name your new hardware/host the same host
> name as the old one and force DHCP to assign the same IP address, the
> migration process has little chance of success. Of course, you can give
> a new name, but capture card and input connections will be lost. You
> will have to manually rebuild it, but I am not ready for that. So, I
> caved in and used same hostname and IP address.
>
> Are there any scripts available that will change host/IP entries in the
> database as part of restore? BTW, mythweb also gets confused if IP changes.

As Mike said, use mythconverg_restore.pl with the --change_hostname
option, as described here [1], which is referred to from the
over-arching article [2].

[1]:
https://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend
[2]: https://www.mythtv.org/wiki/Backend_migration

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: Please help me move my backend to new host/hardware. [ In reply to ]

rramesh2400 at gmail

Mar 26, 2023, 9:07 AM

Post #9 of 12 (262 views)

Permalink

On 3/26/23 00:47, Jan Ceuleers wrote:
> On 25/03/2023 23:46, Ram Ramesh wrote:
>> Unfortunately, it appears that tuners are tied to either backend name or
>> IP address. So, unless you name your new hardware/host the same host
>> name as the old one and force DHCP to assign the same IP address, the
>> migration process has little chance of success. Of course, you can give
>> a new name, but capture card and input connections will be lost. You
>> will have to manually rebuild it, but I am not ready for that. So, I
>> caved in and used same hostname and IP address.
>>
>> Are there any scripts available that will change host/IP entries in the
>> database as part of restore? BTW, mythweb also gets confused if IP changes.
> As Mike said, use mythconverg_restore.pl with the --change_hostname
> option, as described here [1], which is referred to from the
> over-arching article [2].
>
> [1]:
> https://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend
> [2]:https://www.mythtv.org/wiki/Backend_migration
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums:https://forum.mythtv.org
Jim,

Thanks. I read migration notes on the web, but did not review
db_restore notes again. So, I missed the instructions towards the end of
db_restore wiki page. In the hurry of things, we tend to skip over
critical info. My fault. Will be more careful next time.

Regards
Ramesh

Re: Please help me move my backend to new host/hardware. [ In reply to ]

rramesh2400 at gmail

Mar 26, 2023, 9:21 AM

Post #10 of 12 (262 views)

Permalink

On 3/25/23 22:08, Stephen Worthington wrote:
>
> To diagnose shut down and power off problems, you could enable a
> systemd early debug shell:
>
> https://freedesktop.org/wiki/Software/systemd/Debugging
>
> 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.
>
> https://linuxconfig.org/how-to-enable-all-sysrq-functions-on-linux
>
> 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
> # Seehttps://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
> # for what other values do
> #kernel.sysrq=438
> kernel.sysrq=1
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums:https://forum.mythtv.org
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.

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.

Regards
Ramesh

Re: Please help me move my backend to new host/hardware. [ In reply to ]

rramesh2400 at gmail

Mar 26, 2023, 2:33 PM

Post #11 of 12 (262 views)

Permalink

On 3/26/23 11:21, Ram Ramesh wrote:
> On 3/25/23 22:08, Stephen Worthington wrote:
>>
>> To diagnose shut down and power off problems, you could enable a
>> systemd early debug shell:
>>
>> https://freedesktop.org/wiki/Software/systemd/Debugging
>>
>> 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.
>>
>> https://linuxconfig.org/how-to-enable-all-sysrq-functions-on-linux
>>
>> 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
>> # Seehttps://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
>> # for what other values do
>> #kernel.sysrq=438
>> kernel.sysrq=1
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums:https://forum.mythtv.org
> 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.
>
> 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.
>
> Regards
> Ramesh

Here is what the screen says when it goes into an infinite loop
reporting some event and stays there (I only waited 5 min)

[OK] Reached tagget Power-off
[67652.NNNNNN] block device autoloading is deprecated and will be
removed
<repeat 9 more times with different numbers for NNNN>
[67667.NNNNNN] blkdev_get_no_open: 119 callbacks suppressed
<messge repeats endlessly from block device autoloading line with
different NNNN>

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.

Regards
Ramesh

Re: Please help me move my backend to new host/hardware. [ In reply to ]

rramesh2400 at gmail

Mar 26, 2023, 8:19 PM

Post #12 of 12 (262 views)

Permalink

On 3/26/23 16:33, Ram Ramesh wrote:
> On 3/26/23 11:21, Ram Ramesh wrote:
>> On 3/25/23 22:08, Stephen Worthington wrote:
>>>
>>> To diagnose shut down and power off problems, you could enable a
>>> systemd early debug shell:
>>>
>>> https://freedesktop.org/wiki/Software/systemd/Debugging
>>>
>>> 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.
>>>
>>> https://linuxconfig.org/how-to-enable-all-sysrq-functions-on-linux
>>>
>>> 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
>>> # Seehttps://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
>>> # for what other values do
>>> #kernel.sysrq=438
>>> kernel.sysrq=1
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users@mythtv.org
>>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>>> http://wiki.mythtv.org/Mailing_List_etiquette
>>> MythTV Forums:https://forum.mythtv.org
>> 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.
>>
>> 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.
>>
>> Regards
>> Ramesh
>
> Here is what the screen says when it goes into an infinite loop
> reporting some event and stays there (I only waited 5 min)
>
> [OK] Reached tagget Power-off
> [67652.NNNNNN] block device autoloading is deprecated and will be
> removed
> <repeat 9 more times with different numbers for NNNN>
> [67667.NNNNNN] blkdev_get_no_open: 119 callbacks suppressed
> <messge repeats endlessly from block device autoloading line with
> different NNNN>
>
> 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.
>
> Regards
> Ramesh
>
>
>
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.

Thanks for everyone's help.

Regards
Ramesh