I was recently asked: "Did you solve it?"

Its been a few month since I attempted this conversion. My memory on the subject is a little foggy...

If I recall I was able to boot via the legacy BIOS but was never able to complete leapp conversion. I am slowly moving my infrastructure pieces by pieces on to new servers and evaluating.

Here are some Distro's that I am looking at:

- For the Gateway, I am testing OPNsense
- For mail I use SOGo, I am transitioning to iredmail

Moving from legacy BIOS to UEFI

I am attempting to migrate a test ClearOS Server to AlmaLinux 9 using leapp.

I running into an issue (or I think I am) where it seems for the migration to work it requires that the server boots with EUFI. Here is the message from the leapp log:

Risk Factor: high
Title: GRUB core will be updated during upgrade
Summary: On legacy (BIOS) systems, GRUB core (located in the gap between the MBR and the first partition)
does not get automatically updated when GRUB is upgraded.

My Linux CentOS servers boot is using the legacy BIOS. I believe I have done all the steps required to create the an efi partition:

[root@services26 ~]# df /boot/efi
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda5 548508 10316 538192 2% /boot/efi
[root@services26 ~]# du /boot/efi
1884 /boot/efi/EFI/BOOT
2508 /boot/efi/EFI/clearos/fonts
8424 /boot/efi/EFI/clearos
10312 /boot/efi/EFI
10316 /boot/efi
[root@services26 ~]#

Here is my partitions layout:

[root@services26 ~]# ​​​​​​​​​​​​fdisk -l /dev/sda
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 12.9 GB, 12885950464 bytes, 25167872 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 1F8BC950-871F-466E-B4C4-8E9FD8B16690


# Start End Size Type Name
1 2048 1000000 487.3M Linux filesyste Linux filesystem
2 2099200 6293503 2G Linux swap Linux swap
3 6293504 25165823 9G Linux LVM Linux LVM
4 34 2047 1007K BIOS boot BIOS boot partition
5 1000002 2099199 536.7M EFI System EFI-system
[root@services26 ~]#

The last step that I did was to run the grub install cmd:

[root@services26 ~]# grub2-install --target=x86_64-efi /dev/sda
Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
Installation finished. No error reported.
[root@services26 ~]#

The server always wants to boot from partition 1 instead of the new partition 5 that I created and not sure how to change that execution?

Thanks Nick for inquiring.

Hello Nick,

Really really really nice to heard from you again. I hope all is well...

I regards to your question: the server above is currently unavailable for me to do an update. Instead I ran a few cmds on a test vm. This is not an update but an install of mongodb-server showing similar issues with the same above 'nodejs-libs.x86_64' library. Note this time the library is not even installed ... that also can not be right?

Dependency issue: mongodb-server

Hello,

During my latest update of one of my servers, I am having a dependency issue:


---> Package openssl11-libs.x86_64 1:1.1.1k-2.el7 will be installed
---> Package v8.x86_64 1:3.14.5.10-25.el7 will be obsoleted
--> Processing Dependency: libv8.so.3()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64
--> Finished Dependency Resolution
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-1062.18.1.el7 will be erased
---> Package v8.x86_64 1:3.14.5.10-25.el7 will be obsoleted
--> Processing Dependency: libv8.so.3()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64
--> Finished Dependency Resolution
Error: Package: mongodb-server-2.6.12-6.el7.x86_64 (@clearos-epel)
Requires: libv8.so.3()(64bit)
Removing: 1:v8-3.14.5.10-25.el7.x86_64 (@clearos-epel)
libv8.so.3()(64bit)
Obsoleted By: 1:nodejs-libs-16.13.2-3.el7.x86_64 (clearos-epel)
~libv8.so.9()(64bit)[/code]

It appears that the package mongodb-server requires a library that is being removed/obsolete with the install of the package: nodejs-libs

I have had to exclude the nodejs-libs package to perform my update:

Finally found out from where this mysterious 'mcad' service message came from. It turns out that one of my Unifi AP appliances was the culprit and was configured to do remote Syslog server logging to my server gateway. Thanks Nick for your suggestions.

Hello Nick, this is so weird, same here I also can not find what is this 'mcad' process. Nothing pops out from your suggestions, B.T.W. thanks.

I think I might have to change business and start growing potatoes instead.

Low memory; process mcad (xxxxx) killed

I had a blip happen to my Gateway vm yesterday. This issue occurred between 2021-04-14 17:00:10 and 2021-04-14 20:55:51. I was notified by email of the issue, the server seem to respond appropriately. The issue stopped without my intervention.



I ran the following cmd while the issue was happening with no results.


I also restarted the vm during the event with no changes to the issue.

Does any one know what is the 'mcad' service?

Dudley Ali wrote:

Philippe Eveleigh wrote:

I could be wrong about this but I do not think you can. I believe there is no connection on cable, you join the Ethernet Network of your ISP.

If you had a PPP (ADSL, VDSL) you would have a better chance at doing this since you actually login for that protocol, you would still need to contact your ISP to see if they allow you to connect more than once. Note this does not provide more bandwidth since that is a feature of the line not the connection.

Thank you I will give it a look
Dudley

Hello Dudley,

My answer at the time might not be correct. I have learned over time that some ISP's may allow more than one connection by monitoring the MAC addresses used; anyways for ISP’s here in Canada. If you are allowed more than one connection and notice that you are denied your allocated number. You may be required to contact your ISP to clear the MAC addresses that are not in use anymore.

Regards

Agreed, as usual thank you for your input.