Re: systemd woes continue

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 "<cntl-D>\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 "<cntl-D>" 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
> "<cntl-D>\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 "<cntl><alt><del>" 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
>