Current Debian Image for A20-SOM broken?

Started by hesspet, June 27, 2015, 03:28:48 PM

Previous topic - Next topic

hesspet

Hello I've downloaded the SD Card image from here:

https://www.olimex.com/wiki/A20-SOM

Put it on SD Card an it runs on the board, but accessing the SD Card with gparted or parted or other tools leads do errors.

This ist strange. It looks like, that the partition table is in some way inconsitstent.

E.g.


parted /dev/sda
GNU Parted 2.3
Verwende /dev/sda
Willkommen zu GNU Parted! Geben Sie 'help' ein, um eine Liste der verfügbaren Kommados zu erhalten.
(parted) print                                                           
Modell: USB Mass Storage Device (scsi)
Festplatte  /dev/sda:  7969MB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: loop

Nummer  Anfang  Ende    Größe   Dateisystem  Flags
1      0,00B   7969MB  7969MB  fat32


Only one partition? This could not be.

cause:
In the A20 I see two partitions.


# lsblk

NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda            8:0    1   7,4G  0 disk
├─sda1         8:1    1    16M  0 part
└─sda2         8:2    1   3,7G  0 part



At the end this means, resizing of the partition is not possible, so this image is unusable, cause resizing or adding other partition won't work. Can someone give me a hint how to fix this problem? (Without building my own SD.Image)


Gerrit

parted is broken in my opinion.

QuoteHello I've downloaded the SD Card image from here:

https://www.olimex.com/wiki/A20-SOM

Why don't you follow the instructions on this page then to resize.

The Debian Linux image is 4GB and the file system can be extended to suit a bigger card. Use the following three commands to execute a script that would use all the free space of your card:

  sudo su
  resize_sd.sh /dev/mmcblk0 2
  reboot


if resize_sd.sh can be found try /opt/resize_sd.sh /dev/mmcblk0 2

the script uses fdisk and resize2fs in the same way as described here https://www.olimex.com/forum/index.php?topic=4105.msg17367#msg17367


d4

In short the problem is as follows. I  think that the image file was
built on a SD card that was originally formatted as a single VFAT volume
(no partitions). Then it was partitioned as it is now. But the VFAT
signature is still present at the beginning of the image file. This
confuses 'parted' and may lead to big data loss.

The explanation and more details are in   http://bugs.debian.org/788808

You should use the command

dd conv=notrunc if=/dev/zero of=THEIMAGEFILE.img bs=446 count=1

on the image file, and on any other image file where you read 'MSDOS' in
the output of
od  -c THEIMAGE.img | head