• systemd woes continue

    From Bob Tracy@21:1/5 to All on Thu Jul 11 05:50:01 2019
    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)
  • From John Blake@21:1/5 to Bob Tracy on Thu Jul 11 15:10:03 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to John Blake on Thu Jul 11 16:30:01 2019
    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)
  • From John Blake@21:1/5 to John Paul Adrian Glaubitz on Thu Jul 11 18:10:01 2019
    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)
  • From Bob Tracy@21:1/5 to John Blake on Fri Jul 12 07:50:02 2019
    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)
  • From Witold Baryluk@21:1/5 to All on Wed Jul 17 11:50:02 2019
    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
  • From Michael Cree@21:1/5 to Bob Tracy on Wed Jul 17 11:20:01 2019
    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)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Wed Jul 17 11:20:01 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to Michael Cree on Wed Jul 17 12:20:02 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to Frank Scheiner on Wed Jul 17 16:00:02 2019
    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)
  • From Witold Baryluk@21:1/5 to All on Wed Jul 17 16:10:01 2019
    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"
  • From Frank Scheiner@21:1/5 to John Paul Adrian Glaubitz on Wed Jul 17 16:10:01 2019
    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)
  • From Frank Scheiner@21:1/5 to John Paul Adrian Glaubitz on Wed Jul 17 15:40:01 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to Frank Scheiner on Wed Jul 17 16:50:02 2019
    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)
  • From Frank Scheiner@21:1/5 to Frank Scheiner on Wed Jul 17 16:40:01 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to Witold Baryluk on Wed Jul 17 16:50:02 2019
    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)
  • From Bob Tracy@21:1/5 to Frank Scheiner on Thu Jul 18 15:40:02 2019
    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)
  • From Bob Tracy@21:1/5 to Witold Baryluk on Thu Jul 18 16:10:02 2019
    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)
  • From Aurelien Jarno@21:1/5 to Michael Cree on Sun Sep 1 21:40:02 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to Aurelien Jarno on Mon Sep 2 12:50:01 2019
    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)
  • From Aurelien Jarno@21:1/5 to Aurelien Jarno on Mon Sep 9 23:10:02 2019
    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)
  • From Bob Tracy@21:1/5 to Aurelien Jarno on Tue Sep 17 05:40:02 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to Bob Tracy on Tue Sep 17 15:50:02 2019
    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)
  • From Skye@21:1/5 to Bob Tracy on Tue Sep 17 21:30:01 2019
    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)
  • From Bob Tracy@21:1/5 to Bob Tracy on Wed Sep 18 02:10:02 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to Bob Tracy on Wed Sep 18 12:10:01 2019
    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)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Wed Sep 18 22:20:01 2019
    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)
  • From Bob Tracy@21:1/5 to John Paul Adrian Glaubitz on Thu Sep 19 07:30:01 2019
    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)
  • From John Paul Adrian Glaubitz@21:1/5 to Bob Tracy on Thu Sep 19 09:30:01 2019
    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)
  • From Bob Tracy@21:1/5 to John Paul Adrian Glaubitz on Thu Sep 19 15:20:02 2019
    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)