Re: PWS 433au (Miata) recovery update
On Wed, Feb 6, 2019 at 12:04 AM Meelis Roos wrote: > > I share my experience of fresh install of and embedded SBC Alpha > (Eiger with EV6 500 MHz). > > Only an ancient Debian installer worked for me. The reason appeared to > be broken IRQ numbers for Eiger. > > So I used 2 disks. I first installed the ancient Debian on disk 1. > That worked. > > Next, I used that to bootstrap Gentoo on second disk, with ext3 as was > supported by Debian tooling. > > Then I debugged the new kernel and fixed the IRQ problem. Now I had a > recent kernel. I sent the patch https://lkml.org/lkml/2018/10/12/379 to > linux-alpha but it seems to have been ignored - PING! Sorry, not sure how I missed it. I'll include it in my pull request this weekend (with Maciej's R-b). Thanks!
Re: PWS 433au (Miata) recovery update
On Thu, 7 Feb 2019, Maciej W. Rozycki wrote: > Well, at this point I think it makes sense to just resend the patch. In > case that helps I may offer you my Reviewed-by tag as the change looks > obviously correct to me; `eiger_mv.nr_irqs' is 128 and we need to match it > here. FWIW, it's been always broken for the non-generic configuration, since the introduction of Eigler support back in ~2.3.32. Maciej
Re: PWS 433au (Miata) recovery update
On Wed, 6 Feb 2019, Meelis Roos wrote: > Then I debugged the new kernel and fixed the IRQ problem. Now I had a > recent kernel. I sent the patch https://lkml.org/lkml/2018/10/12/379 to > linux-alpha but it seems to have been ignored - PING! You may have previously been covered by CONFIG_ALPHA_LEGACY_START_ADDRESS I would guess. Well, at this point I think it makes sense to just resend the patch. In case that helps I may offer you my Reviewed-by tag as the change looks obviously correct to me; `eiger_mv.nr_irqs' is 128 and we need to match it here. Maciej
Re: PWS 433au (Miata) recovery update
I share my experience of fresh install of and embedded SBC Alpha (Eiger with EV6 500 MHz). Only an ancient Debian installer worked for me. The reason appeared to be broken IRQ numbers for Eiger. So I used 2 disks. I first installed the ancient Debian on disk 1. That worked. Next, I used that to bootstrap Gentoo on second disk, with ext3 as was supported by Debian tooling. Then I debugged the new kernel and fixed the IRQ problem. Now I had a recent kernel. I sent the patch https://lkml.org/lkml/2018/10/12/379 to linux-alpha but it seems to have been ignored - PING! Next I emerged the newest filesystem tools (e2fsutils) to support latest ext4 features and bootstrapped next Gentoo installation from second disk to the first disk, with ext4 and the newest kernel. The resulting Gentoo with Eiger and patched kernel is working fine - I have to carry the kernel patch around until gets applied upstream. Even btrfs seems to work on alpha - I have a btrfs volume with 5x4.5G disks :) -- Meelis Roos
Re: PWS 433au (Miata) recovery update
On Fri, Jan 18, 2019 at 12:19:52AM +, Maciej W. Rozycki wrote: > (much useful information set in the appropriate historical context) Thank you for your thoughts. The earlier reported problem with "/lib/systemd/systemd-udevd" evidently requiring AF_UNIX socket support to be built-in rather than modular has been confirmed. Setting "CONFIG_UNIX=y" in the kernel configuration was enough to get me past that particular problem I was seeing with the initial ramdisk. So, per advice I was given a long time ago, *do* examine the "systemd" README file under "/usr/share/doc": many kernel configuration requirements are mentioned there. As far as gleaning the additional udev-related info, one *might* infer it from the error messages produced by the executable, *or* one can examine the udev- related files under "/lib/systemd/system", one of which explicitly mentions AF_UNIX in the context of a restricted address family. I also note that the current "initramfs-tools" have evidently forgotten how to automatically check and mount local file systems *other* than "/" and "/usr". Every boot since restoring my PWS thus far has dropped me into emergency mode with everything mounted read-write and ready to go (including swap) *other* than the local non-tmpfs file systems. Manually running the appropriate flavor of "fsck" and mounting the file systems before exiting emergency mode results in the expected normal startup of multi-user system services. "journalctl -xb" has, for the case of one such file system that didn't get checked/mounted, the following messages: (...) -- The job identifier is 271 and the job result is done. Dec 21 13:02:10 smirkin systemd[1]: Starting of /dev/sda2 not supported. -- Subject: A start job for unit dev-sda2.device has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit dev-sda2.device has finished with a failure. -- -- The job identifier is 307 and the job result is unsupported. Dec 21 13:02:10 smirkin systemd[1]: Dependency failed for File System Check on /dev/sda2. -- Subject: A start job for unit systemd-fsck@dev-sda2.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit systemd-fsck@dev-sda2.service has finished with a failure. -- -- The job identifier is 306 and the job result is dependency. Dec 21 13:02:10 smirkin systemd[1]: Dependency failed for /boot. -- Subject: A start job for unit boot.mount has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit boot.mount has finished with a failure. (...) My guess is, device naming conventions have, once again, changed as far as what the systemd service descriptions/templates expect. Anyone have any idea how and/or where to fix this most efficiently? --Bob
Re: PWS 433au (Miata) recovery update
On Wed, 16 Jan 2019, Bob Tracy wrote: > Odd thing about the disk partitioning scheme. The disk label definitely > has to be "bsd" for SRM to be happy, but if Linux is the only OS on the > disk, all the rest of the BSD partitioning conventions don't have to be > observed as far as slice "c" spanning the entire disk, slice "a" being > the "boot" slice, slice "b" being "swap", and so forth. I doubt dual- > booting with Digital UNIX or one of the *BSD variants is a practical > possibility for most people, particularly those with PWS systems having > limited disk space. SRM doesn't actually care about or know the disk partitioning scheme, however it does require a signature and a pointer to the location of the boot loader (with `aboot' being the usual choice for Linux) in the first physical sector, and these structures happen to clash with the location of the IBM PC's DOS-style partition table. As you observe the partitions for Linux use can be arbitrary. I used to install `aboot' outside any partition by just leaving a number of sectors at the beginning of the disk unassigned; `aboot' takes some 80KiB only. This is analogous to disks using a DOS-style partition table where you'd often leave the whole (simulated) first track of first cylinder unassigned for boot loader use. This saves a partition table entry for a data area that can hardly be used through the corresponding block device anyway. NB be aware if you ever boot Windows NT on an Alpha machine that has an SRM signature on some disks, then the first sector of these disks will get corrupted under NT's assumption that these disks have no data and need to have a DOS-style partition table installed in the first sector. Any OSF/1 disk label will be retained, however the SRM signature will be lost making such disks unbootable and will have to be restored to make them bootable again. Also the presence of the DOS-style partition table marker may confuse the Linux kernel if support for such partition tables has been compiled in in the addition to support for OSF/1 disk labels. > A brief note about partitioning programs: "fdisk" is NOT your friend > on the Alpha, especially in "modern" times. Use "parted" and save > yourself much frustration. I had a look at the GIT history of `util-linux' and it looks like in the conversion of the tool to use `libfdisk', also included with `util-linux', support has been lost, which I find rather unfortunate. It should be pretty straightforward to resurrect with the aid of old code, however it was never particularly clean (as has not been what still remains in `fdisk') due to the use of `#ifdef __alpha__' to select the label type, meaning you could not work with a disk intended for an Alpha system using fdisk compiled for a different host architecture. It looks to me like the current framework would make it easier to avoid this #ifdef hack, but obviously any remains would have to be cleaned up. There used to be a tool called `minlabel' too that you could use to partition your Alpha disk, but it was rather crude. > (1) "systemd" (and "udevd" by extension) don't play well with "/usr" > being on a separate partition from "/". If I have *any* advice to offer > both the battle-scarred veteran and the newbie, it would be to consider > consolidating those two partitions into a single partition. Me? I'd > prefer the younger generation of system programmers consider the > perfectly valid reasons why those filesystems might have been separate > to begin with, and respect those reasons. (Hint: much smaller disks.) In the old days it used to be a common practice to have /usr NFS-mounted in some installations, often where NIS was also used; perhaps it is not anymore. FWIW, Maciej
Re: PWS 433au (Miata) recovery update
On Wed, Jan 16, 2019 at 01:10:14AM -0600, Bob Tracy wrote: > (initramfs / systemd / udevd issue) I think I may have this one painted into a corner... CONFIG_UNIX (at least) needs to be "y" instead of "m". This is a relatively new dependency. For userland applications used in the boot process to have such dependencies on kernel configuration options is "unfortunate" to put it mildly. --Bob
