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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I do have similar issue with systemd.

It fails "local-fs.target" task, unless I remove /boot (which is on
separate device) entry from "/etc/fstab"

swap works (based on "free" and "/proc/swaps"), and systemd does enable it automatically.

Another issue I do face, is that systemd doesn't bring up network
interface, and does complain about "ifup" or even before it that it failed.
It just says: "Starting of /sys/subsystem/net/devices/enp0s1 not
supported". Huh?

Manually doing "ifup enp0s1" works just fine.

Unfortunately, the logs are rather sparse, and they don't tell me why it failed.

The entry in /etc/network/interfaces looks just fine.

And the entry in /etc/fstab is fine too (it do use UUID), because if I
restore it and do manually "mount /boot" or "mount -a", it works fine.

śr., 17 lip 2019 o 09:12 Michael Cree <mcree@orcon.net.nz> napisał(a):

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.

--
Witold Baryluk
My PGP keys for 2017-02-17 - 2019-02-17:
5B8C 48CB 8B2F CF53 CA55 0995 16D9 6FA2 20A8 F130 https://functor.xyz/pgp/witold.baryluk-gmail.gpg.asc https://keys.mailvelope.com/pks/lookup?op=get&search=0x16D96FA220A8F130

<div dir="ltr"><div>I do have similar issue with systemd.</div><div><br></div><div>It fails &quot;local-fs.target&quot; task, unless I remove /boot (which is on separate device) entry from &quot;/etc/fstab&quot;<br></div><div><br></div><div>swap works (
based on &quot;free&quot; and &quot;/proc/swaps&quot;), and systemd does enable it automatically.<br></div><div><br></div><div>Another issue I do face, is that systemd doesn&#39;t bring up network interface, and does complain about &quot;ifup&quot; or
even before it that it failed. It just says: &quot;Starting of /sys/subsystem/net/devices/enp0s1 not supported&quot;. Huh?<br></div><div><br></div><div>Manually doing &quot;ifup enp0s1&quot; works just fine.</div><div><br></div><div>Unfortunately, the
logs are rather s

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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...

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.

Some Solutions:

1) if you have a recent Alpha with USB then you just need to plug
in a memory stick with the linux non-free firmware package during
install.

2) One could build your own kernel with the firmware in-built then
do a tftp boot across the network to bring up the Alpha with the
installer in the CD drive and continue to install.

3) One could debootstrap a minimal system on x86-64; use qemu-alpha
to 2nd stage bootstrap and install the kernel/firmware and generate
an initrd with the firmware. Then write that to the disk that will
then be installed into the Alpha, but you likely need a SCSI
controller for the x86-64 machine to write the disk.

4) In the absence of the SCSI controller for your x86-64 machine,
extend the tftp boot on Alpha to NFS mount that Alpha root
filesystem you just bootstrapped and bring up the Alpha entirely
from the network, and then install manually to its system disk.

So many options to install...

Cheers,
Michael.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

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).

There isn't really anything specific to the Alpha architecture which
would break that.

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.

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.

I agree. parted is the preferred tool these days.

It is a while since I have partitioned a disk for Alpha but I think
parted should work.

Yep. Works fine for me with debian-installer.

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.

I will hopefully solve that issue soon. I have vacation next week so I will most likely be working on the problem.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hey John,

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.

Regards,
Witold


śr., 17 lip 2019 o 13:33 Frank Scheiner <frank.scheiner@web.de> napisał(a):

On 7/17/19 11:54, John Paul Adrian Glaubitz wrote:

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.

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 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?

[1]: https://lists.debian.org/debian-alpha/2014/06/msg00012.html

Cheers,
Frank

--
Witold Baryluk
My PGP keys for 2017-02-17 - 2019-02-17:
5B8C 48CB 8B2F CF53 CA55 0995 16D9 6FA2 20A8 F130 https://functor.xyz/pgp/witold.baryluk-gmail.gpg.asc https://keys.mailvelope.com/pks/lookup?op=get&search=0x16D96FA220A8F130

<div dir="ltr"><div>Hey John,</div><div><br></div><div>&gt; The gist is: A lot of projects don&#39;t test their code on systems with separate <br></div><div>&gt; /usr partitions anymore, so things get silently broken.<span class="gmail-im"></span><br><
span class="gmail-im">
</span></div><div><br></div><div>I don&#39;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.</div><div><br></div><div>PS. On my amd64 system with systemd, I do have separate /usr, and it does work.</div><div><br></div><div>Regards,</div><div>Witold</div><div><br></div></div><br><div class="gmail_quote"

