Update: I don't like Arch - It doesn't even have an install script and I had to go following inaccurate instructions about setting up and the package list seemed disappointing. It doesn't seem have the breadth I want. Mint is back as the 'SMA' distro. So it's Ubuntu I'll probably go for and I have the Mint sources.list stuff for Ubuntu (with one Mint repo). Mint does some Xserver magic and the meaty stuff is Ubuntu's.

I have The BRL-0.7.7 script, and am about to run it on Slackware. Is there anything else I need? BTW I have a recent backup of Slackware, with access to Mint. I don't exactly find the BRL Documents inspiring. If I get your shutdown problem, I can try to sort it. If it hoses Slackware, it's 10 minutes to put it back via usb drive. Surprisingly, Networkmanager and systemd actually work in Mint, although there's no sound, which I never bothered investigating.

Setting Arch Linux up certainly requires more manual effort than other distros. I think the argument here is that it's simple for certain definitions of simple. Some users like the control it provides. For others, well, Bedrock's ability to use one distro's install process and another distro's packages is particularly helpful here, if I do say so myself.

Arch's primary repo is useful more because it offers relatively new instances of packages rather than its breadth. Mint or Slackware may very well have the same packages, but they'll likely be older.

In terms of breadth, Arch's real claim to fame is its User Repository. It is very rare in my experience for some non-Arch distro to provide a package that is missing from both Arch's main repository and its AUR. That having been said, AUR packages are often broken, and they don't have the same level of trustworthiness as one may expect from traditional distro repositories.

You don't need anything else.

Bedrock is extremely manpower limited. We're unable to have the same breadth of the documentation as better equipped projects. If that's a problem, I recommend against using Bedrock, at least at this time.

The primary focus is on:

• Explaining what Bedrock Linux is. Despite substantial efforts here, a lot of people still end up confused. I'm hoping to make a video later this year demonstrating it, which may help.
• Explaining how to use it, including required Bedrock specific concepts.

Is there anything in particular regarding how to use Bedrock that you feel is lacking?

So, Arch has some extra packages? It would want to! I looked at the support Forum and found it poorly supported. Mint has excellent support. I suppose it's a case of 'the devil you know.'
I've no real reaction to BRL yet. I haven't ironed out silly things which I'll allow any distro

Anyhow, the Slackware Stop problem: I think I have it down to this bit of code from /etc/rc.d/rc.0 (=rc.6). If you just look at the "# Added by Dec" lines

echo $OMITPIDS # Added by Dec returns nothing. $OMITPIDS is blank
/bin/sleep 5 # Added by Dec This was to let processes terminate
/usr/bin/ps -e # Added by Dec This shows 30+ processes rolling off the screen
/usr/bin/echo " Try to turn off quota." # Added by Dec Not seen: I just see the INIT error.

That's about half a dozen subroutines from the end, but it doesn't look at them. I have an echo statement on turning off quota but I don't see it. Now I don't have quota, but the echo is before the routine. Some of the subroutines are skipped, because I don't have encryption, or fancy disk setups but everything below has echo statements. Swap is still on. The "No more processes at this runlevel is program output; probably from init, so the script may exit. /sbin/killall5 is there. Ideas?

The same ideas I've mentioned already in this thread:

• My best guess for the issue is this sequence of events:
  1. Slackware's shutdown sequence sends SIGTERM to Bedrock's /etc filesystem.
  2. Instead of unmounting properly, Bedrock's /etc filesystem crashes and blocks access to /etc.
  3. Slackware's shutdown sequence tries to utilize /etc.
• My best guess for avenues to resolve it are:
  1. Confirm the theory is correct then fix Bedrock's /etc filesystem so it unmounts properly on SIGTERM. This is the preferred option, but may take quite some effort and time.
  2. Hook into Slackware's shutdown sequence with something that unmounts /etc after any necessary changes to global files are done but before the /etc filesystem is sent SIGTERM. It is not clear if this is suitable as a general solution, but could probably unblock anyone who wants to use Slackware's init with Bedrock in the immediate future.

