On 2016-09-04, Rick Thomas wrote: > On Sep 4, 2016, at 3:12 AM, Rick Thomas <rbthomas@pobox.com> wrote: > >>> On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian <vagrant@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. ... > 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. Good! > 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. That warning is unnecessarily alarming, in my opinion. It basically means it's using the default, compiled-in environment variables, and with modern u-boot using distro_bootcmd, this is a good thing. If you save the environment variables, you don't benefit from fixes and improvements to the default environment in newer u-boot versions without manually resetting to the new compiled in defaults and then re-saving them each time you update u-boot. With distro_bootcmd, there should generally be no need to save the environment variables, just update the boot script(s) used to do various different things. With flash-kernel from stretch or jessie-backports, the boot scripts are customizable in /etc/flash-kernel/bootscripts/. > I wonder if it’s possible that the installer is using the wrong > version of “/etc/fw_env.config”? The installer doesn't, and in general, shouldn't mess with the u-boot environment in such an invasive way... at least on most of the armhf platforms I've dealt with. Maybe some older armel platforms need this. live well, vagrant
Attachment:
signature.asc
Description: PGP signature