chromeos-install fails to install stateful |
|
Issue descriptionChrome Version: (copy from chrome://version) OS: (e.g. Win7, OSX 10.9.5, etc...) 9731.0.0 (Official Build) dev-channel guado_moblab test What steps will reproduce the problem? (1) chromeos-install What is the expected result? Install properly What happens instead? When it is time to mount the stateful partition to copy from the USB stick, it fails to mount. [ 9819.724643] EXT4-fs (loop7): ext4_check_descriptors: Checksum for group 128 failed (11580!=45091) [ 9819.724665] EXT4-fs (loop7): group descriptors corrupted! [ 9952.562590] init: whining-update-db main process (13045) terminated with status 1 [ 9952.562626] init: whining-update-db main process ended, respawning Retrying mkfs and mounting works fine. It does not happen all the time. Adding fsck -Vn at the end of write_partition, it appears that the partition is corrupted just after writing partition 12. [see install_err]. Purging the page cache after mkfs seems to work around the issue. We access the destination device through a loop back device that comes and goes. I would expect mount/fsck to not bypass the page cache to read the filesystem data. We are using mount from util-linux 2.28. Man page of mount from 2.30 mentions: """ Since util-linux v2.29 mount command re-uses the loop device rather than initialize a new device if the same backing file is already used for some loop device with the same offset and sizelimit. This is necessary to avoid a filesystem corruption."""
,
Jul 10 2017
After reproducing one more time:
mount /dev/loop10 /tmp/install-mount-point/
mount: wrong fs type, bad option, bad superblock on /dev/loop10,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
dropping the cache is not helping.
I end up with 10 loop device because chromeos-install is not removing them on failure:
losetup -a
/dev/loop0: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop1: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop2: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop3: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop4: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop5: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop6: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop7: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop8: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop9: [0004]:1246 (/dev/sda), offset 4456448000
/dev/loop10: [0004]:1246 (/dev/sda), offset 4456448000
Interestingly, although all loop devices point to the same location, running fsck fails only on some loop devices:
for i in $(seq 0 10) ; do fsck -Tn /dev/loop$i >/dev/null ; echo loop$i : $? ; done
e2fsck 1.43.4 (31-Jan-2017)
loop0 : 0
e2fsck 1.43.4 (31-Jan-2017)
loop1 : 4
e2fsck 1.43.4 (31-Jan-2017)
loop2 : 0
e2fsck 1.43.4 (31-Jan-2017)
loop3 : 0
e2fsck 1.43.4 (31-Jan-2017)
loop4 : 4
e2fsck 1.43.4 (31-Jan-2017)
loop5 : 0
e2fsck 1.43.4 (31-Jan-2017)
loop6 : 4
e2fsck 1.43.4 (31-Jan-2017)
loop7 : 0
e2fsck 1.43.4 (31-Jan-2017)
loop8 : 4
e2fsck 1.43.4 (31-Jan-2017)
loop9 : 0
e2fsck 1.43.4 (31-Jan-2017)
loop10 : 4
,
Jul 11 2017
Ran into the similar issue with CPFE test images on dev channel: Lars 9718.0.0, Lars 9725.0.0 and Electro 9731.0.0. But when we went back to 9715.0.0 version, it could work well. |
|
►
Sign in to add a comment |
|
Comment 1 by gwendal@chromium.org
, Jul 10 2017