On 06/04/2016 07:03 AM, Finn Thain wrote: > Yes, systemd is very slow to boot on this system, so timeouts are likely > to be the problem.
The timeouts are related to dbus, not to systemd. I also do not think that sysvinit would actually be faster. sysvinit runs shell code for boilerplate stuff while systemd does that with built-in C code and I don't think we disagree here that bash code with lots of forking is always slower than compiled C code. I have, in fact, used systemd on several Amigas and it was faster than sysvinit, even on my old trusty A1200 with 68030/50 CPU and 64 MiB. If I remember correctly, I was also using systemd on my Centris 650 but I cannot say for sure, the machine is in the basement at the moment. The timeout issue is simply related to dbus messages being sent and received and systemctl sends dbus messages to invoke actions in the service manager (=systemd). Since systemd takes longer on old hardware than on a current x86_64 machine, you sometimes see timeouts. The action is normally performed without any problems anyway. > Immediately after booting it and logging in at ttyS0, I > see that PID 1 has already consumed over 2 CPU minutes (for comparison, ps > consumed 2 CPU seconds). Well, that's because the whole startup is now aggregated in one process. For a fair comparison, you would actually have to sum over all the instances of bash, sed, grep, awk and whatnot that sysvinit is starting in to order to be able to boot the machine. I'm pretty sure those will add up to more than two minutes of CPU time. >> How did you try to fetch it? > > > root@pacman:~# wget > http://ftp.ports.debian.org/debian-ports/pool-m68k/main/n/ntp/ntpdate_4.2.8p7+dfsg-4_m68k.deb > converted > 'http://ftp.ports.debian.org/debian-ports/pool-m68k/main/n/ntp/ntpdate_4.2.8p7+dfsg-4_m68k.deb' > (ANSI_X3.4-1968) -> > 'http://ftp.ports.debian.org/debian-ports/pool-m68k/main/n/ntp/ntpdate_4.2.8p7+dfsg-4_m68k.deb' > (UTF-8) > --1970-01-01 04:45:18-- > http://ftp.ports.debian.org/debian-ports/pool-m68k/main/n/ntp/ntpdate_4.2.8p7+dfsg-4_m68k.deb > Resolving ftp.ports.debian.org (ftp.ports.debian.org)... 130.89.148.14, > 149.20.20.22, 2001:610:1908:b000::148:14, ... > Connecting to ftp.ports.debian.org > (ftp.ports.debian.org)|130.89.148.14|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 63850 (62K) [application/x-debian-package] > Saving to: 'ntpdate_4.2.8p7+dfsg-4_m68k.deb.1' > > ntpdate_4.2.8p7+dfs 0%[ ] 0 --.-KB/s in 0s > > > 1970-01-01 04:45:24 (0.00 B/s) - Read error at byte 0/63850 (Invalid > argument). Retrying. > > --1970-01-01 04:45:25-- (try: 2) > http://ftp.ports.debian.org/debian-ports/pool-m68k/main/n/ntp/ntpdate_4.2.8p7+dfsg-4_m68k.deb > Connecting to ftp.ports.debian.org > (ftp.ports.debian.org)|130.89.148.14|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 63850 (62K) [application/x-debian-package] > Saving to: 'ntpdate_4.2.8p7+dfsg-4_m68k.deb.1' > > ntpdate_4.2.8p7+dfs 0%[ ] 0 --.-KB/s in 0s > > > 1970-01-01 04:45:26 (0.00 B/s) - Read error at byte 0/63850 (Invalid > argument). Retrying. Hmm, that's very odd. I haven't seen similar issues on my m68k machines. Is there a way to verify that the kernel itself works as expected? > The same wget command works fine on my Linux/x86 laptop (which is also > running a custom kernel but is not running Debian unstable). Is kernel > support for IPv6 madatory in Debian unstable? No, that should not be necessary. >>> Adrian, if you debootstrap and publish a more up-to-date root >>> filesystem, I suggest that /etc/resolv.conf and /etc/apt/sources.list >>> should use Google DNS and ftp.ports.debian.org respectively. >> >> Yeah, will do that later today. Was planning to do that anyway. > > Thanks. Perhaps the new debootstrap will fix the wget error. I haven't got around doing that yet. I am currently at my parent's house and the internet broke down after a thunderstorm. I was just able to fix the wiring and now the internet is working here again. If I don't manage to take care of creating a new chroot, you can actually do it yourself very easily, with the help of qemu: > https://wiki.debian.org/M68k/sbuildQEMU Just omit all the sbuild parts, i.e. just run debootstrap with --foreign and --arch=m68k, then copy qemu-m68k-static into the chroot and run the following command after changing into the chroot: # ./debootstrap/deboostrap If you don't want to compile qemu-m68k yourself, you can grab a pre-compiled static binary from my Debian websspace: > https://people.debian.org/~glaubitz/qemu-m68k-static > I would also like to try the Debian kernel at > http://ftp.de.debian.org/debian-ports/pool-m68k/main/l/linux/linux-image-4.5.0-2-m68k_4.5.5-1_m68k.deb > > but it is not possible to boot a Debian kernel without an initrd > containing all the kernel modules. But apt-get is not working for me... > > root@pacman:~# apt-get install linux-image-m68k > Reading package lists... 65% > Segmentation fault That looks like a hardware problem. I haven't seen any particular issues with segmentation faults on m68k unless there was a problem with the hardware. >> Any wishes for additional, pre-installed packages? > > Would it help to pre-install linux-image-m68k? That is, would it cause a > usable initrd to be generated? Otherwise perhaps I could generate that for > myself after I boot a custom kernel. I can try to do that. But I cannot tell you whether it will work. > ntpdate is always useful for old machines that may have no clock battery > (as old batteries tend to leak acid) or have no RTC support in the kernel, > which is the case for certain Mac models. I have actually made much better experiences with systemd-timesyncd which I have replaced ntpdate with on my buildds. Works much more reliably and was very easy to set up (the Arch Wiki has all the details): root@tirpitz:~> systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: active (running) since Wed 2016-04-27 18:09:43 CEST; 1 months 7 days ago Docs: man:systemd-timesyncd.service(8) Main PID: 920 (systemd-timesyn) Status: "Synchronized to time server 130.133.1.10:123 (time.fu-berlin.de)." CGroup: /system.slice/systemd-timesyncd.service └─920 /lib/systemd/systemd-timesyncd (...) The same applies to systemd-networkd/systemd-resolved which helped me resolve all the network problems I had on the buildds at home. Really worth a try for headless machines. It doesn't have as many features as network-manager, but it gets the minimal job done to set up networking. > In general I would choose lightweight package alternatives (sysvinit, ucb > vi, busybox etc.) but that isn't going to suit most d.p.o users, as the > relevant hardware is usually more powerful than this Mac LC III, with 20 > MB RAM and a 25 MHz 68030. Well, I wouldn't say that sysvinit is lightweight as compared to systemd for the aforementioned reasons but I can try to make a systemd-less chroot non-the-less. > BTW, I see that the Debian kernel config sets CONFIG_MAC_SCSI=y. As of > v3.19 you can make that driver modular and save memory on systems that > don't need it like Atari, Amiga and 68040 Macs. Similarly, > CONFIG_MAC8390=y can be made modular as of v4.4. Good to know. Could you maybe file a bug report against src:linux in the Debian bug tracker? Ben Hutchings will happily incorporate the change, he is Debian's main kernel maintainer. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - [email protected] `. `' Freie Universitaet Berlin - [email protected] `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
