Bug#1034124: udev security update breaks all ext4 removable storage handling
Package: udisks2
Version: 2.8.1-4+deb10u1
Severity: serious
Hi,
The security team recently released udisks2 2.8.1-4+deb10u1 that forces
the mount option 'errors=remount-ro' to be used for all mounting
operations on ext4 file systems.
However it seems the code was not modified correctly to allow that
option to be used.
On a system with a LXDE based desktop environment, hot-plugging an ext4
formatted USB drive, result in the user being presented with an "Mount
option `errors=remount-ro' is not allowed" error dialog box, and the
mount not occurring.
Same when mounting manually as regular user through udisksctl:
==
max@pibuster:~ $ udisksctl mount -b /dev/sda2
Error mounting /dev/sda2:
GDBus.Error:org.freedesktop.UDisks2.Error.OptionNotPermitted: Mount
option `errors=remount-ro' is not allowed
==
Looking at debian/patches/mount-ext-readonly-on-errors.patch
It did seem the author of the patch knew options need to be allowed, as
he does add "errors=remount-ro" to ext4_allow:
+static const gchar *ext4_allow[] = { "errors=remount-ro", NULL };
However looking at is_mount_option_allowed() in
src/udiskslinuxfilesystem.c the allow list handling code only expect a
lists of allowed option keys in ext4_allow, not entries in the form
key=value...
So that is not going to fly without further changes to
is_mount_option_allowed()...
Yours sincerely,
Floris Bos
Bug#926037: systemd: localectl console keymap configuration delayed
On 1/2/22 2:10 PM, Michael Biebl wrote: On 02.01.22 13:32, Floris Bos wrote: I recall in some cases it is also necessary to regenerate initramfs after a keyboard settings change. E.g. when LUKS encryption is used and the user needs to be able to enter the password to unlock the disks in the console prior to the rest of the system being booted. So just restarting one of the services actually may not be enough. Well, I'm not yet convinced that doing this in localed is the correct place. After all, if you run dpkg-reconfigure console-setup, it doesn't update the initramfs either, or does it? It does on my Ubuntu box. Not certain about upstream Debian. -- Yours sincerely, Floris Bos
Bug#926037: systemd: localectl console keymap configuration delayed
On 1/2/22 12:01 PM, Michael Biebl wrote: On 19.12.21 00:56, Floris Bos wrote: Yes, your Debian specific stuff in debian/patches/debian/Use-Debian-specific-config-files.patch only seems to set /etc/default/keyboard However with other Linux distributions the setting is also instantly applied to console, so that is what me and other users are expecting. With other Linux distributions this seems to be done by restarting the systemd-vconsole-setup unit in src/local/localed.c vconsole_reload() : https://github.com/systemd/systemd/blob/main/src/locale/localed.c#L97 Think that function needs to be patched by whatever is necessary to have the change do take effect on Debian (run "dpkg-reconfigure keyboard-configuration" and "setupcon -k --force" ?) Currently we disable vconsole via debian/rules, so there is no systemd-vconsole-setup.service. Maybe a fix could be as simple as shipping a symlink systemd-vconsole-setup.service → keyboard-setup.service ? Or do we need to restart console-setup.service as well? I recall in some cases it is also necessary to regenerate initramfs after a keyboard settings change. E.g. when LUKS encryption is used and the user needs to be able to enter the password to unlock the disks in the console prior to the rest of the system being booted. So just restarting one of the services actually may not be enough. Yours sincerely, Floris Bos
Bug#926037: systemd: localectl console keymap configuration delayed
Hi, This issue is still present in recent Debian/Ubuntu versions. > Am 30.03.19 um 18:11 schrieb Iiro Laiho: > > When I set the system keymap using the "localectl" command, the > > application of the new layout to the virtual consoles is delayed. On Sun, 31 Mar 2019 20:23:09 +0200 Michael Biebl wrote: > TTBOMK, localectl just writes to /etc/default/keyboard and /etc/default > /console-setup and leaves it up to console-setup to apply those changes, > which is usually done during bootup. Yes, your Debian specific stuff in debian/patches/debian/Use-Debian-specific-config-files.patch only seems to set /etc/default/keyboard However with other Linux distributions the setting is also instantly applied to console, so that is what me and other users are expecting. With other Linux distributions this seems to be done by restarting the systemd-vconsole-setup unit in src/local/localed.c vconsole_reload() : https://github.com/systemd/systemd/blob/main/src/locale/localed.c#L97 Think that function needs to be patched by whatever is necessary to have the change do take effect on Debian (run "dpkg-reconfigure keyboard-configuration" and "setupcon -k --force" ?) Yours sincerely, Floris Bos
Bug#1001599: "x11vnc -auth guess" not working properly due to missing dependency on x11-utils
Package: x11vnc When x11vnc is started with "-auth guess" it runs a script that may call xdpyinfo. This fails in cases the x11-utils package that provides xdpyinfo is not installed on the user's system. Suggest a dependency on x11-utils is added to the x11vnc package. Related to: https://github.com/LibVNC/x11vnc/issues/105
Bug#929410: RANDR extension not present
Package: tigervnc-scraping-server Version: 1.9.0+dfsg-3 Seems the tigervnc package is missing randr support. == $ x0tigervncserver -SecurityTypes none Wed May 22 22:20:30 2019 Geometry: Desktop geometry is set to 1024x768+0+0 XDesktop: Using evdev codemap XDesktop: XTest extension present - version 2.2 XDesktop: RANDR extension not present XDesktop: Will not be able to handle session resize Main: Listening on port 5900 ^C == While my system/X server certainly has the RANDR extension: == $ xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 7680 x 7680 HDMI-1 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.00* 800x600 60.32 56.25 848x480 60.00 640x480 59.94 == Think you are missing a build dependeny on the libxrandr2 library. If HAVE_XRANDR is not set at compile time, it always prints the message ( https://github.com/TigerVNC/tigervnc/blob/master/unix/x0vncserver/XDesktop.cxx#L182 )
Bug#928517: current symlink missing for jessie
Package: mirrors http://ftp.debian.org/debian/dists/jessie/main/installer-amd64/current/ no longer exists. - It used to be there. - "current" is still there for other Debian releases. (e.g. http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/ ) We have some scripts that dedicated server providers use to provision servers in datacenters (PXE network installations), and those expect "current" to be there... Yours sincerely, Floris Bos
Bug#888440: [Pkg-openldap-devel] Bug#888440: "dpkg-reconfigure slapd" fails if backup directory already exists
On 01/25/2018 05:54 PM, Ryan Tandy wrote: Nor an option to simply not move the thing, but delete it. We already have a dump of it, right? Not sure. We have a dump of the config, but I don't think it dumps the data, does it? That's pretty confusing as well. You are right, in this case it only seems to have copied configuration to dump_database_destdir While the documentation suggests that directory is meant to dump the whole database to on upgrades: == Template: slapd/dump_database Type: select __Choices: always, when needed, never Default: when needed _Description: Dump databases to file on upgrade: Before upgrading to a new version of the OpenLDAP server, the data from your LDAP directories can be dumped into plain text files in the standard LDAP Data Interchange Format. . Selecting "always" will cause the databases to be dumped unconditionally before an upgrade. Selecting "when needed" will only dump the database if the new version is incompatible with the old database format and it needs to be reimported. If you select "never", no dump will be done. Template: slapd/dump_database_destdir Type: string Default: /var/backups/slapd-VERSION _Description: Directory to use for dumped databases: Please specify the directory where the LDAP databases will be exported. In this directory, several LDIF files will be created which correspond to the search bases located on the server. Make sure you have enough free space on the partition where the directory is located. The first occurrence of the string "VERSION" is replaced with the server version you are upgrading from. == This can confuse unwitting users into thinking they do have a backup of everything, as the directory do is filled with .ldif files. Yours sincerely, Floris Bos
Bug#888440: [Pkg-openldap-devel] Bug#888440: "dpkg-reconfigure slapd" fails if backup directory already exists
Hi, On 01/25/2018 05:54 PM, Ryan Tandy wrote: On Thu, Jan 25, 2018 at 05:05:27PM +0100, Floris Bos wrote: I am not seeing any easy option to prevent this from happening. Removing the existing backup first isn't easy enough? If you can guarantee us that the name of the folder we would need to delete is always /var/backups/unknown-2.4.44+dfsg-5+deb9u1.ldapdb -even in future package updates- that is a possibility. However would prefer not to make assumptions like that :-) There is a preseed option (slapd/dump_database_destdir) to change the backup directory the database dump goes to, but that doesn't seem to affect the directory the old folder is moved to. Oh, really? If I understand you correctly, that sounds like a second bug - not respecting destdir for that location? It is respecting it for the destination of the database dump. But in addition to making a database dump, it also wants to move the original folder to /var/backups, and I do not see any option to change that destination. == # echo "slapd slapd/dump_database_destdir string /var/backups/just-testing" | debconf-set-selections # DEBIAN_FRONTEND=noninteractive dpkg-reconfigure slapd Backing up /etc/ldap/slapd.d in /var/backups/just-testing... done. Moving old database directory to /var/backups: Backup path /var/backups/unknown-2.4.44+dfsg-5+deb9u1.ldapdb exists. Giving up... == Yours sincerely, Floris Bos
Bug#888440: "dpkg-reconfigure slapd" fails if backup directory already exists
Package: slapd Version: 2.4.44+dfsg-5+deb9u1 Hi, Currently "dpkg-reconfigure slapd" wants to move the old database directory to /var/backups However this fails if there already exists such a directory in /var/backups from a previous run. == # DEBIAN_FRONTEND=noninteractive dpkg-reconfigure slapd Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.44+dfsg-5+deb9u1... done. Moving old database directory to /var/backups: Backup path /var/backups/unknown-2.4.44+dfsg-5+deb9u1.ldapdb exists. Giving up... == I am not seeing any easy option to prevent this from happening. There is a preseed option (slapd/dump_database_destdir) to change the backup directory the database dump goes to, but that doesn't seem to affect the directory the old folder is moved to. Nor an option to simply not move the thing, but delete it. We already have a dump of it, right? Yours sincerely, Floris Bos
Bug#888426: certtool has year 2k38 problem, giving problems for scripts that generate 20 year certs today
Package: gnutls-bin Version: 3.5.8-5+deb9u3 Severity: important Hi, Seems certtool (at least the version shipped with Debian Stretch) has a year 2038 problem on 32-bit architectures. We have a program that generates SSL certificates with 20 year validity for communication within an internal network, and it started failing today. To reproduce (on i386 arch): == $ certtool --generate-privkey --outfile test.key Generating a 3072 bit RSA private key... $ cat >test.tpl <$ certtool --generate-self-signed --load-privkey test.key --template test.tpl Generating a self signed certificate... Overflow while parsing days == Does work if setting date backwards to yesterday. == $ sudo date --set '2018-1-24' Wed 24 Jan 00:00:00 GMT 2018 $ certtool --generate-self-signed --load-privkey test.key --template test.tpl Generating a self signed certificate... X.509 Certificate Information: Version: 3 Serial Number (hex): 5a67cc853834650f7069e6eb Validity: Not Before: Wed Jan 24 00:00:05 UTC 2018 Not After: Thu Dec 31 23:23:23 UTC 2037 [...] == Yours sincerely, Floris Bos
Bug#568577: Please provide pam-auth-update rule for pam_mkhomedir
On 02/05/2010 11:25 PM, Petter Reinholdtsen wrote: Package: libpam-runtime Version: 1.1.1-1 Severity: wishlist File: /usr/sbin/pam-auth-update Tags: patch User: debian-...@lists.debian.org UserTags: debian-edu It would be nice if the pam_mkhomedir module was handled by pam-auth-update, to allow it to be enabled during installation using preseeding. It is useful when setting up system loading home directories from windows servers. Here is a proposal for the content to put in /usr/share/pam-configs/mkhomedir, based on the setup provided for windows users with windows home directories. Any update on this bug? Meanwhile downstream distributions like Ubuntu did add /usr/share/pam-configs/mkhomedir to their libpam-runtime package. And it is kinda annoying to have Debian and Ubuntu behave differently, if you are writing scripts that are supposed to work on both. Yours sincerely, Floris Bos
Bug#862225: pam_mount mounts using old password when a password change is forced on login
On 06/26/2017 08:53 AM, Jochen Sprickerhof wrote: Hi Floris, Thanks for the bug report, I plan to add it in the next release. * Floris Bos <b...@je-eigen-domein.nl> [2017-05-10 00:38]: passwordoptionalpam_mount.so disable_interactive Is there any reason for the disable_interactive? Without it, it prompted for password. Not sure why it did that. -- Yours sincerely, Floris Bos
Bug#862225: pam_mount mounts using old password when a password change is forced on login
Package: libpam-mount Version: 2.14-1.1 I have a setup where client computers run Debian Jessie and use: - libpam-ldapd for authentication - libpam-mount to mount a remote home directory through sshfs, using the login password entered by the user. The remote server uses the same ldap server for authentication. Normally works. However if the user's password has expired, and he is forced to change it straight away on login, libpam-mount fails to mount the home directory. It tries to login to the remote server with the old password, instead of the changed new one. It seems the Debian package only adds libpam-mount to /etc/pam.d/common-auth (to capture the entererd password), and /etc/pam.d/common-session (where it uses the earlier captured password to do the actual mount). However to be able to capture the new password on forced password changes on login, it should also be added to /etc/pam.d/common-password Adding the following line there seems to fix it for me: passwordoptionalpam_mount.so disable_interactive -- Yours sincerely, Floris Bos
Bug#681801: Preseeding console-keymaps-at/keymap=us no longer works to select keymap
Package: console-setup-udeb Version: 1.80 We perform automated preseeded Debian installations. With Debian Squeeze we are able to use the following boot parameters to prevent Debian from prompting for country and keyboard settings: == debian-installer/locale=en_US kbd-chooser/method=us console-keymaps-at/keymap=us == However with Wheezy this no longer works, and we get prompted for keyboard map regardless (screenshot: http://s17.postimage.org/on6is922n/keymap_prompt.png ) In case a different preseed value then console-keymaps-at/keymap=us is necessary nowadays, please update the documentation ( http://d-i.alioth.debian.org/manual/en.amd64/apbs04.html#preseed-l10n ) -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635161: open-iscsi: add a udeb
Hi, On Saturday, July 23, 2011 12:37:29 PM Colin Watson wrote: I'd like to merge Ubuntu's support for iSCSI during d-i back into Debian. Here's a patch for open-iscsi to add a udeb, which is the first step in making this work. Once this has landed, I'll merge the partman-iscsi work I've done into the d-i repository. I was wondering why the upstream iscsistart is not included in the udeb. That way it would be possible to simply call iscsistart -b if an iBFT table is present to auto-configure the iSCSI settings, without having to prompt the user. Related bugs: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495042#15 (debian-installer: add iscsi root installation) -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495042: debian-installer: add iscsi root installation
Hi,
Bumping an old feature request.
On Thursday, August 14, 2008 09:42:31 AM you wrote:
Add iscsi root installation feature to debian installer.
I was wondering if there were any plans to add this?
Did experiment a bit with it myself, and it's not that much work to simply
detect the iSCSI settings set in the BIOS/boot firmware, and connect to the
iSCSI target automatically, like CentOS and Windows do.
See the attached (unpolished) patches as a starting point of a way this can be
done.
In short what is necessary is:
- check for the presence of an iBFT table in memory. This can be done by
loading the iscsi_ibft kernel module and checking /sys.
Since it only scans a memory region and does not do any more agressive
probing, it's safe to load by default.
- if found, it means iSCSI is configured on the computer and the other iscsi
kernel modules should be loaded. As well as an udeb with the open-scsi
usermode tools that are responsible for setting up the connection. Calling
iscsistart -b is enough to automatically connect to the target using the
information found in the iBFT and attach the disks.
- make sure open-iscsi is added to the packages to be installed, and that a
initramfs with iscsi support is created, so that the system will start after
reboot.
--
Yours sincerely,
Floris Bos
diff -ur hw-detect-1.87.orig/debian/disk-detect.templates hw-detect-1.87/debian/disk-detect.templates
--- hw-detect-1.87.orig/debian/disk-detect.templates 2011-06-23 21:57:17.0 +0200
+++ hw-detect-1.87/debian/disk-detect.templates 2011-07-13 01:10:41.0 +0200
@@ -42,3 +42,13 @@
Description: for internal use; can be preseeded
Check for the presence of multipath devices?
+Template: disk-detect/iscsi_connect
+Type: text
+# :sl2:
+_Description: Connecting to iSCSI target
+
+Template: disk-detect/iscsi_error
+Type: error
+# :sl2:
+_Description: Error connecting to iSCSI target (using the login information found in the iBFT)
+
diff -ur hw-detect-1.87.orig/disk-detect.sh hw-detect-1.87/disk-detect.sh
--- hw-detect-1.87.orig/disk-detect.sh 2011-06-23 21:57:17.0 +0200
+++ hw-detect-1.87/disk-detect.sh 2011-07-13 01:24:09.0 +0200
@@ -120,10 +120,31 @@
fi
}
+iscsi_probe() {
+
+ log Looking for iSCSI iBFT table...
+ modprobe iscsi_ibft || true
+
+ if [ -e /sys/firmware/ibft/target0 ]; then
+ anna-install open-iscsi-udeb
+ modprobe iscsi_tcp
+ db_progress START 0 1 disk-detect/iscsi_connect
+ iscsistart -b || db_input high disk-detect/iscsi_error
+ db_progress STOP
+ apt-install open-iscsi || true
+ else
+ log No iSCSI iBFT table found, not loading iSCSI package
+ fi
+
+ return 0
+}
+
if ! hw-detect disk-detect/detect_progress_title; then
log hw-detect exited nonzero
fi
+iscsi_probe
+
while ! disk_found; do
CHOICES=
for mod in $(list_disk_modules | sort); do
diff -ur kernel-wedge-2.77.orig/modules/scsi-modules kernel-wedge-2.77/modules/scsi-modules
--- kernel-wedge-2.77.orig/modules/scsi-modules 2011-03-12 19:38:58.0 +0100
+++ kernel-wedge-2.77/modules/scsi-modules 2011-07-11 20:03:03.0 +0200
@@ -26,3 +26,5 @@
aic94xx ?
stex ?
xen-blkfront ?
+iscsi_tcp ?
+iscsi_ibft ?
diff -urN open-iscsi-2.0.871.3.orig/debian/control open-iscsi-2.0.871.3/debian/control
--- open-iscsi-2.0.871.3.orig/debian/control 2011-05-02 20:52:46.0 +0200
+++ open-iscsi-2.0.871.3/debian/control 2011-07-11 19:31:03.0 +0200
@@ -28,6 +28,15 @@
The userspace component consists of a daemon, iscsid and a management
utility, iscsiadm
+Package: open-iscsi-udeb
+Architecture: any
+Section: debian-installer
+XC-Package-Type: udeb
+Depends: ${shlibs:Depends}, ${misc:Depends}, scsi-modules, libnss-files-udeb
+Description: Open-iSCSI initiator
+ .
+ For use by debian-installer.
+
#Package: linux-iscsi-modules-source
#Architecture: all
#Depends: ${shlibs:Depends}, ${misc:Depends}, module-assistant, debhelper (= 4.0.0), bzip2
diff -urN open-iscsi-2.0.871.3.orig/debian/extra/initramfs.hook open-iscsi-2.0.871.3/debian/extra/initramfs.hook
--- open-iscsi-2.0.871.3.orig/debian/extra/initramfs.hook 2011-05-02 20:52:46.0 +0200
+++ open-iscsi-2.0.871.3/debian/extra/initramfs.hook 2011-07-13 01:02:57.0 +0200
@@ -26,6 +26,6 @@
cp /etc/iscsi/initiatorname.iscsi $DESTDIR/etc
cp /etc/iscsi/iscsi.initramfs $DESTDIR/etc
-for x in crc32c libcrc32c iscsi_tcp libiscsi scsi_transport_iscsi; do
+for x in crc32c libcrc32c iscsi_tcp iscsi_ibft libiscsi scsi_transport_iscsi; do
manual_add_modules ${x}
done
diff -urN open-iscsi-2.0.871.3.orig/debian/open-iscsi-udeb.dirs open-iscsi-2.0.871.3/debian/open-iscsi-udeb.dirs
--- open-iscsi-2.0.871.3.orig/debian/open-iscsi-udeb.dirs 1970-01-01 01:00:00.0 +0100
+++ open-iscsi-2.0.871.3/debian/open-iscsi-udeb.dirs 2011-07-11 23:20:22.0 +0200
@@ -0,0 +1,5 @@
+usr/bin
+usr/sbin
+var/lib/open-iscsi
+usr/lib/finish-install.d
+etc/iscsi
diff -urN open-iscsi-2.0.871.3.orig/debian/open-iscsi
Bug#615600: BOOTIF= kernel commandline option does not work
Hi,
On Tuesday, March 01, 2011 04:28:16 pm Marc Haber wrote:
On Sun, Feb 27, 2011 at 04:22:28PM -0400, Joey Hess wrote:
Thomas Mieslinger wrote:
I try to install a HP DL180G6 fully automated. The Server has an
addtional dualport NIC. kernel and initrd are loaded over the NIC
labeled 0 on the Box, after the kernel has initialized all NICs the
first Ethernet on the add in card is eth0.
~ # cat /proc/cmdline
initrd=/boot/DEBIAN6_x8664/initrd.gz
preseed/url=http://4.3.2.1/installation/profiles/1cc1deebab9e
BOOTIF=01-1C-C1-DE-EB-AB-9E BOOT_DEBUG=2 DEBCONF_DEBUG=5 fb=false
BOOTIF is a pxelinux boot parameter. It is supported by the Debian
initramfs when pxe booting, but it is not supported by the Debian
installer.
Perhaps it should be. In the meantime, you can use the documented
preseeding interface of booting with interface=eth1. I don't think
netcfg allows specifying a interface by MAC though.
I guess the following changes do kind of a job:
etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
ACTION==add, SUBSYSTEM==net, IMPORT{program}=bootif $attr{address}
The related Ubuntu bug has a patch as well:
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/56679
(Matt already mentioned he doesn't like that patch, so it's not a permantent
solution.
But if you are just looking for a quick fix for now, you can use it in your own
build).
--
Yours sincerely,
Floris Bos
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: closed by Matthew Palmer mpal...@debian.org
On Monday, February 07, 2011 06:00:40 am Matthew Palmer wrote: Also, busybox patches should be put into a separate bug report which blocks this one, to keep things clear. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606654 - Busybox should include arping applet Regarding IPv6: I see there is already a bug for building a ndisc6-udeb: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611330 but it seems the idea is to put only rdisc6 in there: == I've now discovered that I need the rdisc6 tool as well as rdnssd, so the attached patch now builds an ndisc6-udeb containing just the rdisc6 binary. == Would it be possible to include the ndisc6 binary as well, and use that in the same way as arping? -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562122: Improve preseeding of network device to use
Bumping an old bug. I've preseeded netcfg/choose_interface to auto, to try and avoid the netcfg/choose_interface question being asked. What I suspect is the problem, is the wireless interface is showing link so the question still gets asked. My thoughts on how to extend this functionality was: allow preseeding the interface to use based on: 1) vendor component of the MAC 2) PCI ID 3) some substring of the interface description because preseeding the specific interface by name is a non-starter, due to the way Linux can't consistently enumerate the interfaces. I think that at least selection of the network interface by MAC-address instead of interface name should be possible. There is currently a patch pending for Ubuntu: http://launchpadlibrarian.net/60443113/S31pxedust (belonging to bug https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/56679 ) Any chance of getting this into Debian as well? -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542441: #542441 Re: old LVM data is not erased
Hi, This old bug is still present in Squeeze, except that I have only seen it cause issues on systems with more than one disk. If there is a LVM volume on the 2nd disk that has a group name that is the same Debian wants to use, install fails with a red Volume group name already in use To reproduce on a (virtual) system with 2 disks: - install Debian. - swap the disks cables, so that disk 1 becomes disk 2. - try to install Debian again. I think Debian should remove the labels from ALL disks if I specify partman- lvm/device_remove_lvm. Or as an alternate solution pick a random volume group name by default, so there are not any conflicts. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607847: ITP: php5-ioncube-nonfree -- Ioncube loader PHP module
Package: wnpp Severity: wishlist Owner: Floris Bos b...@je-eigen-domein.nl * Package name: php5-ioncube-nonfree Version : 4.0.1 Upstream Author: Ioncube * URL: http://www.ioncube.com/loaders.php * License: Commercial Description: Many commercial PHP web applications distribute their files as ionCube bytecode. To be able to execute the bytecode, a loader has to be installed as PHP module. The loader is available at: http://www.ioncube.com/loaders.php (binary only) Its license allows redistribution: == [...] 2 DISTRIBUTION 2.1 The Loader may be freely distributed to third parties alone or as part of a distribution containing other items provided that this license is also included. 2.2 The Loader may under no circumstances be branded as another product, whether distributed or not. 2.3 Distribution as part of a commercial product is permitted provided such distribution is in accordance with clauses 2.1 and 2.2 with respect to the Loader. == While I understand the issues some folks have with closed source software, this piece of software is just as essential for the average webhosting company, as for example the Flash plug-in is for the average desktop user. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537271: debian-installer: network may not be usable as soon as link is up
On Thursday, July 16, 2009 05:39:24 pm you wrote: the debian-installer seems to assume that the network is usable as soon as the link comes up, which may not be the case if the 802.1d spanning tree protocol is in use, in which case it can be up to ~30 seconds before the switch port will forward ethernet frames. i've noticed that trying to preseed a network install on a machine attached to an STP-enabled switch usually fails since as soon as the network link is up, d-i attempts to perform a reverse DNS lookup and fetch the preseed.cfg file via HTTP, both of which timeout and fail before the switch port the machine is attached to enters the forwarding state. a nice strategy to detect if the network is usable might be to send ARP requests for the default gateway's IP address and consider the network up only after the default gateway is reachable. it looks like there is a busybox version of the arping utility that could help accomplish this. Quick dirty workaround if enabling arping in busybox (or implementing the same in C in netcfg itself) is not an option, may also be to simply increase the number of ARP retries. echo 60 /proc/sys/net/ipv4/neigh/eth0/mcast_solicit -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606515: Preseed installation does not wait for network to be ready
Hi,
Attached a patch to netcfg that waits for the link to come up before
proceeding.
It times out after 10 seconds, so if link detection is broken for some reason
it doesn't affect the install.
--
Yours sincerely,
Floris Bos
diff -ur netcfg.orig/Makefile netcfg/Makefile
--- netcfg.orig/Makefile 2009-10-28 21:37:37.0 +0100
+++ netcfg/Makefile 2010-12-11 20:51:10.362642461 +0100
@@ -26,7 +26,7 @@
all: $(TARGETS)
-netcfg-static: netcfg-static.o static.o
+netcfg-static: netcfg-static.o static.o ethtool-lite.o
netcfg: netcfg.o dhcp.o static.o ethtool-lite.o
$(TARGETS): $(COMMON_OBJS)
diff -ur netcfg.orig/netcfg.h netcfg/netcfg.h
--- netcfg.orig/netcfg.h 2010-09-06 23:53:19.0 +0200
+++ netcfg/netcfg.h 2010-12-11 20:10:50.761351395 +0100
@@ -41,6 +41,9 @@
ff02::1 ip6-allnodes\n \
ff02::2 ip6-allrouters\n
+/* Maximum number of seconds to wait for network link to come up */
+#define LINK_TIMEOUT 10
+
typedef enum { NOT_ASKED = 30, GO_BACK } response_t;
typedef enum { DHCP, STATIC, DUNNO } method_t;
typedef enum { ADHOC = 1, MANAGED = 2 } wifimode_t;
diff -ur netcfg.orig/static.c netcfg/static.c
--- netcfg.orig/static.c 2010-12-11 20:03:12.091975462 +0100
+++ netcfg/static.c 2010-12-11 20:49:30.851349894 +0100
@@ -269,10 +269,10 @@
int netcfg_activate_static(struct debconfclient *client)
{
-int rv = 0, masksize;
+int rv = 0, masksize, tries = 0;
char buf[256];
char ptr1[INET_ADDRSTRLEN];
-
+
#ifdef __GNU__
snprintf(buf, sizeof(buf),
settrans -fgap /servers/socket/2 /hurd/pfinet --interface=%s --address=%s,
@@ -381,6 +381,16 @@
debconf_capb(client, backup);
return -1;
}
+
+di_info(Waiting for the link of interface %s to come up, interface);
+
+do {
+usleep(10); /* sleep a tenth of a second */
+if (++tries LINK_TIMEOUT*10) {
+di_info(Link did not come up, but timeout expired, continuing...);
+break;
+}
+} while ( ethtool_lite(interface) == 2 /*DISCONNECTED*/ );
return 0;
}
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
On Saturday, December 11, 2010 07:31:48 am Christian PERRIER wrote:
Correct. Apparently, though, that behaviour didn't bother anybody
enough to look at current netcfg code and propose the needed patch
Fair enough.
Attached a patch that introduces a new netcfg/hostname option that -if set-
takes precedence over the RDNS/DHCP hostname
magic.
This patch has a dependency on my other bug/patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606515 (Preseed
installation does not wait for network to be ready)
Because if netcfg/hostname is set, the reverse DNS check is skipped, and the
chance is higher that the installer attempts to fetch
the kickstart file before the network link is up running.
--
Yours sincerely,
Floris Bos
diff -ur netcfg.orig1/debian/netcfg-common.templates netcfg/debian/netcfg-common.templates
--- netcfg.orig1/debian/netcfg-common.templates 2009-09-12 16:13:23.0 +0200
+++ netcfg/debian/netcfg-common.templates 2010-12-11 17:20:01.361351304 +0100
@@ -105,6 +105,12 @@
administrator. If you are setting up your own home network, you can make
something up here.
+Template: netcfg/hostname
+Type: string
+Description: Hostname that can be preseeded.
+ .
+ If specified this disables the automatic detection of the hostname by netcfg.
+
Template: netcfg/invalid_hostname
Type: error
# :sl2:
diff -ur netcfg.orig1/dhcp.c netcfg/dhcp.c
--- netcfg.orig1/dhcp.c 2010-08-06 23:49:44.0 +0200
+++ netcfg/dhcp.c 2010-12-11 23:18:25.841977721 +0100
@@ -473,12 +473,19 @@
}
/*
- * Default to the hostname returned via DHCP, if any,
+ * If the netcfg/hostname preseed value is set use that
+ * Otherwise default to the hostname returned via DHCP, if any,
* otherwise to the requested DHCP hostname
* otherwise to the hostname found in DNS for the IP address
* of the interface
*/
-if (gethostname(buf, sizeof(buf)) == 0
+debconf_get(client, netcfg/hostname);
+if (!empty_str(client-value))
+{
+strncpy(buf, client-value, sizeof(buf));
+debconf_set(client, netcfg/get_hostname, buf);
+}
+else if (gethostname(buf, sizeof(buf)) == 0
!empty_str(buf)
strcmp(buf, (none))
verify_hostname(buf) == 0
diff -ur netcfg.orig1/static.c netcfg/static.c
--- netcfg.orig1/static.c 2010-08-06 06:32:41.0 +0200
+++ netcfg/static.c 2010-12-12 00:12:44.691551386 +0100
@@ -454,9 +464,28 @@
GET_GATEWAY : CONFIRM;
break;
case GET_HOSTNAME:
-seed_hostname_from_dns(client, ipaddress);
-state = (netcfg_get_hostname(client, netcfg/get_hostname, hostname, 1)) ?
-GET_NAMESERVERS : GET_DOMAIN;
+debconf_get(client, netcfg/hostname);
+if (!empty_str(client-value)) {
+/* Copy preseeded netcfg/hostname to hostname variable and netcfg/get_hostname */
+hostname = strdup(client-value);
+debconf_set(client, netcfg/get_hostname, hostname);
+
+/* FQDN? Then set domain */
+char *s = strchr(hostname, '.');
+if (s s[1] != '\0') {
+domain = strdup(s + 1);
+debconf_set(client, netcfg/get_domain, domain);
+have_domain = 1;
+*s = '\0';
+}
+state = GET_DOMAIN;
+
+} else {
+seed_hostname_from_dns(client, ipaddress);
+state = (netcfg_get_hostname(client, netcfg/get_hostname, hostname, 1)) ?
+GET_NAMESERVERS : GET_DOMAIN;
+}
+
break;
case GET_DOMAIN:
if (!have_domain) {
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
Package: netcfg Version: 1.46 The value specified using netcfg/get_hostname seems to be ignored, if a reverse DNS entry is present for the IP-address of the server being installed. Seems to be a bit similar to this bug: http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=544513 (dhcp returned hostname take precedence on netcfg/get_hostname) Except in my case it seems the reverse DNS hostname is used, instead of the DHCP hostname. I think netcfg/get_hostname should take precendence over everything else. Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606654: Busybox should include arping applet
Package: busybox-udeb Version: 1.10.2-2 I think the arping applet should be enabled in the Busybox build. It helps a great deal in debugging general network issues and could be helpful to create a solution for some other bugs like: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537271 (network may not be usable as soon as link is up) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606515 (Preseed installation does not wait for network to be ready) Yours sincerely, Floris Bos --- busybox-1.10.2/debian/config/config.udeb.orig 2010-12-10 16:13:59.0 +0100 +++ busybox-1.10.2/debian/config/config.udeb 2010-12-10 16:14:28.0 +0100 @@ -589,7 +589,7 @@ # CONFIG_FEATURE_PREFER_IPV4_ADDRESS is not set # CONFIG_VERBOSE_RESOLUTION_ERRORS is not set # CONFIG_ARP is not set -# CONFIG_ARPING is not set +CONFIG_ARPING=y # CONFIG_BRCTL is not set # CONFIG_FEATURE_BRCTL_FANCY is not set # CONFIG_DNSD is not set
Bug#606654: Busybox should include arping applet
Hi, On Friday, December 10, 2010 05:12:39 pm Ferenc Wagner wrote: Floris Bos b...@je-eigen-domein.nl writes: I think the arping applet should be enabled in the Busybox build. It helps a great deal in debugging general network issues and could be helpful to create a solution for some other bugs like: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537271 (network may not be usable as soon as link is up) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606515 (Preseed installation does not wait for network to be ready) Please read http://wiki.debian.org/DebianInstaller/FAQ#Q.3AWhyispingnotavailableinthede bugshell Roughly the same applies to arping. After all, you can cat /proc/net/arp to check whether the gateway has a complete entry. But wouldn't you need to initiate network communication before an entry in /proc/net/arp for the gateway appears? Right now PXE preseed installations are broken, making Debian unsuitable for use by dedicated server providers. The Debian installer does not wait for the network link to come up (can take about 3 seconds on some NICs connected to a standard Gigabit switch), nor does it take into account that it can take 30 seconds before network activity is possible in spanning tree configurations. A simply 1-line fix if we had arping might be executing between netcfg and network-preseed: arping -f -c 35 $GATEWAY_IP (wait until you get an ARP reply from the gateway, timeout after 35 seconds/tries). I don't think calling wget 35 times, and grepping /proc/net/arp is a clean alternative, just to save 4 KB of space. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
Hi, On Friday, December 10, 2010 05:17:15 pm Ferenc Wagner wrote: Floris Bos b...@je-eigen-domein.nl writes: The value specified using netcfg/get_hostname seems to be ignored, if a reverse DNS entry is present for the IP-address of the server being installed. [...] I think netcfg/get_hostname should take precendence over everything else. Half of the current behaviour is documented in http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-network Maybe the idea was to enable skipping the question without specifying a fixed name. Well, if you think people rely on the current behavior because it's partial documented, then treat my bug report as a feature request for a preseed option to override this behavior. Not everyone has the power to change their own reverse DNS entries, or it might take time to process (send a request to the upstream provider that is responsible for the IP block, wait for them to process it, and reload the nameserver zonefile). And people like to be able to choose their own hostname. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
On Friday, December 10, 2010 09:53:42 pm Ferenc Wagner wrote: Not everyone has the power to change their own reverse DNS entries, or it might take time to process (send a request to the upstream provider that is responsible for the IP block, wait for them to process it, and reload the nameserver zonefile). And people like to be able to choose their own hostname. Yeah. Currently they can either 1. not preseed it but type in during installation, or 2. set it in the DNS records. Looks like it worked good enough till now. Guess it wasn't good enough 5 years ago either. :-) Seems my bug is a duplicate of: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343269 -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606515: Preseed installation does not wait for network to be ready
Package: network-preseed Version: 1.41 We are experiencing problems automatically installing Debian Lenny on a number of dedicated servers using PXE and preseed. Our setup works correctly with some hardware configurations, while others give a Failed to retrieve the preconfiguration file error message. If we manually press Continue and tell Debian installer to fetch the preconfiguration file a second time from the menu, installation does work properly. I suspect the reason it does not work the first time is that Debian installer does not bother to wait before the network link is ready, before attempting to fetch the preconfiguration file. When I press alt-F4 and look at the messages it shows: == 23:15:29 main-menu[1624]: INFO: menu item 'network-preseed' selected 23:15:32 kernel: eth0: Link is up 1000 Mbps Full Duplex Flow control: none == So if I understand the messages correctly the network-preseed routine is executed 3 seconds before the link is actually up? We assign a static network configuration to the servers using boot parameters like this: == kernel http://INSTALL-SERVER/main/installer- amd64/current/images/netboot/debian-installer/amd64/linux netcfg/choose_interface=auto debian-installer/locale=en_US kbd- chooser/method=us console-keymaps-at/keymap=us netcfg/disable_dhcp=true netcfg/get_ipaddress=$ip netcfg/get_netmask=$netmask netcfg/get_gateway=$gateway netcfg/get_nameservers=127.0.0.1 netcfg/get_hostname=$hostname netcfg/get_domain= preseed/url=http://INSTALL- SERVER/kickstart.php/debian-preseed (where $ip $netmask $gateway and $hostname is filled in with the information of the server being provisioned) == KVM over IP screenshot of the error message: http://image.bayimg.com/gabigaade.jpg Screenshot of the messages: http://image.bayimg.com/gabihaade.jpg Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
