Re: Cannot restore Centos 8 successfully

On 28/1/2021 9:57 π.μ., Nikolaos Milas wrote:

> What is the device.map? How can this error be avoided or fixed?

Interestingly, (I now remembered that) I had faced the same issue(s) 
again when restoring a CentOS 7 box, on the same environment (VM on a 
private cloud [GRNET ViMa VPS Service] for production systems addressed 
to the Public Research & Educational Institutions in Greece).

See the thread at: https://sourceforge.net/p/mondo/mailman/message/35572230/

At the time (4 years ago) I had found a solution, by re-installing GRUB, 
yet, the issue probably was never fixed.

However, now, with CentOS 8, I have still been unable to re-install GRUB 
successfully.

In the meantime, I made a new restore effort.

During this new effort, mondorestore did NOT ask me to do "mkinitrd 
initramfs" (or I missed it and it continued on). This has happened to me 
more than once: sometimes I am taken to do "mkinitrd initramfs" and 
sometimes not (or I miss it and it continues on, without my noticing it).

Bruno, any comments on this?

In the end, I restarted with CentOS 8 boot disk, entered Troubleshooting 
mode (Rescue / Option 1: Continue) and tried to re-install GRUB:

    chroot /mnt/sysroot

I noticed that /dev/vda1 was not mounted, so I did:

    mnt /dev/vda1 /boot

I saw that in /boot/grub2 there is a grub.cfg.pristine file (with 
current timestamp, which means it was probably created during restore). 
There is also the original (judging from timestamp) grub.cfg, which I 
renamed to grub.cfg.old and then I did:

    grub2-mkconfig -o /boot/grub2/grub.cfg

Then, to get the current UUIDs I did:

    blkid

and corrected /etc/fstab accordingly (using the current UUID for 
/dev/vda1), because the boot partition (/dev/vda1) is specified by UUID 
therein.

Finally I exited and rebooted, but still it won't boot.

I again entered Troubleshooting mode; this time, when I did:

    chroot /mnt/sysroot

I noticed that /dev/vda1 was normally mounted at /boot so I tried:

    grub2-install /dev/vda

which was executed successfully:

    Installing for i386-pc platform.
    Installation finished. No error reported.

Finally I retried rebooting and this time it booted successfully! In the 
login prompt there was a message:

    mailgwl login: [   22.150700] nf_conntrack: default automatic helper
    assignment has been turned off for security reasons and CT-based
    firewall rule not found. Use the iptables CT target to attach
    helpers instead.

I will need to investigate this, but the VM has been finally restored 
and working!

 From the above can you trace any possible issue with mondo that might 
need to get fixed to improve the restore procedure?

In any case, it is obvious that I wouldn't avoid the need to update 
/etc/fstab with the correct UUID (if it has changed). Could this be the 
cause that mondorestore fails to install GRUB successfully, i.e. due to 
the fact that the boot partition cannot be mounted correctly because of 
the UUID change?

Looking forward to your feedback.

All the best,
Nick




_______________________________________________
Mondo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mondo-devel