Openwrt/scripts/ubinize-image.sh

155 lines
2.6 KiB
Bash
Raw Normal View History

#!/bin/sh
images: fix boot failures on NAND with small sub pages SquashFS has a minimum block size of at least 1k, so we need to make sure the last data block is also at least that big. This is not an issue on NOR or SD CARD devices, since their rootfs partitions go all the way to the end of the usable space. But on NAND with ubiblock, the rootfs partition will be the exact space, rounded up to LEB size. Unfortunately, some NAND chips with small sub pages have a LEB size of x.5 kiB. This can cause the the last data block to be less than 1k, which will cause the last block to be inaccessible, causing boot failures as seen on MR24: [ 1.532960] block ubiblock0_3: created from ubi0:3(rootfs) [ 1.538457] ubiblock: device ubiblock0_3 (rootfs) set to be root filesystem [ 1.552847] SQUASHFS error: squashfs_read_data failed to read block 0x621472 [ 1.559896] squashfs: SQUASHFS error: unable to read id index table [ 1.566474] VFS: Cannot open root device "(null)" or unknown-block(254,0): error -5 Since on most NOR devices, the start of the squashfs partition is not aligned. Since the start of the rootfs_data partition there is dependend on the SquashFS size, we cannot just always pad it, as the padding could creep into the rootfs_data partition, breaking jffs2. So fix this by ensuring a squashfs rootfs is always a multiple of 1k only for UBI and NAND sysupgrade images. Fixes #2460 without affecting NOR devices. Tested-by: Russell Senior <russell@personaltelco.net> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
2019-09-03 12:16:12 +00:00
. $TOPDIR/scripts/functions.sh
part=""
ubootenv=""
ubinize_param=""
kernel=""
rootfs=""
outfile=""
err=""
ubinize_seq=""
ubivol() {
volid=$1
name=$2
image=$3
autoresize=$4
size="$5"
echo "[$name]"
echo "mode=ubi"
echo "vol_id=$volid"
echo "vol_type=dynamic"
echo "vol_name=$name"
if [ "$image" ]; then
echo "image=$image"
images: fix boot failures on NAND with small sub pages SquashFS has a minimum block size of at least 1k, so we need to make sure the last data block is also at least that big. This is not an issue on NOR or SD CARD devices, since their rootfs partitions go all the way to the end of the usable space. But on NAND with ubiblock, the rootfs partition will be the exact space, rounded up to LEB size. Unfortunately, some NAND chips with small sub pages have a LEB size of x.5 kiB. This can cause the the last data block to be less than 1k, which will cause the last block to be inaccessible, causing boot failures as seen on MR24: [ 1.532960] block ubiblock0_3: created from ubi0:3(rootfs) [ 1.538457] ubiblock: device ubiblock0_3 (rootfs) set to be root filesystem [ 1.552847] SQUASHFS error: squashfs_read_data failed to read block 0x621472 [ 1.559896] squashfs: SQUASHFS error: unable to read id index table [ 1.566474] VFS: Cannot open root device "(null)" or unknown-block(254,0): error -5 Since on most NOR devices, the start of the squashfs partition is not aligned. Since the start of the rootfs_data partition there is dependend on the SquashFS size, we cannot just always pad it, as the padding could creep into the rootfs_data partition, breaking jffs2. So fix this by ensuring a squashfs rootfs is always a multiple of 1k only for UBI and NAND sysupgrade images. Fixes #2460 without affecting NOR devices. Tested-by: Russell Senior <russell@personaltelco.net> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
2019-09-03 12:16:12 +00:00
[ -n "$size" ] && echo "vol_size=${size}"
else
echo "vol_size=1MiB"
fi
if [ "$autoresize" ]; then
echo "vol_flags=autoresize"
fi
}
ubilayout() {
local vol_id=0
images: fix boot failures on NAND with small sub pages SquashFS has a minimum block size of at least 1k, so we need to make sure the last data block is also at least that big. This is not an issue on NOR or SD CARD devices, since their rootfs partitions go all the way to the end of the usable space. But on NAND with ubiblock, the rootfs partition will be the exact space, rounded up to LEB size. Unfortunately, some NAND chips with small sub pages have a LEB size of x.5 kiB. This can cause the the last data block to be less than 1k, which will cause the last block to be inaccessible, causing boot failures as seen on MR24: [ 1.532960] block ubiblock0_3: created from ubi0:3(rootfs) [ 1.538457] ubiblock: device ubiblock0_3 (rootfs) set to be root filesystem [ 1.552847] SQUASHFS error: squashfs_read_data failed to read block 0x621472 [ 1.559896] squashfs: SQUASHFS error: unable to read id index table [ 1.566474] VFS: Cannot open root device "(null)" or unknown-block(254,0): error -5 Since on most NOR devices, the start of the squashfs partition is not aligned. Since the start of the rootfs_data partition there is dependend on the SquashFS size, we cannot just always pad it, as the padding could creep into the rootfs_data partition, breaking jffs2. So fix this by ensuring a squashfs rootfs is always a multiple of 1k only for UBI and NAND sysupgrade images. Fixes #2460 without affecting NOR devices. Tested-by: Russell Senior <russell@personaltelco.net> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
2019-09-03 12:16:12 +00:00
local rootsize=
local autoresize=
local rootfs_type="$( get_fs_type "$2" )"
if [ "$1" = "ubootenv" ]; then
ubivol $vol_id ubootenv
vol_id=$(( $vol_id + 1 ))
ubivol $vol_id ubootenv2
vol_id=$(( $vol_id + 1 ))
fi
for part in $parts; do
name="${part%%=*}"
prev="$part"
part="${part#*=}"
[ "$prev" = "$part" ] && part=
image="${part%%=*}"
prev="$part"
part="${part#*=}"
[ "$prev" = "$part" ] && part=
size="$part"
images: fix boot failures on NAND with small sub pages SquashFS has a minimum block size of at least 1k, so we need to make sure the last data block is also at least that big. This is not an issue on NOR or SD CARD devices, since their rootfs partitions go all the way to the end of the usable space. But on NAND with ubiblock, the rootfs partition will be the exact space, rounded up to LEB size. Unfortunately, some NAND chips with small sub pages have a LEB size of x.5 kiB. This can cause the the last data block to be less than 1k, which will cause the last block to be inaccessible, causing boot failures as seen on MR24: [ 1.532960] block ubiblock0_3: created from ubi0:3(rootfs) [ 1.538457] ubiblock: device ubiblock0_3 (rootfs) set to be root filesystem [ 1.552847] SQUASHFS error: squashfs_read_data failed to read block 0x621472 [ 1.559896] squashfs: SQUASHFS error: unable to read id index table [ 1.566474] VFS: Cannot open root device "(null)" or unknown-block(254,0): error -5 Since on most NOR devices, the start of the squashfs partition is not aligned. Since the start of the rootfs_data partition there is dependend on the SquashFS size, we cannot just always pad it, as the padding could creep into the rootfs_data partition, breaking jffs2. So fix this by ensuring a squashfs rootfs is always a multiple of 1k only for UBI and NAND sysupgrade images. Fixes #2460 without affecting NOR devices. Tested-by: Russell Senior <russell@personaltelco.net> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
2019-09-03 12:16:12 +00:00
ubivol $vol_id "$name" "$image" "" "${size}MiB"
vol_id=$(( $vol_id + 1 ))
done
if [ "$3" ]; then
ubivol $vol_id kernel "$3"
vol_id=$(( $vol_id + 1 ))
fi
images: fix boot failures on NAND with small sub pages SquashFS has a minimum block size of at least 1k, so we need to make sure the last data block is also at least that big. This is not an issue on NOR or SD CARD devices, since their rootfs partitions go all the way to the end of the usable space. But on NAND with ubiblock, the rootfs partition will be the exact space, rounded up to LEB size. Unfortunately, some NAND chips with small sub pages have a LEB size of x.5 kiB. This can cause the the last data block to be less than 1k, which will cause the last block to be inaccessible, causing boot failures as seen on MR24: [ 1.532960] block ubiblock0_3: created from ubi0:3(rootfs) [ 1.538457] ubiblock: device ubiblock0_3 (rootfs) set to be root filesystem [ 1.552847] SQUASHFS error: squashfs_read_data failed to read block 0x621472 [ 1.559896] squashfs: SQUASHFS error: unable to read id index table [ 1.566474] VFS: Cannot open root device "(null)" or unknown-block(254,0): error -5 Since on most NOR devices, the start of the squashfs partition is not aligned. Since the start of the rootfs_data partition there is dependend on the SquashFS size, we cannot just always pad it, as the padding could creep into the rootfs_data partition, breaking jffs2. So fix this by ensuring a squashfs rootfs is always a multiple of 1k only for UBI and NAND sysupgrade images. Fixes #2460 without affecting NOR devices. Tested-by: Russell Senior <russell@personaltelco.net> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
2019-09-03 12:16:12 +00:00
case "$rootfs_type" in
"ubifs")
autoresize=1
;;
"squashfs")
# squashfs uses 1k block size, ensure we do not
# violate that
rootsize="$( round_up "$( stat -c%s "$2" )" 1024 )"
;;
esac
ubivol $vol_id rootfs "$2" "$autoresize" "$rootsize"
vol_id=$(( $vol_id + 1 ))
images: fix boot failures on NAND with small sub pages SquashFS has a minimum block size of at least 1k, so we need to make sure the last data block is also at least that big. This is not an issue on NOR or SD CARD devices, since their rootfs partitions go all the way to the end of the usable space. But on NAND with ubiblock, the rootfs partition will be the exact space, rounded up to LEB size. Unfortunately, some NAND chips with small sub pages have a LEB size of x.5 kiB. This can cause the the last data block to be less than 1k, which will cause the last block to be inaccessible, causing boot failures as seen on MR24: [ 1.532960] block ubiblock0_3: created from ubi0:3(rootfs) [ 1.538457] ubiblock: device ubiblock0_3 (rootfs) set to be root filesystem [ 1.552847] SQUASHFS error: squashfs_read_data failed to read block 0x621472 [ 1.559896] squashfs: SQUASHFS error: unable to read id index table [ 1.566474] VFS: Cannot open root device "(null)" or unknown-block(254,0): error -5 Since on most NOR devices, the start of the squashfs partition is not aligned. Since the start of the rootfs_data partition there is dependend on the SquashFS size, we cannot just always pad it, as the padding could creep into the rootfs_data partition, breaking jffs2. So fix this by ensuring a squashfs rootfs is always a multiple of 1k only for UBI and NAND sysupgrade images. Fixes #2460 without affecting NOR devices. Tested-by: Russell Senior <russell@personaltelco.net> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
2019-09-03 12:16:12 +00:00
[ "$rootfs_type" = "ubifs" ] || ubivol $vol_id rootfs_data "" 1
}
set_ubinize_seq() {
if [ -n "$SOURCE_DATE_EPOCH" ] ; then
ubinize_seq="-Q $SOURCE_DATE_EPOCH"
fi
}
while [ "$1" ]; do
case "$1" in
"--uboot-env")
ubootenv="ubootenv"
shift
continue
;;
"--kernel")
kernel="$2"
shift
shift
continue
;;
"--part")
parts="$parts $2"
shift
shift
continue
;;
"-"*)
ubinize_param="$@"
break
;;
*)
if [ ! "$rootfs" ]; then
rootfs=$1
shift
continue
fi
if [ ! "$outfile" ]; then
outfile=$1
shift
continue
fi
;;
esac
done
if [ ! -r "$rootfs" -o ! -r "$kernel" -a ! "$outfile" ]; then
echo "syntax: $0 [--uboot-env] [--part <name>=<file>] [--kernel kernelimage] rootfs out [ubinize opts]"
exit 1
fi
ubinize="$( which ubinize )"
if [ ! -x "$ubinize" ]; then
echo "ubinize tool not found or not usable"
exit 1
fi
ubinizecfg="$( mktemp 2> /dev/null )"
if [ -z "$ubinizecfg" ]; then
# try OSX signature
ubinizecfg="$( mktemp -t 'ubitmp' )"
fi
ubilayout "$ubootenv" "$rootfs" "$kernel" > "$ubinizecfg"
set_ubinize_seq
cat "$ubinizecfg"
ubinize $ubinize_seq -o "$outfile" $ubinize_param "$ubinizecfg"
err="$?"
[ ! -e "$outfile" ] && err=2
rm "$ubinizecfg"
exit $err