[SOLVED] bedrock using fallback init: unable to login
Bedrock LinuxThis forum is for the discussion of Bedrock Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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):
Code:
[OKAY] Preparing /proc
[OKAY] Preparing /sys
/etc/init.d/rcS: line 77: can't create /proc/sys/kernel/hotplug: nonexistent directory
/etc/init.d/rcS: line 78: can't create /sys/kernel/uevent_helper: Permission denied
[OKAY] Preparing /dev, /dev/pts, /dev/shm, /run
[ -- ] starting mdev/etc/init.d/rcS: line 113: can't create /proc/sys/kernel/hotplug: nonexistent directory
[FAIL]
[ -- ] Loading modules[ 28.312055] ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
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.
Code:
__
\ \___ Welcome to
\ _ \ Bedrock Linux
\___/ 1.0beta2 Nyla
login[3270]: root login on 'tty'
/bedrock/bin/brsh: export: line 33: illegal option -f
Bedrock Linux 1.0Beta2 Nyla artemis /dev/tty1
artemis login:
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.
Last edited by jr_bob_dobbs; 04-15-2018 at 05:16 PM.
I realize that a fallback strata bedrock would not be able to go online nor do anything else aside from the commands within busybox.
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.
Quote:
Originally Posted by jr_bob_dobbs
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.
I find it a bit concerning there's a workflow need for this. The upcoming release's improvements can't come soon enough.
Quote:
Originally Posted by jr_bob_dobbs
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):
Code:
[OKAY] Preparing /proc
[OKAY] Preparing /sys
/etc/init.d/rcS: line 77: can't create /proc/sys/kernel/hotplug: nonexistent directory
/etc/init.d/rcS: line 78: can't create /sys/kernel/uevent_helper: Permission denied
[OKAY] Preparing /dev, /dev/pts, /dev/shm, /run
[ -- ] starting mdev/etc/init.d/rcS: line 113: can't create /proc/sys/kernel/hotplug: nonexistent directory
[FAIL]
[ -- ] Loading modules[ 28.312055] ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
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?
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.
Quote:
Originally Posted by jr_bob_dobbs
hen I log in ... or try to. After entering user name and password.
Code:
__
\ \___ Welcome to
\ _ \ Bedrock Linux
\___/ 1.0beta2 Nyla
login[3270]: root login on 'tty'
/bedrock/bin/brsh: export: line 33: illegal option -f
Bedrock Linux 1.0Beta2 Nyla artemis /dev/tty1
artemis login:
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?
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:
Code:
set -x
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:
Code:
export -f pathremove pathprepend pathappend
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.
Last edited by jr_bob_dobbs; 04-16-2018 at 10:07 PM.
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:
Code:
export -f pathremove pathprepend pathappend
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.
Great!
Quote:
Originally Posted by jr_bob_dobbs
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.
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:
Code:
case "$(/bedrock/bin/bri -n)" in
"arch")
echo "This only runs with arch"
;;
"gentoo")
echo "This only runs with gentoo"
;;
"slackware")
echo "This only runs with slackware"
;;
esac
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.
Last edited by ParadigmComplex; 04-17-2018 at 04:24 AM.
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:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.