Jump to content

Recommended Posts

I am creating a script that can backup sd-cards running on the system, resizing it with desired value or via resize2fs calculated.

 

I learn a lot but there are a few things I don't fully understand.

When I create a backup I dd what I understand is the bootsector, ie I grab the "start" position of the partition I am backing up with fidisk  and use that value and a blocksize of 512. I then add another 10mb (in bytes) just to be sure. Usually the bootsector is 8192 big, but not always (IIRC nanopi neo3;s is WAY bigger).

dd bs=512 count=$DDBOOTSECTOR if=/dev/mmcblk0 of=$IMG_FILE conv=noerror,sync status=progress

I then truncate the file, calculated either by resize2fs minimum calculation or via an input + file usage in df (depending of what flag I start the script with) + bootsector + yadayadayda. (if someone want me to post the script I will, but the script and calculations work, although I "force" some commands)
I then loop the created img file and delete the partition on the /dev/loop0 and recreates it to cover 100%.

Then format it with mkfs.ext4 copying the name and uuid from wherever I backup from.

 

I mount the loop and rsync /

rsync -ahvD --exclude={/lost+found,/proc/*,/sys/*,/dev/*,/tmp,/run/*,/mnt/*,/media/*,/var/log.hdd,/var/swap,/etc/udev/rules.d/70-persistent-net.rules,/var/lib/asterisk/astdb.sqlite3-journal} --info=progress2 --stats --delete --force --partial / $tmp_dir

This seems to work, but there are probably some things that are just "accepted" not really "perfect".

 

So questions:
1. Should I only dd the EXACT bootsector and not add the extra 10mb? The reason I ask is because if I try to delete the partition with parted, I have to do a hack in the scrip where I simulate button presses, it warns me that "the partition cant be outside of the disk" when I try to REMOVE it. Solution, I use sfdisk to remove the partition, but it prompts me to think there is something wrong going on here. If the size I create is ABOVE the resize2fs reported minimum i don't get this warning. sfdisk was the solution in this case, but still curious on this behavior. If I try to only dd the small part, it sometimes works, sometimes doesn't so I come here asking. (I might be able to do some further research but since I have other questions, why not ask)

 

2. Does armbian ever update the u-boot via apt?
I do my next update with rscync by looping the file and mounting it. But that wont EVER cover the bootsector.

2b. If yes, do I solve this by again dd:ing ONLY the bootsector?

 

3. I have noticed that sudo apt update on armbian includes armhf even though running arm64. This makes the update process VERY long.

dpkg --print-foreign-architectures

shows armhf so i remove it with

dpkg --remove-architecture armhf

and then

find /var/lib/apt/lists/ -type f -exec rm {} -v \;

Seems to fix this but is this a bad idea? Why is the armhf even being fetched to begin with?

To my memory I have not added arhmf architecture...

 

Thanks in advance!

Edited by bedna
typos
Link to comment
Share on other sites

Armbian & Khadas are rewarding contributors

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