On 7/17/19 15:41, John Paul Adrian Glaubitz wrote:

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.

I just wanted to "add" these NICs to the list of hardware that needs
firmware to work correctly on Alpha, i.e. like:

```
Yeah, that's a problem for any Alpha with a Qlogic SCSI controller...

...and a e100 or tg3 driven NIC.
```

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

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.

Oh, I see, didn't anticipate that the non-free suite is on different
mirrors. But see above.

Cheers,
Frank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/19 11:54, John Paul Adrian Glaubitz wrote:

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.

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 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?

[1]: https://lists.debian.org/debian-alpha/2014/06/msg00012.html

Cheers,
Frank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/19 3:50 PM, Frank Scheiner wrote:

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

debian-cd requires a mirror to be available locally through the filesystem,
it doesn't support connecting to a remote HTTP server as it creates hardlinks on the filesystem for certain things.

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.

Doesn't help unfortunately, see above ;-).

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/19 15:50, Frank Scheiner wrote:

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

Probably not, as [3] shows that one still needs to use different
directories for the different targets.

[3]: http://deb.debian.org/

Ok, what about a redirect on the Debian-Ports mirror for a "/debian-ports/pool/non-free/" directory to e.g. "http://deb.debian.org/debian/pool/non-free"? Apt seems to support
redirects.

Cheers,
Frank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/19 3:45 PM, Witold Baryluk wrote:

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,

What is the error message you are getting? The difference between systemd and sysvinit
in this case is that often sysvinit silently ignores problems and just moves on which
is why you never notice when a mount fails, for example.

similar to Michael issue. So, I dont think it is really related to separate /usr vs non separate /usr.

That's not what I meant, really. But the point is: If you are using a separate /usr on Linux these days, you are voiding your warranty which is why Debian
is even moving towards unifying /usr and /bin, /sbin etc.

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.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 17, 2019 at 03:16:09PM +0200, 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.

Many other things to comment on in this thread, but not much time to do
so at the moment. I *did* want to comment on the above...

It more than likely would be completely against Debian policy/guidelines
to do so, but the best *technical* solution to the qlogic firmware issue
on Alpha is to build the firmware into the kernel along with the driver.
That is how it was done for older Debian releases (and other distros)
before kernel developers adopted the default position of NOT building
the firmware into the kernel. The fact that the firmware is non-free
from a licensing perspective only made matters worse. As a side-note,
if you build your own kernel from source and build-in a driver (rather
than build it as a module) that requires firmware, you *have* to include
the firmware in the kernel as well -- the kernel configurator neither
detects nor enforces inclusion of the corresponding firmware -- you have
to manually specify you want that done. My custom kernels have all the
drivers for hardware that's present and required at boot time built-in
to the kernel, along with the required firmware. For the Miata platform
I use (PWS 433au), the two affected drivers are for the qlogic SCSI card
and the Radeon-based graphics card.

Things get complicated in a hurry when required drivers are built as
modules if the firmware isn't available when the hardware gets auto-
detected and the module gets loaded. As one person in this thread
already observed, one workaround is to blacklist the driver module to
prevent it from being loaded until the firmware can somehow be made
available -- a less than satisfactory solution because the driver must
then be loaded manually -- definitely not user-friendly in any sense of
the phrase.

To summarize... If *I* were trying to put together an installer image
for the Alpha platform, it would include drivers for the default disk controllers for each Alpha variant, drivers for the standard DEC video
cards, and drivers for the commonly-used Radeon cards that seem to be
the agreed-upon upgrade used by the Alpha community. I'm not familiar
with Alpha platforms other than the one I use (Miata), but I think it
would be helpful/useful for us to put together a list of disk controller
and video drivers that might reasonably be needed in an installer image.
This would help Adrian get the Debian installer where it needs to be in
fewer iterations.

Respectfully,
--Bob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 17, 2019 at 01:45:21PM +0000, Witold Baryluk wrote:

Hey John,

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.

Recall my original statement of the issue. Separate "/usr" is ok.
Other persistent filesystems, say, "/boot", do *not* work. This is
consistent with what the rest of us are seeing who have run into this
problem with "systemd". I agree with the assertion/speculation that
what we're seeing shouldn't be unique to Alpha, and I don't think it is.

