bedrock using fallback init: unable to login
 

So I had the idea of a minimal bedrock system that would be the fallback strata and not much else. I realize that a fallback strata bedrock would not be able to go online nor do anything else aside from the commands within busybox. The point is that system would be verified and, once it was working, I could then do backups and *then* other strata would be added.

The install followed the manual install part of the docs, with rootfs and global being separate strata and with the fallback strata and its init as the only choices in the eraly boot-time strata & init selection menu.

Kernel, modules, firmware and initrd were copied from my daily driver BLFS 8.1 system. They're known to be good.

After setting up things in lilo from my boot-mananger OS, I reboot. I pick operating system from the lilo menu. The kernel loads fine. The initramdisk prompts me for the LUKS password (indicating that it was loaded and is running fine). I enter the password and hit enter.

The text logo for Bedrock Linux 1.0beta2 Nyla is displayed. I pick the init to use (only one is there, naturally) and hit enter.
Then this (note: this is typed, while looking at a picture taken on my phone, so errors are possible):
skipping kernel/firmware blah-blahs
I suppose that the above could actually be not a problem: my initrd uses udev and I seem to recall that hotplug was what was used in the years before udev?

Then I log in ... or try to. After entering user name and password.
It loops into the login prompt again. I also tried this as a non-root user.

The weird thing is, line 33 of brsh is a commented line, part of a block of commented lines. And nowhere in brsh is there *anything* called with a "-f" parameter.

Has anything like this happened to anyone else?

Thank you.

Busybox provides `udhcpc` which can be used to get internet access via ethernet. Won't get you wifi, but it can get online, assuming everything else is working.

I find it a bit concerning there's a workflow need for this. The upcoming release's improvements can't come soon enough.

I've not read anything about it being deprecated. As far as I know, it's just another, much simpler method of managing devices. I didn't want to distribute (e)udev with its associated disk usage overhead with Bedrock just for fallback where busybox's hotplug-based mdev gets the job done. It's not as featureful as (e)udev, but it doesn't need to be for fallback to do its job.

However, it's apparently not getting the job done in your situation. I've never seen that before. That bit of the code base very rarely gets exercised, though, and so it's not a huge surprise for there to be an issue with it. I don't know if Linux is deprecating it in newer kernels, or if some distros compile it out of their kernel build, or if some initrds do something to disable it, or if there's just a bug in how I'm using it, or if something else is going on. I typically strongly prefer to dig into something like this and fix it properly, but given (1) how rarely this subsystem is used and (2) how much pressure I'm under to get the next release out, I'm inclined to leave it for the time being and spend the associated time working on the upcoming release if it's not a problem with you.

I've been considering dropping fallback with the upcoming release anyways. One of the reasons is that I don't like having a rarely exercised feature like this. It risks exactly the kind of issue you've just run into - I think I called exactly this possibility in the IRC room a ways back. Cutting it also saves development time, testing time, documentation. I've added code to the build system for the upcoming release which scans the code base for exactly the busybox applet list we need and cuts the rest. This cuts Bedrock's disk overhead a bit (looks like the installer for the upcoming release will likely be under 1MB - tempted to distribute it on a floppy as a joke) and speeds up compile time, but also removes things like the udhcpc feature I mentioned earlier and significantly lessens fallback's usefulness. I'll still have some debug solution in case all the other inits break, but probably something much smaller in scope. I'm thinking something along the lines of kernel-line value which gets detected then dumps diagnostics to disk which can then be used to debug what's going on.

I've never seen that before, and I'm honestly lost as to what could be going on to cause that. Unlike fallback, this subsystem gets exercised a lot.

One easy way to debug this is add:

to /bedrock/bin/brsh, just after the initial comment block. This will make it spit out what it's doing, line by line. Then try to login again. With luck, it'll spit out a "-f" somewhere which we can use to home in on the underlying problem.

I did not know about "set -x". Very handy! Thank you.

That allowed me to find the error quickly and easily. The actual error occurred in line 33, yes, but not in brsh. Upon login, /etc/profile is interpreted, and *that* was where the actual problem was occurring:
During the configuration phase of the original install of this bedrock, I had added to the profile, adding some function definitions that I knew would be needed by a specific planned strata (not yet put in). The use of "export -f" is a bash-ism, so will obviously in retrospect not work in busybox. D'oh!

I reverted the profile and rebooted. That fixed it: I was able to log in. Success: the fallback-only bedrock works. :)

From the bedrock docs, my understanding is that /etc/profile must be global, so to set up a per-strata profile cannot happen. I'll have to think about that for a bit.

Great! :)

You can check which stratum provides the current process with `bri -n` and conditionally run code that way. For example, you could put something like this into your /etc/profile:

Take a look at `bri --help` if you haven't already - there's some useful stuff in there. For example, once you get X11 running, you can run `bri -p $(xprop | awk '$1 ~ /PID/ {print$3}')` then click a window and it'll print which stratum provides the window.

FWIW, /etc/profile is global as a way of ensuring all login shells - provided by all strata - get Bedrock-specific functionality. An alternative way to do this would be to make /etc/profile local but automatically enforce that certain content is included within each instance. I was strongly considering this change anyways. The fact it jives with the way you were mentally modeling things further encourages it.

Whoa. Kickass. Perfect. Thank you! :)

Happy to help :)