I report because remove the BOM is very easy but the reason of the warn is not oblivious (and find it not easy). Reproducible: Always Steps to Reproduce: by mistake i have configured kwrite to use the "byte order mark" and i have modified /etc/fstab with it. Actual Results: As result openrc display a message "[mntent]: line 1 in /etc/fstab not valid" only if the first line is a comment (so begin with "[BOM]#"); if the first line begin with a mountpoint (so is "[BOM]LABEL=root / ...") no errors are displayed. Expected Results: Preventing the use of the BOM as default in editors and/or an upgrade to the documentation (the users must be warned) can be a solution if the problem is upstream (not verified but i think at util-linux, writed before UTF8). Ask for emerge --info and more details if necessary.
i have no idea what this byte order mark thing is, nor what your fstab looks like. please post as attachments the working fstab file and the failing one.
Created attachment 299973 [details] fstab before edit reduced in size as sample
Created attachment 299975 [details] fstab after edit vim or nano or any other text editor will not display the first chars or warn about its presence.
Created attachment 299977 [details] fstab after edit - modfied to not display warn if the first line is not a comment will not be ignored
http://en.wikipedia.org/wiki/Byte_order_mark Some random issues in udisks kde (unable to remove disconnected devices configured in fstab) gestures (unsure, because i have updated the system in meantime but after the update and BOM removed there are no more issues i report it but i tent to exclude ralations) and the warn by openrc seems to are all the simptoms. Because all the text editors i know are used to skip the BOM sequence and report only the file a UTF8 text is not easy to find (the solution is a simple tail -c +4 fstab >fstab.nobom). Same problem can affect other rc components, configuration files and more especially if imported from an UTF16 environment od other OS. My request is mainly to upgrade the documentation in order to warn the users.
what documentation ? i don't think inserting BOM in any system config file is supported. /etc/fstab is just one of those files.
(In reply to comment #6) - BOM is optional (even discouraged) in the UTF8 standard for any text or flat file, but is part of the standard. - fstab (and similar system config) was defined as flat (text file), before UTF8 standard was introduced. - fstab not respect the UTF8 standard but is documented as text/flat (non legacy) file. > i don't think inserting BOM in any system config file is > supported. If the system files are not full compliant with the UTF8 standard it must be declared and documented. Adding a check or directly filter the BOM in parsing config files will make openrc and/or util-linux compliant to the standard. > what documentation ? - UTF8 - FAQ - Handbook for gentoo. - docs and comment in config files for openrc. Simply add "The system config files are not _UTF8 standard_ but are in a legacy format, so the use of UTF8 is admitted but the presence of the BOM no." or something similar is necessary. I agree the implicit assertion of yours: full supporting the standard will take too much (not-so-useful) work. The use of a proprietary or legacy format is admitted but must be declared.
(In reply to comment #7) i see no value at all in the tools supporting this BOM cruft i have no problem with a note in the UTF8 docs
(In reply to comment #8) > i see no value at all in the tools supporting this BOM cruft i agree, but "ask has no cost". The "official" confirmation than BOM and full UTF8 is not supported for system configs was the result i meed. > i have no problem with a note in the UTF8 docs good. Thanks. Solved at documentation upgrade for me.
There ya go, fixed in CVS. Thanks for reporting!
