Bug#502618: Same thing here, too -- some more details incl. preseed file
Hi, we ran into this problem, too, with preseeded Lenny installations -- but it happens not always respectively not on all hardware. We do automatic installations via preseeding with this preseed file: http://debian.ethz.ch/d-i/p.server While we installed an 32 bit machine that way without hassles on Friday, we have this problem on at least two 64 bit machines with the amd64 and the i386 installer, but only since about mid of last week. Worked fine about two weeks ago on three different amd64 machines including one of those where it doesn't work anymore since Thursday last week or so. There was at least one time on Friday where it didn't work on one of the 64 bit machines while it worked afterwards on the 32 bit machine. Currently we use the netboot image snapshots from 17th of September on our PXE boot server. Kind regards, Axel Beckert -- Axel Beckert [EMAIL PROTECTED] support: +41 44 633 2668 IT Support Group, HPT D17 (new address!) voice: +41 44 633 4189 Departement Physik, ETH Zurichfax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: #502618: No change with scratching the disk before installing
Hi, just wanna inform that now also our formerly working 32 bit machine has that problem permanently, even after scratching the whole disk with dd if=/dev/zero of=/dev/sda over night before. (We formerly suspected the previous existence of an LVM on the disk caused that behaviour.) The strange thing stays that this and other machines installed fine before and that the bug occurred on some machines earlier (Friday) and others later (Monday afternoon while it worked Monday morning). So now _all_ of our to-be-installed systems show this behaviour, independently of hardware or installation architecture, independently of the previous disk content. Which is kind of bad, because to workaround this bug now means that we have to go back to manual installation. :-( We also looked through all changed udebs the last two weeks on our mirror (ftp.ch.debian.org) and checked packages.q.d.o as well as their changelog, but none of the changes pointed into this direction. Probably the only relevant package which changed at all during the last weeks is partman-base (changed in Lenny as well as in Sid). HTH. Kind regards, Axel Beckert -- Axel Beckert [EMAIL PROTECTED] support: +41 44 633 2668 IT Support Group, HPT D17 (new address!) voice: +41 44 633 4189 Departement Physik, ETH Zurichfax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502913: #502913: probably same as #502618 and #502432
Hi, this bug is very likely the same bug as #502618 and #502432. Kind regards, Axel Beckert -- Axel Beckert [EMAIL PROTECTED] support: +41 44 633 2668 IT Support Group, HPT D17 (new address!) voice: +41 44 633 4189 Departement Physik, ETH Zurichfax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
Hi, On Tue, Oct 21, 2008 at 06:16:46PM +0200, Frans Pop wrote: The cause looks to be a recent change by Colin Watson in partman-base (128). If I rebuild parted_server without that change, I can no longer reproduce the error. Interesting. We at least had a few successful installations where version 128 was used according to the mirror's access logs, especially on those machines where it failed only on later (re)installations. So I expected the bug to be not in there. But the time when the change happened really suggests that this causes the problems. I just made a manual installation and unpacked (but not configured) partman-base_127_amd64.udeb in the right moment and it worked again without problems. So I can confirm that the changes between 127 and 128 of partman-base at least introduced this regression. P.S.: #502913 (debian-installer: mkfs.ext3 fails with raid10+dmcrypt+lvm) seems to be the same bug. Kind regards, Axel Beckert -- Axel Beckert [EMAIL PROTECTED] support: +41 44 633 2668 IT Support Group, HPT D17 (new address!) voice: +41 44 633 4189 Departement Physik, ETH Zurichfax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502913: #502913: Patch works fine here, too
Hi. Colin's patch works here like a charm and we're happy to be able to do automatic installations again. I injected the patched package into our automatic installation via preseed/early_command: d-i preseed/early_command stringif [ `uname -m` = x86_64 ]; then arch=amd64; else arch=i386; fi; wget http://debian.ethz.ch/d-i/libparted1.8-udeb_1.8.8.git.2008.03.24-10.1~fix502618_$arch.udeb; udpkg --unpack libparted1.8-udeb_1.8.8.git.2008.03.24-10.1~fix502618_$arch.udeb Tested it with our fully automatic (preseeding from http://debian.ethz.ch/d-i/p.server) installation on amd64 as well as i386 (both on the same machine though). Kind regards, Axel Beckert -- Axel Beckert [EMAIL PROTECTED] support: +41 44 633 2668 IT Support Group, HPT D17 (new address!) voice: +41 44 633 4189 Departement Physik, ETH Zurichfax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: #502618: Patch works fine here, too
Hi. (Sorry for the double post, first mail went to a duplicate of this bug with a similar bug number, #502913.) Colin's patch works here like a charm and we're happy to be able to do automatic installations again. I injected the patched package into our automatic installation via preseed/early_command: d-i preseed/early_command stringif [ `uname -m` = x86_64 ]; then arch=amd64; else arch=i386; fi; wget http://debian.ethz.ch/d-i/libparted1.8-udeb_1.8.8.git.2008.03.24-10.1~fix502618_$arch.udeb; udpkg --unpack libparted1.8-udeb_1.8.8.git.2008.03.24-10.1~fix502618_$arch.udeb Tested it with our fully automatic (preseeding from http://debian.ethz.ch/d-i/p.server) installation on amd64 as well as i386 (both on the same machine though). Kind regards, Axel Beckert -- Axel Beckert [EMAIL PROTECTED] support: +41 44 633 2668 IT Support Group, HPT D17 (new address!) voice: +41 44 633 4189 Departement Physik, ETH Zurichfax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504655: debian-installer: Kernel panic when velocity driver started
Package: debian-installer Severity: important Version: 20081105 Tried to install Debian Lenny on a VIA EPIA SN (VIA C7, i386 arch) board today. This one has a VIA Rhine II (VT6102) and a VIA Velocity (VT6120/VT6121/VT6122) NIC. When detecting the network cards, the kernel panics. In the log I saw that the panic happened while ip was running. The panic hasn't happened with an old, 2.6.24 based Lenny installer I tried first (but didn't seem to have LVM support). http://bugzilla.kernel.org/show_bug.cgi?id=11121 seems to be exactly the problem I have. Looks like the problem has been introduced with 2.6.26, so it's really a regression. Tried the Installer from 29. Oct. 2008 (AFAIK RC1) as well as the daily snapshot from today (5. Nov. 2008). Workaround is to add pci=noacpi at the boot prompt as reported in the comments to the above mentioned kernel bug report. Regards, Axel -- Axel Beckert - [EMAIL PROTECTED] - http://noone.org/abe/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505897: busybox: syslogd option -D mentioned in man page not available in binary
Package: busybox Version: 1:1.10.2-2 Severity: minor From the man page: ---snip--- syslogd syslogd[OPTION]... System logging utility. Note that this version of syslogd ignores /etc/syslog.conf. Options: -n Run in foreground -O FILE Log to given file (default=/var/log/messages) -l nSet local log level -S Smaller logging output -s SIZE Max size (KB) before rotate (default=200KB, 0=off) -b NUM Number of rotated logs to keep (default=1, max=99, 0=purge) -R HOST[:PORT] Log to IP or hostname on PORT (default PORT=514/UDP) -L Log locally and via network (default is network only if -R) -D Drop duplicates -C[size(KiB)] Log to shared mem buffer (read it using logread)/* NB: -Csize shouldn't have space (because size is optional) */ ---snap--- On the command line: 20/0/0 [EMAIL PROTECTED]:pts/1 18:00:25 [~] # /sbin/syslogd -n -D -C128 /sbin/syslogd: invalid option -- D BusyBox v1.10.2 (Debian 1:1.10.2-2) multi-call binary Usage: syslogd [OPTION]... System logging utility. Note that this version of syslogd ignores /etc/syslog.conf. Options: -n Run in foreground -O FILE Log to given file (default=/var/log/messages) -l nSet local log level -S Smaller logging output -R HOST[:PORT] Log to IP or hostname on PORT (default PORT=514/UDP) -L Log locally and via network (default is network only if -R) -C[size(KiB)] Log to shared mem buffer (read it using logread) 21/1/0 [EMAIL PROTECTED]:pts/1 18:00:30 [/home/abe/debian] # Either this function has been removed upstream and therefore should be removed from the man page, or it has not been compiled into the Debian version of busybox -- in which case it either should be removed from the man page or compiled in. There are also further options mentioned in the man page but not in the help output of busybox as shown above. They're probably also not available in the binary. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (600, 'unstable'), (400, 'stable'), (110, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages busybox depends on: ii libc6 2.7-15 GNU C Library: Shared libraries busybox recommends no packages. busybox suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#517231: libc6-udeb: busybox' wget segfaults in libresolv-2.9.so during d-i
Hi, On Thu, Feb 26, 2009 at 06:47:28PM +0100, Aurelien Jarno wrote: Started up a netboot unstable installer by accident and directly after Could you point me to the image you used? Initially I used the Lenny installer from September 2008 (was the one on the disk and worked fine until now). I then changed to the official Debian 5.0 stable installer. Used the netboot image from http://ftp.ch.debian.org/debian/dists/Debian5.0/main/installer-i386/current/images/netboot/netboot.tar.gz But forgot the sync the new image to our second DHCP/TFTP server. And the machine seemed to have always booted from there. So that's why d-i mirror/suiteselect stable d-i mirror/codename string lenny in the preseeding file got ignored initially (while the normal non-preseeded installation worked anyway) and brought this d-i/libc6 issue to the daylight. - the installer you used is glibc 2.7 based, and a copy of glibc 2.9 is extracted over it without any check. As we already found out in IRC, that's what happens. On Thu, Feb 26, 2009 at 07:55:23PM +0100, Aurelien Jarno wrote: The problem appears when the image has been built using libc6-udeb version 2.7 and a libc6-udeb 2.9 is downloaded and unpacked. The new glibc is not fully usable until other glibc udeb packages, namely libnss-dns-udeb and libnss-files-udeb are unpacked. The segfault is caused here by using libc6 2.9 with a libnss-dns version 2.7. Thanks for debugging and the explanation! Kind regards, Axel Beckert -- Axel Beckert beck...@phys.ethz.ch support: +41 44 633 26 68 IT Services Group, HPT D 17 voice: +41 44 633 41 89 Departement of Physics, ETH Zurich CH-8093 Zurich, Switzerlandhttp://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517935: debian-installer: partman-auto/expert_recipe minimum size sanity check counts both LVM VG and LV
Package: debian-installer
Severity: normal
Version: 20090123
While preparing the presseding file for our fully automated Lenny
workstation installation I ran into the following bug:
The following recipe works fine on a 80026 MB:
d-i partman-auto/expert_recipe string \
dphys-ws-part ::\
256 1000 512 ext3 \
$primary{ } $bootable{ }\
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ /boot } \
. \
61440 100 1 lvm \
$primary{ } $defaultignore{ } \
method{ lvm } vg_name{ vg0 }\
. \
15248 4 46080 ext3 \
$lvmok{ } in_vg{ vg0 } lv_name{ root } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ / } \
. \
2048 1 10240 ext3 \
$lvmok{ } in_vg{ vg0 } lv_name{ data } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ /export/data1 } \
. \
1024 2000 10240 ext3\
$lvmok{ } in_vg{ vg0 } lv_name{ scr } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ /scratch } \
. \
10 1000 1048576 ext3\
$lvmok{ } in_vg{ vg0 } lv_name{ dummy } \
method{ keep } \
.
And the following does not and the default recipe (root + swap) is
used instead:
d-i partman-auto/expert_recipe string \
dphys-ws-part ::\
256 1000 512 ext3 \
$primary{ } $bootable{ }\
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ /boot } \
. \
61440 100 1 lvm \
$primary{ } $defaultignore{ } \
method{ lvm } vg_name{ vg0 }\
. \
15249 4 46080 ext3 \
$lvmok{ } in_vg{ vg0 } lv_name{ root } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ / } \
. \
2048 1 10240 ext3 \
$lvmok{ } in_vg{ vg0 } lv_name{ data } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ /export/data1 } \
. \
1024 2000 10240 ext3\
$lvmok{ } in_vg{ vg0 } lv_name{ scr } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ /scratch } \
. \
10 1000 1048576 ext3\
$lvmok{ } in_vg{ vg0 } lv_name{ dummy } \
method{ keep } \
.
The only difference: The minimal / LV size grew from 15248 to 15249.
You can easily check that minimum boot partition size plus minimal VG
size fit onto the disk without problems and that all the remaining
partitions fit into the VG with their minimal size.
But the installer seems to sum up all minimal
Bug#646984: busybox-syslogd: Regression in 1.19.2: Line breaks, date, hostname, type and severity missing in logread output
Package: busybox-syslogd Version: 1:1.19.2-1 Version: 1:1.19.2-3 Severity: grave Justification: Makes package (nearly) unusable Hi, since 1:1.19.2-1, line breaks, date, hostname, log entry type and severity are missing in logread's output. It should look like this (missing parts manually added, partially with dummy values) and did so before until and including 1:1.18.5-1: Oct 29 01:25:35 nemo something.severity postfix/master[26877]: reload -- version 2.8.5, configuration /etc/postfix Oct 29 01:25:35 nemo something.severity dhclient: Internet Systems Consortium DHCP Client 4.2.2 Oct 29 01:25:35 nemo something.severity dhclient: Copyright 2004-2011 Internet Systems Consortium. Oct 29 01:25:35 nemo something.severity dhclient: All rights reserved. Oct 29 01:25:35 nemo something.severity dhclient: For info, please visit https://www.isc.org/software/dhcp/ Oct 29 01:25:35 nemo something.severity dhclient: Oct 29 01:25:35 nemo something.severity dhclient: Listening on LPF/ath0/00:15:af:88:97:8d Oct 29 01:25:35 nemo something.severity dhclient: Sending on LPF/ath0/00:15:af:88:97:8d Oct 29 01:25:35 nemo something.severity dhclient: Sending on Socket/fallback Oct 29 01:25:37 nemo something.severity miredo[26713]: No reply from Teredo server Oct 29 01:25:37 nemo something.severity miredo[26713]: Lost Teredo connectivity Oct 29 01:25:37 nemo something.severity miredo[26713]: Teredo pseudo-tunnel stopped Oct 29 01:25:39 nemo something.severity dhclient: DHCPRELEASE on ath0 to 192.168.1.1 port 67 Oct 29 01:25:39 nemo something.severity dhclient: send_packet: Network is unreachable Oct 29 01:25:39 nemo something.severity dhclient: send_packet: please consult README file regarding broadcast address. Oct 29 01:25:40 nemo something.severity kernel: [659969.975145] ADDRCONF(NETDEV_UP): ath0: link is not ready Oct 29 01:25:41 nemo something.severity postfix/master[26877]: reload -- version 2.8.5, configuration /etc/postfix Oct 29 01:25:42 nemo something.severity dhclient: Internet Systems Consortium DHCP Client 4.2.2 Oct 29 01:25:42 nemo something.severity dhclient: Copyright 2004-2011 Internet Systems Consortium. Oct 29 01:25:42 nemo something.severity dhclient: All rights reserved. Oct 29 01:25:42 nemo something.severity dhclient: For info, please visit https://www.isc.org/software/dhcp/ Oct 29 01:25:42 nemo something.severity dhclient: Oct 29 01:25:42 nemo something.severity dhclient: Listening on LPF/eth0/00:1f:c6:58:c9:66 Oct 29 01:25:42 nemo something.severity dhclient: Sending on LPF/eth0/00:1f:c6:58:c9:66 Oct 29 01:25:42 nemo something.severity dhclient: Sending on Socket/fallback Oct 29 01:25:42 nemo something.severity dhclient: DHCPRELEASE on eth0 to 192.33.103.254 port 67 Oct 29 01:25:42 nemo something.severity dhclient: send_packet: Network is unreachable Oct 29 01:25:42 nemo something.severity dhclient: send_packet: please consult README file regarding broadcast address. Oct 29 01:25:45 nemo something.severity kernel: [659970.834403] atl2 :03:00.0: irq 44 for MSI/MSI-X Oct 29 01:25:45 nemo something.severity kernel: [659970.835264] ADDRCONF(NETDEV_UP): eth0: link is not ready Oct 29 01:25:45 nemo something.severity dhclient: Internet Systems Consortium DHCP Client 4.2.2 Oct 29 01:25:45 nemo something.severity dhclient: Copyright 2004-2011 Internet Systems Consortium. Oct 29 01:25:45 nemo something.severity dhclient: All rights reserved. Oct 29 01:25:45 nemo something.severity dhclient: For info, please visit https://www.isc.org/software/dhcp/ Oct 29 01:25:45 nemo something.severity dhclient: Oct 29 01:25:45 nemo something.severity dhclient: Listening on LPF/ath0/00:15:af:88:97:8d Oct 29 01:25:45 nemo something.severity dhclient: Sending on LPF/ath0/00:15:af:88:97:8d Oct 29 01:25:45 nemo something.severity dhclient: Sending on Socket/fallback Oct 29 01:25:45 nemo something.severity dhclient: DHCPRELEASE on ath0 to 192.168.1.1 port 67 Oct 29 01:25:45 nemo something.severity dhclient: send_packet: Network is unreachable Real-life example with 1:1.18.5-1: Oct 29 01:25:35 nemo syslog.info syslogd started: BusyBox v1.18.5 Oct 29 01:25:35 nemo user.notice kernel: klogd started: BusyBox v1.18.5 (Debian 1:1.18.5-1) Oct 29 01:35:01 nemo authpriv.info /usr/sbin/crond[9261]: pam_unix(cronie:session): session opened for user root by (uid=0) Oct 29 01:35:01 nemo cron.info /USR/SBIN/CROND[9262]: (root) CMD (command -v debian-sa1 /dev/null debian-sa1 1 1) Oct 29 01:35:01 nemo authpriv.info /USR/SBIN/CROND[9261]: pam_unix(cronie:session): session closed for user root But since version 1:1.19.2-1, it looks like this: postfix/master[26877]: reload -- version 2.8.5, configuration /etc/postfixdhclient: Internet Systems Consortium DHCP Client 4.2.2dhclient: Copyright 2004-2011 Internet Systems Consortium.dhclient: All rights reserved.dhclient: For info, please visit https://www.isc.org/software/dhcp/dhclient: dhclient: Listening on
Bug#649747: 127.0.1.1 hack is not supported by kFreeBSD
Hi Robert, Robert Millan wrote: (it remains to be found whether it's true on Hurd pfinet, anyone can find out by running ping 127.0.1.1?) Seems as if it works: strauss:~# ping 127.0.1.1 PING 127.0.1.1 (127.0.1.1): 56 data bytes 64 bytes from 127.0.1.1: icmp_seq=0 ttl=255 time=10.053 ms 64 bytes from 127.0.1.1: icmp_seq=1 ttl=255 time=0.000 ms 64 bytes from 127.0.1.1: icmp_seq=2 ttl=255 time=0.000 ms ^C--- 127.0.1.1 ping statistics --- 4 packets transmitted, 3 packets received, 25% packet loss round-trip min/avg/max/stddev = 0.000/3.351/10.053/4.739 ms strauss:~# (Had to install inetutils-ping first as iputils-ping is not available on Hurd.) Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2023184736.gf2...@sym.noone.org
Bug#756841: tasksel: --task-desc no more works
Package: tasksel
Version: 3.20
Severity: important
Dear Tasksel Maintainers,
acording to the man page, tasksel --task-desc $task should give a
description of a task. But all I get is an empty blank line per task:
abe@c-cactus:~$ tasksel --list-tasks
u desktop Debian desktop environment
u web-serverweb server
u print-server print server
u database-server SQL database
u dns-serverDNS Server
u file-server file server
u mail-server mail server
i ssh-serverSSH server
i laptoplaptop
abe@c-cactus:~$ tasksel --task-desc ssh-server
abe@c-cactus:~$ tasksel --task-desc mail-server
abe@c-cactus:~$ tasksel --list-tasks | awk '{print $2}' | xargs -n1 tasksel
--task-desc
abe@c-cactus:~$ echo $LANG
C.UTF-8
abe@c-cactus:~$
I've seen screenshots where this worked in the past. I though don't know
if they are from Debian Wheezy or Squeeze.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (110, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.15-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tasksel depends on:
ii apt 1.1~exp2
ii debconf [debconf-2.0] 1.5.53
ii liblocale-gettext-perl 1.05-8
ii perl-base 5.18.2-7
ii tasksel-data3.20
tasksel recommends no packages.
tasksel suggests no packages.
-- debconf information:
tasksel/tasks:
tasksel/title:
tasksel/desktop: xfce
tasksel/first: ssh-server, laptop
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4v75aw1@c-cactus.deuxchevaux.org
Bug#756841: tasksel: --task-desc no more works
Control: found -1 3.14.1 Hi, Cyril Brulebois wrote: I've seen screenshots where this worked in the past. I though don't know if they are from Debian Wheezy or Squeeze. FWIW: Building 3.14.1 (wheezy's version) in a sid chroot, or testing tasksel in a wheezy chroot doesn't seem to get any better results. In the meanwhile I was able to reproduce the issue on an existing Wheezy installation, too. So the mentioned screenshots were likely from Squeeze. Marking as found in Wheezy. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140802134118.gm6...@sym.noone.org
Bug#756841: tasksel: --task-desc no more works
Hi again, Cyril Brulebois wrote: Axel Beckert a...@debian.org (2014-08-02): In the meanwhile I was able to reproduce the issue on an existing Wheezy installation, too. So the mentioned screenshots were likely from Squeeze. Marking as found in Wheezy. The screenshots I know about seem to be from a Wheezy machine. Here's one of them: $ tasksel --task-desc ssh-server Project-Id-Version: tasksel-tasks Report-Msgid-Bugs-To: POT-Creation-Date: 2012-06-09 08:27+ PO-Revision-Date: 2010-01-14 21:20+0100 Last-Translator: Holger Wansing li...@wansing-online.de Language-Team: Debian German debian-l10n-ger...@lists.debian.org Language: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit $ Since this seems to have been captured with German locales, I've tried to reprodcue it with German locales: $ env LANG=de_DE tasksel --task-desc ssh-server $ still shows an empty line. But this one outputs something: $ env LANGUAGE=de_DE:de tasksel --task-desc ssh-server Project-Id-Version: tasksel-tasks Report-Msgid-Bugs-To: POT-Creation-Date: 2012-06-09 08:27+ PO-Revision-Date: 2010-01-14 21:20+0100 Last-Translator: Holger Wansing li...@wansing-online.de Language-Team: Debian German debian-l10n-ger...@lists.debian.org Language: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit $ Nevertheless this only seems to be meta information about the translation. There's not a single part of information about the task itself. So the issue still seems there, even though I can now reproduce the output I saw on Wheezy. Tracked it to: | commit 9efc98df74352433af747463bc44404f332f2ee8 | Author: Joey Hess j...@kitenet.net | Date: Sun Feb 27 22:38:07 2011 -0400 | | remove Description and Packages fields | | Only the manual and standard tasks need those fields now. aka. 3.00~5 Thanks. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140802192006.go6...@sym.noone.org
Bug#609733: installation-reports: UltraSparc 10 doesn't find its CD-ROM drive
Package: installation-reports Severity: normal Hi, after debugging http://bugs.debian.org/560823 resulted in an unbootable system again, I tried today's Squeeze installer image to revive the installation. But the installer fails because it can't find it's cdrom. According to lsmod the cdrom driver is loaded. I also don't see any hard disk device in /dev. The box was running 2.6.32-5-sparc64 before and worked fine with it. I though never had to access the cdrom from the running system, so I don't know if that would have worked. The system was initially installed with some Lenny installer beta images running 2.6.24 and runs Debian Sid since then. The last time I had to revive the system, I used that CD and it still worked fine. Will try to boot the system with some Lenny CD to see if that works. I was able to configure the network manually, so I could save the logs as shown below as well as the content of /dev. drwxr-xr-x2 root root 60 Jan 11 23:20 block drwxr-xr-x2 root root 2000 Jan 11 23:20 char crw-rw-rw-1 root root 5, 1 Jan 11 23:49 console lrwxrwxrwx1 root root 11 Jan 11 23:20 core - /proc/kcore crw-rw-rw-1 root root 10, 61 Jan 11 23:49 cpu_dma_latency crw-rw-rw-1 root root 29, 0 Jan 11 23:49 fb0 lrwxrwxrwx1 root root 13 Jan 11 23:20 fd - /proc/self/fd brw-rw-rw-1 root root 2, 0 Jan 11 23:49 fd0 crw-rw-rw-1 root root 1, 7 Jan 11 23:49 full drwxr-xr-x2 root root 80 Jan 11 23:20 input crw-rw-rw-1 root root 1, 11 Jan 11 23:49 kmsg srw-rw-rw-1 root root0 Jan 11 23:20 log brw---1 root root 7, 0 Jan 11 23:20 loop0 crw-rw-rw-1 root root 10, 62 Jan 11 23:49 mdesc crw-rw-rw-1 root root 1, 1 Jan 11 23:49 mem drwxr-xr-x2 root root 60 Jan 11 23:20 net crw-rw-rw-1 root root 10, 60 Jan 11 23:49 network_latency crw-rw-rw-1 root root 10, 59 Jan 11 23:49 network_throughput crw-rw-rw-1 root root 1, 3 Jan 11 23:49 null crw-rw-rw-1 root root 10, 139 Jan 11 23:49 openprom crw-rw-rw-1 root root 1, 4 Jan 11 23:49 port crw---1 root root 108, 0 Jan 11 23:20 ppp crw-rw-rw-1 root root 10, 1 Jan 11 23:49 psaux crw-rw-rw-1 root root 5, 2 Jan 11 23:49 ptmx drwxr-xr-x2 root root0 Jan 1 1970 pts crw-rw-rw-1 root root 1, 8 Jan 11 23:49 random crw-rw-rw-1 root root 254, 0 Jan 11 23:49 rtc0 drwxr-xr-x2 root root 40 Jan 11 23:20 shm lrwxrwxrwx1 root root 15 Jan 11 23:20 stderr - /proc/self/fd/2 lrwxrwxrwx1 root root 15 Jan 11 23:20 stdin - /proc/self/fd/0 lrwxrwxrwx1 root root 15 Jan 11 23:20 stdout - /proc/self/fd/1 crw-rw-rw-1 root root 5, 0 Jan 11 23:49 tty crw-rw-rw-1 root root 4, 0 Jan 11 23:49 tty0 crw-rw-rw-1 root root 4, 1 Jan 11 23:49 tty1 crw-rw-rw-1 root root 4, 10 Jan 11 23:49 tty10 crw-rw-rw-1 root root 4, 11 Jan 11 23:49 tty11 crw-rw-rw-1 root root 4, 12 Jan 11 23:49 tty12 crw-rw-rw-1 root root 4, 13 Jan 11 23:49 tty13 crw-rw-rw-1 root root 4, 14 Jan 11 23:49 tty14 crw-rw-rw-1 root root 4, 15 Jan 11 23:49 tty15 crw-rw-rw-1 root root 4, 16 Jan 11 23:49 tty16 crw-rw-rw-1 root root 4, 17 Jan 11 23:49 tty17 crw-rw-rw-1 root root 4, 18 Jan 11 23:49 tty18 crw-rw-rw-1 root root 4, 19 Jan 11 23:49 tty19 crw-rw-rw-1 root root 4, 2 Jan 11 23:55 tty2 crw-rw-rw-1 root root 4, 20 Jan 11 23:49 tty20 crw-rw-rw-1 root root 4, 21 Jan 11 23:49 tty21 crw-rw-rw-1 root root 4, 22 Jan 11 23:49 tty22 crw-rw-rw-1 root root 4, 23 Jan 11 23:49 tty23 crw-rw-rw-1 root root 4, 24 Jan 11 23:49 tty24 crw-rw-rw-1 root root 4, 25 Jan 11 23:49 tty25 crw-rw-rw-1 root root 4, 26 Jan 11 23:49 tty26 crw-rw-rw-1 root root 4, 27 Jan 11 23:49 tty27 crw-rw-rw-1 root root 4, 28 Jan 11 23:49 tty28 crw-rw-rw-1 root root 4, 29 Jan 11 23:49 tty29 crw-rw-rw-1 root root 4, 3 Jan 11 23:49 tty3 crw-rw-rw-1 root root 4, 30 Jan 11 23:49 tty30 crw-rw-rw-1 root root 4, 31 Jan 11 23:49 tty31 crw-rw-rw-1 root root 4, 32 Jan 11 23:49 tty32 crw-rw-rw-1 root root 4, 33 Jan 11 23:49 tty33 crw-rw-rw-1 root root 4, 34 Jan 11 23:49 tty34 crw-rw-rw-1 root root 4, 35 Jan 11 23:49 tty35 crw-rw-rw-1 root root 4, 36 Jan 11 23:49 tty36 crw-rw-rw-1 root root 4, 37 Jan 11 23:49 tty37
Bug#609733: installation-reports: UltraSparc 10 doesn't find its CD-ROM drive (Lenny works fine)
Hi, Axel Beckert wrote: after debugging http://bugs.debian.org/560823 resulted in an unbootable system again, I tried today's Squeeze installer image to revive the installation. I used the netinst image btw. But the installer fails because it can't find it's cdrom. According to lsmod the cdrom driver is loaded. I also don't see any hard disk device in /dev. The box was running 2.6.32-5-sparc64 before and worked fine with it. I though never had to access the cdrom from the running system, so I don't know if that would have worked. The system was initially installed with some Lenny installer beta images running 2.6.24 and runs Debian Sid since then. The last time I had to revive the system, I used that CD and it still worked fine. Will try to boot the system with some Lenny CD to see if that works. Freshly downloaded and burned Lenny 5.0.7 netinst image works fine. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112002546.gc12...@sym.noone.org
Bug#609733: installation-reports: UltraSparc 10 doesn't find its CD-ROM drive
Hi, Julien Cristau wrote: On Wed, Jan 12, 2011 at 00:58:24 +0100, Axel Beckert wrote: Jan 11 23:20:31 kernel: [0.00] Linux version 2.6.32-5-sparc64 (Debian 2.6.32-15) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 Tue Jun 1 06:56:43 UTC 2010 That's an awfully old kernel. Indeed. Didn't notice. Which image did you use? The one available at http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/sparc/iso-cd/ It says This build finished at Mon Jan 10 06:47:46 UTC 2011. and debian-testing-sparc-netinst.iso 10-Jan-2011 07:47 138M in the browser cache of the page from where I downloaded it. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112083410.gg12...@sym.noone.org
Re: SPARC daily d-i builds
Hi, Gaudenz Steinlin wrote: Due to the lack of porter and buildd admin interest there are currently no daily builds for the SPARC architecture. These builds will be reenable as soon as someone finds the time to do the necessary buildd setup. I just ran into this yesterday when debbugging grub on Sparc: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609733 I would also be willing to do the neccessary setup myself if someone provides me with the necessary access to a sparc buildd. Cyril Brulebois wrote: I would also be willing to do the neccessary setup myself if someone provides me with the necessary access to a sparc buildd. So, again, it's not about lack of interest, it's about lack of time. ... and the lack of enough disk space on a Sparc buildd: Philipp Kern wrote: 15:27 trave11er ok, we didn't get any reply from stappers, so sparc dailies still have the old kernels, afaict Does http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609733 suffice as bug report? 15:33 phil otavio: were going to is quite untrue. There still isn't a bug report, and I did report the result of my investigation, i.e. there's no space on the only LVMed sparc buildd we have. 15:37 otavio phil: I didn't recall about the space issue 15:37 otavio phil: indeed So meh, whatever. To my knowledge that's still true. We currently don't have the capacities and we admitted that. Furthermore not asking -wb-team might not give you answers, indeed. Sorry if I missed something along the way. So how much disk space is needed for building the daily images, why does it have to be on a buildd (i.e. does it suffice to throw hardware at it) and how new/fast does the sparc to be? I do have a bunch of Sparcs at home which are not in use yet, but most of them are Ultra 5 and 10 which should be around 15 years old or older. I also have one dual processor sparc built by Tritec which I haven't setup yet, so I don't know the details about processor speed -- but I got it for free and it has/had Woody installed according to the previous owner, so it can't be very new. (I also have some more 32-bit Sparcs, but I know that _they_ won't help. ;-) If any of them could help I'll see what I can do (which is also mostly a function of time.)-: Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112094719.gh12...@sym.noone.org
Bug#703146: Bug#704263: installation-reports: busybox fails to verify on current wheezy/sid installer
Hi, Adam Baxter wrote: Subject: […] busybox fails to verify on current wheezy/sid installer Same here. But not only busybox, but also dmsetup, libdevmapper1.02.1, etc. As this was prefixed with in-target I checked how the issue is presented from inside the chroot: apt-get install busybox really complains about an unauthenticated package. apt-get update doesn't solve the issue but reveals the source for the issue: W: GPG errror: http://debian.ethz.ch wheezy Release: The following signatures were invalid: BADSIG AED4B06F473041FA Debian Archive Automatic Signing Key (6.0/squeeze) ftpmas...@debian.org According to https://lists.debian.org/debian-mirrors/2013/03/msg5.html this looks a lot like http://bugs.debian.org/703146 (Cc'ed), too, which is worked on. Interestingly the issue could be solved by running the following commands inside the chroot while D-I asks me which kernel to install: # cd /var/lib/apt/lists # rm ftp.*.debian.org* # apt-get update # apt-get install busybox (No BADSIG here, installs fine.) (If I do this before that question, debootstrap seems to overwrite the previous installation and hence the manually installed busybox.) So the funny thing is that all packages were accepted despite the BADSIG issue, except busybox. Sounds as if there's more broken than just #703146. It also seems to have forgotten some settings after aborting at the busybox install failure. E.g. preseeding stuff (otherwise I would have expected that it doesn't ask me for the kernel to choose at some point) as well the fact that it should have had installed lvm2 into the target (as I manually partitioned a VG in the installer), i.e. it didn't find any root file system at the first reboot and I had to boot via PXE for rescue mode to install lvm2, too. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402123409.gb28...@sym.noone.org
Re: Bug#684128: down the memory hole
Hi Ian. ian_br...@fastmail.net wrote: It seems that Historical Revisionism, of the bad kind, is now in operation at Debian, in that critical commentary about unapplied patches is made to disappear down the memory hole, without leaving so much as a trace on the relevant bug report. If it were thought that the criticism was unfair, or inaccurate, then it could be allowed to remain in place, so that other people might judge its lack of merit for themselves. In the case of bug #684128, post #108, however, the fact that the offending message was promptly vaporized* (as will be this one also), of course suggests that the opposite is true. I'm (again) not really sure what you mean with these paragraphs, but the message Subject: Bug#684128: Info received (When I use a word, Humpty Dumpty said...) Message-ID: handler.684128.b684128.136491666013227.acki...@bugs.debian.org References: 20130402083114.6bba69b4.ian_br...@fastmail.net (for reference, that mail is available online at http://lists.debian.org/20130402083114.6bba69b4.ian_br...@fastmail.net) looked a lot like non-sense spam to me and I reported it as such in the BTS. And obviously the one reading that report was of the same opinion. I wouldn't be surprised if others hit the Send a report that this bug log contains spam link after that mail of yours, too. If you want to make comments about bugs that people should actually read, please make sure that your mail is concise and does not tell fairy tales to hide your intent. The BTS is no literature contest. TIA. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405161826.gb28...@sym.noone.org
Bug#703404: debian-installer: wheezy (PXE boot) failes to install busybox and kernel
Hi, Konrad Vrba wrote: can somebody please fix this bug? I think this will be fixed with the Wheezy D-I RC2 release which is currently prepared and expected in a few days. And yes, it's annoying. Ran into that several times. There are several workarounds posted in the related bug-reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703146#25 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703404#112 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704263#15 The last time I used an USB stick with a daily image added my preseeding URL as boot parameter manually. Worked fine (at least for that aspect). Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130406093608.gc9...@sym.noone.org
Bug#665466: task-laptop: Should no more depend on apmd
Package: task-laptop Version: 3.08 Severity: normal Dear Maintainer, task-laptop currently depends on apmd. But the description of apmd says: Since lenny Debian kernels are not built with APM support anymore. You need to compile a kernel with apm support enabled to use this package. You need to boot the kernel with the apm=on option if you want to enable the driver. In most cases, users may want to know that there are newer power management schemes, like ACPI. So IMHO task-laptop should drop the Depends on apmd or at most convert it to a Suggests. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (900, 'testing'), (600, 'stable'), (110, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.3.0-rc6-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkb69l0i@nemo.deuxchevaux.org
Bug#665466: task-laptop: Should no more depend on apmd
retitle 665466 task-laptop: Should no more recommend apmd severity 665466 minor kthxbye Axel Beckert wrote: task-laptop currently depends on apmd. s/depends/Recommends/ Nevertheless it's installed by default since Recommends are installed by default. Additionally that way apmd is lifted to the same level as acpi-* which seems wrong for the same reason: But the description of apmd says: Since lenny Debian kernels are not built with APM support anymore. You need to compile a kernel with apm support enabled to use this package. You need to boot the kernel with the apm=on option if you want to enable the driver. In most cases, users may want to know that there are newer power management schemes, like ACPI. So IMHO task-laptop should drop the Depends on apmd or at most convert it to a Suggests. s/Depends/Recommends/, too, so that it's no more installed by default. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120324134817.gt17...@sym.noone.org
Bug#676370: debootstrap: Outdated default mirrors for Ubuntu
Package: debootstrap Version: 1.0.40 Severity: minor Dear Maintainer, Many (but not all) Ubuntu releases which are supported by debootstrap but officially EoL have not http://old-releases.ubuntu.com/ubuntu set as default mirror: * dapper * edgy * feisty * gutsy * intrepid * jaunty * karmic maverick is officially EoL but still seems to be around on the normal mirrors as of now. Nevertheless it will likely move to old-releases.ubuntu.com soon, so I'd change that one, too. breezy, hoary and warty are fine. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (400, 'stable'), (110, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debootstrap depends on: ii wget 1.13.4-3 Versions of packages debootstrap recommends: ii debian-archive-keyring 2012.4 ii gnupg 1.4.12-4 debootstrap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120606140520.68e80b8a...@sym2.noone.org
Bug#676373: debootstrap: No more can bootstrap Ubuntu releases before Feisty
Package: debootstrap Version: 1.0.40 Severity: normal Affects: xen-tools Dear Maintainer, while testing xen-tools I noticed that debootstrap can no more bootstrap the Ubuntu releases Warty, Hoary, Breeazy, Dapper or Edgy. (Only the last two matter for xen-tools.) In those cases debootstrap fails with the following error message, even with the correct mirror (cf. http://bugs.debian.org/676370): # /usr/sbin/debootstrap --no-check-gpg --verbose --arch=i386 dapper /tmp/EsVv1M2Clj http://old-releases.ubuntu.com/ubuntu I: Retrieving Release E: Invalid Release file, no entry for main/binary-i386/Packages # /usr/sbin/debootstrap --no-check-gpg --verbose --arch i386 edgy /tmp/EsVv1M2Clj http://old-releases.ubuntu.com/ubuntu I: Retrieving Release E: Invalid Release file, no entry for main/binary-i386/Packages # It doesn't make a difference with or without --no-check-gpg. It seems to work for Ubuntu Feisty: # /usr/sbin/debootstrap --no-check-gpg --verbose --arch i386 feisty /tmp/EsVv1M2Clj http://old-releases.ubuntu.com/ubuntu I: Retrieving Release I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Checking component main on http://old-releases.ubuntu.com/ubuntu... I: Retrieving adduser I: Validating adduser I: Retrieving alsa-base I: Validating alsa-base I: Retrieving alsa-utils I: Validating alsa-utils I: Retrieving apt I: Validating apt I: Retrieving apt-utils I: Validating apt-utils I: Retrieving aptitude ^CE: Interrupt caught ... exiting -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (400, 'stable'), (110, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debootstrap depends on: ii wget 1.13.4-3 Versions of packages debootstrap recommends: ii debian-archive-keyring 2012.4 ii gnupg 1.4.12-4 debootstrap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120606142232.5d1b0b8a...@sym2.noone.org
Bug#572013: udhcpc: bashism in /usr/share/udhcpc/default.script causes network setup to fail
Package: udhcpc Version: 1:1.15.3-1 Severity: important File: /usr/share/udhcpc/default.script I got a bug report by private mail. Here's the summary of it: /usr/share/udhcpc/default.script contains $((metric++)) which seems to be a bashism although checkbashisms doesn't find it (http://bugs.debian.org/572006), but dash definitely can't parse it, since it's not necessary for POSIX conpliance. This causes causes network setup failures at least in some cases. (Worked fine for me + checkbashisms didn't find it, so I didn't notice this bashism when testing that code.) The easy solution is to use $((metric=metric+1)) instead. Will check for further occurrences of this bashism inside the busybox package and add a patch against current SVN to this bug report. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'stable'), (500, 'testing'), (110, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages udhcpc depends on: ii busybox 1:1.15.3-1 Tiny utilities for small and embed udhcpc recommends no packages. udhcpc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100228221823.523e61b...@nemo.ontheroad.deuxchevaux.org
Re: Bug#572008: udhcpc: bash-ism in default.script
merge 572008 572013 tag 572008 + confirmed kthxbye Jeff King wrote: My /bin/sh is dash. Running udhcpc yields: $ sudo udhcpc -fi wlan0 udhcpc (v1.15.3) started Sending discover... Sending select for 10.0.0.7... Lease of 10.0.0.7 obtained, lease time 864000 /usr/share/udhcpc/default.script: Resetting default routes SIOCDELRT: No such process /usr/share/udhcpc/default.script: 62: arithmetic expression: expecting primary: metric++ The problem is that dash does not understand arithmetic increment, like $((metric++)). The attached patch uses metric=$((metric+1)) instead. Hehe, I just reported the same bug against that code I added to the package, too, just a few minutes later. Merged the two bugs. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100228222643.gx1...@sym.noone.org
Bug#572013: Patch for #572013, #572008 (bashism in udhcpc/default.script)
Hi, although Jeff King already kindly provided a patch in #572008, I prefer the following slightly more compact and complete patch patch against r62547. Verified that this syntax works fine with dash, ksh, mksh, bash and zsh. Index: changelog === --- changelog (revision 62547) +++ changelog (working copy) @@ -1,3 +1,10 @@ +busybox (1:1.15.3-2) unstable; urgency=low + + [ Axel Beckert ] + * Fix bashism in udhcpc default.script (Closes: #572008, #572013) + + -- Axel Beckert a...@debian.org Mon, 01 Mar 2010 01:04:13 +0100 + busybox (1:1.15.3-1) unstable; urgency=low [ Bastian Blank ] Index: tree/udhcpc/usr/share/udhcpc/default.script === --- tree/udhcpc/usr/share/udhcpc/default.script (revision 62547) +++ tree/udhcpc/usr/share/udhcpc/default.script (working copy) @@ -19,7 +19,7 @@ metric=0 for i in $router; do - /sbin/route add default gw $i dev $interface metric $((metric++)) + /sbin/route add default gw $i dev $interface metric $((metric=metric+1)) done fi Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 signature.asc Description: Digital signature
Bug#572013: Patch for #572013, #572008 (bashism in udhcpc/default.script)
Hi, Bastian Blank wrote: On Mon, Mar 01, 2010 at 02:10:54AM +0100, Axel Beckert wrote: - /sbin/route add default gw $i dev $interface metric $((metric++)) + /sbin/route add default gw $i dev $interface metric $((metric=metric+1)) I currently think about why this metric argument is there anyway. The script from the isc dhcp does not set it in this case. Maybe it could just be removed. As just discussed on #debian-boot with Otavio, the busybox udeb's udhcpc (special default.script for the udeb by Otavio) does not set the metric either, so we should be able to safely drop it, yes. Axel Beckert wrote: Will check for further occurrences of this bashism inside the busybox package and add a patch against current SVN to this bug report. In the meanwhile I indeed found some more occurrences of this bashism -- and now I also remember from where that code originates: Our default.script is mainly based on the scripts in busybox' examples/udhcpc/ directory. Those are though not part of the binary packages as we ship our own default.script. Will send an appropriate patch for the example scripts to upstream, too. Hope to find time to create the new patches either late this evening or tomorrow. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100301125331.ga1...@sym.noone.org
Bug#591756: busybox-udeb: Please enable VLAN support
Package: busybox-udeb Version: 1:1.15.3-1 Severity: wishlist Please enable VLAN support in busybox-udeb (and probably the best if also enabled in busybox and busybox-static) so that D-I can be used in environments where VLANs are used. See also http://bugs.debian.org/433568 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'oldstable'), (400, 'stable'), (110, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5idbdjn@kiva6.ethz.ch
Bug#683329: flash-kernel: Toshiba AC100 support broken [fix included]
Control: found -1 3.0~rc.2 Control: found -1 3.3+deb7u2 Control: found -1 3.11 Control: tag -1 + patch Control: severity -1 important Hi, Thomas Maass wrote: flash-kernel no longer flashs the Toshiba AC100 (Tegra2). It shows only Installing version... but no Flashing... The last version I remember to work was 3.0rc1. Actually it was 3.0~rc.1. And the first one which no more worked was 3.0~rc.2. Ran into that too when switching my AC100 from Ubuntu Precise to Debian Wheezy -- and it's still present in Debian Jessie/Sid. Vincent Zweije wrote: Trying to flash a new kernel failed - flash-kernel exits early because some shell command returned an error code. I have tracked this down to faulty boot device detection. This little loop from /usr/share/flash-kernel/functions around line 468 does the detection: for p in $android_boot_device*[0-9]; do abootimg=$(LC_ALL=C abootimg -i $p 2/dev/null) image_size=$(abootimg_get_image_size $abootimg) if [ -n $image_size ] [ $image_size -gt $largest_size ]; then part=$p fi done The assignment to abootimg contains a call to abootimg -i $p. This call fails when the glob pattern on the line above returns a block device that is not an android boot image. Since the script is executed with -e, this aborts the script. Adding a || : after the command fixes the problem thus: for p in $android_boot_device*[0-9]; do abootimg=$(LC_ALL=C abootimg -i $p 2/dev/null || : ) image_size=$(abootimg_get_image_size $abootimg) if [ -n $image_size ] [ $image_size -gt $largest_size ]; then part=$p fi done I came to the same conclusion and patch: --- functions.orig 2013-10-25 13:58:31.379524139 +0200 +++ functions 2013-10-25 13:40:48.984844024 +0200 @@ -475,7 +475,7 @@ part= largest_size=-1 for p in $android_boot_device*[0-9]; do - abootimg=$(LC_ALL=C abootimg -i $p 2/dev/null) + abootimg=$(LC_ALL=C abootimg -i $p 2/dev/null || true) image_size=$(abootimg_get_image_size $abootimg) if [ -n $image_size ] [ $image_size -gt $largest_size ]; then Tagging the bug report accordingly and raising the severity to important as this definitely affects all AC100 users. The probably easiest work-around (i.e. one which doesn't involve patching) is to use Julian's packages from http://people.debian.org/~jak/ac100/ which are apt-get-able. JFTR: Here's a condensed summary of what happens: # for i in /dev/mmcblk0p*; do echo $i; abootimg -i $i | fgrep 'image size'; abootimg -i $i /dev/null 21 ; echo $?; done /dev/mmcblk0p1 * image size = 5242880 bytes (5.00 MB) 0 /dev/mmcblk0p2 * image size = 8388608 bytes (8.00 MB) 0 /dev/mmcblk0p3 /dev/mmcblk0p3: no Android Magic Value /dev/mmcblk0p3: not a valid Android Boot Image. 1 ← This is where flash-kernel aborts due to set -e. /dev/mmcblk0p4 /dev/mmcblk0p4: no Android Magic Value /dev/mmcblk0p4: not a valid Android Boot Image. 1 /dev/mmcblk0p5 /dev/mmcblk0p5: no Android Magic Value /dev/mmcblk0p5: not a valid Android Boot Image. 1 /dev/mmcblk0p6 /dev/mmcblk0p6: no Android Magic Value /dev/mmcblk0p6: not a valid Android Boot Image. 1 /dev/mmcblk0p7 /dev/mmcblk0p7: no Android Magic Value /dev/mmcblk0p7: not a valid Android Boot Image. 1 # Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131025120238.ga20...@sym.noone.org
Bug#767682: D-I: installer hangs on re-formatting ext4 partition (having grub in the partition boot record).
Control: found -1 20150107 Control: severity -1 serious Hi, MARTON Jozsef wrote: The formatting dialog hanged at 33%. * What outcome did you expect instead? To re-format /dev/sda3 creating a fresh ext4 filesystem. After examining the situation and killing the mkfs.ext4 process on a second virtual terminal, the installer gave a red screen error and returned to the partitioning menu. Invoking mkfs.ext4 manually on the sencond VT, it gave the yes-no question that follows (captured under the running Jessie install, so mke2fs version might be different). This might be the point where the installer hanged at. # mkfs.ext4 /dev/sda3 mke2fs 1.42.12 (29-Aug-2014) /dev/sda3 contains a ext4 file system last mounted on / on Sat Nov 1 20:18:44 2014 Proceed anyway? (y,n) We ran into this today with the current Jessie installer (labeled RC1 IIRC). Context was the reinstallation of a computer with the same partition layout. The question vanishes if a -F is passed to the mkfs.ext* call, so this should be an easy fix: -F Force mke2fs to create a filesystem, even if the specified device is not a partition on a block special device, or if other parameters do not make sense. In order to force mke2fs to create a filesystem even if the filesystem appears to be in use or is mounted (a truly dangerous thing to do), this option must be specified twice. After formatting from the second VT, installer was able to continue without re-formatting the partition. An other solution was to zero out the forst few megabytes of sda3 using dd and /dev/zero to allow formatting by the installer. I consider both variants unsuitable for unexperienced users. A hanging TUI without _any_ trace of reason, neither in the TUI no in the syslog nor in the partman log must not happen. Raising the severity to serious because I think that this is a scenario (reinstallation or retrying an incomplete installation) which can happen often enough and will confuse users massively due no feedback from the installer what happens. (D-I team: feel free to downgrade again to important if you disagree, but I really would like to see this fixed for Jessie.) Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204110710.ga14...@sym.noone.org
Re: Bug#776101: aptitude: hangs forever on 'setting up console-setup (1.116)'
Control: reassign -1 console-setup 0.116 Hi, Gordon Morehouse wrote: running 'aptitude upgrade' followed by 'aptitude update' You mean running 'aptitude update' followed by 'aptitude upgrade', don't you? on a Debian testing system hangs How long did you approximately wait? after similar output from aptitude: Installing new version of config file /etc/console-setup/compose.ISO-8859-3.inc ... Installing new version of config file /etc/console-setup/compose.ISO-8859-4.inc ... Installing new version of config file /etc/console-setup/compose.ISO-8859-7.inc ... Installing new version of config file /etc/console-setup/compose.ISO-8859-9.inc ... This output is not from aptitude but either from dpkg or ucf. Setting up console-setup (1.116) ... This is output from dpkg, announcing that it will now run console-setup's postinst script. 'top' shows aptitude taking about 3-4% CPU but it is stuck. Because aptitude is probably not the one which is working at that time. The one which should do something is either a postinst script from some to-be-installed package or some trigger. But dpkg would have announce triggers. As well as aptitude is mentioning that it's re-reading it's database. Did top show any other child process of aptitude? Ctrl-C is not effective. Ok. Kill with SIGTERM does stop the process while breaking terminal echo. Sure, because it doesn't leave aptitude a chance to do so. IMHO expected behaviour. It leaves the aptitude /var lockfile dirty. Dito. Running 'sudo dpkg --configure -a' has a couple errors about /var/cache/debconf/config.dat being locked as well. This sounds as if the aptitude including its children processes were killed while debconf tried to ask you a question or -- more likely -- generate a config file. I'm quite sure this is no issue with aptitude at all but likely with the postinst script of a to-be-installed package. I currently assume it's console-setup, also because it's a heavy debconf user. Hence reassigning. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150123233827.gd26...@sym.noone.org
Bug#767682: D-I: installer hangs on re-formatting ext4 partition (having grub in the partition boot record).
Hi Cyril, Cyril Brulebois wrote: I couldn't reproduce this issue with the upcoming D-I Jessie RC3: We just tested it the way we ran into it by using http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso and we could no more reproduce it either. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150415124441.gd5...@sym.noone.org
Bug#792729: debootstrap: Uses wrong keyring to bootstrap etch (and likely also other archived releases)
Package: debootstrap Version: 1.0.67 Severity: normal Control: affects -1 xen-tools $ debootstrap --verbose --arch amd64 etch /tmp/2d2hgjrQsL http://debian.ethz.ch/debian-archive/debian I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature E: Release signed by unknown key (key id B5D0C804ADB11277) $ debootstrap --keyring=/usr/share/keyrings/debian-archive-removed-keys.gpg --verbose --arch amd64 etch /tmp/9TZTmvueLz http://debian.ethz.ch/debian-archive/debian I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id 7EA391D72477203B58C04FBCB5D0C804ADB11277) I: Retrieving Packages I: Validating Packages But /usr/share/debootstrap/scripts/etch contains: keyring /usr/share/keyrings/debian-archive-keyring.gpg This should be changed to: keyring /usr/share/keyrings/debian-archive-removed-keys.gpg This seems also to count for all other archived Debian releases (as egrep '^keyring' /usr/share/debootstrap/scripts/* shows) and may also count for archived Ubuntu releases. (Didn't test the latter, but ubuntu-archive-keyring contains a similarily named file: /usr/share/keyrings/ubuntu-archive-removed-keys.gpg) This issue has been found in Jessie, but still seems to be present in Sid. Reporting from a Sid machine, but against the version in Jessie. The current workaround for xen-tools is to use --debootstrap-cmd='debootstrap --keyring=/usr/share/keyrings/debian-archive-removed-keys.gpg' as option to xen-create-image. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'buildd-unstable'), (400, 'stable'), (110, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debootstrap depends on: ii wget 1.16.3-3 Versions of packages debootstrap recommends: ii debian-archive-keyring 2014.3 ii gnupg 1.4.19-3 debootstrap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tg6sk7p@kiva6.ethz.ch
Bug#792729: debootstrap: Uses wrong keyring to bootstrap etch (and likely also other archived releases)
Hi, Axel Beckert wrote: may also count for archived Ubuntu releases. (Didn't test the latter, but ubuntu-archive-keyring contains a similarily named file /usr/share/keyrings/ubuntu-archive-removed-keys.gpg) Nope. That file is empty. O.o Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150717203919.gq2...@sym.noone.org
Bug#792734: debootstrap: Please support bootstrapping oldoldstable
Package: debootstrap Version: 1.0.71 Severity: wishlist Hi, debootstrap supports bootstrapping oldstable but does not yet support bootstrapping oldoldstable. A symlink from /usr/share/debootstrap/scripts/oldoldstable to sid likely suffices to fix this. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'buildd-unstable'), (400, 'stable'), (110, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debootstrap depends on: ii wget 1.16.3-3 Versions of packages debootstrap recommends: ii debian-archive-keyring 2014.3 ii gnupg 1.4.19-3 debootstrap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4ier10i@kiva6.ethz.ch
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Hi Roger, Roger Shimizu wrote: > For example, I know for it's necessary to have GNU/screen support for > armel/armhf/arm64 platform; howover, for i386/amd64 PC, it usually > have CRT/LCD and physical keyboard attached, so it's easily to switch > console by Alt-F1 ~ F4 during debian installing.So for i386/amd64 > netboot targets, GNU/screen support is considered unnecessary. I disagree that screen support for i386 in unnecessary. There are rather popular x86 boards which only have a serial console and no VGA, e.g.: http://www.pcengines.ch/alix3d2.htm (actually all but two models on http://www.pcengines.ch/alix.htm) http://www.pcengines.ch/apu.htm http://www.pcengines.ch/apu2b2.htm So I think adding screen support to D-I on at least i386, too, would add some value. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Hi Roger, Roger Shimizu wrote: > However, there's even no network-console (SSH) target for i386/amd64 yet [6]. […] > [6] > https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/i386 Maybe that's the wrong place to look for. Because I'm very sure I used that feature already on Intel x86 architectures. And the required packages exist for quite a while now: https://packages.debian.org/search?keywords=network-console Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: Screen support (was: Next d-i alpha release: late June)
Hi, Cyril Brulebois wrote: > > During RFC stage of adding screen-udeb, firstly I though it's not > > necessary for normal PC, which is not exact the same with "everyone" > > you mentioned but should be close to, however a few feedbacks > > convinced me that normal PC still need screen-udeb [0][1][2]. [...] > > I think the solution below is a middle ground, which I guess it can be > > accepted by everyone. > > - Keep screen-udeb in "common" for everyone, but don't start it > > automatically on i386/amd64. > > It'd be nice if Ben, Axel, Philipp (cc'd) could share whether they > expect screen to start automatically, with text and/or graphical > installer, or whether they would be OK to opt in for that (and if so, > how). I have no strong preference here. My imagination is the following: * Start screen by default if there's no virtual console available, i.e. over serial console and SSH console. * Don't start screen by default if there's a virtual console * Having a screen-udeb for i386/amd64/powerpc/etc. available shouldn't hurt though. * Screen in combination with the graphical D-I doesn't make sense to me, i.e. we shouldn't run it there. I though can also imagine and am fine with the following setup: * Only start screen on demand via menu on every platform. There are though a few workflow questions in mind which I haven't noticed yet in this thread (but I might have overseen or forgotten it): * If D-I is running inside screen, there should be an outside-screen D-I menu entry to reattach the running session on the current terminal device. Examples: + Starting D-I inside screen via serial console and then switching to SSH as soon as network has been setup. + Running D-I inside screen via SSH and then loose the network connection and wanting to reconnect. * The user should be informed if his D-I is running under screen to know that the Ctrl-A prefix is active. (Maybe the presence of the status line already suffices here.) * What happens if the screen session ends? * What happens if the user (accidentially) presses Ctrl-A Ctrl-X (e.g. locks the session). Maybe this should be added to the list of "stupid / dangerous key bindings" in https://anonscm.debian.org/cgit/collab-maint/screen.git/tree/debian/udeb/screenrc#n20 (Yes, that will be my job, but I'd prefer to here some other opinion on this first before implementing it.) > Please note I mostly disagree with the UI (= User Interface) changes it > imposes on users. I'm fine with it being around for people who would > like to have it, and maybe automatically started (see above); but the > extra bar at the top is a big no for me. Cc-ing Christian to get his > opinion on this matter as he's been taking care of “user interface vs. > users” matters for a long time. See my comment above. I think that this status bar is a very good way to tell the user that his D-I is running in a screen session. If we agree to get rid of it (which I don't recommend), we should make some dialog pop up telling the user that D-I now runs under screen. This could be also done, by enabling screen's startup message again in https://anonscm.debian.org/cgit/collab-maint/screen.git/tree/debian/udeb/screenrc#n7 Alternatively the hack to start window numbering with 1 instead of 0 (https://anonscm.debian.org/cgit/collab-maint/screen.git/tree/debian/udeb/screenrc#n53) could also be used to show an individual initial message. > Also, I'm not sure whether we have any input methods which might be > confused by ^A being “eaten” by screen. Does anyone know? I (as package maintainer of screen) are not aware of any such issues. But then again, I don't use any non-latin input methods other than the compose key. The most common usability issue is "Go to beginning of line" being bound to Ctrl-A in Emacs and emacs-ish UIs like (b)ash in emacs-mode. (But Ctrl-B of tmux or Ctrl-T of ratpoison isn't better: It's bound to "cursor left" and "transpose characters" in most emacs-ish applications. I definitely recommend to stay with Ctrl-A if there are no real input-method blockers.) Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: screen-udeb prevents bterm, and thus a lot of languages
Hi, Roger Shimizu wrote: > On Mon, Sep 12, 2016 at 12:30 AM, Samuel Thibault <sthiba...@debian.org> > wrote: > > Another argument against screen-udeb by default on normal VGA console: > > it seems to be preventing bterm from running, and thus disables a lot of > > languages which need it. I haven't really followed what conclusion > > there was with screen-udeb, but > > > > https://d-i.debian.org/daily-images/amd64/daily/netboot/mini.iso > > > > still has it enabled by default. > > Thanks for letting us know this issue! > > invoking screen is in script: > - > https://anonscm.debian.org/cgit/d-i/rootskel.git/tree/src/sbin/debian-installer > > It uses system's $TERM, if bterm fails in screen, maybe it's a bug of screen? As I am not sure what exactly is meant by "bterm": Is it the udeb version of bogl-bterm? Or something completely different? > > Axel, do you have any comment on this issue? Sounds like a strong argument against enabling it by default on VGA consoles. I'm totally fine with that. :-) Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: HTTPS metadata in Mirrors.masterlist?
Hi,
Peter Palfrader wrote:
> I don't think ftp.*.debian.org providers should do https with that name.
> We regularly point ftp.*.debian.org to other places when mirrors go away
> temporarily, and the only service we guarantee the new target has is
> http://.../debian/
>
> Adding https just makes this a whole extra mess.
As outlined in my recent mail I don't think that it's that much of an
extra-effort once we track HTTPS in Mirrors.masterlist. And I
especially think the gain outweighs the additional effort.
> By all means offer https on your "base" hostname, like ftp.acc.umu.se,
> but please don't do it on ftp.*.debian.org.
Hence I disagree.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: HTTPS metadata in Mirrors.masterlist?
du.sv (168.232.49.158) debian.usu.edu (129.123.104.15) debian.uvigo.es (193.146.32.74) debian.volia.net (82.144.192.7) debian.xtdv.net (118.69.65.177) dennou-k.gfd-dennou.org (130.54.59.159) dennou-q.gfd-dennou.org (133.5.166.3) freedom.dicea.unifi.it (150.217.9.3) free.hands.com (78.129.164.123) ftp2.cn.debian.org (101.6.6.178) ftp2.de.debian.org (137.226.34.46) ftp.acc.umu.se (194.71.11.165) ftp.antik.sk (88.212.10.12) ftp.arnes.si (193.2.1.88) ftp.be.debian.org (195.234.45.114) ftp.belnet.be (193.190.67.98) ftp.bg.debian.org (62.44.96.11) ftp.br.debian.org (200.236.31.3) ftp.caliu.cat (147.83.91.172) ftp.cc.uoc.gr (147.52.159.12) ftp.ch.debian.org (129.132.53.171) ftp-chi.osuosl.org (64.50.236.52) ftp.cn.debian.org (202.38.95.110) ftp.crifo.org (163.172.198.88) ftp.cz.debian.org (195.113.161.73) ftp.debianclub.org (203.150.226.27) ftp.debian.cz (195.113.161.73) ftp.debian.nl (194.109.21.67) ftp.de.debian.org (141.76.2.4) ftp.dk.debian.org (130.225.254.116) ftp.fau.de (131.188.12.211) ftp.gwdg.de (134.76.12.6) ftp.halifax.rwth-aachen.de (137.226.34.46) ftp.icm.edu.pl (193.219.28.2) ftp.iitm.ac.in (203.199.213.69) ftp.is.debian.org (194.105.226.20) ftp.jaist.ac.jp (150.65.7.130) ftp.jp.debian.org (133.5.166.3) ftp.lanet.kr (112.169.81.204) ftp-master.debian.org (138.16.160.17) ftp.metu.edu.tr (144.122.144.177) ftp.mpi-sb.mpg.de (139.19.205.14) ftp.nluug.nl (145.220.21.40) ftp.no.debian.org (194.71.11.165) ftp-nyc.osuosl.org (64.50.233.100) ftp-osl.osuosl.org (140.211.166.134) ftp.rnl.tecnico.ulisboa.pt (193.136.164.6) ftp.se.debian.org (194.71.11.165) ftp.sg.debian.org (210.23.25.77) ftp.sh.cvut.cz (147.32.127.196) ftp-stud.hs-esslingen.de (129.143.116.10) ftp.tu-graz.ac.at (129.27.3.13) ftp.udc.es (193.144.61.75) ftp.uk.debian.org (78.129.164.123) ftp.uni-mainz.de (134.93.178.166) ftp.uni-sofia.bg (62.44.96.11) ftp.u-strasbg.fr (130.79.200.5) ftp.zcu.cz (147.228.57.10) hanzubon.jp (61.115.118.67) kambing.ui.edu (152.118.24.30) merlin.fit.vutbr.cz (147.229.176.19) mirror.0x.sg (210.23.25.77) mirror.aarnet.edu.au (202.158.214.106) mirror.amaze.com.au (122.252.2.42) mirror.applebred.net (103.246.16.176) mirror.as35701.net (195.234.45.114) mirror.bytemark.co.uk (212.110.161.69) mirror.cedia.org.ec (201.159.221.67) mirror.checkdomain.de (46.4.50.2) mirror.corbina.net (195.14.50.21) mirror.crazynetwork.it (93.63.162.59) mirror.csclub.uwaterloo.ca (129.97.134.71) mirror.cse.iitk.ac.in (202.3.77.108) mirror.cse.unsw.edu.au (129.94.242.25) mirror.daniel-jost.net (88.198.52.102) mirror.de.leaseweb.net (37.58.58.140) mirror.dkm.cz (86.49.49.49) mirror.hmc.edu (134.173.34.196) mirror.i3d.net (213.163.76.200) mirror.kku.ac.th (202.28.209.254) mirror.liquidtelecom.com (197.155.77.1) mirror.litnet.lt (193.219.61.87) mirror.math.princeton.edu (128.112.18.21) mirror.nexcess.net (208.69.120.55) mirror.nforce.com (85.159.239.121) mirror.nl.leaseweb.net (5.79.108.33) mirror.one.com (46.30.211.12) mirror.plusserver.com (85.25.85.13) mirror.pmf.kg.ac.rs (147.91.204.28) mirror.poliwangi.ac.id (36.67.40.211) mirror.positive-internet.com (80.87.134.17) mirror.pregi.net (202.90.159.172) mirror.rit.edu (129.21.171.72) mirrors.acm.jhu.edu (128.220.70.55) mirrors.bloomu.edu (148.137.11.75) mirrors.cat.pdx.edu (131.252.208.20) mirrors.dcarsat.com.ar (186.33.231.17) mirrors.dotsrc.org (130.225.254.116) mirrorservice.org (212.219.56.184) mirrors.evowise.com (89.45.92.5) mirror.sinavps.ch (185.73.240.181) mirrors.ircam.fr (129.102.1.37) mirror.sjc02.svwh.net (72.5.72.15) mirrors.kernel.org (198.145.20.143) mirrors.linux.iu.edu (156.56.247.193) mirrors.lug.mtu.edu (141.219.84.115) mirrors.namecheap.com (209.188.21.32) mirrors.netix.net (87.121.121.2) mirrors.ocf.berkeley.edu (169.229.226.30) mirrors.pdx.kernel.org (198.145.20.143) mirrors.sfo.kernel.org (149.20.37.36) mirrors.syringanetworks.net (66.232.64.7) mirror.steadfast.net (208.100.4.53) mirrors.tuna.tsinghua.edu.cn (101.6.6.178) mirrors.ucr.ac.cr (163.178.174.25) mirror.sucs.swan.ac.uk (137.44.10.8) mirrors-usa.go-parts.com (69.46.22.133) mirrors.ustc.edu.cn (202.38.95.110) mirrors.wikimedia.org (208.80.154.15) mirrors.xjtu.edu.cn (202.117.3.45) mirrors.xmission.com (198.60.22.13) mirrors.xservers.ro (89.38.249.150) mirror.t-home.mk (195.26.153.65) mirror.ueb.edu.ec (190.15.128.196) mirror.units.it (140.105.48.55) mirror.usertrust.info (24.26.241.22) mirror.us.leaseweb.net (108.59.10.97) mirror.uta.edu.ec (200.93.227.165) mirror.vorboss.net (5.10.144.130) mirror.yandex.ru (213.180.204.183) oyu-net.jp (61.206.119.174) packages.hs-regensburg.de (194.95.104.50) pkg.adfinis-sygroup.ch (95.128.34.165) pubmirror.plutex.de (109.69.67.245) rsync.osuosl.org (140.211.166.134) security-master.debian.org (82.195.75.93) sft.if.usp.br (143.107.129.14) shadow.ind.ntou.edu.tw (140.121.80.200) suro.ubaya.ac.id (203.114.224.252) syncproxy2.eu.debian.org (130.89.148.10) syncproxy2.wna.debian.org (149.20.4.16) syncproxy3.eu.debian.org (5.153.231.9) syncproxy3.wna.debian.org (209.87.16.40) syncprox
Re: HTTPS metadata in Mirrors.masterlist?
Hi, Axel Beckert wrote: > After having HTTPS-enabled mirrors listed in the Mirrors.masterlist, > the next step would be to make httpredir.debian.org HTTPS-aware. > Currently https://httpredir.debian.org/ shows me the following error > message: > > httpredir.debian.org uses an invalid security certificate. > The certificate is only valid for www.debian.org Due to starting reading the debian-mirrors list from a different e-mail address recently, I missed the anouncement of httpredir.debian.org having died and being redirected to deb.debian.org -- which actually is available via HTTPS. So ignore that part of my mail which was about https://httpredir.debian.org/. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: Digital signature
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
Hi Ben, Ben Hutchings wrote: > > /etc/kernel/postinst.d/initramfs-tools: > > update-initramfs: Generating /boot/initrd.img-4.19.0-4-686-pae > > cp: failed to access '/var/tmp/mkinitramfs_URATxd//usr/bin/touch': Too many > > levels of symbolic links > > E: /usr/share/initramfs-tools/hooks/fsprotect failed with return 1. [...] > The copy_file function applies two > transformations to the target filename: > > 1. If it matches /bin/*, /lib*, or /sbin/*, add /usr to the beginning >since the initramfs is usrmerged. > 2. If it refers a directory, add the basename of the source filename. > > These need to be done in the opposite order, to handle a target > filename of "/bin" correctly. Thanks for the prompt analysis. > This is a bug in initramfs-tools. Ok. Since I can't see any such bug report against initramfs-tools, I will file one after this mail. > But this is a very different problem from the one Chris Lamb > reported. I disagree that it is _very_ different since it has very similar symptoms. The cause might be very differnt, though, indeed. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links
Hi, > cp: failed to access '/var/tmp/mkinitramfs_mSMoqa//usr/bin/busybox': Too many > levels of symbolic links > E: /usr/share/initramfs-tools/hooks/zz-busybox failed with return 1. I'm having a very similar issue which makes me think that this is a more generic issue and not necessarily busybox-specific: /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.19.0-4-686-pae cp: failed to access '/var/tmp/mkinitramfs_URATxd//usr/bin/touch': Too many levels of symbolic links E: /usr/share/initramfs-tools/hooks/fsprotect failed with return 1. update-initramfs: failed for /boot/initrd.img-4.19.0-4-686-pae with 1. run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 dpkg: error processing package linux-image-4.19.0-4-686-pae (--configure): installed linux-image-4.19.0-4-686-pae package post-installation script subprocess returned error exit status 1 Note that it's /usr/bin/touch and /usr/share/initramfs-tools/hooks/fsprotect, but otherwise looks like the same issue. >From my point of view this looks like either an issue in initramfs-tools or in both, busybox and fsprotect (and maybe more) packages not having adapted to breaking changes in initramfs-tools. Chris Lamb wrote: > Whilst you could indeed change this, given that my attempt at usrmerge > failed for reasons unrelated to busybox and/or initramfs generation JFTR: My case is on a non-usrmerge i386 system running Sid. The issue shows up for at least a few weeks now if not longer (hadn't touched that system for a few weeks or so beforehand) and seemingly for all kernels installed or upgraded since it appeared the first time. > Thus, we should probably just close this bug. Huh? If I wouldn't have found this bug report, I'd have filed (and might still file) the above as at least severity serious as it breaks the installation/upgrade of more or less unrelated packages. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#983491: Keyboard Layout configuration wizard - Swiss localization
Hi again,
Axel Beckert wrote:
> But then we should name it "Swiss German/Rumantsch/Liechtenstein
> German" and "Swiss French/Lëtzebuergesch" to be correct in your sense
> of correctness.
*sigh* "Swiss French/Swiss Italian/Lëtzebuergesch" of course.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Emanuele, Emanuele Rocca wrote: > On 2023-10-10 01:45, Axel Beckert wrote: > > I tried that, installer ran through fine, grub boots from disk after > > installation, kernel loads initramfs and then falls into the initramfs > > prompt and fractions of a second later (sometimes even beforehand) the > > whole screen goes black and then nothing helps then pressing the power > > button for about 10 seconds. > > This sounds like you might have missed the wiki step "Add qnoc-sc8280xp > module to initramfs": > https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s I indeed missed that first, but fixed it via rescue mode of the d-i image. > OK then once you chroot into the installed system you should be able to > check if qnoc-sc8280xp is in /etc/initramfs-tools/modules. If not, > > echo qnoc-sc8280xp >> /etc/initramfs-tools/modules Was already in there. > To triple-check that the needed module is in there: > > zstdcat /initrd.img | cpio -itv | grep qnoc-sc8280xp.ko Was also already in there. Additionally there are quite some messages about things being pending due to waiting for something else from that kernel module seconds before the screen blanks. Can send pictures I made of it, in case they could be helpful. And since you've mentioned /initrd.img instead of /boot/initrd.img (as I have a single filesystem installation for now), I also added a symlink at /initrd.img pointing to /boot/initrd.img. But it didn't change anything either. (I later noticed that this likely was unnecessary as GRUB also looks for kernel and initrd.img under /boot and for a versioned file anyways.) > In any case, the daily netinst image should now work! Indeed. Had to use that to check the above today as the mini.iso no more works due to the updated kernel in sid. > There's no need to manually copy any firmware and similar > shenanigans. Well, still quite some shenanigans left for now. > If you have the time, please follow the > InstallingDebianOn/Thinkpad/X13s page again from the begingging to > the end (quite a few things have changed) and let me know if that > works for you. Haven't done a reinstallation for now. (And I'm actually not that keen on it currently, but I will have to do it at some point, because I forgot to enable disk encryption. But I'd first like to understand what's wrong as I seem to have followed all steps.) Via d-i's rescue mode I have also updated the kernel to 6.5.0-2, but the symptoms stay: Lots of "pending/waiting for" message by qnoc-sc8280xp and then a dark, blank screen and nothing happens anymore. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Emanuele, Emanuele Rocca wrote: > On 2023-05-04 11:53, Axel Beckert wrote: > > Sure. I intend to run Debian Unstable on it anyway > > Now you can. :-) Hmmm, I tried a few days ago (October 1st) with the image from https://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/arm64/iso-cd/ and it hang with a message saying something about "generating empty device tree" or so. > https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s Ah, I see, there's much more than just the installer image needed. Thanks for that hint! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Emanuele, Axel Beckert wrote: > Emanuele Rocca wrote: > > On 2023-05-04 11:53, Axel Beckert wrote: > > > Sure. I intend to run Debian Unstable on it anyway > > > > Now you can. :-) > > Hmmm, I tried a few days ago (October 1st) with the image from > https://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/arm64/iso-cd/ > and it hang with a message saying something about "generating empty > device tree" or so. And that image didn't contain the dtb files to copy while the mini.iso from d-i.d.o did. > > https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s > > Ah, I see, there's much more than just the installer image needed. I tried that, installer ran through fine, grub boots from disk after installation, kernel loads initramfs and then falls into the initramfs prompt and fractions of a second later (sometimes even beforehand) the whole screen goes black and then nothing helps then pressing the power button for about 10 seconds. The same happens if I start the recovery mode from the grub menu when booting from the disk. arm64.nopauth is in there. And I can easily install tons of packages when I boot from the installer USB stick into the rescue mode and chroot into the installation on disk. Even installing the recommended packages did not change anything with regards to the screen going black about 12 seconds after booting. I also tried to disable any console font changes via dpkg-reconfigure -plow console-setup console-setup-linux but to no avail. Any ideas what could have gone wrong or how I can fix this? I feel I'm _soooo_ close. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1030627: debootstrap: Causes dpkg segfault in "chroot /… dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb" when trying to bootstrap Wheezy or earlier
Control: tag -1 + moreinfo
Hi,
I think, I found the cause:
Axel Beckert wrote:
> 9440 open("/var/log/dpkg.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 6
> 9440 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> 9440 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7fbf3816
> 9440 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> 9440 lseek(6, 0, SEEK_SET) = 0
> 9440 fcntl(6, F_GETFD) = 0
> 9440 fcntl(6, F_SETFD, FD_CLOEXEC) = 0
> 9440 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=0xff600400} ---
> 9440 +++ killed by SIGSEGV (core dumped) +++
>
> I must admit, I currently don't see which system call caused the
> segfault. Full strace log attached.
I currently suspect it's none of them, but I was testing on a new host
which doesn't have the setting vsyscall=emulate mentioned by myself
(and since then have todally forgotton about) in
https://github.com/xen-tools/xen-tools/blob/master/debian/NEWS
Please don't react on this bug report until I've verified if that's
really the cause.
If it's the cause, I will close this bug report and write down the
hint in a more prominent place. If it's not the cause, I'll remove the
"moreinfo" tag.
And sorry for the potential noise.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1030627: debootstrap: Causes dpkg segfault in "chroot /… dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb" when trying to bootstrap Wheezy or earlier
Control: reassign -1 xen-tools 4.9.1-1 Control: retitle -1 xen-tools: Document configuration needed for older releases better Hi, Axel Beckert wrote: > > I must admit, I currently don't see which system call caused the > > segfault. Full strace log attached. > > I currently suspect it's none of them, but I was testing on a new host > which doesn't have the setting vsyscall=emulate mentioned by myself > (and since then have todally forgotton about) in > https://github.com/xen-tools/xen-tools/blob/master/debian/NEWS Yep, that was it. Sorry for the noise. > If it's the cause, I will close this bug report and write down the > hint in a more prominent place. Well, not closing but reassigning to xen-tools. And wondering where I should put that information better. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1030627: debootstrap: Causes dpkg segfault in "chroot /… dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb" when trying to bootstrap Wheezy or earlier
Package: debootstrap
Version: 1.0.128+nmu2
Severity: normal
Control: affects -1 xen-tools
Running "debootstrap --verbose --arch amd64
--keyring=/usr/share/keyrings/debian-archive-removed-keys.gpg wheezy
/tmp/hH11H2NR4o http://archive.debian.org/debian; (or Debian or Ubuntu
releases older than that) on Sid/Bookworm ends up like this:
[…]
I: Extracting tar...
I: Extracting tzdata...
I: Extracting util-linux...
I: Extracting xz-utils...
I: Extracting zlib1g...
I: Installing core packages...
W: Failure trying to run: chroot "/tmp/hH11H2NR4o" dpkg --force-depends
--install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /tmp/hH11H2NR4o/debootstrap/debootstrap.log for details
Looking into /tmp/hH11H2NR4o/debootstrap/debootstrap.log I find this
dpkg segfault at the end:
[…]
2023-02-05 21:13:42 (1.72 MB/s) -
'/tmp/hH11H2NR4o//var/cache/apt/archives/partial/zlib1g_1%3a1.2.7.dfsg-13_amd64.deb'
saved [87392/87392]
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
missing architecture
Segmentation fault (core dumped)
The segfault seems to have beein in the dpkg inside the chroot, not in
debootstrap:
[1395173.551147] dpkg[17643] vsyscall attempted with vsyscall=none
ip:ff600400 cs:33 sp:7ffcc14c1118 ax:ff600400 si:428720
di:7ffcc14c1130
[1395173.551155] dpkg[17643]: segfault at ff600400 ip ff600400
sp 7ffcc14c1118 error 15 likely on CPU 6 (core 6, socket 0)
[1395173.551160] Code: Unable to access opcode bytes at 0xff6003d6.
/tmp/hH11H2NR4o/var/lib/dpkg/status looks like this afterwards:
Package: dpkg
Status: install ok installed
Maintainer: unknown
Version: 1.16.18
This file seems to have been generated by scripts/debian-common.
Not sure if something changed in the way debootstrap generates initial
files like this, but to me this seems a regression in deboostrap
compared to Bullseye where this still worked. Could have other reasons,
though, too.
Here's end of an "strace -f" of that chrooted dpkg call:
9440 stat("/sbin/start-stop-daemon", {st_mode=S_IFREG|0755, st_size=28152,
...}) = 0
9440 open("/var/lib/dpkg/info/format", O_RDONLY) = 6
9440 fstat(6, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
9440 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7fbf3816
9440 read(6, "1\n", 4096) = 2
9440 close(6) = 0
9440 munmap(0x7fbf3816, 4096) = 0
9440 stat("/var/lib/dpkg/info/format-new", 0x7ffe47838f90) = -1 ENOENT (No
such file or directory)
9440 open("/var/log/dpkg.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 6
9440 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
9440 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7fbf3816
9440 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
9440 lseek(6, 0, SEEK_SET) = 0
9440 fcntl(6, F_GETFD) = 0
9440 fcntl(6, F_SETFD, FD_CLOEXEC) = 0
9440 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0xff600400} ---
9440 +++ killed by SIGSEGV (core dumped) +++
I must admit, I currently don't see which system call caused the
segfault. Full strace log attached.
dpkg-segfault-inside-wheezy-chroot.xz
Description: Result of 'strace -f -o dpkg-segfault-inside-wheezy-chroot -s 65536 chroot /tmp/hH11H2NR4o dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb'
This issue seems to affect these Debian and Ubuntu releases: precise,
oneiric, natty, maverick, lucid, karmic, jaunty, intrepid, hardy, gutsy,
feisty, edgy, dapper, wheezy, squeeze, lenny, etch and sarge.
As wheezy was the most recent Debian release of them, I looked into that
closer as an example to what went wrong.
This issue has been found by running
https://github.com/xen-tools/xen-tools/blob/master/examples/release-testing
on a Bookworm amd64 host with LVM as storage. It bootstraps all releases
listed in
https://github.com/xen-tools/xen-tools/blob/master/etc/distributions.conf
without the "dont-test" tag.
(Bug report written on a different host.)
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'),
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1,
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages debootstrap depends on:
ii wget 1.21.3-1+b2
Versions of packages debootstrap recommends:
ii arch-test 0.20-1
ii debian-archive-keyring 2021.1.1
ii gnupg 2.2.40-1
Versions of
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Emanuele, Emanuele Rocca wrote: > On 2023-05-03 08:16, Axel Beckert wrote: > > Machine: Thinkpad X13s (ARM) > > Sorry, I've realized only after sending my previous message and having a > coffee that this is about the X13s. :) :-) > The X13s is unfortunately not supported by Linux 6.1 that Bookworm will > ship with. Oh, ok. I see. > Hopefully 6.4 will include all the needed patches. xnox's image uses 6.2 so far, i.e. also something newer than 6.1. > > But Dimitri's Ubuntu Installer Live image lunar-desktop-arm64.iso from > > https://people.canonical.com/~xnox/ubuntu-concept/full/daily-live/current/ > > as of 2023-03-07 20:08 booted fine without these issues. > > > > It would be nice if Dimitri (xnox@d.o, Cc'ed) could tell us which fix > > has been applied by him (or Ubuntu) to this image so that we can fix > > this issue also in Debian, maybe even before the release of Bookworm. > > If that image works, then it includes quite a few of out of tree kernel > patches. I see. I kinda hoped it would just be some not enabled drivers or bugs in the .dtb file or so as the D-I RC2 announcement mentioned the X13s explicitly (admittelly only with flash-kernel having gotten support for it). > As per [1] they are unfortunately not going to be applied to > the Debian kernel, we have to wait for upstream inclusion. Sure. I intend to run Debian Unstable on it anyway, so I can wait. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: Bug#1036933: screen-udeb: Should screen really be installed setgid utmp?
Hi,
Sven Joachim wrote:
> Recently I noticed that the screen program in the screen-udeb
> package is installed setgid utmp, and I wonder if this actually
> makes any sense.
I suspect that setgid utmp indeed is not needed the installer context
from a general viewpoint, but screen is rather picky about its
permissions, especially setgid and setuid. (See below.) So our
decision back then was based on the following:
Screen has two supported ways to edit /var/log/wtmp:
A) via setgid utmp
B) via libutempter
Because we didn't want to pull in another library (libutempter) into
the installer when we created screen-udeb (and hence adding the need
to provide a libutempter udeb as well as libutempter freezes before
installer releases, etc.), we decided continue to use (A) for the
screen-udeb while the remainder of the screen package switched from
(A) to (B).
> While I do not have much experience with the installer, I would expect
> it to run all programs as root anyway, so there should be no need for
> setgid there.
Good point. Then again, it shouldn't do any harm for the very same
reason, right?
Screen is particular picky about its and /run/screen's permissions and
it might refuse to work if they're not set to one of the supported
permission combinations. See /usr/share/doc/screen/README.Debian.gz
So changing them definitely needs some additional tests. In general,
I'd prefer to avoid that, especially in the udeb where it does no
harm.
> Having screen installed setgid sets up a secure execution environment
> that precludes the use of certain environment variables, see the
> "Secure-execution mode" section in ld.so(8). Recently ncurses has also
> started to restrict such programs, see #1034372.
Thanks for that pointer, wasn't aware of that kind of feature. But I
fail to see how
https://invisible-island.net/ncurses/NEWS.html#index-t20230408 is
related.
https://invisible-island.net/ncurses/NEWS.html#index-t20230418 and
https://invisible-island.net/ncurses/NEWS.html#index-t20230423 look
more related, though. Maybe a typo in #1034372, 08 vs 18?
Anyway, IMHO ncurses should not care about setuid/setgid when already
called under root. It makes sense under any other user, though.
> Hopefully none of this matters much. I have CC'ed debian-boot, as the
> people working on the installer will be much more qualified to give
> advice than I am.
Cyril Brulebois wrote:
> Given the first sentence of this last paragraph, it looks like we're not
> considering doing anything for Bookworm at this time
That's also the reason why I didn't reply back in May: We were way to
deep into the Bookworm freeze to do anything on that front IMHO. And
the installer just worked fine with regards to its screen usage.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Package: installation-reports Severity: normal Tags: d-i X-Debbugs-Cc: Axel Beckert , Dimitri Ledkov , Debian ARM Mailing List , Manuel Traut Boot method: USB Image version: https://cdimage.debian.org/cdimage/bookworm_di_rc2/arm64/iso-cd/debian-bookworm-DI-rc2-arm64-netinst.iso Date: 2023-05-03, several times between noon and evening (CEST) Machine: Thinkpad X13s (ARM) Partitions: didn't come that far Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect media: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: [Note: Had to disable Secure Boot, to be able to boot from my USB 3.0 stick (plugged into the Thinkpad USB-C docking station). Before disabling Secure Boot I could choose it as boot device but I was always immediately returned to the device's boot device selection menu.] After choosing either "expert install" (first and prefered try) or "graphical expert install" (second try and second choice) I saw these three lines and then nothing more happened: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... Waited 10 minutes at least, i.e. left it alone, did something else and came back later. Even adding the "debug" kernel parameter didn't bring up any more details on what's happening. Ubuntu seems to have had the same problem with Kinetic according to https://www.reddit.com/r/thinkpad/comments/vh1xse/comment/is1pq78/ But Dimitri's Ubuntu Installer Live image lunar-desktop-arm64.iso from https://people.canonical.com/~xnox/ubuntu-concept/full/daily-live/current/ as of 2023-03-07 20:08 booted fine without these issues. It would be nice if Dimitri (xnox@d.o, Cc'ed) could tell us which fix has been applied by him (or Ubuntu) to this image so that we can fix this issue also in Debian, maybe even before the release of Bookworm. (I only read in the recent D-I RC2 annoucement that there is already some support for the X13s, so I haven't tried it beforehand.) -- Package-specific info: [Stripped as — for obvious reasons — the bug report has been written on a different device.]