The "everything on /" default partitioning scheme is sensible for people
new to UN*X who simply want to get Linux up and running as quickly and
easily as possible. For people with a little bit of experience and a
sense of historical perspective, separate persistent filesystems are the
way to go. Most of the "heavy" disk I/O is associated with directories
like "/tmp" and "/var", not to mention swap partitions. "/tmp" is non- persistent in modern distros, so we'll ignore it for now. On the other
hand, "/var" sees quite a bit of disk I/O (software updates, spooling,
e-mail, etc.), and it makes sense for "/var" to be on a separate
partition so that *when* a crash occurs, the resulting filesystem
corruption won't affect "/".

Other persistent filesystems are a matter of individual
taste/preference, but in general, the idea is to distinguish between
those parts of the directory hierarchy that are relatively stable vs.
those that are likely to see a lot of writing. Modern filesystems
aren't as likely to be unrecoverable after a crash, so we can get away
with a monolithic "everything on /" philosophy. That wasn't always the
case, and old fossils like me that got burned decades ago haven't
forgotten the lessons that were learned the hard way :-(. Another consideration is that disks used to be much smaller, and multiple
persistent partitions were pretty much a forced choice, i.e., you
couldn't put everything on a single spindle, and there was no way to
construct a large logical volume out of multiple smaller physical ones
as we can do today. The standard hard disks available for a DEC PWS
when that system first hit the market would certainly have required
either separate persistent filesystems or logical volume capability
to be useful. At the time I first installed Linux on an Alpha, I think
only RedHat was using LVM by default (although they no longer supported
Alpha at that point), and I can't remember whether anyone else's
installer even offered it as an option.

In summary, I guess I'm saying there are valid reasons in 2019 for
having multiple persistent fiiesystems, even with large physical disks
and the ability to create large logical volumes out of multiple smaller
ones.

--Bob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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):

--
Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On 9/1/19 9:12 PM, Aurelien Jarno wrote:

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.

Indeed. I have observed this as well on my XP-1000. I think I have sometimes seen that on sh4
but so far it's not clear to me what the problem is. I will have a look at the system issue
tracker and if it's not already reported, open a new issue upstream.

systemd upstream is usually very responsive when it comes to fixing such issues, so I'm confident
we can get this sorted out.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-09-01 21:12, Aurelien Jarno wrote:

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):

In my case, upgrading glibc to 2.29 (now available in unstable) fixed
the issue.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Sep 09, 2019 at 10:49:25PM +0200, Aurelien Jarno wrote:

...

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.

--Bob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Bob!

On 9/17/19 4:38 AM, Bob Tracy wrote:

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.

Great. Thanks for confirming.

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.

Unless you actively enabled systemd-networkd/systemd-resolveconfd, they
don't become active on their own. And NetworkManager is not related to
systemd.

I do recommend setting up systemd-networkd/systemd-resolveconfd for headless machines though as it makes network configuration rather painless.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Many thanks to all who have been putting effort into this issue.

I plan to download the lasted build and try booting my AlphaStations again.

-----Original Message-----
From: John Paul Adrian Glaubitz [mailto:glaubitz@physik.fu-berlin.de]
Sent: Tuesday, September 17, 2019 7:27 AM
To: Bob Tracy
Cc: debian-alpha@lists.debian.org
Subject: Re: systemd woes continue

Hi Bob!

On 9/17/19 4:38 AM, Bob Tracy wrote:

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.

Great. Thanks for confirming.

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.

Unless you actively enabled systemd-networkd/systemd-resolveconfd, they
don't become active on their own. And NetworkManager is not related to
systemd.

I do recommend setting up systemd-networkd/systemd-resolveconfd for headless machines though as it makes network configuration rather painless.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Sep 16, 2019 at 09:38:55PM -0500, Bob Tracy wrote:

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.

--Bob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Bob!

On 9/18/19 1:48 AM, Bob Tracy wrote:

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.

Your permanent bashing of systemd makes answering your mails stressful
for me. I have contributed to systemd quite some bit and I have a good relationship with several of the developers, so the pointless bashing
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.

As for the network configuration issue you are having, this might be a
result of udev renaming your network interfaces names [1]. You can
try disabling that.

Adrian

[1] https://wiki.archlinux.org/index.php/Network_configuration#Revert_to_traditional_interface_names

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Sep 18, 2019 at 11:46:06AM +0200, John Paul Adrian Glaubitz wrote:

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.

