9. よくある質問¶
9.1. インストールされたシステムがパーティション全体を使用しないのはなぜですか?¶
RAUC 経由でインストールされたファイル システム イメージは、ターゲット デバイスのパーティションよりも小さいサイズで作成された可能性があります。
特に、異なるパーティション サイズを使用するデバイスに同じバンドルをインストールする場合は、ファイル システム イメージよりも tar アーカイブを使用することをお勧めします。 RAUC を tar アーカイブからインストールすると、最初にターゲット パーティションに新しいファイル システムが作成され、フル サイズを使用できるようになります。
9.2. D-Bus (クライアント/サーバーモード) なしで RAUC を使用することはできますか?¶
はい。 --disable-service 構成オプションを使用して RAUC をコンパイルすると、サービス モードおよび D-Bus サポートなしで RAUC をコンパイルできます。
./configure –disable-service
コマンド ライン ツールのすべての呼び出しは、マシンで実行されている RAUC サービス プロセスに転送されるのではなく、直接実行されます。
9.3. RAUC に ext2 / ext3 ファイルタイプがないのはなぜですか?¶
ext4 は ext3 の後継です。 ext4 よりも ext3 を使用する利点はありません。
ジャーナリングなしのファイルシステムが必要な場合、依然として ext2 を選択する傾向がある人もいます。 これは必要ありません。 作成時に ext4 でジャーナリングをオフにできるためです。
mkfs.ext4 -O ^has_journal
またはそれ以降:
tune2fs -O ^has_journal
利用可能な ext4 スロット タイプしかない場合でも、ext4 としてマウント可能な各ファイル システムが動作する可能性があることに注意してください (ファイル名の接尾辞が適用されます)。
9.4. Is the RAUC bundle format forwards/backwards compatible?¶
While RAUC now supports two bundle formats (verity and crypt) in addition to the original format (plain), all are still installable by default. Support for the old format can be disabled via the configuration. Going forward, any issue with installing bundles using old formats or features would be considered a bug, except after an explicit deprecation period of several years.
Newer RAUC versions have added features (such as casync), slot types (eMMC/MBR/GPT bootloader partitions) and bundle formats (verity and crypt). Only if you use those features by enabling them in the bundle manifest, older versions of RAUC that cannot handle them will refuse to install the bundle. As long as you don’t enable new features, our intention is that bundles created by newer versions will be installable by older versions and any such issues would be considered a bug.
Some background is described in the Forward and Backward Compatibility section.
If there are ever reasons that require an incompatible change, you can use a two step migration using an intermediate version.
9.5. Can I use RAUC with a dm-verity-protected partition?¶
Yes you can, as the offline-generated dm-verity hash tree is simply part of
the image that RAUC writes to the partition.
To ensure RAUC does not corrupt the partition by executing hooks or writing
slot status information, use type=raw in the respective slot config and
use a global (see slot status file) on a separate
non-redundant partition with setting statusfile=</path/to/global.status>.
9.6. Can I use RAUC with a dm-crypt-protected partition?¶
Yes you can, by using the /dev/mapper/<devicename> as the device for the
slot (with the type of the filesystem of your choice).
This way, RAUC interacts only with the unencrypted device/content.
For example, with an encrypted root filesystem slot (perhaps unlocked by an initramfs loaded from a different partition):
[slot.rootfs.0]
device=/dev/mapper/crypt-rootfs0
type=ext4
bootname=system0
Remember to unlock the inactive slots as well so that RAUC can write to them.
9.7. What causes a payload size that is not a multiple of 4kiB?¶
RAUC versions up to 1.4 had an issue in the casync bundle signature generation, which caused two signatures to be appended. While the squashfs payload size is a multiple of 4kiB, the end of the first signature was not aligned. As RAUC uses the second (“outer”) signature during verification, this didn’t cause problems. RAUC 1.5 fixed the casync bundle generation and added stricter checks, which rejected the older bundles. In RAUC 1.5.1, this was reduced to a notification message.
To avoid the message, you can recreate the bundle with RAUC 1.5 and newer.
9.8. How can I refer to devices if the numbering is not fixed?¶
There are many reasons why device numbering might change from one kernel version to the next, across boots or even between hardware variants. In the context of RAUC, this is mainly relevant for block, MTD and UBI devices.
In almost all cases, the proper way to configure this is to use udev rules.
For block devices, udev ships with rules which create symlinks in
/dev/disk/by-path/.
These are not affected by changes in the probe order or by other devices that
are not always connected.
For example, on an emulated ARM machine, this results in:
root@qemuarm:~# ls -l /dev/disk/by-path
lrwxrwxrwx 1 root root 9 Nov 18 12:46 platform-a003c00.virtio_mmio -> ../../vda
By using /dev/disk/by-path/platform-a003c00.virtio_mmio in your
configuration, you ensure that you always refer to the same block device.
For UBI volumes, no equivalent rules are currently shipped by udev, so custom rules can be used. Depending on how the symlinks should be named, different rules could be used:
# Use the volume name instead of the number
SUBSYSTEM=="ubi", KERNEL=="ubi*_*", ATTRS{mtd_num}=="*", SYMLINK+="$parent_%s{name}"
# Use the MTD device number instead of the UBI device number
SUBSYSTEM=="ubi", KERNEL=="ubi*_*", ATTRS{mtd_num}=="*", SYMLINK+="ubi_mtd%s{mtd_num}_%s{name}"
# Use the MTD device name instead of the UBI device number
SUBSYSTEM=="ubi", KERNEL=="ubi*_*", ATTRS{mtd_num}=="*", IMPORT{program}="/bin/sh -ec 'echo MTD_NAME=$(cat /sys/class/mtd/mtd%s{mtd_num}/name)'" SYMLINK+="ubi_%E{MTD_NAME}_%s{name}"
When enabling all of these rules (which you should not do), you will get something like:
crw------- 1 root root 249, 0 Nov 18 13:46 /dev/ubi0
crw------- 1 root root 249, 1 Nov 18 13:46 /dev/ubi0_0
lrwxrwxrwx 1 root root 6 Nov 18 13:46 /dev/ubi0_rauc-test -> ubi0_0
lrwxrwxrwx 1 root root 6 Nov 18 13:46 /dev/ubi_nandsim_rauc-test -> ubi0_0
crw------- 1 root root 10, 59 Nov 18 13:46 /dev/ubi_ctrl
lrwxrwxrwx 1 root root 6 Nov 18 13:46 /dev/ubi_mtd3_rauc-test -> ubi0_0
Custom udev rules can also be very useful when you want to refer to the active data partition (in a scenario with redundant data partitions) with a fixed name.
