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