Re: systemd network interface configuration (was "Re: systemd woes continue")
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
Re: systemd network interface configuration (was "Re: systemd woes continue")
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
systemd network interface configuration (was "Re: systemd woes continue")
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)
Re: systemd woes continue
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.
Re: systemd woes continue
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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
RE: systemd woes continue
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:glaub...@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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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
Re: systemd woes continue
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 . > [ 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 aurel...@aurel32.net http://www.aurel32.net
Re: systemd woes continue
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 . > [ 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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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 . [ 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 aurel...@aurel32.net http://www.aurel32.net
Re: systemd woes continue
On Wed, Jul 17, 2019 at 01:45:21PM +, 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
Re: systemd woes continue
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
Re: systemd woes continue
On 7/17/19 4:13 PM, Frank Scheiner wrote: > 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. Again, debian-cd requires a local mirror on the filesystem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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
Re: systemd woes continue
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
Re: systemd woes continue
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 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=0x16D96FA220A8F130
Re: systemd woes continue
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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
Re: systemd woes continue
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
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 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=0x16D96FA220A8F130
Re: systemd woes continue
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.
Re: systemd woes continue
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.
Re: systemd woes continue
On Thu, Jul 11, 2019 at 09:48:14PM +0900, John Blake wrote:
> (...)
> I have a DS10L 617mhz and I can't figure out which version is the best to
> attempt to install on it.?? I'd rather avoid things like this issue with
> systemd where they obviously haven't tried to actually test it on an alpha
> processor...
I don't believe the systemd issue I'm experiencing is unique to the alpha
architecture. Apologies if I left you with that impression. That being
said, I'm pretty sure most of the people reading this know how I feel
about "systemd", and I'll state here and now, for the record, that my
feelings are irrelevant at this point. That battle was lost a long time
ago, and the community is best served by trying to identify and fix the
legitimate bugs.
> The other question I have is whether or not someone has fixed the issue with
> fdisk on the system (...)
Check back in the relatively recent (no more than a year ago) archives for
this mailing list, but I believe we agreed that "fdisk" was not the correct
tool to use for setting up the disk partitions on Alpha. The criticism about
"fdisk" being mentioned in the installation documentation is legitimate, and
that should be fixed. However, since this is an Alpha-specific thing, and
Alpha is no longer a release architecture for Debian, the chances of getting
the documentation updated are tending more toward "not happening" these days
:-(.
If there's a "systemd" wonk tracking this conversation, the main issue
I'm seeing with the multiple persistent filesystems is that the
dependency service scripts for filesystems other than "/" and "/usr" are
dynamically generated at boot time based on what's defined in
"/etc/fstab". The other filesystems are being correctly discovered and
enumerated (based on the messages I see on the console), but for some
reason, "systemd" is unable to figure out how to choose and run the
appropriate "fsck" variant ("e2fsck" in my case), so the dependencies
(remaining filesystems) fail. Other than this recent crap with more
than one process trying to read input from the console at the same time,
the workaround for the remaining persistent filesystems is
straightforward: (1) when dropped into "emergency mode", enter the root
password; (2) run the appropriate filesystem checker for each of the
remaining persistent filesystems, and mount them; (3) exit "emergency
mode", and the system *should* finish coming up multi-user. I usually
do a few other things before exiting emergency mode, such as bring up my
primary network interface so I can run "ntpdate" and set the system
clock (on my PWS 433au, the hardware clock is *always* *way* off
following a reboot, and yes, the battery on the motherboard is good).
--Bob
Re: systemd woes continue
It's been a year or two since I last tried to install the experimental debian alpha image on my DS10L, and my abiding memory of the last attempt was banging my head against a problem with creating BSD disklabel on the ide hard drive due to fdisk being updated a few years prior to remove the older functionality of BSD disklabels and the instructions not having been updated since then, and the people I asked for help had simply been updating their systems instead of doing fresh installs. The BSD disklabel is required for SRM/IDE systems, and this system will dual boot from two separate drives alongside a functional VMS install. I did eventually get the disklabel written using an old version of fdisk through a process I've since forgotten. It's on hold for the moment as I tried to run a Gentoo install on the drive a few hours ago and it appears that the drive is dead, so I'll need to buy a new drive before I try again. On 7/11/2019 11:11 PM, John Paul Adrian Glaubitz wrote: Hi John! On 7/11/19 2:48 PM, John Blake wrote: I have a DS10L 617mhz and I can't figure out which version is the best to attempt to install on it. I'd rather avoid things like this issue with systemd where they obviously haven't tried to actually test it on an alpha processor, but I have no problem with recompiling things as necessary (although I would like to avoid the Gentoo path of recompiling everything). systemd works the same way on my Alpha XP-1000 as it works on my Intel boxes. I assume you are talking about the non-functionality of a separate /usr partition, but this is something that isn't guaranteed to work well on Linux, no matter whether one uses systemd or any other type of init daemon. The other question I have is whether or not someone has fixed the issue with fdisk on the system, because I remember the last time I tried to install linux on the system in question, it wouldn't format the drive with a BSD partition as was necessary and after some discussion on some mailing list or another it was discovered that the required functionality had been phased out of fdisk a few years before, and nobody had noticed on either side that it made it impossible to follow the given directions on the FAQ/wiki. It was still being automatically included with the distro and at the time I had to burn an ancient stable version just to put the partition table right in order to install. debian-installer doesn't use fdisk (anymore), it uses partman. Did you try any of the recent installation images, see [1]. Please note these images are currently shipped without proprietary firmware. Adrian [1] https://cdimage.debian.org/cdimage/ports/2019-07-07/
Re: systemd woes continue
Hi John! On 7/11/19 2:48 PM, John Blake wrote: > I have a DS10L 617mhz and I can't figure out which version is the best to > attempt to install on it. I'd rather avoid things like this issue with > systemd where they obviously haven't tried to actually test it on an alpha > processor, but I have no problem with recompiling things as necessary > (although I would like to avoid the Gentoo path of recompiling everything). systemd works the same way on my Alpha XP-1000 as it works on my Intel boxes. I assume you are talking about the non-functionality of a separate /usr partition, but this is something that isn't guaranteed to work well on Linux, no matter whether one uses systemd or any other type of init daemon. > The other question I have is whether or not someone has fixed the issue with > fdisk on the system, because I remember the last time I tried to install > linux on the system in question, it wouldn't format the drive with a BSD > partition as was necessary and after some discussion on some mailing list or > another it was discovered that the required functionality had been phased out > of fdisk a few years before, and nobody had noticed on either side that it > made it impossible to follow the given directions on the FAQ/wiki. It was > still being automatically included with the distro and at the time I had to > burn an ancient stable version just to put the partition table right in order > to install. debian-installer doesn't use fdisk (anymore), it uses partman. Did you try any of the recent installation images, see [1]. Please note these images are currently shipped without proprietary firmware. Adrian > [1] https://cdimage.debian.org/cdimage/ports/2019-07-07/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: systemd woes continue
This brings up a question I need to ask of the people who know best on this mailing list: I have a DS10L 617mhz and I can't figure out which version is the best to attempt to install on it. I'd rather avoid things like this issue with systemd where they obviously haven't tried to actually test it on an alpha processor, but I have no problem with recompiling things as necessary (although I would like to avoid the Gentoo path of recompiling everything). The other question I have is whether or not someone has fixed the issue with fdisk on the system, because I remember the last time I tried to install linux on the system in question, it wouldn't format the drive with a BSD partition as was necessary and after some discussion on some mailing list or another it was discovered that the required functionality had been phased out of fdisk a few years before, and nobody had noticed on either side that it made it impossible to follow the given directions on the FAQ/wiki. It was still being automatically included with the distro and at the time I had to burn an ancient stable version just to put the partition table right in order to install. On 7/11/2019 11:54 AM, Bob Tracy wrote: Greetings. It has been a while since I last checked in. Thought I'd let the rest of the Alpha community know I'm still around :-). I'm up and running on kernel version 5.2.0, built from the kernel.org source tree as is my usual pattern. The previous kernel running on my system was 5.1.0-rc7. Between then and today, something changed in user space that made the expected drop into systemd's "emergency mode" more painful than usual. First, "systemd" still cannot handle systems with persistent filesystems other than "/" and "/usr". As far as I know, the bug report I filed against "systemd" is still open, and no progress has been made on that front. The added complication when I rebooted the system today was multiple processes attempting to read input from the console at the same time. Both the old kernel and the new one behaved identically, which is why I'm assuming a problem with userspace. If you immediately type in the "root" password when prompted (without waiting for additional background init tasks to finish), things work normally up to the point where the console font gets loaded. Sometime after that, part of what you type goes to the command line, and the rest goes to ???. Tty echo is disabled, so you can't tell which input characters are going to the interactive shell, and which ones are going to ???. A workaround I discovered by accident is to keep typing "\n" until the "emergency mode" shell exits and "systemd" attempts to continue with normal startup. That fails, and "systemd" drops back into "emergency mode" again. However, only an interactive shell is listening at that point, so you can go about the usual cleanup tasks (run "fsck" on the remaining filesystems, mount them, bring up the primary network interface, etc.), and *then* type "" to continue with normal system startup. If you wait until *after* the console font gets loaded before trying to type the "root" password, the only way forward might be to try typing "\n" multiple times until "systemd" attempts to continue with normal startup, fails, and then drops you back into "emergency mode" again. I didn't try that. Typing "" works, at least, to restart the system and give you another crack at entering the "root" password immediately after the "emergency mode" prompt appears. No idea which startup process is competing with the "emergency mode" interactive shell for input from the console keyboard. --Bob
systemd woes continue
Greetings. It has been a while since I last checked in. Thought I'd let the rest of the Alpha community know I'm still around :-). I'm up and running on kernel version 5.2.0, built from the kernel.org source tree as is my usual pattern. The previous kernel running on my system was 5.1.0-rc7. Between then and today, something changed in user space that made the expected drop into systemd's "emergency mode" more painful than usual. First, "systemd" still cannot handle systems with persistent filesystems other than "/" and "/usr". As far as I know, the bug report I filed against "systemd" is still open, and no progress has been made on that front. The added complication when I rebooted the system today was multiple processes attempting to read input from the console at the same time. Both the old kernel and the new one behaved identically, which is why I'm assuming a problem with userspace. If you immediately type in the "root" password when prompted (without waiting for additional background init tasks to finish), things work normally up to the point where the console font gets loaded. Sometime after that, part of what you type goes to the command line, and the rest goes to ???. Tty echo is disabled, so you can't tell which input characters are going to the interactive shell, and which ones are going to ???. A workaround I discovered by accident is to keep typing "\n" until the "emergency mode" shell exits and "systemd" attempts to continue with normal startup. That fails, and "systemd" drops back into "emergency mode" again. However, only an interactive shell is listening at that point, so you can go about the usual cleanup tasks (run "fsck" on the remaining filesystems, mount them, bring up the primary network interface, etc.), and *then* type "" to continue with normal system startup. If you wait until *after* the console font gets loaded before trying to type the "root" password, the only way forward might be to try typing "\n" multiple times until "systemd" attempts to continue with normal startup, fails, and then drops you back into "emergency mode" again. I didn't try that. Typing "" works, at least, to restart the system and give you another crack at entering the "root" password immediately after the "emergency mode" prompt appears. No idea which startup process is competing with the "emergency mode" interactive shell for input from the console keyboard. --Bob
