On Sep 4, 2016, at 3:12 AM, Rick Thomas <rbtho...@pobox.com> wrote: >> On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian <vagr...@debian.org> wrote: >> >>> I'd be curious if you re-install and delete each partition individually >>> and re-create manually vs. using one of the auto-partitioning methods. >
Having messed up my first try at this (albeit in a way that shed some light on the problem), I resolved to try again. I followed the standard script and did the Testing install. This time I did the manual partitioning correctly, deleting the first (and only) partition on the uSD and creating two partitions in the resulting free space, i.e. /boot and root. As expected, when it came time to reboot from the installer to the installed system, it hung and did not reboot. However, when I un-plugged and re-plugged the Cubox, just to see what would happen, lo and behold, It booted! And the installed system appears to be intact. The only unusual thing is that when it was starting up, u-boot remarked, “*** Warning - bad CRC, using default environment”. What this seems to be saying is that the “make bootable” part of the installer is not putting the boot script (or, indeed, any of the u-boot environment) where u-boot is expecting to find it. I wonder if it’s possible that the installer is using the wrong version of “/etc/fw_env.config”? Maybe this is a clue — on my machine running testing, I have the following: > rbthomas@cube:~$ cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config > # Configuration file for fw_(printenv/saveenv) utility. > # Up to two entries are valid, in this case the redundant > # environment sector is assumed present. > # > # XXX this configuration might miss a fifth parameter for the "Number of > # sectors" > > # MTD device name Device offset Env. size Flash sector size > /dev/mmcblk0 0x80000 0x2000 > rbthomas@cube:~$ cat /etc/fw_env.config > # Configuration file for fw_(printenv/saveenv) utility. > # Up to two entries are valid, in this case the redundant > # environment sector is assumed present. > # > # XXX this configuration might miss a fifth parameter for the "Number of > # sectors" > > # MTD device name Device offset Env. size Flash sector size > /dev/mmcblk0 0x80000 0x2000 > rbthomas@cube:~$ ls -ld /dev/mmcblk* > brw-rw---- 1 root disk 179, 0 Jul 25 12:50 /dev/mmcblk1 > brw-rw---- 1 root disk 179, 1 Jul 25 12:50 /dev/mmcblk1p1 > rbthomas@cube:~$ I don’t know why the uSD card is called mmcblk1, not mmcblk0, but it would certainly explain what we’re seeing if the same phenomenon is present in the installer environment… Just thinking, Rick