I'm happy to pursue it myself when I get to it, but my plate is currently full with more pressing items and it'll be a while. If you want to go after it I'd be delighted for the assistance.

I can confirm your theory is correct. The sigkill is losing /etc. It seemed pretty obvious because one echo worked, while the next one didn't. But I did this: I copied the routine posted in my last post and everything below it to /bedrock/rc.6 and inserted this bit just before that subroutine: The machine powered off perfectly. That's a work around, not a fix. But the fact that the same script works in /bedrock but not in /etc indicates that what you say is correct. It would have probably been more elegant to have which closes the file, but it works the way it is. I gather Bedrock raises a lazy eyebrow at LSB compliance?

I gather the files in your /bedrock/strata/bedrock/etc have precedence over the ones in /etc? Some fancy --bind mounting? Anyhow in Slackware, you have some handy options

• Add the PIDs you don't want killed to $OMITPIDS. From what I can find, it's only ever used for one program, mdmon.
• Move the /etc/rc.d directory to your /bedrock/strata/bedrock/etc/

The latter isn't so great, because when your bind mounting is unmounted, you run the risk of losing your file then. Moving to a neutral venue is best - like I did. The only files you have to bother about in /etc/rc.d are the executables; the rest are ignored.

What totally surprised me (I did a grep for OMITPIDS in /etc/rc.d) is that rc.K has a similar set of 'killall5' commands to rc.6 (issuing sigterm & sigkill), but they don't freak anything there.

Provided you restrict yourself to only one stratum with this issue/work-around, that's probably fine for your personal use. If you're interested in potentially more in the future - multiple Slackware strata, or maybe a CRUX one which shares this same issue - a Slackware local path would be preferable instead. Maybe `/bedrock/strata/slackware/rc.6`; i.e., on Slackware's root.

I'm at a loss for how something like Bedrock could be pursued while retaining LSB compliance.

There is no generic `/etc` to have precedence over. It's context dependent. If you haven't read the basic usage documentation, I strongly recommend you do: https://bedrocklinux.org/0.7/basic-usage.html

