Bug#813995: flash-kernel: writes to nand without being aware of bad blocks
Control: reassign -1 mtd-utils
So far I see no evidence for the claim that flashcp should not be used
for writing to NAND devices in either its --help or its source (it has
no man page AFAICS).
Having a tool in Debian called "flashcp" which can (according to this
report, I haven't checked this myself) destroy some classes of flash
device with no warning is a clear problem irrespective of flash
-kernel's use of that tool.
At the very least flashcp should either abort when used on NAND devices
or should be renamed norwrite (cf. nandwrite) but ideally it would Just
Work properly when used on a nand device.
mtd-utils maintainer(s), please let me know if this is either wontfix
or if the fix is going to take some time, in either case I will
workaround flashcp in flash-kernel (either permanently or temporarily
respectively).
I suppose it is also possible that this is a bug in the underlying
/dev/mtdN and/or mtdblockN device or in the h/w specific driver at the
bottom of the stack?
codesearch.debian.net doesn't show any other use in packages other than
flash-kernel, but of course that doesn't account for users calling the
tool directly.
Thanks,
Ian.
On Sun, 2016-02-07 at 12:09 +0100, Uwe Kleine-König wrote:
> Package: flash-kernel
> Version: 3.35+deb8u2
> Severity: critical
> Justification: causes serious data loss
> Control: block 806926 with -1
>
> Hello,
>
> when flash-kernel writes a kernel/initrd to NAND flash it uses plain
> write(2) to /dev/mtdX (flash-kernel < 3.52) or flashcp
> (flash-kernel >= 3.52). If the device being written to has bad blocks
> these are tried to be erased and written by both approaches.
>
> This results in a non-booting system at best. In general writing to
> bad
> blocks can also affect other (otherwise good) blocks and so result in
> loss of unrelated data. I never saw this in practise, but the
> manufacturers of NAND flash say so.
>
> I didn't check which machines are affected, but Netgear ReadyNAS
> 102/104
> (which isn't in flash-kernel's database yet, but see below for the
> obvious entry to add support for them and #806926) is affected and
> flash
> kernel managed to break a ReadyNAS 102 already (non-permanently by
> good
> fortune as far as I can tell up to now).
> I guess there are several other machines affected though.
>
> The right fix is to use nandwrite to write to NAND flash and only use
> flashcp for NOR.
>
> Something like
>
> test -f /sys/class/mtd/mtdX/oobsize
>
> could be used to detect if the device is NAND or NOR. But there might
> be
> more reliable ways I'm not aware of.
>
> I will debug/test a bit more with the broken rn102 (and its owner :-)
> to
> maybe come up with a patch, but if someone beats me that's very
> welcome,
> too.
>
> Best regards
> Uwe
>
> -- System Information:
> Debian Release: 8.2
> APT prefers stable
> APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'),
> (1, 'experimental')
> Architecture: armhf (armv7l)
>
> Kernel: Linux 3.16.0-4-armmp (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages flash-kernel depends on:
> ii debconf [debconf-2.0] 1.5.56
> ii devio 1.2-1
> ii initramfs-tools 0.120
> ii linux-base 3.5
> ii ucf 3.0030
>
> Versions of packages flash-kernel recommends:
> ii u-boot-tools 2014.10+dfsg1-5
>
> flash-kernel suggests no packages.
>
> -- Configuration Files:
> /etc/flash-kernel/db changed:
> Machine: NETGEAR ReadyNAS 104
> DTB-Id: armada-370-netgear-rn104.dtb
> DTB-Append: yes
> Mtd-Kernel: uImage
> Mtd-Initrd: minirootfs
> U-Boot-Kernel-Address: 0x04000000
> U-Boot-Initrd-Address: 0x05000000
> Required-Packages: u-boot-tools
>
>
> -- debconf information:
> flash-kernel/linux_cmdline: quiet
>
>
Reply to: