Back in 2016 or so I had a slackware system that I bedrocked. It ran stable for around a year or so.

With the current version of bedrock, one can hijack a slackware or one can add a slackware strata, but there is one problem: can't boot off the slackware init without problems. Specifically, shutdown and/or reboot hangs. Makes shutting down a real hardware install kind of a pain in the neck.

So the other day, just trying to sort things out on my head, I set up slackware in an emulated machine and then hijacked it with the older (Nyla) bedrock. As it had in the past, that was able to reboot and shut down without any problems.

What changed from Nyla to Poki?

Powering off is actually a very complicated area in linux generally.
What do these 2 commands do (as root)?

1. init 0
2. echo off >/sys/power/state

A lot of things changed. It was about three years of R&D and a near complete rewrite. I don't really know which change is causing the issue with Slackware. If I did I would have fixed it. I very much want to dig into it and figure it out, but I'm completely swamped with other requests and haven't gotten around to it yet.

My theory for what's going on is:

• Slackware runs shutdown scripts from /etc
• One of the shutdown scripts sends SIGTERM to all non shutdown related processes
• This should cause the Bedrock filesystem on /etc to unmount cleanly. However, maybe instead it's killing the filesystem, blocking access to /etc.
• Slackware then tries to run another shutdown script from the blocked /etc and hangs.

However, I haven't actually confirmed this. It could be something else.

Nyla also had an etc filesystem. I did not make any explicit changes around signal handling that would obviously break things here. One change I did make was bumping the libfuse version from 2.x to 3.x. Maybe libfuse broke here in that time, as 2.x to 3.x was a major release of their own with many changes. This was an API-breaking change such that I cannot trivially test falling back to 2.x.

EDIT: wrong thread

First of all, let me say that power-off, like time, is only fully known and understood by a small number of people in the world. It's actually a complex area.

Second, your theory is wrong. Slackware doesn't unmount /, it remounts it 'ro' and has no problem reading /etc.

If Bedrock is killed early by a killall, you might be best hacking /etc/ yourself. If you added a bedrock script to sort things, remounting bedrock ro or unmounting /etc or something like that, you'd be back in business. It strikes me this isn't a slackware problem, it's a bedrock problem.

I never said it unmounted /. I'm in complete agreement it remounts it read-only. I am at a loss for why you think I would feel otherwise.

I'm all ears for alternative theories.

If you're proposing we add a Slackware specific shutdown script to unmount Bedrock's /etc filesystem at shutdown before Slackware's init sends out SIGTERMs, that does seem like a pursue-able work-around for the issue I proposed in my theory. However, given that you flat out state my theory is wrong, I'm at a loss for how to interpret what you're saying here. Can you rephrase or expand?

Assuming my theory is correct, in the long term I'd rather debug the situation and fix whatever changed between Nyla and Poki. However, it's not clear to me when I'll find the time to debug this properly, and such a work around for specifically jr_bob_dobbs may be adequate for the present. I can look into making such a shutdown script for jr_bob_dobbs to utilize in the near-ish future, probably just after releasing 0.7.8beta1.

I think everyone is in agreement on that point, given this worked with the previous major Bedrock release and doesn't with the current. No one here seems to be claiming anything to the contrary.

Sorry, I misread your post. When you said this: "This should cause the Bedrock filesystem on /etc to unmount cleanly. However, maybe instead it's killing the filesystem, blocking access to /etc." I presumed that involved unmounting /.

No worries, such misunderstandings happen. I'm certainly happy to see more people in the Bedrock section of LQ, particularly those who know Slackware, which isn't a particular area of strength for me.

Slackware is good - you promote yourself to it, but it definitely doesn't hold your hand. There are several unofficial repositories, slackbuilds and the slackware forum is populated by very knowledgeable people. But slackware is essentially sysVinit, and probably going to stay that way, despite the general leaning towards systemd. If you can handle bash scripts you're ok.

The pain is packages using loads of dependencies - typically Python based. I tried hard with Invesalius, and openshot on different installs of slackware in the last year or two. When I saw what was coming on Freecad, I gave up without a fight, and resorted to a (slow loading) Appimage in each case.

You bemoan your proficiency with slackware; I know nothing about bedrock. When you add bedrock to a distro, what's the overhead? Let's say I add in Mint(= Ubuntu with go-faster stripes) which is 64 bit with libs in /usr/lib (which is strictly 32 bit in slackware). How does it work?

• In theory there's CPU usage when a process from one distro executes a process from another, but it's negligible. The main non-negligable performance hit is when accessing /etc, which can take longer and use more CPU than it would normally. Don't run a database out of /etc on Bedrock.
• Bedrock's own components may consume a handful of megabytes of RAM. Having multiple instances of things like libc will in theory consume more RAM than than a traditional, single-libc distro.
• Bedrock's own components took less than 10MB of disk space last time I looked at it. However, a typical workflow will have multiple copies of files like libc which can add up.

I run Bedrock on both a Raspberry Pi 3b+ and an old netbook, both of which handle it fine. If you are interested in even weaker hardware, e.g. embedded systems, my guess is the overhead will start to become problematic.

Read through the basic usage documentation https://bedrocklinux.org/0.7/basic-usage.html to get a sense of how it works from a user's point of view. Under the hood its mostly implemented with a lot of virtual file system layer tools such as chroot, pivot_root, bind mounts (including shared subtree management), a couple FUSE filesystems, and probably other things I'm forgetting. We use whatever tools are available to crack a given problem. Specific details change between releases quite drastically. Once we reach 1.0 stable and the churn stops I hope to write a white paper on it.

No, my hardware isn't that bad. i3 twin core @2.4Ghz, 6G of ram, Series 7 Intel chipset (=Panther Point), HD4000 GPU, 250G SSD.

