Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file
On 23 August 2015 at 09:56, Cyril Brulebois k...@debian.org wrote: Hi, fsate...@debian.org fsate...@debian.org (2015-08-22): Package: keyboard-configuration Severity: important User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: init-rcs-service (maintonly considered slightly annoying.) Hi, Your package keyboard-configuration has an initscript that is enabled in runlevel S, but it does not provide a corresponding systemd service unit. Systemd generates units for all sysv init scripts that do not have a corresponding systemd unit. By default, it sets DefaultDependencies=yes, which means they get ordered after early boot has finished. The problem is that to preserve the runlevel S semantics, systemd in debian is currently[1] ordering all S services Before=sysinit.target. This target is particularly early in the boot sequence, which means that it is most of the time too strict. In turn, this means it is fairly easy to end up with dependency cycles. For an example, see bug [763315]. Do note that the cycle still exists with sysvinit, it is just that systemd complains more loudly. Please add a systemd unit for the given service with the appropriate dependencies, which most of the time will be less strict than Before=sysinit.target. In other cases, the script is simply not applicable in systemd, in which case the package should ship a symlink to /dev/null as /lib/systemd/system/initscript.service. We have prepared a transition wiki page[2] explaining the issue in more detail, and outlining some general guidance. Please refer to it as it will have useful information. If you have any other doubts, feel free to ask in pkg-systemd-maintain...@lists.alioth.debian.org (Talking more as d-i RM than possible comaintainer, which I'm not.) src:console-setup could probably do with more hands on it, especially given (very friendly) bug reports like #763695. If you guys had any time to spend on making sure boot time dependencies are correct, and possibly that boot time performances improve over time, that would be much appreciated. Does console-setup actually need to be run before user services are started? My guess is that it only needs to run before getty, but it should not block other services that want to start. If someone could answer that question it should be very simple to provide a patch for this. -- Saludos, Felipe Sateler
Bug#797095: amd64: netboot 2015-04-22, 2015-06-04, 2015-08-13 fail, wheezy succeeds
Package: debian-installer Version: 20150422+deb8u1 Severity: grave Justification: renders package unusable Dear Maintainer, summary --- amd64 netboot wheezy 2015-01-05 works amd64 netboot jessie 2015-04-22 fails amd64 netboot jessie 2015-06-04 fails amd64 netboot stretch 2015-08-13 fails details --- Have a 40-node cluster. Started With wheezy: Head node + 2 compute nodes up compute nodes installed via dhcp and tftp from wheezy netboot Upgraded head node and compute nodes, each separately, to jessie Trying to install another compute node via dhcp, tftp, and netboot (Using the same framework on head that worked for wheezy) using netboot 2015-08-13 - something creates a reboot loop syslog on head shows (start) syslog Aug 27 14:29:09 geodyncomp2 in.tftpd[26229]: RRQ from 10.2.81.13 filename pxelinux.0 Aug 27 14:29:09 geodyncomp2 in.tftpd[26229]: tftp: client does not accept options Aug 27 14:29:09 geodyncomp2 in.tftpd[26230]: RRQ from 10.2.81.13 filename pxelinux.0 Aug 27 14:30:51 geodyncomp2 dhcpd: DHCPDISCOVER from 00:30:48:f6:d4:6c via eth0 Aug 27 14:30:51 geodyncomp2 dhcpd: unexpected ICMP Echo Reply from 10.2.80.237 Aug 27 14:30:51 geodyncomp2 dhcpd: unexpected ICMP Echo Reply from 10.2.80.237 Aug 27 14:30:52 geodyncomp2 dhcpd: DHCPOFFER on 10.2.81.13 to 00:30:48:f6:d4:6c via eth0 Aug 27 14:30:59 geodyncomp2 dhcpd: DHCPREQUEST for 10.2.81.13 (10.2.81.1) from 00:30:48:f6:d4:6c via eth0 Aug 27 14:30:59 geodyncomp2 dhcpd: DHCPACK on 10.2.81.13 to 00:30:48:f6:d4:6c via eth0 ...the reset happens here...or the bios retries...or something Aug 27 14:30:59 geodyncomp2 in.tftpd[26691]: RRQ from 10.2.81.13 filename pxelinux.0 Aug 27 14:30:59 geodyncomp2 in.tftpd[26691]: tftp: client does not accept options Aug 27 14:30:59 geodyncomp2 in.tftpd[26692]: RRQ from 10.2.81.13 filename pxelinux.0 (end) syslog = netboot 2015-06-04 fails with different results (yes, I can provide details) netboot 2015-04-22 fails with different results (yes, I can provide details) netboot 2015-01-05, wheezy, works The version is reported as 20150422+deb8u1, which I believe is dated 2015-06-04. My system is jessie. Not knowing how to change sources.list to just get that one package from stretch, I downloaded the netboot images. -rw-r--r-- 1 cut 19368308 Aug 27 01:33 netboot_jessie_2015-04-22.tar.gz -rw-r--r-- 1 cut 38576779 Aug 27 09:28 netboot_jessie_2015-06-04_gtk.tar.gz -rw-r--r-- 1 cut 19370121 Aug 27 09:26 netboot_jessie_2015-06-04.tar.gz -rw-r--r-- 1 cut 21360976 Aug 27 14:21 netboot_stretch_2015-08-13.tar.gz -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information Thank you, Dogulas.
Bug#797095: PXE on hp server
HP ProLiant DL390 Gen 9, redscreen with testing/main/installer-amd64/20150813/images/netboot: debian-installer/amd64/pxelinux.0 If I replace ONLY pxelinux.0 with stable/main/installer-amd64/20150422+deb8u1/images/netboot: debian-installer/amd64/pxelinux.0 (but use all of the rest of testing) It works fine. BIOS: https://lh3.googleusercontent.com/-zt4mDD83nJk/Vd945RKzrZI/RJs/SnCmyVrbqYI/s640-Ic42/IMG_20150827_123703.jpg https://lh3.googleusercontent.com/-oZzD7rUIccQ/Vd945anGZKI/RJs/W2BPjXQnZug/s640-Ic42/IMG_20150827_123757.jpg Red screen: https://lh3.googleusercontent.com/-pMX9hP59Cgg/Vd945c2hsKI/RJs/NSCECD1-Nbw/s640-Ic42/IMG_20150827_123937.jpg