I would not be so quick to blame glibc. (If you can point me to the
actual bug in glibc I will reconsider my opinion).

Systemd sidesteps glibc and makes direct geteuid, etc., syscalls.
Because Alpha did not have these syscalls systemd had a nasty hack
only compiled on Alpha which I was worried would break one day.
Systemd is one of the reasons why I supported getting the geteuid
compatible syscalls into the Alpha kernel.

Systemd may have come right because it was re-compiled against
recent linux headers and picked up the new Linux syscalls on Alpha,
and, if so, it will only work with a 5.1 or newer kernel.

I have been meaning to test this theory and re-look at the relevant
systemd code and consider whether it needs further patching (maybe
the Alpha specific hack can now be removed) but haven't got around to
it.

Cheers,
Michael.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 path
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.

Thanks in advance for the assist.

--Bob

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address (masked)
netmask 255.255.255.240
network (masked)
broadcast (masked)
gateway (masked)
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers (masked)
dns-search (my registered domain)

# /64 prefix assigned by Hurricane Electric
iface eth0 inet6 static
address (masked)
netmask 64
scope global

# Wireless settings for D-Link DWA-131 (r8712u driver from staging -- sigh)
# The initial interface name is wlan0, but that gets remapped to the name
# below by systemd+udev.
allow-hotplug wlx1c7ee513fb7b
iface wlx1c7ee513fb7b inet dhcp
wireless-mode Managed
wpa-driver wext
wpa-ssid (masked)
wpa-psk (masked)

# USB RTL8153 Gigabit Ethernet Adapter
allow-hotplug enx00e04c6881f7
iface enx00e04c6881f7 inet static
address (masked)
netmask 255.255.255.0
network (masked)
broadcast (masked)
gateway (masked)

# Hurricane Electric tunnel: ID# (masked) est. 01 May 2016
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address (masked)
netmask 64
endpoint (masked)
local (masked, but IPv4 address of eth0)
ttl 255
gateway (masked)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Bob!

On 9/19/19 7:09 AM, Bob Tracy wrote:

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.

It's okay. Let's try to tackle your remaining problems.

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.

Both systemd services here are "systemd-networkd" and "systemd-resolved" and both are disabled by default. "resolvconf" is not related to systemd.

So, I guess the main question on the table is, what's the best path
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.

Using /etc/network/interfaces should still work, so the easiest thing
to do would be to check whether your interface names have been renamed.

Looking at your /etc/network/interfaces, I can see that you are using
the modern driver-oriented device names while for your cable connection
you are stuck with eth0.

So, my assumption is that udev is indeed renaming your network interfaces
and while you (or some script) has set the new interface names for your wireless card in /etc/network/interfaces, you are still using "eth0" for
your wired network card.

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.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Sep 19, 2019 at 09:10:20AM +0200, John Paul Adrian Glaubitz wrote:

(...)
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.

The wired card really *is* "eth0". "ip a" shows five interfaces in the
current active (correct) environment:

1: lo
2: eth0 (my primary network interface, connected to a pre-CIDR routable
class C network)
3: enx00e04c6881f7 (USB NIC connected to an internal non-routable class
C network)
4: sit0@NONE (tunnel for IPv6-in-IPv4 traffic)
7: he-ipv6@NONE (a point-to-point IPv4 connection to the IPv6 tunnel broker)

The wireless interface in the "interfaces" file corresponds to a USB
adapter I haven't used with the Alpha in a long time. I left the
configuration info there as a reminder of how to do that if/when it
becomes necessary :-).

At the risk of providing too much information, the Alpha is serving as a
local IPv6 gateway router. "/etc/sysctl.conf" has "net.ipv6.conf.all.forwarding=1" which is appropriate (required) for a
router, because otherwise, "radvd" will "unexpectedly" configure an
additional global IPv6 address for "eth0" which you definitely do not
want. The only global scope IPv6 addresses are statically assigned to
the "eth0" and "he-ipv6" interfaces.

There remains a bit of strangeness, even if/when the interfaces are
brought up correctly, because of the "gateway" configuration line
associated with the USB interface. I need to comment that out: multiple default routes at identical priorities is a legitimate configuration
error in my setup. At one time, there was a legitimate reason for that
gateway line to be there: no need to go into that level of detail at
present :-).

--Bob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)