Tar.gz BMR assistance

[DeathMeddle1337]

Hello all, I have a nice puzzler here for you all. I am trying to recover my system from an all inclusive tar.gz archive. I have tried a few different ways, I will give a bit of backstory below. Feel free to ask for any details that might be missing.

So for some reason PlayOnLinux does not like my laptop, I always have display issues after trying to install it. Either way to recover from my most recent adventure, I figured I would just unzip my tar archive over the current setup, and this worked to a point. I was able to get back into the system, hurrah. But I was now having display issues with Steam, causing it not to load. I like to play around (I always wondered what rm -rf / did, 'exactly'...now I know) so I figured, I would wipe the system, install a new instance of Debian 9, unzip over it, and go from here. So now I am here.

I installed a new instance of Debian Stretch. This install is to an encrypted LVM spanning 2 drives, exactly as the backup came from.
At this point we have the Laptop running Stretch 9 & Kernal 4.05, while the archive was made on Kernel 4.17.
Booted to a live filesystem, mounted the LVM and drive with the tar.gz, ran standard extraction of the archive to root of the LVM. This proceeded correctly, no errors.
I rebooted the system, and grub send me to the 4.05 recovery as I expected.
I altered /etc/crypttab with the new UUIDs for the drives with the output of

Code: Select all

cryptsetup luksUUID /dev/sd$$

I ran

Code: Select all

update-initramfs -u

This proceeded correctly and gave no error, generating/updating an initramfs for 4.17
I ran

Code: Select all

update-grub

This proceeded to say it updated grub and added the correct settings for the new kernel 4.17.
Reboot and grub still tries to force me into the 4.05 kernel.
Obviously I am missing something, but I am not sure what. Any points in the correct direction would be great.
Thanks for everything!

[DeathMeddle1337]

Update, reading through the man pages I also ran the following.

Code: Select all

update-grub2

And got the same issue.

[Dai_trying]

I'm no expert with lvm or anything like that but I was thinking that you might be multi-booting this machine (as you mentioned installing another instance of Debian), if this is the case your grub might be controlled by another "instance" (or OS) and if so then the OS controlling grub would need to be update-grub'd (on my machine update-grub2 is just a symlink to update-grub so would do exactly the same)

[DeathMeddle1337]

Thanks for the reply, however I made sure to format the system between these steps. I also ran rm -rf / which deletes anything under root as well.

[vitaliok78]

Hello all, I have a nice puzzler here for you all. I am trying to recover my system from an all inclusive tar.gz archive. I have tried a few different ways, I will give a bit of backstory below. Feel free to ask for any details that might be missing.

So for some reason PlayOnLinux does not like my laptop, I always have display issues after trying to install it. Either way to recover from my most recent adventure, I figured I would just unzip my tar archive over the current setup, and this worked to a point. I was able to get back into the system, hurrah. But I was now having display issues with Steam, causing it not to load. I like to play around (I always wondered what rm -rf / did, 'exactly'...now I know) so I figured, I would wipe the system, install a new instance of Debian 9, unzip over it, and go from here. So now I am here.

I installed a new instance of Debian Stretch. This install is to an encrypted LVM spanning 2 drives, exactly as the backup came from.
At this point we have the Laptop running Stretch 4.05, while the archive was made on 4.17.
Booted to a live filesystem, mounted the LVM and drive with the tar.gz, ran standard extraction of the archive to root of the LVM. This proceeded correctly, no errors.
I rebooted the system, and grub send me to the 4.05 recovery as I expected.
I altered /etc/crypttab with the new UUIDs for the drives with the output of

Code: Select all

cryptsetup luksUUID /dev/sd$$

I ran

Code: Select all

update-initramfs -u

This proceeded correctly and gave no error, generating/updating an initramfs for 4.17
I ran

Code: Select all

update-grub

This proceeded to say it updated grub and added the correct settings for the new Stretch kernel 4.17.
Reboot and grub still tries to force me into the 4.05 kernel.
Obviously I am missing something, but I am not sure what. Any points in the correct direction would be great.
Thanks for everything!

I would always do HDD low level format before installing the Debian Linux, this make sure the HDD is functional and let's the Debian installer do it's clean installation work correctly on a fully clean HDD.

[p.H]

Booted to a live filesystem, mounted the LVM and drive with the tar.gz, ran standard extraction of the archive to root of the LVM. This proceeded correctly, no errors.

