bedrock & slackware
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)?
|
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:
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. |
Quote:
Quote:
Quote:
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. Quote:
|
Quote:
|
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? |
Quote:
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. Quote:
|
Quote:
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." |
Quote:
Quote:
Quote:
Quote:
|
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. |
Quote:
Quote:
Quote:
Quote:
Quote:
|
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 Code:
echo off > /sys/power/state or go with the reboot options (shutdown -r or, I think 'halt -r'), or the hibernate option, which involves a poweroff. Code:
echo disk > /sys/power/state |
All times are GMT -5. The time now is 10:03 PM. |