Closed Bug 1073779 Opened 10 years ago Closed 10 years ago

rpi full-SD-card flashing script has some problems

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

Product:
Firefox OS Graveyard
Component:
GonkIntegration
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: cjones, Unassigned)

References

Details

The script tries to be smart in two ways: it has you insert an SD card and triest to auto-detect the new block device, and it tries to configure the SDCARD partition to expand to fill available free space after the fixed-size boot/root/system/data/cache partitions.  This works great on the linux host and two SD cards I tested.  But it came out in https://github.com/raspberrypi/firmware/issues/315 that both of those are failing:

1. An sdcard created as /dev/sdc isn't detected as /dev/sdc, instead the script thinks one of its partitions, /dev/sdc1, is the new device.  Obviously things blow up when it tries to partition /dev/sdc1.

2. sfdisk bungles the computation of the partition geometry for the expand-into-free-space parition:

Partitioning /dev/sdc ...
[...snip...]
   Device Boot    Start       End   #sectors  Id  System
/dev/sdc1          8192    110591     102400   e  W95 FAT16 (LBA)
/dev/sdc2        112640    122879      10240  83  Linux
/dev/sdc3        124928   1148927    1024000  83  Linux
/dev/sdc4       1150976  15523839   14372864  85  Linux extended
/dev/sdc5       1153024   4089855    2936832  83  Linux
/dev/sdc6       4091904   4194303     102400  83  Linux
/dev/sdc7       4196352  15523839   11327488   c  W95 FAT32 (LBA)
[...snip...]
end of partition 4 has impossible value for cylinders: 1021 (should be in 0-1020)
 
sfdisk: I don't like these partitions - nothing changed.

The specification for the (extended) partition 4 sent to sfdisk is

1150976,+,85

where the "+" means expand into remaining space.  So sfdisk is computing an end boundary that sfdisk doesn't like!  Grrr :/.

(1) looks like it might be a quirk of unix |sort|, so probably easy to fix.  I don't know what to do about (2).  I think for now I'll roll back the smarts and just have people manually expand SDCARD using gparted (hoping that doesn't screw up the partitions either), if they need more than a few GB available on /sdcard.
How do one roll back the smarts and manually partition the cards. Here is the output from my first build on 16GB card. 

$ sudo fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
4 heads, 16 sectors/track, 486192 cylinders, total 31116288 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
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      110591       51200    e  W95 FAT16 (LBA)
/dev/mmcblk0p2          112640      122879        5120   83  Linux
/dev/mmcblk0p3          124928     1148927      512000   83  Linux
/dev/mmcblk0p4         1150976    31116287    14982656   85  Linux extended
/dev/mmcblk0p5         1153024     4089855     1468416   83  Linux
/dev/mmcblk0p6         4091904     4194303       51200   83  Linux
/dev/mmcblk0p7         4196352    31116287    13459968    c  W95 FAT32 (LBA)
It looks like your SD card was flashed correctly!  Great :).

I'd like to "dumb down" the script by making these changes

 - instead of trying to auto-detect a newly-inserted SD card, ls /dev before asking the user to insert their SD card, and then ls /dev again after asking them to insert it.  Then the user can visually scan for their new device.

 - instead of trying to expand the SDCARD partition to fill available free space, just hard-code a conservative size like 1 GB.  Then after the flashing script finishes, print a message telling users to run gparted or a similar program to resize their SDCARD partition if they want to.
(In reply to Chris Jones [:cjones] temporarily active; ni?/f?/r? if you need me from comment #2)
> It looks like your SD card was flashed correctly!  Great :).
> 
I cheated. :) 

Dropped all partitions on the card before running the script.
Another problem is that one partition-naming scheme is "foopN" but another is "fooN".  Sigh.  Definitely need another solution.
> end of partition 4 has impossible value for cylinders: 1021 (should be in 0-1020)

I'm able to reproduce something similar with another flash drive.  I hate teh lunix sometimes.
(In reply to Chris Jones [:cjones] temporarily active; ni?/f?/r? if you need me from comment #2)
>  - instead of trying to expand the SDCARD partition to fill available free
> space, just hard-code a conservative size like 1 GB.  Then after the
> flashing script finishes, print a message telling users to run gparted or a
> similar program to resize their SDCARD partition if they want to.

That sounds like a good strategy. Some distros recommend using rpi-config to resize the partition. 

http://elinux.org/RPi_Resize_Flash_Partitions#Raspi-config
Right --- we can't use that program directly in FFOS as far as I know, but that's the right kind of idea.  Note too that FFOS's partition layout is rather different than Raspbian's.
It was getting to hairy to produce FFOS disk images, so I went and pushed a commit to hard-code the 4GB partition layout in the flashing script

https://github.com/mozilla-b2g/device-rpi/commit/8f7d86369f697711cfbe99b3015938da338635d8

That means the flash.sh script should now work for any disk.  But it's usually more convenient for end users to flash pre-made builds.
You need to log in before you can comment on or make changes to this bug.