Did the old and new installation use a separate partition for /boot ? If yes, did you mount it before restoring the archive and executing other actions ?

At this point we have the Laptop running Stretch 4.05, while the archive was made on 4.17.

What are 4.05 and 4.17 ? Stretch is Debian 9.

grub send me to the 4.05 recovery as I expected.

What is the "4.05 recovery" ? Why did you expect it ?

update-grub2

It is an alias of update-grub (or the other way around).

I would always do HDD low level format

Hard disk low level format is not available to the user. You probably just wrote zeroes to all the disk. This is totally overkill. Erasing signatures with wipefs is more than enough.

[DeathMeddle1337]

Thank you for your response.

I would always do HDD low level format before installing the Debian Linux, this make sure the HDD is functional and let's the Debian installer do it's clean installation work correctly on a fully clean HDD.

I am using an SSD so TRIM should have taken care of that for me. That and the process of creating an encrypted drive in the Debian installer overwrites the drive(s) for security purposes as needed, so there should be nothing left over.

[DeathMeddle1337]

Thank you for your reply, each response is in turn.

Booted to a live filesystem, mounted the LVM and drive with the tar.gz, ran standard extraction of the archive to root of the LVM. This proceeded correctly, no errors.
Did the old and new installation use a separate partition for /boot ? If yes, did you mount it before restoring the archive and executing other actions ?

As I recall I went with the simplest options during the initial install, that put everything in one encrypted lvm container, and I do see /boot in my backup. It was my understanding that running update-initramfs and update-grub would update those initial boot locations outside of that.

That being said I do remember seeing a /boot/efi when setting up my Ext. HDD through the GUI. I will look into this path further, thanks for the pointer!

At this point we have the Laptop running Stretch 4.05, while the archive was made on 4.17.
What are 4.05 and 4.17 ? Stretch is Debian 9.

Kernel Versions, I should have clarified.

grub send me to the 4.05 recovery as I expected.
What is the "4.05 recovery" ? Why did you expect it ?

Because I had not run the update-initramfs or upgrade-grub at that point, so I expected it to boot with the last known good information.

update-grub2
It is an alias of update-grub (or the other way around).

Thanks for confirming that. I kinda figured but good to know.

[p.H]

As I recall I went with the simplest options during the initial install, that put everything in one encrypted lvm container

The guided installation with encrypted LVM creates a separate boot partition mounted on /boot, as the Debian installer does not support installing GRUB with an encrypted /boot.

I do see /boot in my backup

If you created the backup archive when the boot partition was mounted, then its contents in /boot was archived.
But if it was not mounted when you restored the backup, anything in /boot in the archive was restored in the root filesystem, not in the boot partition, leaving its GRUB and kernel files untouched. And GRUB is set up to use the files in the boot partition.

It was my understanding that running update-initramfs and update-grub would update those initial boot locations outside of that.

update-initramfs re-generates the initramfs which contains the lines from /etc/crypttab which must be opened early.
update-grub re-generates /boot/grub/grub.cfg which contains the location of the kernel and initramfs files.
But they do not update the location where the core image of GRUB looks for /boot/grub.

[DeathMeddle1337]

As I recall I went with the simplest options during the initial install, that put everything in one encrypted lvm container

The guided installation with encrypted LVM creates a separate boot partition mounted on /boot, as the Debian installer does not support installing GRUB with an encrypted /boot.

I do see /boot in my backup

If you created the backup archive when the boot partition was mounted, then its contents in /boot was archived.
But if it was not mounted when you restored the backup, anything in /boot in the archive was restored in the root filesystem, not in the boot partition, leaving its GRUB and kernel files untouched. And GRUB is set up to use the files in the boot partition.

It was my understanding that running update-initramfs and update-grub would update those initial boot locations outside of that.

These do not update the location where the core part of GRUB looks for /boot/grub.

This is exactly the route I was thinking of after my last post, thank you for confirming this. I will unpack /boot to the correct location and go from there. I will let everyone know the results.

Thanks again.

[DeathMeddle1337]

So, I was able to find the correct boot partition, now it is just a matter of updating the information contained within. I can see it does display the older kernel information. Is anyone aware of a way to do update this with the correct information? Everything is branded so I doubt a simple cut/paste would work.

[p.H]

This should do the trick :
Move the contents of /boot while the partition is not mounted to a temporary directory.
Mount the boot partition. Don't forget to update the UUID in /etc/fstab.
Copy the contents of the temporary directory into /boot.