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
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 noproblem 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 necessaryand 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
[1] https://cdimage.debian.org/cdimage/ports/2019-07-07/
Hi John!problem with recompiling things as necessary (although I would like to avoid the Gentoo path of recompiling everything).
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
systemd works the same way on my Alpha XP-1000 as it works on my Intel boxes.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
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
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/
(...)
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...
The other question I have is whether or not someone has fixed the issue with fdisk on the system (...)
On Wed, Jul 10, 2019 at 09:54:40PM -0500, Bob Tracy wrote:
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 bug I see on my XP1000 with systemd is that it fails to mount
the filesystems in /etc/fstab and so stops in emergency mode; one
can enter the root password, issue "mount -a" and "swapon -a" and
exit and the boot resumes fines. I never had this problem with
sysvinit and have no idea why systemd does not cope. I will
probably reinstall sysvinit. Every time I have tried systemd on
my Alpha I have ended up deinstalling it and reverting back to
sysvinit and it looks like this time will be no exception.
Cheers,
Michael.
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.
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,
The other question I have is whether or not someone has fixed
the issue with fdisk on the system,
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.
On Thu, Jul 11, 2019 at 04:11:44PM +0200, John Paul Adrian Glaubitz wrote:
systemd works the same way on my Alpha XP-1000 as it works on my Intel boxes.
Interesting. It doesn't work on mine; it fails to mount the
filesystems even when I recently tried a new install into a
spare partition (but I did use debootstrap to install, not the
installer disk).
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,
Pardon? A separate /usr partition has always been supported on
Linux, so I am not sure what you are tallking about...
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://lwn.net/Articles/670071/
The other question I have is whether or not someone has fixed
the issue with fdisk on the system,
fdisk is a lost cause. It no longer supports a BSD partition. I
believe the maintainer of fdisk was spoken to about this quite some
time ago but was not interested in fixing it.
It is a while since I have partitioned a disk for Alpha but I think
parted should work.
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.
Yeah, that's a problem for any Alpha with a Qlogic SCSI controller.
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.
Yeah, that's a problem for any Alpha with a Qlogic SCSI controller.
If you want to use e100 (e.g. DE602) and tg3 (e.g. DEGXA) driven NICs
during installation, these should be added here, too.
To sum things up: what Adrian intends to do for Alpha - pre-include the firmware on the installer discs - seems to be the only way to get this problem fixed w/o manual intervention during installation.
It's on my TODO list. It's just not trivial since I need to modify debian-cd >> to be able to merge the contrib and non-free repositories from the main
FTP servers during CD image build.
JH Chatenet once created a debootstrap "addon" (see [1] for details)
that merges "unstable" and "unreleased" suites, maybe functionality from
that addon can be reused here?
The gist is: A lot of projects don't test their code on systems withseparate
/usr partitions anymore, so things get silently broken.
On 7/17/19 11:54, John Paul Adrian Glaubitz wrote:
On 7/17/19 11:00 AM, Michael Cree wrote:wrote:
On Thu, Jul 11, 2019 at 04:11:44PM +0200, John Paul Adrian Glaubitz
/usr partition,I assume you are talking about the non-functionality of a separate
but this is something that isn't guaranteed to work well on Linux,
Pardon? A separate /usr partition has always been supported on
Linux, so I am not sure what you are tallking about...
It's not really supported anymore:
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
https://lwn.net/Articles/670071/
We have recently had a similar discussion on the debian-68k mailing list.
The gist is: A lot of projects don't test their code on systems withseparate
/usr partitions anymore, so things get silently broken.
Very unfortunate.
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.
Yeah, that's a problem for any Alpha with a Qlogic SCSI controller.
If you want to use e100 (e.g. DE602) and tg3 (e.g. DEGXA) driven NICs
during installation, these should be added here, too.
I actually wanted to provide a write-up of my in-depth testing of some
older ISOs from Adrian on DS20E, DS25 and ES45, but I didn't find the
time yet and there are already newer ISOs available to try, so I'll just
put some parts of what I learned here, as it seems to fit the discussion:
What I saw during my testing (when a Qlogic SCSI controller (e.g. KZPBA)
is used - mainly relevant for ES45 which has no integrated SCSI
controller, DS20E and DS25 instead have integrated Adaptec SCSI
controllers which aren't affected) is, that the qla1280 driver gets
loaded during startup of the installer (kernel) automatically. It
doesn't work though due to missing firmware. Then when you provide the firmware DEBs to the installer it takes multiple attempts to actually
install the required firmware for the Qlogic SCSI controller. When it
finally succeeds (I actually don't remember if it succeeded at all, or
if I manually put the firmware in place), the qla1280 driver is unloaded
and then reloaded (this time with firmware in place). But unfortunately
the Qlogic SCSI controller is no longer responsible. I don't know if
this is due to the first load w/o firmware or due to the unloading, but
it doesn't matter, providing the firmware as intended by the installer doesn't work for such a configuration.
The only way to get it working was to blacklist the qla1280 module
during startup, manually mount a prepared firmware directory to `/lib/firmware` and manually load the qla1280 module afterwards but
before entering the partitioning step.
Similar for the NIC modules, when using e100 or tg3 driven NICs on Alpha.
BTW here other architectures differ, e.g. an rx2660 (ia64) with two tg3 driven NICs works perfectly fine w/o firmware available and I've also
seen it working perfectly with e100 driven NICs on x86 IIRC.
If you have a tulip driven NIC and/or a sym53c8xx driven SCSI controller (e.g. KZPCA) you're fine, as these don't require firmware. Same for
machines with Adaptec controllers, though the integrated NICs of the
DS25 still require firmware to operate correctly.
****
To sum things up: what Adrian intends to do for Alpha - pre-include the firmware on the installer discs - seems to be the only way to get this problem fixed w/o manual intervention during installation.
It's on my TODO list. It's just not trivial since I need to modifydebian-cd
to be able to merge the contrib and non-free repositories from the main
FTP servers during CD image build.
JH Chatenet once created a debootstrap "addon" (see [1] for details)
that merges "unstable" and "unreleased" suites, maybe functionality from
that addon can be reused here?
[1]: https://lists.debian.org/debian-alpha/2014/06/msg00012.html
Cheers,
Frank
On 7/17/19 3:16 PM, Frank Scheiner wrote:
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.
Yeah, that's a problem for any Alpha with a Qlogic SCSI controller.
If you want to use e100 (e.g. DE602) and tg3 (e.g. DEGXA) driven NICs
during installation, these should be added here, too.
What do you mean by adding them? The drivers? Or the firmware? If the firmware is not packaged, someone needs to add them to one of the
firmware packages.
To sum things up: what Adrian intends to do for Alpha - pre-include the
firmware on the installer discs - seems to be the only way to get this
problem fixed w/o manual intervention during installation.
It's also the standard way how it's done. debian-cd (the software used to build the CD images) supports adding firmware packages. But the problem
is that firmware packages are usually part of the non-free suite which is
not available in Debian Ports but on the main Debian repositories only.
However, the main repositories and the Debian Ports repositories are
separate mirrors and currently, debian-cd does not support more than
one mirror during CD image build.
So, while I can enable to include firmware during image build, debian-cd
is unable to find the firmware packages as they are not part of the Debian Ports mirror
I hope that clarifies the problem.
It's on my TODO list. It's just not trivial since I need to modify debian-cd
to be able to merge the contrib and non-free repositories from the main
FTP servers during CD image build.
JH Chatenet once created a debootstrap "addon" (see [1] for details)
that merges "unstable" and "unreleased" suites, maybe functionality from
that addon can be reused here?
That just merges two suites but not two mirrors.
On 7/17/19 11:00 AM, Michael Cree wrote:
On Thu, Jul 11, 2019 at 04:11:44PM +0200, John Paul Adrian Glaubitz wrote: >>> 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,
Pardon? A separate /usr partition has always been supported on
Linux, so I am not sure what you are tallking about...
It's not really supported anymore:
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
https://lwn.net/Articles/670071/
We have recently had a similar discussion on the debian-68k mailing list.
The gist is: A lot of projects don't test their code on systems with separate /usr partitions anymore, so things get silently broken.
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.
Yeah, that's a problem for any Alpha with a Qlogic SCSI controller.
It's on my TODO list. It's just not trivial since I need to modify debian-cd to be able to merge the contrib and non-free repositories from the main
FTP servers during CD image build.
Ok, could it work when using the CDN (deb.debian.org) as described on
[2]? Or does this just redirect to the actual ports mirror for ports architectures?
[2]: https://www.ports.debian.org/mirrors
That just merges two suites but not two mirrors.
Oh, I see, didn't anticipate that the non-free suite is on different
mirrors. But see above.
On 7/17/19 15:41, John Paul Adrian Glaubitz wrote:
On 7/17/19 3:16 PM, Frank Scheiner wrote:
To sum things up: what Adrian intends to do for Alpha - pre-include the
firmware on the installer discs - seems to be the only way to get this
problem fixed w/o manual intervention during installation.
It's also the standard way how it's done. debian-cd (the software used to
build the CD images) supports adding firmware packages. But the problem
is that firmware packages are usually part of the non-free suite which is
not available in Debian Ports but on the main Debian repositories only.
However, the main repositories and the Debian Ports repositories are
separate mirrors and currently, debian-cd does not support more than
one mirror during CD image build.
Ok, could it work when using the CDN (deb.debian.org) as described on
[2]? Or does this just redirect to the actual ports mirror for ports architectures?
[2]: https://www.ports.debian.org/mirrors
The gist is: A lot of projects don't test their code on systems with separate
/usr partitions anymore, so things get silently broken.
I don't have separate /usr, just single / (ext4) partition, and just separate /boot (ext2), and still systemd fails to mount this /boot file system,
similar to Michael issue. So, I dont think it is really related to separate /usr vs non separate /usr.
PS. On my amd64 system with systemd, I do have separate /usr, and it does work.Again, there is nothing Alpha-specific in systemd that would cause such breakage.
To sum things up: what Adrian intends to do for Alpha - pre-include the firmware on the installer discs - seems to be the only way to get this problem fixed w/o manual intervention during installation.
Hey John,
The gist is: A lot of projects don't test their code on systems withseparate
/usr partitions anymore, so things get silently broken.
I don't have separate /usr, just single / (ext4) partition, and just
separate /boot (ext2), and still systemd fails to mount this /boot file system, similar to Michael issue. So, I dont think it is really related to separate /usr vs non separate /usr.
PS. On my amd64 system with systemd, I do have separate /usr, and it does work.
On Wed, Jul 10, 2019 at 09:54:40PM -0500, Bob Tracy wrote:
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 bug I see on my XP1000 with systemd is that it fails to mount
the filesystems in /etc/fstab and so stops in emergency mode; one
can enter the root password, issue "mount -a" and "swapon -a" and
exit and the boot resumes fines.
The bug I see on my XP1000 with systemd is that it fails to mount
the filesystems in /etc/fstab and so stops in emergency mode; one
can enter the root password, issue "mount -a" and "swapon -a" and
exit and the boot resumes fines.
This issue is reproducible in qemu-system-alpha. I have never seen that
on other architectures.
In my case there are a few infos about the issue in the boot log (I
don't remember seeing that before, so they might have appeared with
recent systemd versions):
[ 15.010734] systemd[1]: Set hostname to <alpha>.
[ 15.052726] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
[ 16.959952] systemd[1]: Condition check resulted in udev Kernel Socket being skipped.
[ 16.962881] systemd[1]: Starting of /dev/disk/by-uuid/4b9cdcc1-bb8b-4905-97cc-0a9be7a44bcc not supported.
[UNSUPP] Starting of /dev/disk/by-u…cc-0a9be7a44bcc not supported.
[ 16.970694] systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/4b9cdcc1-bb8b-4905-97cc-0a9be7a44bcc.
[DEPEND] Dependency failed for File…1-bb8b-4905-97cc-0a9be7a44bcc.
[ 16.974600] systemd[1]: Dependency failed for /boot.
[DEPEND] Dependency failed for /boot.
[ 16.977530] systemd[1]: Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Local File Systems.
[ 16.980460] systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
[ OK ] Started Emergency Shell.
[ OK ] Reached target Emergency Mode.
On 2019-07-17 20:36, Michael Cree wrote:
On Wed, Jul 10, 2019 at 09:54:40PM -0500, Bob Tracy wrote:
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 bug I see on my XP1000 with systemd is that it fails to mount
the filesystems in /etc/fstab and so stops in emergency mode; one
can enter the root password, issue "mount -a" and "swapon -a" and
exit and the boot resumes fines.
This issue is reproducible in qemu-system-alpha. I have never seen that
on other architectures.
In my case there are a few infos about the issue in the boot log (I
don't remember seeing that before, so they might have appeared with
recent systemd versions):
[ 15.010734] systemd[1]: Set hostname to <alpha>.
[ 15.052726] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
[ 16.959952] systemd[1]: Condition check resulted in udev Kernel Socket being skipped.
[ 16.962881] systemd[1]: Starting of /dev/disk/by-uuid/4b9cdcc1-bb8b-4905-97cc-0a9be7a44bcc not supported.
[UNSUPP] Starting of /dev/disk/by-u…cc-0a9be7a44bcc not supported.
[ 16.970694] systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/4b9cdcc1-bb8b-4905-97cc-0a9be7a44bcc.
[DEPEND] Dependency failed for File…1-bb8b-4905-97cc-0a9be7a44bcc.
[ 16.974600] systemd[1]: Dependency failed for /boot.
[DEPEND] Dependency failed for /boot.
[ 16.977530] systemd[1]: Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Local File Systems.
[ 16.980460] systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
[ OK ] Started Emergency Shell.
[ OK ] Reached target Emergency Mode.
...
You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):
...
You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):
In my case, upgrading glibc to 2.29 (now available in unstable) fixed
the issue.
Verified. Life is now better, if not good :-). This is the first time
I've been able to accomplish an "almost clean" boot of my Alpha in MANY months.
I say "almost clean", because a recent update managed to break my
resolver configuration: "/etc/resolv.conf" came up completely empty, in
spite of "/etc/network/interfaces" having the requisite
"dns-nameservers" and "dns-search" lines for my primary interface (eth0).
The "resolvconf" package is definitely installed, but I'm guessing some
new interaction between "systemd", "NetworkManager", and possibly "resolvconf" is, er, ah, unfortunate.
Verified. Life is now better, if not good :-). This is the first time
I've been able to accomplish an "almost clean" boot of my Alpha in MANY months.
I say "almost clean", because a recent update managed to break my
resolver configuration: "/etc/resolv.conf" came up completely empty, in
spite of "/etc/network/interfaces" having the requisite
"dns-nameservers" and "dns-search" lines for my primary interface (eth0).
The "resolvconf" package is definitely installed, but I'm guessing some
new interaction between "systemd", "NetworkManager", and possibly "resolvconf" is, er, ah, unfortunate.
I say "almost clean", because a recent update managed to break my
resolver configuration: "/etc/resolv.conf" came up completely empty, in
spite of "/etc/network/interfaces" having the requisite
"dns-nameservers" and "dns-search" lines for my primary interface (eth0).
The "resolvconf" package is definitely installed, but I'm guessing some
new interaction between "systemd", "NetworkManager", and possibly "resolvconf" is, er, ah, unfortunate.
It appears that all the configuration info in "/etc/network/interfaces"
for my "eth0" interface was completely ignored other than the IPv4
address. No IPv6 address, no "dns-*" config items, etc. Thanks,
systemd! Not :-(. I blame "systemd", because, when it was still
dropping me into emergency mode, "eth0" came up correctly.
[1] https://wiki.archlinux.org/index.php/Network_configuration#Revert_to_traditional_interface_names
is just annoying. Please let's have a more constructive discussion, after all, the previous issues on alpha were not caused by systemd either but
a bug in glibc for alpha.
Your permanent bashing of systemd makes answering your mails stressful
for me.
On Wed, Sep 18, 2019 at 11:46:06AM +0200, John Paul Adrian Glaubitz wrote:
Your permanent bashing of systemd makes answering your mails stressful
for me.
Adrian -- please accept my apology for my rantings... They contribute nothing to the conversation, and as you note, irritate the very people
in the best position to render needed assistance.
Going back to a previous message you sent, you suggested looking at a
few systemd network-related services:
(1) systemd-networkd: this is currently showing "disabled" on my system
(vendor preset: enabled).
(2) resolver-related systemd services such as "resolvconf" and "systemd-resolved":
"resolvconf" is "enabled", but "systemd-resolved" is "disabled"
(vendor preset: enabled).
None of the services mentioned above have any configuration files other
than the defaults.
So, I guess the main question on the table is, what's the best pathUsing /etc/network/interfaces should still work, so the easiest thing
forward to ensure network interfaces are brought up and configured automatically at boot time? Related to that question: is the use of "/etc/network/interfaces" deprecated? That's where my network
configuration details currently exist, and that used to be sufficient,
even after the migration from the old-style init program/scripts to "systemd". A sanitized copy of my current "interfaces" file is
attached.
(...)
So, can you please type "ip a" and check what device name is actually assigned
to your wired card and if it differs from "eth0", adjust your /etc/network/ interfaces file?
If your wired card is actually named "eth0", then the problem is somewhere else and we need to proceed in your next mail.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 354 |
Nodes: | 16 (2 / 14) |
Uptime: | 40:16:02 |
Calls: | 7,650 |
Calls today: | 2 |
Files: | 12,811 |
Messages: | 5,699,587 |