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

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