[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

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.


> 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,

Attachment: signature.asc
Description: PGP signature

Reply to: