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
Re: systemd woes continue
It's been a year or two since I last tried to install the experimental debian alpha image on my DS10L, and my abiding memory of the last attempt was banging my head against a problem with creating BSD disklabel on the ide hard drive due to fdisk being updated a few years prior to remove the older functionality of BSD disklabels and the instructions not having been updated since then, and the people I asked for help had simply been updating their systems instead of doing fresh installs. The BSD disklabel is required for SRM/IDE systems, and this system will dual boot from two separate drives alongside a functional VMS install. I did eventually get the disklabel written using an old version of fdisk through a process I've since forgotten. It's on hold for the moment as I tried to run a Gentoo install on the drive a few hours ago and it appears that the drive is dead, so I'll need to buy a new drive before I try again. On 7/11/2019 11:11 PM, John Paul Adrian Glaubitz wrote: Hi John! On 7/11/19 2:48 PM, 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, but I have no problem with recompiling things as necessary (although I would like to avoid the Gentoo path of recompiling everything). systemd works the same way on my Alpha XP-1000 as it works on my Intel boxes. I assume you are talking about the non-functionality of a separate /usr partition, but this is something that isn't guaranteed to work well on Linux, no matter whether one uses systemd or any other type of init daemon. 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. debian-installer doesn't use fdisk (anymore), it uses partman. Did you try any of the recent installation images, see [1]. Please note these images are currently shipped without proprietary firmware. Adrian [1] https://cdimage.debian.org/cdimage/ports/2019-07-07/
Re: systemd woes continue
Hi John! On 7/11/19 2:48 PM, 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, but I have no problem with recompiling things as necessary > (although I would like to avoid the Gentoo path of recompiling everything). systemd works the same way on my Alpha XP-1000 as it works on my Intel boxes. I assume you are talking about the non-functionality of a separate /usr partition, but this is something that isn't guaranteed to work well on Linux, no matter whether one uses systemd or any other type of init daemon. > 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. debian-installer doesn't use fdisk (anymore), it uses partman. Did you try any of the recent installation images, see [1]. Please note these images are currently shipped without proprietary firmware. Adrian > [1] https://cdimage.debian.org/cdimage/ports/2019-07-07/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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 "\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
