You are not logged in.
Attempted to boot into recovery mode under Unstable yesterday and I end up with the following error message:
Cannot open access to console, the root account is locked.
I don't remember encountering this issue in the past. Am I missing or forgetting something?
20170711-01 edit: Many thanks to Sector11 for moving this thread.
Last edited by KrunchTime (2017-07-14 00:45:45)
Offline
^ https://bugs.debian.org/cgi-bin/bugrepo … bug=806852
Try using init=/bin/bash as a kernel parameter instead to boot to a passwordless root shell.
Offline
Thank you HoaS. I'll give it a try.
Offline
Attempted to boot into recovery mode under Unstable yesterday and I end up with the following error message:
Cannot open access to console, the root account is locked.
I don't remember encountering this issue in the past. Am I missing or forgetting something?
I believe I have seen this in the past on a Ubuntu system as generally on Ubuntu the root account is locked.
Real Men Use Linux
Offline
^ https://bugs.debian.org/cgi-bin/bugrepo … bug=806852
Try using init=/bin/bash as a kernel parameter instead to boot to a passwordless root shell.
Is this also an issue when installing BL from the BL ISOs? I get BL from a Debian net install and then use the BL script to add the BL fixins.
Last edited by KrunchTime (2017-07-05 19:36:46)
Offline
Head_on_a_Stick wrote:Is this also an issue when installing BL from the BL ISOs?
No, BL-²H uses v217 of systemd so is unaffected.
Offline
KrunchTime wrote:Head_on_a_Stick wrote:Is this also an issue when installing BL from the BL ISOs?
No, BL-²H uses v217 of systemd so is unaffected.
Ah....maybe I should start using the BL ISOs then. Good info, thank you.
Edit: Well, wait a minute. Debian Unstable currently has v2.33-10 in the repos, so shouldn't that be unaffected as well?
Last edited by KrunchTime (2017-07-05 19:50:25)
Offline
^ https://bugs.debian.org/cgi-bin/bugrepo … bug=806852
Try using init=/bin/bash as a kernel parameter instead to boot to a passwordless root shell.
Okay, after figuring out where I needed to add that parameter, I've only been successful using it once. All other times I get no response from my keyboard, so it's useless in those instances.
I also tried using SystemRescueCD to chroot into my BL-Unstable partition. I'm able to do that, but when I attempt to apt update, I'm getting errors indicating that I may not have network connectivity (using ethernet). However, after bringing up the GUI desktop in SystemRescueCD, I'm able to browse using Firefox.
Last edited by KrunchTime (2017-07-12 02:56:36)
Offline
^ Use damo's cheetsheet in the other thread to chroot from the BL ISO image.
And *please* stop offering vague desciptions — we need to see *actual terminal output* to be able to tell what is going on in your system (and what you are doing to it).
Offline
And *please* stop offering vague desciptions — we need to see *actual terminal output* to be able to tell what is going on in your system (and what you are doing to it).
Got it, although I don't think it would have helped in this situation. The errors are exactly what you would get when trying to apt update when there is no network connectivity.
Offline
Solved...I set a root password and I'm now able to boot into recovery mode. Many thanks to damo for his procedure to chroot into my Unstable partition.
Note: To others reading this thread, if you're running a true BL install, you may not need a root password to use recovery mode. I performed a Debian net install and then installed the bunsen-meta-all package to bring in the BL goodies for my setup.
Last edited by KrunchTime (2017-07-14 06:00:38)
Offline
Solved...I set a root password and I'm now able to boot into recovery mode. Many thanks to damo for his procedure to chroot into my Unstable partition.
And were you then able to view the systemd logs to pin down exactly what happened to cause the failures? So you did get your system booting normally again?
Real Men Use Linux
Offline
I used another method to view the systemd logs and didn't see anything that really stood out to me. However, I'm definitely not an expert at reading systemd logs.
No, I'm still unable to boot normally into my Unstable partition. I'm attempting to apt full-upgrade via recovery mode to see if that fixes the issue. I'm hoping that a package(s) has/have a bug and an update to said package(s) resolves the issue.
Last edited by KrunchTime (2017-07-14 01:14:35)
Offline
I'm now able to boot into recovery mode
Apologies for my ignorance but what is this mysterious "recovery mode" of which you speak?
How exactly do you engage this mode?
I can boot to a console login (either as root or as a normal user) just fine in my BunsenLabs system with the root account locked so I still fail to see what the problem is here.
Offline
In the initial grub boot menu, there is an advanced option. When you select that option, the next screen allows you to boot normally or in recovery mode. Also see my note in response #11. I can take a picture using my tablet if that would be more helpful.
Last edited by KrunchTime (2017-07-14 06:22:49)
Offline
In the initial grub boot menu, there is an advanced option. When you select that option, the next screen allows you to boot normally or in recovery mode.
How quaint 8)
So this option is only available to those who use BunsenLabs' GRUB configuration then?
My methods are more universal in their application; I would consider that to be a corner case.
We could perhaps add an init=/bin/bash boot option if there was a demand for such.
Offline
So this option is only available to those who use BunsenLabs' GRUB configuration then?
What other way is there? And again, I don't start off with a BL install. I perform a Debian net install and then install the bunsen-meta-all package to bring in the BL goodies. So, I'm not sure that it's a true BL Grub configuration.
We could perhaps add an init=/bin/bash boot option if there was a demand for such.
That didn't always work for me; https://forums.bunsenlabs.org/viewtopic … 749#p55749
Offline
What other way is there?
Most people who multiboot would prefer not to switch bootloader when they install a new system, I would think.
The GRUB configuration used in BunsenLabs is exactly the same as upstream Debian, as far as I know.
I would expect that a "Recovery Mode" would never be needed in Debian stable — my family laptop has been running it for three years now with no problems whatsoever and that is a fairly normal Debian stable experience.
I do not think your experiences with your sid-based system should influence the development path of our stable-based distribution and I do not agree that the bug you describe warrants changing a policy that has been extant since #!'s Ubuntu days.
There is no problem with having a locked root account and not being able to log in as root in Recovery Mode sounds entirely normal to me (if the root account is locked) and is not an issue in need of correction, in my opinion.
Offline
Most people who multiboot would prefer not to switch bootloader when they install a new system, I would think.
Pardon my ignorance, but I don't know what you mean.
The GRUB configuration used in BunsenLabs is exactly the same as upstream Debian, as far as I know.
I would expect that a "Recovery Mode" would never be needed in Debian stable — my family laptop has been running it for three years now with no problems whatsoever and that is a fairly normal Debian stable experience.
I guess it depends on the hardware you have. I needed it a few times when I had an AMD graphics card on my old Dell laptop and a kernel upgrade would hose the proprietary driver.
I do not think your experiences with your sid-based system should influence the development path of our stable-based distribution and I do not agree that the bug you describe warrants changing a policy that has been extant since #!'s Ubuntu days.
There is no problem with having a locked root account and not being able to log in as root in Recovery Mode sounds entirely normal to me (if the root account is locked) and is not an issue in need of correction, in my opinion.
I never said or implied that my experience using Unstable should influence the development of BL. Perhaps you're referring to the thread I started about enabling the root account. My purpose in starting that thread was to get feedback from others about a locked root account, pros and cons. As I've learned from my recent experience, you don't actually need a root account, but a root password can be useful for recovery purposes.
Last edited by KrunchTime (2017-07-14 07:07:23)
Offline
AFAIK a 'grub-install /dev/sdx && update-grub' produces the Advanced grub menu entries, on every install I've done, (assuming 30_os-prober is present).
recovery_params="$(echo "${LPARAMS}" | grep 'single\|recovery')" || true
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline