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