[Buildroot] Check root file system at boot time

[Buildroot] Check root file system at boot time

[psnsilva]

Hello all.
I am facing a problem with checking my root file system at boot time and I
don't know what I am missing here.
The target device is a Raspberry Pi and my intention is to check the SD card
at boot time.

I have the following configuration to e2fsck:
# cat /etc/e2fsck.conf
[options]
        log_dir = /var/log/e2fsck
        log_filename = %D%T-e2fsck-%N.%h.log
        log_dir_wait = true
        accept_time_fudge = true
        *broken_system_clock = true*     (as the rPi has no RTC)

And I defined the verification to occur on each boot (at this development
phase): *tune2fs -C 2 -c 1 /dev/mmcblk0p2*

However, in every boot I get the message:
[    2.431923] EXT4-fs (mmcblk0p2): *warning: maximal mount count reached,
running e2fsck is recommended*
[    2.467516] EXT4-fs (mmcblk0p2): recovery complete
[    2.477056] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data
mode. Opts: (null)

and running "*e2fsck -n /dev/mmcblk0p2*" I get:
e2fsck -n /dev/mmcblk0p2
e2fsck 1.42.9 (28-Dec-2013)
Warning!  /dev/mmcblk0p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem
check.
*/dev/mmcblk0p2 has been mounted 4 times without being checked, check
forced.*
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1791665, counted=1791658).
Fix? no

/dev/mmcblk0p2: 3451/467712 files (0.2% non-contiguous), 79183/1870848
blocks

My /etc/fstab as the following entries (among others):
/dev/mmcblk0p1          /boot                        vfat      noatime                   
0       2
/dev/mmcblk0p2         /                               ext4     
defaults,noatime       0       1

In addition, running e2fsck to the SD card, but using my Linux PC is
working. At the next rPi boot the messages does not appear. Reappearing
again on the the second and following boots.

Am I missing some needed scripts at /etc/init.d/ (e.g., SXXcheckroot)?

Thank you in advance by your time.
Kind regards,
Pedro Silva



--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Check-root-file-system-at-boot-time-tp71600.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

[Buildroot] Check root file system at boot time

[Yann E. MORIN]

Pedro, All,

On 2014-06-04 09:02 -0700, psnsilva spake thusly:
> I am facing a problem with checking my root file system at boot time and I
> don't know what I am missing here.
> The target device is a Raspberry Pi and my intention is to check the SD card
> at boot time.

This should not be necessary if the system is properly shut down or
rebooted. In case of power failure, the filesystem is automatically
checked by the filesystem "driver" in the kernel.

Besides, with the standard Buildroot boot process, the root filesystem is
already mounted by the time you can run e2fsck, so you're out of luck in
any case.

> and running "*e2fsck -n /dev/mmcblk0p2*" I get:
> e2fsck -n /dev/mmcblk0p2

You should *not* run fsck on a read-write mounted filesystem. This could
gravely confuse the filesystem "driver" in the kernel.

> In addition, running e2fsck to the SD card, but using my Linux PC is
> working. At the next rPi boot the messages does not appear. Reappearing
> again on the the second and following boots.
> 
> Am I missing some needed scripts at /etc/init.d/ (e.g., SXXcheckroot)?

How do you turn off your RPi? If you just unplug the power from the RPI
without doing a proper shutdown, then it is expected the filesystem will
be incoherent, and a repair is done on the next boot.

I have a bunch of RPi herre at home, and I never experienced this
behaviour when I issue a "shutdown" or a "poweroff" command before
unplugging the power supply.

BTW, the "poweroff" command will not power off the RPI, obviously, since
it lacks a power control circuit, but will flash the "ACT" LED 10 times
when it is safe to remove the power supply from the RPi  (I discovered
that by accident, and it is very handy on a headless RPi!)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Check root file system at boot time

[psnsilva]

Hi Yann,
Thank you by your time.

I usually properly shutdown the rPi triggering "poweroff" or "reboot".
However, the system I am build is to be installed at an uncontrolled
environment, where power interruptions can occur.

As you say, I would expect that in this case the "filesystem "driver" in the
kernel" automatically check the file system at boot time, but it's not
happening. I think I have all the necessary tools (e2fstools) and
configurations on my systems, but I should be missing something here.

Thank you very much,
Pedro Silva




--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Check-root-file-system-at-boot-time-tp71600p71653.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

[Buildroot] Check root file system at boot time

[Yann E. MORIN]

Pedro, All,

On 2014-06-05 03:25 -0700, psnsilva spake thusly:
> I usually properly shutdown the rPi triggering "poweroff" or "reboot".
> However, the system I am build is to be installed at an uncontrolled
> environment, where power interruptions can occur.

Ah, then that makes sense.

> As you say, I would expect that in this case the "filesystem "driver" in the
> kernel" automatically check the file system at boot time, but it's not
> happening.

Check your dmesg for messages like "recovery required on readonly
filesystem".

These mean that recovery on the filesystem is indeed happening.

> I think I have all the necessary tools (e2fstools) and
> configurations on my systems, but I should be missing something here.

As I said, you can't really do an fscp pass on a mounted filesystem. You
may be able to do so on a filesystem mounted read-only, but then you'd
have to reboot after fixing the filesystem.

An alternate solution would be to boot into an initramfs, that would be
responsible for checking the root filesystem, and then pivotroot-ing
into it.

But that will need some additional work on your side, since that not the
standrrd boot process of Buildroot-generated systems.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Check root file system at boot time

[psnsilva]

Analysing dmesg I have the following:
*[    2.035620] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly
filesystem*
*[    2.042939] EXT4-fs (mmcblk0p2): write access will be enabled during
recovery*
[    2.113153] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    2.119785] Indeed it is in host mode hprt0 = 00001101
[    2.333461] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    2.341438] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[    2.349484] hub 1-1:1.0: USB hub found
[    2.353421] hub 1-1:1.0: 5 ports detected
[    2.633280] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
*[    2.698021] EXT4-fs (mmcblk0p2): recovery complete*
*[    2.713363] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data
mode. Opts: (null)*
[    2.721530] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    2.729450] devtmpfs: mounted
[    2.732899] Freeing unused kernel memory: 136K (c0570000 - c0592000)
[    2.753632] usb 1-1.1: New USB device found, idVendor=0424,
idProduct=ec00
[    2.760523] usb 1-1.1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[    2.771391] smsc95xx v1.0.4
*[    2.837447] EXT4-fs (mmcblk0p2): warning: maximal mount count reached,
running e2fsck is recommended*
[    2.846996] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at
usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:be:e9:89
[    2.861325] EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered

So, as far I understood, despite the warning "maximal mount count reached,
running e2fsck is recommended", the SD card checking is actuality happening
(recovery complete)... Is it?



--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Check-root-file-system-at-boot-time-tp71600p71727.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

[Buildroot] Check root file system at boot time

[Yann E. MORIN]

Pedro, All,

On 2014-06-06 06:46 -0700, psnsilva spake thusly:
> Analysing dmesg I have the following:
> *[    2.035620] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly
> filesystem*
> *[    2.042939] EXT4-fs (mmcblk0p2): write access will be enabled during
> recovery*
> [    2.113153] usb 1-1: new high-speed USB device number 2 using dwc_otg
> [    2.119785] Indeed it is in host mode hprt0 = 00001101
> [    2.333461] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
> [    2.341438] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [    2.349484] hub 1-1:1.0: USB hub found
> [    2.353421] hub 1-1:1.0: 5 ports detected
> [    2.633280] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
> *[    2.698021] EXT4-fs (mmcblk0p2): recovery complete*
> *[    2.713363] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data
> mode. Opts: (null)*
> [    2.721530] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
> [    2.729450] devtmpfs: mounted
> [    2.732899] Freeing unused kernel memory: 136K (c0570000 - c0592000)
> [    2.753632] usb 1-1.1: New USB device found, idVendor=0424,
> idProduct=ec00
> [    2.760523] usb 1-1.1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [    2.771391] smsc95xx v1.0.4
> *[    2.837447] EXT4-fs (mmcblk0p2): warning: maximal mount count reached,
> running e2fsck is recommended*
> [    2.846996] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at
> usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:be:e9:89
> [    2.861325] EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
> 
> So, as far I understood, despite the warning "maximal mount count reached,
> running e2fsck is recommended",

How do you build your ext4 filesystem? The way it is generated by
Buildroot is that the maximal mount count is disabled for the ext
familly of filesystems. It looks like you are generating your ext4
filesystem outside of Buildroot, correct? (Note: this has no impact
on the fact that the filesystem would be or would not be checked
after an unclean shutdown.)

> the SD card checking is actuality happening
> (recovery complete)... Is it?

Yes it is.

However, it is anyway highly suggested that you do an fsck pass on a
filesystem which was not properly unmounted. You could o either:

  - boot into an initramfs which would do the fsck, then pivot-root into
    the real filesystem

  - run fsck from the ereal root, and reboot in case fsck did some
    changes to the filesystem

The first case is the cleanest solution, since you delegate the entire
check to fsck, rather than let the filesystem "dirver" in the kernel do
the check.

For the second solution, the check-and-fixing done by the kernel will
anyway occur even before you would have a chance to run fsck.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Check root file system at boot time

[psnsilva]

I am generating the ext4 file system within buildroot. What I did here was,
after the first boot, to force the check every boot issuing the command
"tune2fs -C 2 -c 1 /dev/mmcblk0p2". But seems like I have no need for doing
it.



--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/Check-root-file-system-at-boot-time-tp71600p71738.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

[Buildroot] Check root file system at boot time

[Yann E. MORIN]

Pedro, All,

On 2014-06-06 09:42 -0700, psnsilva spake thusly:
> I am generating the ext4 file system within buildroot. What I did here was,
> after the first boot, to force the check every boot issuing the command
> "tune2fs -C 2 -c 1 /dev/mmcblk0p2". But seems like I have no need for doing
> it.

Ah, OK. No it is not needed. Upon mounted an uncleanly unmounted
filesystem, the kernel will (try to) repair it.

Note however, that if the filesystem is that badly damaged that the
kernel can't even repair it, your screwed. fsck might have a better
chance of fixing the filesystem.

Really, if you expect the filesystem to be often uncleanly unmounted.
you should switch to a read-only filesystem for your / mountpoint (eg.
squashfs). An alternative would be to use a flash-optimised filesystem,
like jffs2, which is designed to recover from untimely power failures to
start with. But jffs2 can sit on a block device, you'd need a reverse
translation layer (eg. blockmtd) to emulate a flash on a block device.

Or, if your filesystem is small enough, put it entirely in an initramfs,
so it is purely in RAM (and only mount your persistent-data filesystem
from the SDcard.)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'