rootfs mounted on / is an in-memory filesystem which typically only contains the tools needed to mount the “real” root filesystem and is emptied after this is done. The initial content of the rootfs are loaded from an initramfs image stored inside or next to the kernel binary and loaded by the bootloader.
The root filesystem on flash is ubi0:root. This is a ...
Squashfs needs a block device to run, thus you need the block emulation over UBI. First make sure it is enabled in your kernel.
You can test this by using the ubiblock command on a running system. For example, running ubiblock -c /dev/ubi0_0 will create the devnode /dev/ubiblock0_0.
Once you have the dependency, you can enable the UBI block on the cmdline ...
Why the numbers don't match up
The "at least 17 erase blocks" warning counts blocks needed by the UBIFS filesystem itself. Of those 17 erase blocks, 14 are UBIFS overhead and 3 are usable filesystem space. The underlying UBI layer underneath also uses 5 erase blocks of overhead.
Getting More Space
There's no way to make a single UBI partition with a ...
UBIFS is designed only for raw flash devices, where the software handles writes to an erased bit or page separately from block erasure. UBIFS does not work on block devices, where the hardware (or usually firmware) handles page or block remapping (and thus wear leveling, to the extent that it does) so as to offer a simple interface where the software can ...
If you want to backup/restore UBIFS partition, make an UBI image with dd from the UBI mount then restore using the ubiupdatevol program from mtd-util.
Make the image:
dd if=/dev/ubi0_0 of=/save_loc/rfs1.ubi
Unmount the target partition:
Restore the image to the target partition:
ubiupdatevol /dev/ubi1_0 /save_loc/rfs1.ubi
the error is related to a problem in the flashing of the board, that
you flash a new image incorrectly - you do not erase whole flash
you flash a new image - by erasing only the erase blocks where you write, but not erasing the rest of eraseblock.
I can imagine this happening if
Ok after a lot of reading, I finally figured it out how to do it on Ubuntu:
1.) Simulate a NAND MT-device with nandsim
modprobe nandsim first_id_byte=... second_id_byte=.. third_id_byte=.. fourth_id_byte=...
List of NAND chip IDs.
2.) Find out the MT-device id
cat /proc/mtd | grep -i "NAND Simulator"
3.) Load UBI kernel module
4.) Erase ...
No, according to the UBIFS documentation, ACL support is not implemented in UBIFS:
UBIFS supports extended attributes if the corresponding configuration
option is enabled (no additional mount options are required). It
supports the user, trusted, and security name-spaces. However, access
control lists (ACL) support is not ...
switch_root moves already mounted /proc, /dev, /sys and /run to
newroot and makes newroot the new root filesystem and starts init
The program init is the process with process ID 1. It is responsible
for initializing the system in the required way. init is started
directly by the kernel and resists signal 9, ...
If there a line in /etc/inittab like:
Then if you send SIGQUIT to init it will replace itself with /tmp/updater_stage2. To reload /etc/inittab after you have changed it send SIGHUP. You can replace /etc/inittab with a bind mount:
mount --bind /tmp/inittab /etc/inittab
kill -HUP 1
kill -QUIT 1
If there is no /etc/...
Yes, it can certainly make sense. Embedded systems will commonly keep two or more separate bootable images on the flash. This way, they can erase and upgrade one, and fall back to the other if the upgrade fails. If you're keeping your root filesystem and your configuration data on the same volume, you're making your upgrade process a lot more complicated, ...