Clone to smaller disk not working.

[mkomarsr]

I'm running the latest clonepi (1.7.4) on the latest debian (10.0).

I narrowed part of the problem down to 'sed' not matching on the sfdisk output.

I made this change to move past that: MBR=sfdisk -d $DEST_DISK to MBR=sfdisk -d $DEST_DISK|tr -s \

I don't have an old machine handy, but I suspect that the sfdisk output changed recently adding some spaces. Unsure if my approach was the best, but for testing purposes, it improved things.

What I'm running into now, is: /dev/sda6: Start sector 204800 out of range. Failed to add #6 partition: Numerical result out of range

Manually creating the same partition sizes results in a different starting sector.

My knowledge of file system partitioning leaves me short of a best solution here.

Any input is welcome. I'm happy to submit a PR but would like some input on what direction to go toward a resolution.

Thanks!

For reference:

root@tvpi:~# sfdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xa8a452f2

Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 8192 137215 129024 63M e W95 FAT16 (LBA) /dev/mmcblk0p2 137216 124735487 124598272 59.4G 5 Extended /dev/mmcblk0p5 139264 204797 65534 32M 83 Linux /dev/mmcblk0p6 204800 729085 524286 256M c W95 FAT32 (LBA) /dev/mmcblk0p7 729088 124735487 124006400 59.1G 83 Linux

and

root@tvpi:~# sfdisk -l /dev/sda Disk /dev/sda: 29.7 GiB, 31914983424 bytes, 62333952 sectors Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xa8a452f2

Device Boot Start End Sectors Size Id Type /dev/sda1 8192 137215 129024 63M e W95 FAT16 (LBA) /dev/sda2 137216 62333951 62196736 29.7G 5 Extended /dev/sda5 139264 204799 65536 32M 83 Linux /dev/sda6 206848 731135 524288 256M c W95 FAT32 (LBA) /dev/sda7 733184 62333951 61600768 29.4G 83 Linux

[SpoddyCoder]

Thanks for the report and detail - currently travelling, so it'll be a few days before I can take a proper look - are you able to paste the ClonePi output?

If you do manage to find the fix before me - PR's are very welcome :)

[mkomarsr]

I created a pull request for the one issue with regard to the sfdisk output changes.

The problem with the other bug I'm looking at, is I'm not sure what the best resolution is with regard to partition management. If I could figure out how they should best be created (manually) I'd be happen to submit a PR that would resolve the issue in an automated way.

I'll see if I can come up with a solution.

On Sun, Jul 28, 2019 at 9:18 AM Paul Fernihough notifications@github.com wrote:

Thanks for the report and detail - currently travelling, so it'll be a few days before I can take a proper look - are you able to paste the ClonePi output?

If you do manage to find the fix before me - PR's are very welcome :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SpoddyCoder/clonepi/issues/7?email_source=notifications&email_token=ADTTCJ3O642325DLSA4MZRLQBWMC7A5CNFSM4IHK7O62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD266QSY#issuecomment-515762251, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTTCJZFDR7WLWK5ZTVE75DQBWMC7ANCNFSM4IHK7O6Q .

[mkomarsr]

I've looked a little more at this and can see where the bad partitioning attempt is happening, but I'm not as well versed in partitioning as I'd like to be and as such am not sure what the correct values should be. I'll look again when I get some more time.

[mkomarsr]

I've boiled it down to this:

The first thing the clone does is to use DD to replicate the partition table. Then it goes through and adjusts the partition sizes but doesn't do anything about the start block of the partitions.

I'm thinking a better approach in the event that the disks are being initialized is to instead of duplicating and then resizing the partitions, is to instead just create them from scratch with the sizes appropriate for the destination disk.

I may make that change in my fork and see where that gets me.

[SpoddyCoder]

Hey @mkomarsr - thanks for keeping the issue updated. You're correct - the approach is to do partial dd to copy the MBR (& a few byes to beyond) - and then let rsync copy the actual filesystem contents. A more refined approach would be what you're suggesting to build it from scratch - tho my feeling is there may be more devil in the detail than there than it initially seems.

If you find a full solution to your issue, please do submit a PR and I will try to review it along with your first PR.

Apologies for the slow responses - work has kept me busy the last few weeks.

[mkomarsr]

I certainly did discover the devil in those details. :) ... I think I have something getting it done though. I was hesitant on my current approach initially. I liked the idea of pulling as much data from the source filesystem as possible ... but... after some consideration I decided that the idea here (I think) is to clone NOOBS created SD cards. So in theory the partitions should always be the same (other than different sizes based on the card capacity) ... So I'm pretty happy with the direction I'm going. If you agree and it can get pulled back into your branch, that'd be awesome. If not, maybe it'll just be a fork.

[mkomarsr]

Any more thoughts on this?

[SpoddyCoder]

Thanks for chasing up @mkomarsr - the issue is now understood and a fix will be released in the next week or so.

[crankynet]

Looks like I ran into this issue. Because I want to move my system from a Pi 3 to a 4, I cloned an SD card but the card won't boot either on my Pi 4 or Pi 3. Found out the copied card is slightly smaller than my source card even though they both are from Sandisk and both are sold as 32GB SD card.