This brings up a question I need to ask of the people who know best on
this mailing list:
I have a DS10L 617mhz and I can't figure out which version is the best
to attempt to install on it. I'd rather avoid things like this issue
with systemd where they obviously haven't tried to actually test it on
an alpha processor, but I have no problem with recompiling things as
necessary (although I would like to avoid the Gentoo path of recompiling
everything).
The other question I have is whether or not someone has fixed the issue
with fdisk on the system, because I remember the last time I tried to
install linux on the system in question, it wouldn't format the drive
with a BSD partition as was necessary and after some discussion on some
mailing list or another it was discovered that the required
functionality had been phased out of fdisk a few years before, and
nobody had noticed on either side that it made it impossible to follow
the given directions on the FAQ/wiki. It was still being automatically
included with the distro and at the time I had to burn an ancient stable
version just to put the partition table right in order to install.
On 7/11/2019 11:54 AM, Bob Tracy wrote:
Greetings. It has been a while since I last checked in. Thought I'd
let the rest of the Alpha community know I'm still around :-).
I'm up and running on kernel version 5.2.0, built from the kernel.org
source tree as is my usual pattern. The previous kernel running on my
system was 5.1.0-rc7. Between then and today, something changed in user
space that made the expected drop into systemd's "emergency mode" more
painful than usual.
First, "systemd" still cannot handle systems with persistent filesystems
other than "/" and "/usr". As far as I know, the bug report I filed
against "systemd" is still open, and no progress has been made on that
front.
The added complication when I rebooted the system today was multiple
processes attempting to read input from the console at the same time.
Both the old kernel and the new one behaved identically, which is why
I'm assuming a problem with userspace. If you immediately type in the
"root" password when prompted (without waiting for additional background
init tasks to finish), things work normally up to the point where the
console font gets loaded. Sometime after that, part of what you type
goes to the command line, and the rest goes to ???. Tty echo is
disabled, so you can't tell which input characters are going to the
interactive shell, and which ones are going to ???.
A workaround I discovered by accident is to keep typing "\n"
until the "emergency mode" shell exits and "systemd" attempts to
continue with normal startup. That fails, and "systemd" drops back into
"emergency mode" again. However, only an interactive shell is listening
at that point, so you can go about the usual cleanup tasks (run "fsck" on
the remaining filesystems, mount them, bring up the primary network
interface, etc.), and *then* type "" to continue with normal
system startup.
If you wait until *after* the console font gets loaded before trying to
type the "root" password, the only way forward might be to try typing
"\n" multiple times until "systemd" attempts to continue with
normal startup, fails, and then drops you back into "emergency mode"
again. I didn't try that. Typing "" works, at least,
to restart the system and give you another crack at entering the "root"
password immediately after the "emergency mode" prompt appears.
No idea which startup process is competing with the "emergency mode"
interactive shell for input from the console keyboard.
--Bob
