openwrt read only file system что делать

> потому что файловая система мониторива только для чтения(ro), нужно перемонтировать в для
> чтения и записи(rw)
> #mount команда отобразит текущие точки монтирования

Делаю mount /etc, получаю:
mount: can’t read ‘/etc/fstab’: No such file or directory”
На этом воображение иссякло.

> потому что файловая система мониторива только для чтения(ro), нужно перемонтировать в для
> чтения и записи(rw)
> #mount команда отобразит текущие точки монтирования

mount говорит
rootfs on / type rootfs (rw)

Источник

Как разблокировать файловую систему только для чтения в дистрибутиве Linux маршрутизатора OpenWRT?

Исправить файлы и папки только для чтения в Windows

Я установил минимальную прошивку OpenWRT на роутер Linksys.

Когда я пытаюсь изменить некоторые файлы в /etc/ каталог например firewall.user файл с помощью команды vi firewall.user он открывает файл в read-only только атрибуты.

Как я могу разрешить редактирование файлов? В chmod команда недоступна, и моя память в маршрутизаторе очень ограничена, поэтому установка дополнительных ресурсов не является вариантом.

Файловая система монтируется только для чтения, вам нужно изменить способ ее монтирования.

Но большинство встроенных систем не работают таким образом, и в этих случаях вам нужно изменить образ, которым вы прошили устройство, чтобы он был правильным с самого начала.

Что ж, в моем случае я установил OpenWRT на SD-карту и подключил к Raspberry PI 2. Сразу после установки я получил такие ошибки:

Я пробовал такие вещи, как:

Мое решение состояло в том, чтобы снова прошить SD-карту, после чего я смог без проблем устанавливать пакеты и записывать на диск.

В качестве альтернативы, если образ хранится на micro / SD-карте / съемном носителе, вы можете подключить его к другому компьютеру Linux и запустить fsck для восстановления файловых систем, чтобы его можно было снова смонтировать. Когда вы вставляете micro / SD в другой ящик Linux, установите флажок dmesg чтобы найти имя устройства (например, / dev / sdb1) и запустить fsck как указано выше.

Источник

read-only filesystem check #4922

Comments

coelner commented Mar 14, 2021

I had problems to save a changed configuration and it takes some time to find the curiosity: the overlay filesystem was mounted readonly, but I need to check this over ssh.
However a short message in the right corner like the field «unsaved changes» would be nice.
Even the mount points page within luci didn’t show the readonly status and therefore did not show a button to remount this as readwrite.

The text was updated successfully, but these errors were encountered:

dangowrt commented Mar 14, 2021

Was it actually overlayfs being mounted r/o or rather OpenWrt’s preinit deciding to use overlayfs with upperdir==tmpfs due to other options being unavailable?
I’m asking this because preinit should make sure we NEVER end up with read-only rootfs and in case rootfs_data being unavailable it should use tmpfs instead. I could create an additional attribute in ubus call system board to allow detecting that state more comfortably (if that’s actually what you are observing).

coelner commented Mar 14, 2021

No, the overlayfs was mounted r/o. I don’t know why this happened. I rebooted the device, but this didn’t happened again.

I guess that something went horrible wrong. I can’t reproduce that issue, but nevertheless, maybe a warning symbol would be useful

dangowrt commented Mar 14, 2021 •

Looks like filesystem holding upperdir didn’t get mounted at all. Did you record logs of that situation?

coelner commented Mar 14, 2021

Sorry, no. I do not have any further information about this

hnyman commented Mar 14, 2021 •

because preinit should make sure we NEVER end up with read-only rootfs and in case rootfs_data being unavailable it should use tmpfs instead.

I think that there is an exception: if the overlay exists but is too full (preventing full overlayfs working), overlayfs mounts it as read-only.

coelner commented Mar 14, 2021

That should not be a problem here:

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Filesystems

This article is about file systems in the OpenWrt installation on built-in flash. For general external support for installing file systems on other devices, including partitioning and mounting see this page about general storage.

Common File System

OverlayFS

Used to merge two filesystems, one read-only and the other writable. flash.layout explains how this is used in OpenWrt.

tmpfs

SquashFS

SquashFS is a read only compressed filesystem. While gzip is available, at OpenWrt it uses LZMA for the compression. Since SquashFS is a read only filesystem, it doesn’t need to align the data, allowing it to pack the files tighter thus taking up significantly less space than JFFS2 (20-30% savings over a JFFS2 filesystem)!

There is a generic problem when running SquashFS on NAND: The issue is that SquashFS has no bad block management at all and requires all blocks on order; but for proper NAND bad block management you also need to be able to skip bad blocks and occasionally relocate blocks (see squashfs and NAND flash). That’s why raw SquashFS is a bad idea on NAND (it works if you use a FTL like UBIFS).

JFFS2

JFFS2 is a writable compressed filesystem with journaling and wear leveling using LZMA for the compression.

It was replaced with UBIFS.

UBIFS

Other filesystems

OpenWrt does not use other filesystems as rootfs. It supports several filesystems attached to via various mechanisms like USB, SATA or network. For a list see storage.

mini_fo

Implementation in OpenWrt

The flash.layout article documents how OpenWrt uses both SquashFS and JFFS2 filesystems combined into one filesystem by overlayfs. The kernel is also stored separately from these partitions in raw flash. When the kernel is built, it is also compressed with LZMA and gzip, as documented in imagebuilder.

Boot process

System bootup is as follows: →process.boot

/overlay was previously named /jffs2

Explanations

: Please feel free to merge Explanation 1 with Explanation 2

Explanations 1

Both SquashFS and JFFS2 are compressed filesystems using LZMA for the compression. SquashFS is a read only filesystem while JFFS2 is a writable filesystem with journaling and wear leveling.
Our job when writing the firmware is to put as much common functionality on SquashFS while not wasting space with unwanted features. Additional features can always be installed onto JFFS2 by the user. The use of mini_fo / overlayfs means that the filesystem is presented as one large writable filesystem to the user with no visible boundary between SquashFS and JFFS2 – files are simply copied to JFFS2 when they’re written.
It’s not all without side effects however.
The fact that we pack things so tightly in flash means that if the firmware ever changes, the size and location of the JFFS2 partition also changes, potentially wiping out a large chunk of JFFS2 data and corrupting the filesystem. To deal with this, we’ve implemented a policy that after each reflash the JFFS2 data is reformatted. The trick to doing that is a special value, 0xdeadc0de ; when this value appears in a JFFS2 partition, everything from that point to the end of the partition is wiped. So, hidden at the end of the firmware images, is the value 0xdeadcode, positioned such that it becomes the start of the JFFS2 partition.
The fact that we use a combination of compressed and partially read only filesystems also has an interesting effect on package management:
In particular, you need to be careful what packages you update. While opkg is more than happy to install an updated package on JFFS2, it’s unable to remove the original package from SquashFS; the end result is that you slowly start using more and more space until the JFFS2 partition is filled. The opkg util really has no idea how much space is available on the JFFS2 partition since it’s compressed, and so it will blindly keep going until the opkg system crashes – at that point you have so little space you probably can’t even use opkg to remove anything.

Explanation 2

On many embedded targets that use NOR flash for the root filesystem, OpenWrt implements a clever trick to get the most out of the limited flash memory capacity while retaining flexibility for the end-user:
Basically, during the image creation, all of the rootfs contents is packed up in a SquashFS filesystem – a highly efficient filesystem with compression support. There’s one important detail about it though: it is a read-only filesystem. To overcome this limitation OpenWrt uses the remaining portion of the NOR rootfs partition to store an additional read/write jffs2 filesystem which is “overlayed” on top of the rootfs (that is, allowing to read unchanged files from the SquashFS but storing all the modifications made to the jffs2 part).
This design has another important advantage for the end-user: even when the read/write partition is in total mess, he can always boot to the failsafe mode (which mounts only the squashfs part) and proceed from there.

Technical Details

The kernel boot process involves discovering of partitions within the NOR flash and it can be done by various target-dependent means:

After that, if MTD_ROOTFS_SPLIT is enabled, the kernel adjusts the rootfs partition size to the minimum required by the particular SquashFS image and automatically adds rootfs_data to the list of the available mtd partitions setting its beginning to the first appropriate address after the SquashFS end and size to the remainder of the original rootfs partition. The resulting list is stored in RAM only, so no partition table of any kind gets actually modified.

For overlaying a special mini_fo filesystem is used, the README is available from the sources at https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-2.6.37/209-mini_fo.patch

Can we switch the filesystem to be entirely JFFS2?

Note: : It is possible to contain the entire root filesystem on a JFFS2-Partition only, instead of a combination of both. The advantage is that changes to included files no longer leaves behind an old copy on the read only filesystem. So you could end up saving space. The disadvantage of this would be, that you have no failsafe any longer and also, JFFS2 takes significantly more space then SquashFS.

Yes, it’s technically possible, but a bit of a mess to actually pull off. The firmware has to be loaded as a trx file, which means that you have to put the JFFS2 data inside of the trx. But, as I said above, the trx has a checksum, meaning that if you ever change that data, you invalidate the checksum. The solution is that you install with the JFFS2 data contained within the trx, and then change the trx-boundaries at runtime. The end result is a single JFFS2 partition for the root filesystem. Why someone would want to do it is beyond me; it takes more space, and while it would allow you to upgrade the contents of the filesystem you would still be unable to replace the kernel (outside of the filesystem), meaning that a seamless upgrade between releases is still not possible! Having SquashFS gives you a failsafe mechanism where you can always ignore the JFFS2 partition and boot directly off SquashFS, or restore files to their original SquashFS versions.

I used to have a trick where I could convert a SquashFS install to a JFFS2 install at runtime by copying all the data onto the SquashFS partition and changing the partition boundaries. I never really had much use for the util – not to mention it required a rather large flash to store both SquashFS and JFFS2 copies of the root during transition – so support for it was dropped.

Notes

Example pictures: on formatted partition / how data is stored (and addressed on ext3)

Источник

OpenWRT Read-only file system

Problem: OpenWRT Rooter LeMaker is running on a Banana Pi. Now the modem monitoring system is rebooting the router every 5 minutes without a reason.

Reason: The SD is corrupt – Files System has a problem. We can read this also in the System Log and in the Kernel Log. If we try to install new software in the OpenWRT we get this error:

Collected errors:

* wfopen: //usr/lib/opkg/info/libext2fs.control: Read-only file system.

* wfopen: //usr/lib/opkg/info/libext2fs.postinst: Read-only file system.

* wfopen: //usr/lib/opkg/info/libext2fs.prerm: Read-only file system.

Also in the top of the web interface we can see, there are many “Unsaved changes”.

OpenWRT Unsaved Changes

Solution OpenWRT Read-only file system:

Create a backup from you System ( System – Backup / Flash Firmware). Then remove the SD card from your Banana PI and flash the OpenWRT again! There is now way to fix the problem.

When you’re a finished then you can Restore backup. So you get all settings back to your router. Only additional software you have to install again.

Solution 2: OpenWRT Read-only file system

If on your router has installed the e2fsck pack, you can run

You can put this in the Local Startup!

You must confirm all questions with Y. Then reboot the router.

Then you should enable the “Check Files System” on your router to prevent errors.

You will find this option on System – Mount Points

Источник

• ← принципы счастливой семейной жизни
• синяк появился через несколько дней →