Trying to move from running OMV 5.5.23-1(Usul) on USB thumb drive, back to hard drive, with no success.
I'm currently running OMV 5 on a USB thumb drive. I've tried many ways to backup / restore to a sas hard drive in the server. Every method I try results in this upon trying to boot to the sas drive after the restore.
**Note, fsarchver works if restoring to another USB thumb drive, but not hard disk**
I've tried backing up / restoring using fsarchiver
I've tried installing fresh OMV 5 on the sas drive, then restoring just the primary partition using fsarchiver
I've tried using dd to create a direct clone from the USB to the SAS drive
I've tried a direct clone with clonezilla to the sas drive
I've tried an rsync backup, then restoring over the top of a fresh OMV 5 install on the sas drive.
All methods give the result above.
The grub bootloader starts, then when it starts to boot, I get (initramfs)
I've tried running fsck /dev/sdc1 but it wants confirmation to try to rewrite a countless number of blocks, I keep hitting y but I've not reached the end, so I gave up on that.
I can post all the exact commands I'm running, but I'm pretty sure they're all run correctly. My guess is that it is something to do with the 2 different media types. I'm hoping someone knows what to do.
note the change in /dev/sdc1 and /dev/sdb1 as these screenshots were taken between different retries, but it's the same drive.
Actually here are some of the commands I've run:
fsarchiver restfs /mnt/6TBbackup/OMVBackup/omvbackup/backup-omv-21-Jan-2021_10-59-06.fsa id=0,dest=/dev/sda1
clone with DD:
dd if=/dev/sdn of=/dev/sda bs=16M status=progress
Restore of Rsync backup taken with the backup plugin:
I ran this command while running the live OMV on the USB, restored over the fresh install of OMV 5 on the sas drive
I first formatted the sas drive partition that was created during the OMV 5 install
rsync -aAXv --delete --exclude="lost+found" /srv/dev-disk-by-label-6TBBackup/OMVBackup/RsyncBackup/omvbackup/ /srv/dev-disk-by-uuid-d77fff66-c483-43d5-b0a5-cceef188de57/
Issue resolved. It ended up being that another SATA drive, connected to the same controller as the SAS drive, had a partition with the SAME UUID as the root partition I was restoring. This was the actual issue all along. I didn' t think it was an issue because the UUID on the USB stick matched as well, but I guess it didn't matter when booting to USB.
In my first attempt to test the restore process, I was using this SATA drive. Grub was not restored / installed correctly on this SATA drive, after restoring the dd portion of the backup, which contains the MBR and partition table, so it was not bootable. I just ended up leaving the SATA drive as is was, after that first attempt, and then added the SAS drive, which I decided would be the permanent boot drive.
When I eventually resolved the issue, I actually changed 2 things, so I didn't pinpoint the root cause.
I booted to systemrescuecd and took an fsarchvier backup of the USB stick
- I restored the new fsarchver backup to the SAS drive
- I also cleared the partitions off that SATA drive before I rebooted.
I initially thought there was an issue where something was not being backed up correctly, by using the backup plugin on the live running OS, and that instead running the backup from the liveCD resolved the issue. But that was not the case. I kind of knew in the back of my mind that the partition had been sitting on that SATA drive, but didn't think it was a problem because the partition UUID on the USB stick also matched, and it was not an issue booting from USB. But it did matter with the 2 hard disks matching, when trying to boot from hard disk. This explains why I could restore my original backups to another USB or a VM and boot without any issue. I reproduced this by simply restoring the dd portion of the backup to the sata drive again, which restores the partition table and UUID, without any data, and upon reboot, it reproduced the broken boot issue where boot halted at initramfs
This is due to my somewhat noobness with linuxI will not make this mistake again!