The adventures continue!<\/p>\n\n\n\n
I run a number of computers at home, almost entirely GNU\/Linux-based. As the hardware continues to age, data integrity had become more and more of a concern. I am particularly worried about sudden disk failures, and with a combination of ddrescue and timeshift I have been setting up whole-partition\/whole-disk and incremental backups on critical systems.<\/p>\n\n\n\n
I have also been trying to use SMART monitoring of SSDs and HDDs to stay ahead of failures. For example, I monitor key log messages and flags for signs of errors or warnings ahead of serious errors. I also watch the clock on these drives. The older they get, the more I should replace them. I have set time-based warnings and “red alerts” based simple disk age alone.<\/p>\n\n\n\n
I use Raspberry Pis for some of my small applications at home. Recently, I wanted to upgrade one of them from Debian bullseye to Debian bookworm. However, while I clone the main drive on the RPi I was afraid that if the upgrade rendered the system un-bootable, I would have lots of down time while I restored the main drive.<\/p>\n\n\n\n
To avoid this, I purchased a second microSD card and imaged it with the cloned partitions from the original. Here is a key lesson I learned from this.<\/p>\n\n\n\n
All of my past experience with disk cloning (see the related posts in this blog) came in handy, from originally cloning the disk images to writing those images to a new drive and then running partition checks to make sure the cloned partitions are properly expanded to the new disk size, etc.<\/p>\n\n\n\n
All of that went swimmingly. But, the new microSD would not boot when inserted into the RPi.<\/p>\n\n\n\n
The problem turned out to be a mismatch in the PARTUUID of the two cloned partitions. While the UUIDs were identical<\/em> to their original counterparts, the RPi boot process uses the PARTUUIDs to boot the correct things … and these were completely different from the originals.<\/p>\n\n\n\n So, it was an easy thing to then correct the mismatch. First, I needed to see the PARTUUIDs of the new partitions on the new microSD card. I simply executed<\/p>\n\n\n\n on the microSD card (e.g. \/dev\/sdc). This printed lots of information, including the PARTUUIDs. When I compared them to running blkid on the original disk, they were VERY different.<\/p>\n\n\n\n One then must edit two files on the new cloned drive: \/boot\/cmdline.txt and \/rootfs\/etc\/fstab. In both places the PARTUUIDs of the \/rootfs partition (needed to get the booting to succeed) and the \/rootfs and \/boot partitions (needed to mount partitions correctly during boot) are present. It was simple to edit in the new PARTUUIDs. <\/p>\n\n\n\n After the fix, the system booted like gangbusters! I hope this helps other people looking to operate backup clones of key systems like this.<\/p>\n","protected":false},"excerpt":{"rendered":" The adventures continue! I run a number of computers at home, almost entirely GNU\/Linux-based. As the hardware continues to age, data integrity had become more and more of a concern. I am particularly worried about sudden disk failures, and with a combination of ddrescue and timeshift I have been setting up whole-partition\/whole-disk and incremental backups […]<\/p>\n","protected":false},"author":2,"featured_media":7398,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":3,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"federated","footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[11],"tags":[344,343,346,345,348,204,347],"class_list":{"0":"post-7368","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-computing","8":"tag-ddrescue","9":"tag-disk-cloning","10":"tag-gparted","11":"tag-parted","12":"tag-partuuid","13":"tag-raspberry-pi","14":"tag-uuid","15":"czr-hentry"},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/steve.cooleysekula.net\/blog\/wp-content\/uploads\/2025\/07\/45673484542_e2e5c13665_b-572299241.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/posts\/7368","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/comments?post=7368"}],"version-history":[{"count":1,"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/posts\/7368\/revisions"}],"predecessor-version":[{"id":7369,"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/posts\/7368\/revisions\/7369"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/media\/7398"}],"wp:attachment":[{"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/media?parent=7368"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/categories?post=7368"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/steve.cooleysekula.net\/blog\/wp-json\/wp\/v2\/tags?post=7368"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}blkid <DEVICE>
<\/pre>\n\n\n\n