Jump to content

Recommended Posts

Posted

I take regular backups from my linux boxes (rsyncing the file system). To resume, I boot from usb, copy the files to the disk of the box and then make it bootable by chrooting into the box and executing grub-install or update-grub. That works fine.

 

But how can I do this on my odroid hc2 running armbian/bullseye? I cannot boot from usb. So I need to make the sd card bootable on my debian-amd64 pc after copying the files on it. Is there some command like "update-uboot" I can execute on amd64? Or do I need a virtual host running arm architecture to do so?

 

Jüregen

  • Solution
Posted

Took me a while to find this out. Finally I found this threat that describes the procedure:

 

 

Seems you have to write a vanilla image to your sd in order to get it bootable. After that you can delete all files and put your own backup on it. Important point is to then change the current uuid in boot/boot.ini (although it says you shouldnt). That worked for me.

 

In many posts it is proposed to take a backup of the first 4 MB from your sd by dd. But restoring it is only possible on exactly the same type of sd, which will typically not be the case if you want to make a clone. I think this is because the first 4 MB do not only cover the u-boot, but also the partition table. So the partition/file system may be corrupted after writing the first 4 MB on a new sd. You have to recreate the partition table afterwards. But the system will not boot. Even when putting the right UUID in boot/boot.ini. Maybe fdisk is somehow corrupting the u-boot when writing the partition table.

 

So I see no point in backing up the first block of the sd. It will help you only if you want to use exactly the same sd again.

 

Regards,

Jürgen

 

 

Posted (edited)

If I may be so frank, I very recently made a post on this forum that would solve this for you.

Might I offer you my piece of software to manage your backups? :)

 

Edited by bedna
Posted

Hi Bedna, this is not exactly what I was looking for. I regularly run backups via rsync - so it is on a file basis, not image. This allows me easily access old states for every file - just like timemachine.

 

Jürgen

Posted (edited)
1 hour ago, jba said:

I regularly run backups via rsync - so it is on a file basis, not image

 

That is exactly what the script does.

Just with an extra bonus of you being able to write the img to a device and that filesystem will boot, and autoexpand if it's supported (witch armbian is). :)
The FIRST img created obv is of the whole system, but subsequent updates on that img files ONLY rsyncs the changed files.

 

If you only want to access the files, just mount the img file with a loop.


I urge you to read the description. :)

 

Edit

Thought I comment on this as well:

Quote

But restoring it is only possible on exactly the same type of sd, which will typically not be the case if you want to make a clone.

 

That is not true, as long as the img fits it can be written to any device.
I even tried it with the script.

I backed up a raspberry pi os from mmcblk0, wrote that img file to a usb that became sda and booted up from it.
Worked like a charm.

But that should work on any img (as long as its created with the same UUID), the os is looking for the uuid, not the device, devices can switch places between boots so they are NEVER reliable to expect to be the same.

Edited by bedna
Posted

Hi bedna,

 

I have to admit that I didnt look too deep in your script. This is mainly because my backaup strategy works now and is established for a lot of system, not only the odroid hc2. Therefore I dont want to change it.

 

But maybe our misunderstanding is based on the terms image and files. For me you can backup on image level or on file level. There is no in-between. Of course you can mount an image and access the files, but its still a different thing. And taking an image-based backup of a running system is not a good idea in my opinion.

 

> But restoring it is only possible on exactly the same type of sd, which will typically not be the case if you want to make a clone.

 

You cited this sentence but removed the sentence before which is important. I was refering to a backup of the first 4 MB of a sd (and not your script). When you restore the first 4 MB to a different sd, you will delete the partition table. So at least you have to rewrite the partition table. But even then it didnt work for me. Did not find out the reason for that, maybe I did something else wrong.

 

Regards,

Jürgen

Posted (edited)
8 hours ago, jba said:

This is mainly because my backaup strategy works now and is established for a lot of system, not only the odroid hc2

 

Oh, My bad, I though your question "How to make a sd card bootable?" was the issue. Great that you solved that!

If other people find this thread, can you explain how you solved that?

 

8 hours ago, jba said:

You cited this sentence but removed the sentence before which is important. I was refering to a backup of the first 4 MB of a sd (and not your script). When you restore the first 4 MB to a different sd, you will delete the partition table. So at least you have to rewrite the partition table. But even then it didnt work for me. Did not find out the reason for that, maybe I did something else wrong.

 

Yes, I removed it because the whole sentence did not make sense to me. It seemed you misunderstood what you quoted.
I even gave you an example of how I restored to sda from a backup from mmcblk0 and that that worked.
What I have learned I HAVE to do to make a backup that I can restore and boot from is that I HAVE to do EXACTLY what you describe above. Not only that, I need to first resize both the backup file AND the partition on that backup, THEN resize the filesystem before backing up to it.
But I am here to learn, if I do not need to do that and can somehow remove 500 lines of code in my script, I would LOVE to do that.
So again, how do you restore your backups so they become bootable?

 

A backup is NOT A BACKUP until you have restored from it

Edit.

I'm starting to believe this is an xy problem/question. You are looking for confirmation rather than the actual answer to your question.

https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem

 

I have a LOT of knowledge in these things, but always open to learn if I am ill informed.

 

Edit 2

I just realized, in OP you mentions grub, that demands a second partition. If you back up a system with boot mounted on either /boot or /boot/efi, how do you backup (rsync) those so those gets restored tp a different partition?

Edited by bedna
Posted

Finally found the better answer to my initial question. The process is described in the wiki:

 

https://docs.armbian.com/User-Guide_Recovery/#flashing-boot-loader

 

However, there is one mistake. Instead  of the last line

 

~ $ bash pack/usr/lib/u-boot/platform_install.sh pack/usr/lib/linux-u-boot-nanopineo2-current /dev/XXX # replace XXX with the actual device 

 

you need to run

 

~ $ source pack/usr/lib/u-boot/platform_install.sh 
~ $ write_uboot_platform pack/usr/lib/linux-u-boot-nanopineo2-current /dev/XXX # replace XXX with the actual device /dev/sdb

 

In addition it is important to start the partition at block 8192 (at least for my odroid HC2, may be a differnet number on other devices).

This way you can easily write your backups to an sd.

 

Regards,

Jürgen

Posted (edited)

Yes, you can obviously reinstall the boot completely instead of backing up what you have on your system. This is great info in the thread!

 

I opted for a backup rather than a reinstall. :)

 

On 11/17/2023 at 7:19 PM, jba said:

In addition it is important to start the partition at block 8192 (at least for my odroid HC2, may be a differnet number on other devices).

 

Not only may, I have learned it is more of a rule than an exception.

This an example with the opi5 img:

Model: Loopback device (loopback)
Disk /dev/loop0: 7315MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name    Flags
 1      16,8MB  285MB   268MB   fat16        bootfs  bls_boot
 2      285MB   7315MB  7030MB  ext4         rootfs

 

Witch is the reason I do a dd of the entire boot sector (including any existing boot partitions if they exist) in the initial backup, sup-sequential backups, I just mount both partitions (if there is a boot partition) on the img and backs up the entire file system.

Edited by bedna

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines