Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"
Thanks for the quick insight into this, Karsten!
Karsten Merker dijo [Fri, Feb 10, 2017 at 09:36:33PM +0100]:
> (...) but this doesn't work in your case as we currently
> only disable the clobbering for /dev/mmcblk0 while your SD card
> shows up as /dev/mmcblk1. I am not 100% sure about that, but IIRC
> with older kernels the SD card in the cubox-i has shown up as
> /dev/mmcblk0.
Hmmm, interesting! Yes, I had not noticed it is finding the card as
mmcblk1. Checking the kernel boot messages, I see the following
messages:
# dmesg |grep mmc
[ 2.509702] sdhci-esdhc-imx 2190000.usdhc: allocated mmc-pwrseq
[ 2.771308] mmc0: SDHCI controller on 2190000.usdhc [2190000.usdhc] using ADMA
[ 2.808099] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
[ 2.816447] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
[ 2.818516] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[ 2.827572] mmc0: queuing unknown CIS tuple 0x80 (4 bytes)
[ 2.868673] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
[ 2.872362] mmc1: host does not support reading read-only switch, assuming write-enable
[ 2.880622] mmc1: new high speed SDHC card at address aaaa
[ 2.884074] mmcblk1: mmc1:aaaa SL16G 14.8 GiB
[ 2.884808] mmc0: new SDIO card at address 0001
[ 2.889061] mmcblk1: p1 p2 p3 p4 < p5 >
[ 3.609029] EXT4-fs (mmcblk1p3): mounted filesystem with ordered data mode. Opts: (null)
[ 4.715715] EXT4-fs (mmcblk1p3): re-mounted. Opts: errors=remount-ro
[ 6.173094] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac4329-sdio.bin
[ 6.179691] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac4329-sdio.txt
[ 6.181794] Adding 2016252k swap on /dev/mmcblk1p5. Priority:-1 extents:1 across:2016252k SSFS
[ 7.313952] EXT4-fs (mmcblk1p2): mounting ext2 file system using the ext4 subsystem
[ 7.322217] EXT4-fs (mmcblk1p2): mounted filesystem without journal. Opts: (null)
So... Well, mmcblk1 is mounted at mmc0 (don't know what mmc1 is), but
other than that, I see nothing too suspicious.
> The easiest solution would be to check for /dev/mmcblk instead of
> /dev/mmcblk0. If nobody has objections against this change, I'll modify
> partman-base accordingly and upload a new version (CCing the partman-base
> uploaders Max Vozeler, Anton Zinoviev, Colin Watson and Christian Perrier
> and Kibi as the d-i release manager).
I would say this makes sense. Even if I had multiple MMC units in my
system, installing on a MMC card should not clobber a preexisting
U-boot image; an option would be for d-i to install the matching right
flavor of the pre-boot environment for the current Debian release, but
of course, that would not enter in Stretch (if it was deemed desirable
at all)
> > As a very minor issue, even in the second case, after the install
> > notifies «Requesting system reboot», it just hangs. I disconnected and
> > reconnected power to get the system to boot — But it booted correctly
> > after that.
>
> I have similar experiences with systems based on other ARM-SoCs,
> but I have not been able to pinpoint the cause. The hang happens
> only when rebooting from the d-i environment; rebooting the
> installed system with exactly the same kernel works without
> problems.
Yes, I have rebooted the machine several times over from other environments.
Reply to: