SOLVED Get rid of two kernel related boot messages

[Sebastian Roth]

I know there is other more important stuff to get done but today I felt like trying to find out about those two kernel boot messages that all of us see when the linux kernel loads.

EXT4-fs (ram0): couldn’t mount as ext3 due to feature incompatibilities
udevd[...]: error creating epoll fd: Function not implemented

The first one is very easy to address by adding this kernel parameter rootfstype=ext4. Sure people could just add this to their host’s kernel parameter field but as we all have it I request this being added in boot.php for all the kernel command lines.

For the second error we need to re-compile the kernel (no need to do this in a hurry! Just add the kernel config change and it will be ready with the next major kernel compile). For the error to disappear we need CONFIG_EPOLL=y.

[Tom Elliott]

I’ve solved this thread for a couple reasons. First, this isn’t really a “bug” in the truest sense. While it did print unwanted data, it had literally 0 impact on the operation of things. That said, the second reason is these “suggestions?” have been achieved. First, I added the rootfsext=ext4 as suggested. Second, we are not starting udevd at boot any more. The findings (as far as we’re aware of) that udev did “special” was it linked the stdin, stdout, and stderr to their respective proc resource element. We were able to do this on our own without needing to start this udev script at boot. This means you should not see the epoll message at all anymore.

[Tom Elliott]

@Wayne-Workman Update and you too can now try it all out.

I updated the init’s and we are no longer having udev startup. It also comes with 0.2.88 version of Partclone!

[Wayne Workman]

@Sebastian-Roth Very nice! Can’t wait to try this out for myself.

[Sebastian Roth]

Turns out that the second message has a longer story… Tom tells me that he disabled CONFIG_EPOLL because it would cause a lot of messages when doing partition creation and things. Sure we don’t need that. Digging into that it turned out that udevd is exiting straight after the epoll check and therefore was never running/used in the FOS client! Populating the /dev directory is actually done by the kernel alone (CONFIG_DEVTMPFS). So we actually don’t need to run the udev startup script I suppose. I removed the udevd startup call and tried different /dev stuff (like adding and removing partitions from a disk) and it updated nicely.