LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Bedrock Linux (https://www.linuxquestions.org/questions/bedrock-linux-118/)
-   -   after adding arch stratum, odd boot-time warning (https://www.linuxquestions.org/questions/bedrock-linux-118/after-adding-arch-stratum-odd-boot-time-warning-4175628570/)

jr_bob_dobbs 04-27-2018 09:37 PM

after adding arch stratum, odd boot-time warning
 
So I added an arch stratum to my bedrock system. Upon reboot, I now get an odd warning message. After choosing the strata/init item from the menu, after the "[OKAY] Preparing /bedrock/run" line, I get this (typed from a picture taken on my phone, so errors are possible):
Code:

[ -- ] Enabling archforce-symlinks warning for arch: A non-symlink file or directory exists at both "/bedrock/strata/arch/etc/resolv.conf" and "/bedrock/etc/resolv.conf". Should exist at "/bedrock/et
c/resolv.conf" with symlink at "/bedrock/strata/arch/etc/resolv.conf" pointing to it instead.

The odd thing is, the files are there, with the real file and the symlink already there as the "should" warning specifies:
Code:

$ ll /bedrock/strata/arch/etc/resolv.conf
lrwxrwxrwx 1 root root 24 Apr 15 10:01 /bedrock/strata/arch/etc/resolv.conf -> /bedrock/etc/resolv.conf
$ ll /bedrock/etc/resolv.conf
-rw-r--r-- 1 root root 261 Apr 27 22:11 /bedrock/etc/resolv.conf

Safe to ignore?
I remember copying in a resolve.conf just before chrooting into the arch strata when I was first setting it up. Could that have caused this?

jr_bob_dobbs 04-28-2018 07:30 AM

Rebooted into my fallback OS (nothing to do with the fallback strata within Bedrock). Removed the resolv.conf from the Arch stratum's etc directory. Rebooted back into Bedrock and BAM: the warning disappeared. :)

ParadigmComplex 04-28-2018 07:58 AM

If everything else is working, e.g. DNS resolution, it should be harmless and ignorable.

What's going on, in case you or anyone else reading is curious: you know how you can read and write and rename files? There's a whole bunch of other things you can do with/to them as well. Two of which - the FS_IOC_GETFLAGS and FS_IOC_SETFLAGS ioctls - work inconsistently in Linux. In some situations you have to use them one way, and in others you have to use them another way. If you get it wrong, you end up with a really subtle and hard to debug problem that could do things like corrupt or crash your program. In my opinion, it's fundamentally broken and Linux should change how it works here. If you want to read more on this issue, see:

NetworkManager uses (or at least used, last time I looked into it) these on /etc/resolv.conf. It doesn't check for which variation should be used; it just makes a (normally reasonable) assumption. This assumption isn't true on Bedrock's /etc and it breaks NetworkManager. My first plan to work around this was to force /etc/resolv.conf to be a symlink to another directory where NetworkManager's assumption is much more likely to be true (namely /bedrock/etc). However, the way I implemented the code to force this was a little naive and it occasionally gets confused, as happened on your setup. It sees a real file with contents at both arch's /etc/resolv.conf and /bedrock/etc/resolv.conf, and it doesn't know which instance you want to keep (.e.g. maybe one is outdated). I have a couple ideas for alternative methods to try which could be more consistent, although the implementation will be more complicated and I'll have to be careful with it. I sadly expect to have to burn a good bit of development time on settling on the solution here for the upcoming release.

As for how to fix that warning you're seeing: Sadly the /bedrock/strata/<stratum> paths aren't guaranteed to work for global paths, only local ones. When Bedrock sets up the arch stratum, it masks global files like /etc/resolv.conf with the global version. When you go through /bedrock/strata/<stratum> paths, you could hit either the underlying file or the global version that's masking on top, depending on context. I didn't put time on providing a clean way to get the underling file, as the vast, vast majority of time no one needs it. However, in this case, the code generating a warning is running before arch is fully setup and is thus looking at the underling file, and so that's the one you'll need to fix.

Here's a hacky way to get the underlying file: from the point of view of the stratum that is providing init, check the explicit path, then keep prefixing /bedrock/strata/<stratum> until you get the underlying file. So for your situation check:
  • brc init ls -l /bedrock/strata/arch/etc/resolv.conf
  • brc init ls -l /bedrock/strata/arch/bedrock/strata/arch/etc/resolv.conf
  • brc init ls -l /bedrock/strata/arch/bedrock/strata/arch/bedrock/strata/arch/etc/resolv.conf
  • brc init ls -l /bedrock/strata/arch/bedrock/strata/arch/bedrock/strata/arch/bedrock/strata/arch/etc/resolv.conf

Keep checking like that until you hit a non-symlink file. That's the file that's causing the problem. It should be safe to `brc init rm` that file path. With that file gone, Bedrock won't be confused about the situation anymore and the warning should disappear.

EDIT: Saw your second post, apparently submitted while I was writing this one. Nice! By booting into the other OS, you're seeing the filesystem before Bedrock does all the rearranging stuff, which is also what it's like when that warning is generated. That's also a valid solution here. Seems like you're good to go!

jr_bob_dobbs 05-05-2018 04:30 PM

Quote:

Originally Posted by ParadigmComplex (Post 5848281)
EDIT: Saw your second post, apparently submitted while I was writing this one. Nice! By booting into the other OS, you're seeing the filesystem before Bedrock does all the rearranging stuff, which is also what it's like when that warning is generated. That's also a valid solution here. Seems like you're good to go!

When in doubt, or when confused, I look at bedrock from outside of bedrock. Keeps things much simpler. :)

ParadigmComplex 05-05-2018 04:49 PM

I wonder if there's a way I can provide the from-outside view without requiring people actually reboot into another OS. I can think of limited solutions, but nothing fully featured and clean. I'll make a note to investigate that in the future.


All times are GMT -5. The time now is 09:45 PM.