Re: systemd woes continue
On Thu, Jul 11, 2019 at 09:48:14PM +0900, John Blake wrote:
> (...)
> 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...
I don't believe the systemd issue I'm experiencing is unique to the alpha
architecture. Apologies if I left you with that impression. That being
said, I'm pretty sure most of the people reading this know how I feel
about "systemd", and I'll state here and now, for the record, that my
feelings are irrelevant at this point. That battle was lost a long time
ago, and the community is best served by trying to identify and fix the
legitimate bugs.
> The other question I have is whether or not someone has fixed the issue with
> fdisk on the system (...)
Check back in the relatively recent (no more than a year ago) archives for
this mailing list, but I believe we agreed that "fdisk" was not the correct
tool to use for setting up the disk partitions on Alpha. The criticism about
"fdisk" being mentioned in the installation documentation is legitimate, and
that should be fixed. However, since this is an Alpha-specific thing, and
Alpha is no longer a release architecture for Debian, the chances of getting
the documentation updated are tending more toward "not happening" these days
:-(.
If there's a "systemd" wonk tracking this conversation, the main issue
I'm seeing with the multiple persistent filesystems is that the
dependency service scripts for filesystems other than "/" and "/usr" are
dynamically generated at boot time based on what's defined in
"/etc/fstab". The other filesystems are being correctly discovered and
enumerated (based on the messages I see on the console), but for some
reason, "systemd" is unable to figure out how to choose and run the
appropriate "fsck" variant ("e2fsck" in my case), so the dependencies
(remaining filesystems) fail. Other than this recent crap with more
than one process trying to read input from the console at the same time,
the workaround for the remaining persistent filesystems is
straightforward: (1) when dropped into "emergency mode", enter the root
password; (2) run the appropriate filesystem checker for each of the
remaining persistent filesystems, and mount them; (3) exit "emergency
mode", and the system *should* finish coming up multi-user. I usually
do a few other things before exiting emergency mode, such as bring up my
primary network interface so I can run "ntpdate" and set the system
clock (on my PWS 433au, the hardware clock is *always* *way* off
following a reboot, and yes, the battery on the motherboard is good).
--Bob
Reply to: