__          __             __
\ \_________\ \____________\ \___
 \  _ \  _\ _  \  _\ __ \ __\   /
  \___/\__/\__/ \_\ \___/\__/\_\_\

Bedrock Linux 1.0alpha2 Momo

Bedrock Linux 1.0alpha2 "Momo" Known issues

  1. No Hostname
  2. /etc/ file sync issue
  3. Difficulty Statically Compiling
  4. Man pages do not work across clients
  5. Debian-based clients: statoverride
  6. /usr-move'd Clients

No Hostname

If your system does not have a hostname despite having created the hostname file, this is due to a simple oversight which should be remedied in the next release. If you would like to fix it on your own, it should be relatively easy. Simply add the following to your /etc/rc.local file:

/bin/hostname $(/bin/cat /etc/hostname)

The next time you boot you should have a proper hostname.

/etc/ file sync issue

The bind mount sharing system does not allow moving or renaming on top of mount points. This is a primarily an issue with files such as /etc/passwd. The most common ways to update such files involve creating a temporary new file and move/renaming it over the old one. This is advantageous as it minimizes the window of time in which something could go wrong and leave a malformed /etc/passwd. However, it does not function with bind mount sharing. One cannot share all of /etc, as other files in there need to be unique per client. One can manually update these files, either by simply editing them with a text editor or by updating them in core Bedrock Linux. This issue is particularly troubling when packages in clients attempt to create users or groups. For the time being, one must manually add the users/groups in a way which does not conflict with the bind mount issue and then re-run the package installation command in the clients.

Possible Solution: This problem is particularly troubling when packages try to add users or groups to shared /etc/passwd and /etc/group. Perhaps we could just ensure that the users/groups are already there, so there is no need to add them. This would require building a database of all possible users/groups that could be added by any package in any distro.

Possible Solution: Look into unionfs-fuse as possible solution.

Difficulty Statically Compiling

Difficulty statically compiling busybox and capchroot have been noted, somewhat dependent on the client/installer host used. This is caused by conscious limitations placed in libraries available in many Linux distributions, particularly glibc.

Possible Solution: Use uclibc to build busybox and capchroot. The downside is that this requires significantly more work for distros which do not have uclibc readily accessible. Look into buildroot.

Man pages do not work across clients

No work has yet been done to ensure man pages work across clients. This might be a single bind mount away from working.

Debian-based clients: statoverride

Occasionally, apt/dpkg will complain about issues with "statoverride". This most likely occurs because it expects a daemon should be running, but it is not. This can be fixed in this instance by simply removing the contents of /var/lib/dpkg/statoverride. Simply leave an empy file in that location. This may come up repeatedly - no work has yet been done to find a permanent solution.

/usr-move'd Clients

A growing number of Linux distributions (such as Arch Linux and Fedora) have moved many of the root-level directories into /usr. To enable backwards compatibility, they have symlinked the root-level directories into the /usr directories. For example, /lib is now symlinked to /usr/lib/. Sadly, Bedrock Linux 1.0alpha1 does not properly handle bind-mounts into symlinked directories. This means one cannot use bind-mounts to share /lib/modules with clients who have undergone the /usr move. However, /usr/lib/modules can be shared just fine. If all of the clients have been /usr-moved, one can simply share the directories within /usr However, if one is using a mix of /usr-moved and non-/usr-moved clients, difficulties arise. Try simply copying these directories every time one is updated.