Bedrock looks interesting to get around the 'multiple dependencies' Issue in Slackware. But if I was doing that, I'd have multiple (well, 2 or 3 anyhow) copies of python hanging about with XXX modules installed in each. Ideas are uncurling themselves in my head here as I write this. I will probably need to repartition (again), and it's probably worth going up a size in hd. I think I can get everything I need from Mint.

So, in summary, Bedrock seems to allow you to pick from a number of distros, but I don't see much mention of Slackware. Are you trialling it in slackware, or trying to develop a slackware stratum? Can you set a "path" for the strata? Something like: "Use slackware, then try debian, then ubuntu."

AFAIK that should be fine. The only issues I recall anyone complaining about with that level of hardware is CPU usage reporting programs might show relatively high CPU usage by "etcfs" when they have some software that queries /etc overly often. If that happens, it's the aforementioned /etc overhead getting blamed for what is partially the fault of whatever is spamming /etc, and my recommendation is to figure out what's spamming /etc and make it behave.

I recommend trying Bedrock out in a VM or on a spare machine if you can, or failing that a spare partition that won't interfere with your daily driver. While we've gotten a lot of things working way better than they have any right to with Bedrock, there is still a ways to go. It's hard to say whether or not Bedrock can do everything you with your personal workflow without just trying it first and seeing. For some people it's perfectly adequate today, while for others we still have pain points they first need resolved.

How well Bedrock interacts with a given distro usually breaks down into three categories:

• Do all major features from that distro work with Bedrock?
  • There is one known issue here: if you use Slackware's init with Bedrock, it'll hang on shutdown. This is the original topic the this thread was discussing.
  • It is possible there are other issues which are not known because this one has resulted in few people trying Bedrock with Slackware.
• Can Bedrock's `brl fetch` feature bootstrap a stratum of the given distro?
  • I added `brl fetch slackware` support, but it hasn't been tested much. I don't know the Slackware community's expectations for what such a thing would really entail. Right now it just grabs the `a` and `l` packages with the expectations that this is sufficient to allow users to bootstrap whatever else they want.
• Is there a Bedrock distro maintainer for the given distro?
  • For Slackware there isn't. We don't have anyone who knows Bedrock and Slackware well and is willing to take on the commitment to fix things should they break. This is why the above two items have open concerns and no one has resolved them yet. In theory I'd love to support more distros, but in practice I'm at the limit for what I personally can do here.

To a large degree, yes. Bedrock has a configuration file at `/bedrock/etc/bedrock.conf` where you can control which includes a `[cross]` section. In that section you can tweak the rules for what comes from where when.

Well, I've got a bit further along.

I've always tried to have a 'save my ass' distro around. I've removed it and am intending to install Arch, because bedrock linux seems very fond of Arch. I don't know Arch and have backups of everything so far, so that's easily sorted if it goes pear shaped. I'll just start with the base and hunt around.

I'm intending to install bedrock on slackware, but I want a look at Arch to see how wide the repository is, and how it copes with the nutty things I want to install. If it has, I can use just Slackware & Arch.

If I hit the same problem you did with bedrock on slackware, I'll have a go at it.

Depending on what that distro was, you probably didn't have to remove it as a first step. The idea behind Bedrock is to let you mix and match features from other distros, and we include installation as such a feature. The way we achieve this is by providing a script which hijacks a given install of some other distro, converting it into a Bedrock Linux install. Thus, you can install whatever distro has the install process and features you like best, then just convert it into Bedrock once things are set up. This conversion process retains most of the initial install's files as starting point to swap things out. Whether you start with Debian, hijack it, and add Arch, or start with Arch, hijack it, and add Debian, doesn't really matter.

There's no official preference for these things. There's distros we have someone onboard who knows well enough to actively support, and there's distros we don't. Arch is supported, but so are Alpine, Debian, Exherbo, Fedora, Gentoo, Ubuntu, Void, et al.

It seems inadvisable to me to try out both Bedrock and some other distro you don't know at the same time. Were it not for the known issue between Bedrock and Slackware's init, I'd have recommended just sticking with Slackware as a starting point and slowly adding in features from other distros.

Baring compatibility issues like the init thing, and I guess familiarity with a given distro, which distro you start with doesn't really matter. Once you've let Bedrock hijack the system, you're running Bedrock. You can add in Arch or Slackware after the fact, and you can remove Arch or Slackware after the fact.

Help here would certainly be appreciated. My interpretation of your proposal to add in a Slackware shutdown script to unmount the etc filesystem does, at least in theory, seem viable. I'd prefer to fix whatever is going on with etcfs/libfuse that created the need in the first place over such a shutdown script, but given the resources available that may take quite a while.

I'm sorry, I've teetotally hijacked your thread .

It's 5 minutes to put the 'save my ass' distro back. I don't like Mint, but it's backed up. A single rsync command returns it as was.

I couldn't help noticing BRL's fondness for Arch, so I had a look, because Arch will probably end up there. BRL is intended for Slackware, where I have a decent sized /. If Arch doesn't have enough packages, it can go. Ubuntu certainly does have enough, and Mint uses them, with a single repo of it's own (They got things in X faster). I'll go quiet for a bit, finding packages, & stuff.


RE: YOUR PROBLEM:
On your system, prepare for a slackware shutdown, issue and see what happens. You can also try 'halt -p' or 'shutdown -h now'
or go with the reboot options (shutdown -r or, I think 'halt -r'), or the hibernate option, which involves a poweroff. It woul;d be worth examining the logs (/var/log/messages, /var/log/syslog, /var/log/dmesg) as one of them might hold the error message. You can also increase the loglevel; I think it's fiddling /proc/sys/kernel/printk, whichj you can do before shutdown.