New: mkcubiecard.sh uses outdated sfdisk switch -D

https://bugs.busybox.net/show_bug.cgi?id=8516

Bug ID: 8516
Summary: mkcubiecard.sh uses outdated sfdisk switch -D
Product: buildroot
Version: 2015.08
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: tudor at tudorholton.com
CC: buildroot at uclibc.org

The mkcubiecard.sh script contains the following lines:

# ~2048, 16MB, FAT, bootable
# ~rest of drive, Ext4
{
echo 32,512,0x0C,*
echo 544,,,-
} | sfdisk -D $DRIVE

There are two problems with this:
1) On newer versions of sfdisk, the -D switch has been removed.
2) Removing the -D switch from the command allows the script to be interpreted. However, the unit sizes are different. In particular, "32,512,0x0c,*" results
in a partition starting at sector 32, of size 256K. (Not 2048, size 16MB as mentioned in the comments) so the latter part of this script fails due to the partition not being large enough.

My 2c would be to use something like parted which has a similar scripting language, but which allows us to specify units so that the numbers don't change meaning on different versions or architectures.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8516

--- Comment #1 from Tudor <[email protected]> ---
According to the linux-sunxi wiki at
http://linux-sunxi.org/Bootable_SD_card#Partitioning , the correct process is:

sfdisk -R ${card}
cat <<EOT | sfdisk --in-order -L -uM ${card}
1,16,c
,,L
EOT

This makes more sense, since we're explicitly specifying units. I've tested the above and it works correctly.

Alternatively, for a fully ext boot partition:

sfdisk -R ${card}
cat <<EOT | sfdisk -L --in-order -uM ${card}
1,,L
EOT

...and then copy uImage and script.bin to /boot on the ext partition...but that's considered experimental.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8516

--- Comment #2 from Thomas Petazzoni <[email protected]> --- Tudor, we would prefer to use "genimage" to generate a full SD card image for the Cubieboard. Would you be willing to work on this and submit a patch? Thanks!

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8516

Thomas Petazzoni <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Thomas Petazzoni <[email protected]> --- Since nobody provided any update to this board defconfig for a very long time, I've removed this defconfig from the tree. See
https://git.buildroot.org/buildroot/commit/?id=01432196cd0ab3e618d51309283b8ca34ec3bf75.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8516

--- Comment #4 from Tudor <[email protected]> ---
I think you're confusing the cubieboard with the cubieboard2. I agree that the problem was fixed, that's why I didn't submit a patch. Someone beat me to it. The new Cubieboard2 config is working perfectly, thank you!

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8516

--- Comment #5 from Thomas Petazzoni <[email protected]> --- (In reply to Tudor from comment #4)
Not sure what you mean here. The bug report was related to the mkcubieboard.sh script, which was only used for the cubieboard_defconfig, to create the SD card.

The cubieboard2_defconfig uses genimage to generate the SD card.

Since the cubieboard_defconfig was causing problems and nobody updated it in more than a year, it was removed. The cubieboard2_defconfig, which has been updated much more recently, has been kept.

Am I missing something?

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8516

--- Comment #6 from Tudor <[email protected]> ---
I was just pointing out that the bug report and your previous comment are out of sync. I reported this bug against the cubieboard2, not the original cubieboard as you assumed from the cruft left behind.

I have only ever owned a cubieboard2. At the time I reported the bug, the cubieboard2_defconfig also called mkcubieboard.sh. As you noted, it doesn't any more as it was converted to genimage before I was able to get to it.

I was only ever reporting against the cubieboard2 build, anyway, so it doesn't affect me. However, I believe the build between the two boards is identical (since the only difference is the number of cores), so I believe that the genimage script for the cubieboard2 could be easily used by cubieboard_defconfig also. However, I don't own an original cubieboard to test it.

You are receiving this mail because:
You are on the CC list for the bug.