I'm in the early days with bedrock, which is a new concept to me. My workaround with rc.6 powers off but doesn't reboot. I did have a look at the Bedrock Basic usage, but can't claim to be familiar with all it's points. I did also find sysvinit and /etc in the "Known issues." The poweroff bit is I gather the condition was not met, so it went to the 'else' option. It strikes me you can fix all this in the install script, by copying the /etc/rc.d stuff (which doesn't exist on systemd) to where it's available. $shutdown_command was set in the early section of rc.6 (=rc.0) depending on whether it was called as rc.6 or rc.0. I'll try exporting that :-D.

Anyhow, I had to append the 'bedrock_init=slackware:/sbin/init' stuff onto the grub line. My usb keyboard wasn't found. The laptop's keyboard might be, but that's on usb too. My system is a Samsung NP350V5C, but it's 6 years old. Specs are: i3 twin core, 6G ram, Series 7 (panther point)chipset, HD4000 graphics (Ivy Bridge?), 250Gssd.

I'll definitely only add ubuntu for another stratum. I'm trying to lower overhead.

SysVinit seems a problem for BRL that you haven't got to yet. You should up the priority, because systemd systems (Debian, ubuntu, Suse & the Red Hat stable) mainly have fairly complete repositories with a huge selection of dependency tracked packages. Why should they install BRL? Otoh, systems with no dependency tracking (Slackware, LFS, etc) would really benefit from BRL but you're not bothering.

It's definitely an unusual project. May take a bit to fully sink in.

This seems to happen for a subset of the users. I have never been able to reproduce it myself, nor have I been able to successfully debug it by proxy. I tried asking people who reproduce it to compare and contrast things like module list or /dev population before and after the keyboard works. At some point I hope to purchase some system that reproduces the issue so I can debug it locally and fix it.

As noted earlier in this thread, I did get it working earlier. It broke out from under me. I haven't had the chance to get back to it yet.

People who have expressed interest in using Slackware's init with Bedrock are greatly outnumbered by people who have shown interest in other items I am prioritizing. Even if the primary determining factor for how I spend my free time was maximizing how much I help the Bedrock user base, I shouldn't prioritize Slackware's init. Exacerbating things further, it's not the primary determining factor. I have my own wants and needs.

I'll get to it when I get to it.

I'm fine with work arounds to run BRL (the extra bit on grub.cfg, and my fiddle on rc.6). You don't run slackware for any length without becoming handy at fixing things yourself, because slackware presumes a basic knowledge, and doesn't present you with massive scripts. I'll poke around for a better fix

For a global fix, that's a whole different ball game. the first thing to do is compile in a kernel driver for the keyboard, or run an initrd. ATM, I have neither. When your bedrock stuff comes in, the keyboard goes out to lunch.

As for the sigkill problem, is there anything wrong with copying/moving /etc/rc.d to /bedrock/strata/slackware/etc/? That could be done as part of the BRL install, and it catches Slackware, using the BSD format, and the systems that use /etc/rc.d/init.d for bootscripts, with symlinks in /etc/rc.d/rc(1-6).d/.

FWIW, I agree totally on LSB, and Slackware raises a middle finger at LSB, although slackware does cater for LSB-compliant software installs, and it does have and check the rcN.d/ directories and run the stuff therein.

If I get time, I'll try a slackware install in a vm and hijack that. It's a little difficult to faultfind a startup problem, but I think you're requiring keyboard input too early. There's a gap when the BIOS drops out before the usb & keyboard driver cuts in.

Ok. A bit further on. I added Ubuntu with 'brl -fetch' & that went ok.

For the boot problem, I moved the original /etc/rc.d/rc.6 without mods to /bedrock/rc.6. Then I added symlinks named /etc/rc.d/rc.0 & /etc/rc.d/rc.6 pointing at /bedrock/rc.6. This works, reboot and I presume halt. Slackware detects how the script was called (as rc.o or rc.6) and shuts down or reboots accordingly. That's a slackware workaround for you. I did a reboot, which worked. It throws this yellow warning in a couple of languages "Warning: File or directory exists at both /proc/1/root/var/run and <somewhere else>. I had to grab a photo as it was a bit too fast to read. Have you met this?

In the Ubuntu stratum, I ran 'apt install openshot.' Openshot is one bitch of a thing to install, using cmake and relying on latest versions of half-assed software. It relies on things like QT5, Python3, PyQt5, zeromq, c++ bindings for something else, and it's other projects. It's basically impossible to compile from source. Anyhow, Apt threw me 2 Gigs of dependencies, which dpkg reported problems with because I lacked gnome, mainly. It eventually jumped ship and baled out.

Starting X was another matter It was one series of endless complaints - from every font path onward. It loaded 10,000 video type extensions from somewhere that I never saw before :-o. But after it was done bellyaching, X ran. XFCE seemed to have crashed. It was bitching about other stuff GnuPG, signatures, and other crap. There was a long wait and I left it and went and had lunch. When I came back, XFCE was running. And to my great surprise, openshot ran! Here's the last 30 lines of the screens full of X errors. and Ubuntu has urinated all over my locale - In X, I'm en_US with all the hassle that gives someone with a UK keyboard. The kernel consoles are ok. How can I change that? In /bedrock/strata/ubuntu/etc? I'll have a go.
To judge from the errors, mine is a minimal install of slackware without features I don't want, and a low cholesterol window manager whereas ubuntu is an 'all bells & whistles' distro with masses of eye candy, with gnome (For goodness sake!) which is distinctly uncomfortable in the no-frills place it finds itself.

As for users, my /etc/profile.d, ~/.bashrc or ~bash_profile are no longer run at login. I log in at runlevel 3, then run startx. Old fashioned, I know. There was 'bsd fortune' which ran at log in and printed a fortune cookie, but it's gone.

I'm baling out to have a look around from Mint and see what my system actually looks like. It's hard to get a handle on things when 'df -h' reports 18G on /, but 'du -sh' reports 282G, and throws up an error featuring two lines of "X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/<somefile in X>: too many layers of symbolic links", from /bedrock/cross/bin/

Done some faultfinding: It's Grim.

• X takes 1 minute 45 seconds to start, which imho is unacceptable.
• I ran 'startx >x.err 2>&1' and the output is on https://pastebin.com/TDySSz6r & it seems to pause on the later warnings.
• /etc/profile.d has ubuntu stuff there instead of my init stuff. Perms are 0644, so it doesn't even run, but my files are not seen.
• Where is the list of bind mounts? I don't know what's mounted over what.
• Programs (e.g. less, gpm) are randomly missing from /usr/bin and moved to /bedrock/cross/bin. So they don't run when called in init scripts. This is bad. My usual way of sorting that would be to run "upgradepkg --reinstall" on the offending package, except I presume There's a bind mount responsible, and I don't know what I'll be installing over/into.
• The mouse in X randomly goes missing, particularly if I touch the taskbar. I'm in X atm, and my keyboard works, but after clicking on the bottom taskbar the mouse is inactive. I clicked on the @shut-down menu, and the mouse went. About 2 minutes later, the menu pops up, and the mouse is active.
• Suspend is an absolute disaster. There's a blank window open, the screen is shaded behind it, the mouse & keyboard are inactive. It's a power-off job.

I'm sure that's a partial list
At this stage, I have to ask about uninstalling. I'm not there yet but it's an option. If I can't fix this stuff, It's going out. I fancy if I do a 'rm -rf on /bedrock, and restore /etc, I should be ok. What inserts brl in the boot sequence?

All of the Stuff I mentioned (Invesalius, Openshot, & Freecad) is available on AppImage. Now Openshot's AppImage fails, but Shotcut (simpler but ok) does install.

I'm heading over to Mint to chase a problem there.

Well you can save your precious time. It's over, for me at the moment.

What clinched for it was to see all the gnu utilities linked to busybox. I don't need that! For someone in the US, who lives in X, that may be ok; not for me. I use the consoles far too much. I realize that makes me a dinosaur, but that's ok. I wouldn't offer any advice, because dinosaurs are fewer in number. Bluntly, Bedrock doesn't cope well in console mode, but hell, it's version 0.7.7, and I'll try it again later.

After compiling the last post, it looked bad, and I thought there was no simple way out of this. A lot of stuff was missing from /usr/local/bin, & /opt - just not there. rsync had to put it back. Rsync is finished now, and the speedup was only 1.70, so I imagined it changed a fair bit. I used the --delete option on rsync, so /bedrock & openshot are gone. But I have openshot in Mint.

As mentioned before, it's a known issue. I'm working on it. It's documented under known issues here along with two work arounds. If you don't plan on switching inits very often, just set the desired one to default and make the timeout low.

`/bedrock/strata/slackware/etc` would just move it back into etcfs. As mentioned earlier, I think `/bedrock/strata/slackware/` (i.e., slackware's root) would be best.

This is fine for a local hacky work-around for someone who is aware of it, but not for a generalized solution. There's a number of issues, but the main one is that there's nothing enforcing it after hijack. If the system changes it (e.g. a package update), the change is undone and the following shutdown will hang.

This is why my preferred solutions here are:

• Make an init config which unmounts /etc. This should be relatively little work. However, it needs to run after the last change to any global file but before the SIGTERM. I haven't checked if we can just drop in an init config which runs at this time.
• Debug why /etc is crashing on SIGTERM instead of unmounting properly and fix it. This is the preferred long term solution, but may be some work to do.

Neither of these are dependent on changing package manager owned files.

I'm not raising a middle finger at LSB at all. For specifically Bedrock, that standardization is useful. I just don't see how I could pursue Bedrock while maintaining LSB compatibility. If I knew a way I'd probably pursue it.

As mentioned earlier, that's probably fine for a personal work around if you don't care to use the init from any other stratum that shares the issue with /etc crashing from SIGTERM on shutdown. If you want to add others, a local path would be needed. I continue to recommend /bedrock/strata/slackware/rc.6. That is, put your moved init stuff on slackware's root. It's local to slackware so it won't conflict with stuff from other strata, it's root managed so errant but low permission processes won't mess with it, and it's out of the way of where package managers usually go.

Some distros make /var/run a symlink to /var, others don't. To ensure they can interact with each other, Bedrock tries to force everything to standardize on /var/run being a symlink to /run. Somehow one of your strata - the one you used to boot in that session - has a (non-symlink) file or directory at both /var/run and /run. Bedrock doesn't know which you want to keep. To resolve this, move all the contents from one into the other and delete the now empty one, then `brl repair` the stratum.

I haven't actually seen anyone else run into this in the current 0.7 release series.

/proc/1/mountinfo

It's a lot to take in without context. It should mostly make sense if once the basic usage stuff from Bedrock's documentation has sunk in, provided background on what bind mounts are/do. However, if I'm interpreting you correctly, I think your goal here is to go the other way around and understand Bedrock by looking at the mount table. That may be some effort, but it could very well work out. If it does help things click for you were they didn't before I can look into reworking the introductory material to leverage such a strategy.


This is how Bedrock works. I'd be happy to elaborate if I knew exactly where you were confused or what you were missing. However, the best I can tell, it's the bare basics, and I don't know how to express them any better than the basic usage documentation we previously discussed.

I strongly disagree. Your system will not be okay if you follow those steps.

It's theoretically possible to back out the hijack process, but it requires a fair bit of background that, from our preceding discussion, I suspect you may lack here. I'd recommend just wiping.

Most bootloaders/kernels/initrds launch /sbin/init on boot. Bedrock's /sbin/init is at /sbin/init from their point of view.

Best of luck!

Two of the issues you ran into were known issues on my to-do list that I'll certainly hope to resolve at some point. If you revisit Bedrock later, hopefully these issues will be no longer standing at that itme.

The majority of the rest of your issues seem to be due to a fundamental misunderstanding about Bedrock's basic usage. I'm always tweaking the documentation to improve it as I better learn how it appears to people new to the project. One of the items on my to-do list I'm hoping to knock out later before the year is out is a video introduction/demonstration of Bedrock, which may work for some people where the available text is inadequate.

I could see ways to you could have arrived at some of your previous apparent misunderstandings, such being confused by Bedrock's local/global distinction. Here, though, I am completely unable to follow your reasoning at all. I don't understand why Bedrock's use of busybox is problematic, or how it could possibly be region related, or what it has to do with X vs console. From where I am sitting, this reads like a series of non-sequiturs. I had hoped the misunderstandings between us were the result of a small number of simple concepts that could be resolved easily, but I am now concerned the gulf here is far wider.

I accept and agree with most of your points.

On Busybox, I did not expect so much messing with my core system. Admittedly, you made it as clear as possible, brl --hijack gave me a clear indication, warnings etc so I can't complain. Everything seemed to be bind mounted in /usr/bin, and indeed this was part of the problem. I went ahead because I had a backup.

I had stuff in /usr/local/bin, & opt, which was moved or wiped. Looking at my Slackware system while running Mint was a revelation. The Ubuntu stratum downloaded by bedrock was innocent enough, but when I added openshot it grew teeth, and overpowered the Slackware config. So my init was Slackware (as far as profile.d), but my X was ubuntu with a poorly prepared XFCE. That was the user experience. I DO NOT want to run busybox - I could run DSL if I wanted that. I had en_IE in consoles and en_US in X. I could fix nothing. Anything I tried to do puked.

I have dual boot, and have the benefits of Mint for a reboot, without having to live there.