Bug#973248: Deprecation warning in Ruby 2.7: $SAFE will become a normal global variable in Ruby 3.0
Package: puppet Version: 5.5.22-1 This is a similar but different bug as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955532 . I get this warning on a puppet run: /usr/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:126: warning: $SAFE will become a normal global variable in Ruby 3.0 I tried fixing it by setting Warning[:deprecated] = false, but that does not work for this specific warning, weirdly enough. So I tried another minimal approach. This fixes it for me, and it should also fix those other deprecation warnings from #955532, so that patch can be dropped if you want. --- a/puppet 2020-10-25 18:04:24.0 +0100 +++ b/puppet 2020-10-27 19:45:13.784467214 +0100 @@ -1,5 +1,11 @@ #!/usr/bin/ruby +def Warning.warn(w) + if w !~ /warning: (URI.(un|)escape is obsolete|\$SAFE will become a normal global variable)/ +super w + end +end + begin require 'puppet/util/command_line' Puppet::Util::CommandLine.new.execute Mike.
Bug#918250: Facter: Could not process routing table entry: Expected a destination followed by key/value pairs
I ran into the same problem. It looks like it only happens on hosts with IPv6 enabled. I found a workaround for hosts where the IPv6 address is configured statically in /etc/network/interfaces. The workaround is to remove the 'onlink' attribute from the route, which can be done reasonably easy by adding one "up" command to any static entry: iface eth0 inet6 static address 2001:0db8:85a3::7a/64 gateway 2001:0db8:85a3::1 dad-attempts 0 # dirty hack. removes 'onlink' attribute. works around #918250. up ip -6 r change default via $IF_GATEWAY HTH Mike.
Bug#921639: [pkg-netfilter-team] Bug#921639: iptables-restore: cannot jump to earlier initialized chain
On 07/02/2019 17:36, Arturo Borrero Gonzalez wrote: > On 2/7/19 4:16 PM, Miquel van Smoorenburg wrote: >> *filter >> :FILERS_UDP - [0:0] >> :FORWARD ACCEPT [0:0] >> :INPUT ACCEPT [0:0] >> :OUTPUT ACCEPT [0:0] >> -A FILERS_UDP --protocol udp --dport sunrpc --source 10.0.79.0/27 --jump >> ACCEPT >> -A INPUT --protocol udp --source 10.0.0.0/8 --jump FILERS_UDP >> COMMIT > > Please, share your linux kernel version. May be a Linux kernel issue already > solved. This was indeed on an ancient kernel (4.9). I just installed the latest buster using the buster alpha 5 installer in a VM, and re-tested. Indeed, the problem is gone. I'm sorry for bothering you. Thanks! Mike.
Bug#921639: iptables-restore: cannot jump to earlier initialized chain
Package: iptables Version: 1.8.2-3 Severity: important I ran into a bug in iptables-restore. This works: *filter :FILERS_UDP - [0:0] :FORWARD ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT --protocol udp --source 10.0.0.0/8 --jump FILERS_UDP -A FILERS_UDP --protocol udp --dport sunrpc --source 10.0.79.0/27 --jump ACCEPT COMMIT And this doesn't: *filter :FILERS_UDP - [0:0] :FORWARD ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A FILERS_UDP --protocol udp --dport sunrpc --source 10.0.79.0/27 --jump ACCEPT -A INPUT --protocol udp --source 10.0.0.0/8 --jump FILERS_UDP COMMIT # iptables-restore -4 -t < iptables-saved.txt iptables-restore v1.8.2 (nf_tables): line 7: RULE_APPEND failed (Invalid argument): rule in chain INPUT The only difference is where the -A FILERS_UDP line is; if it's before INPUT it fails, if it's after INPUT it works. That does not make sense. I ran into this bug on a system that was upgraded from stretch to buster, with a "ferm" firewall. "ferm" compiles its own language into iptables-save output and uses iptables-restore to load the rules. When generating the iptables-save output it sorts the chains alphabetically. So chains that are referred to in the INPUT chain, that start with a letter before 'I', result in this bug. Renaming them to something that starts with a letter that sorts after 'I' made it work. Took me a while to find the cause :) Mike.
Bug#890524: Acknowledgement (pam_unix: tries to close 1048576 files)
I just found that this bug has already been fixed in the upstream pam code, 4 years ago. https://github.com/linux-pam/linux-pam/commit/b0ec5d1e472a0cd74972bfe9575dcf6a3d0cad1c So another way to solve this is "please upgrade to a recent version of linux-pam". Thank you. Mike.
Bug#890524: pam_unix: tries to close 1048576 files
Package: pam
Version: 1.1.8-3.6
Severity: important
Tags: patch, upstream
I noticed that sometimes PAM authentication takes longer than expected
since I upgraded from jessie to stretch. Stracing a binary that calls
pam_authenticate showed that it was trying to close one million files.
Turns out that since stretch, the standard ulimit for number of open
files has changed. Soft limit is still 1024, hard limit went from 65536
to 1048576.
$ ulimit -n
1024
$ ulimit -H -n
1048576
In modules/pam_unix/ there are several loops like this:
if (getrlimit(RLIMIT_NOFILE,)==0) {
if (rlim.rlim_max >= MAX_FD_NO)
rlim.rlim_max = MAX_FD_NO;
for (i=0; i < (int)rlim.rlim_max; i++) {
if (i != STDIN_FILENO)
close(i);
}
}
This is present in pam_unix_acct.c, pam_unix_passwd.c and support.c
Fortunately the loop is limited by MAX_FD_NO, which surely has a sane value:
#define MAX_FD_NO 200
Hmm.
This is overkill. I would change "rlim_max" to "rlim_cur" at least, and
perhaps lower MAX_FD_NO to something more reasonable.
If it really is important to close *all* open files, it would be better
to add something like the below, and replace the loops with
pam_close_all_files(<> + 1).
#include
#include
#include
#include
#include
#define MAX_FD_NO 10
#ifdef __linux__
int pam_close_all_files_procfs(int start_at_fd)
{
DIR *dir = opendir("/proc/self/fd");
if (dir == NULL)
return -1;
int dfd = dirfd(dir);
struct dirent de, *de_p;
while (readdir_r(dir, , _p) == 0 && de_p != NULL) {
char *endp;
int fd = (int)strtol(de.d_name, , 10);
if (endp != de.d_name && fd >= start_at_fd && fd != dfd) {
close(fd);
}
}
closedir(dir);
return 0;
}
#endif
void pam_close_all_files(int start_at_fd)
{
#ifdef __linux__
if (pam_close_all_files_procfs(start_at_fd) == 0)
return;
#endif
struct rlimit rlim;
if (getrlimit(RLIMIT_NOFILE,)==0) {
if (rlim.rlim_cur >= MAX_FD_NO)
rlim.rlim_cur = MAX_FD_NO;
for (int i = 0; i < (int)rlim.rlim_cur; i++) {
if (i >= start_at_fd)
close(i);
}
}
}
#ifdef TEST
int main()
{
pam_close_all_files(0);
}
#endif
Thanks,
Mike.
Bug#883938: RFT: Candidate fix for boot failure of Debian 8.10 on various x86 systems
On 12/12/17 02:57, Ben Hutchings wrote: > https://people.debian.org/~benh/packages/jessie-pu/linux-image-3.16.0-4-amd64_3.16.51-3~a.test_amd64.deb > > Please report back (to the bug address) whether this fixes the > regression for you. > Fixes the problem on our servers. Thanks! Mike.
Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51
Same here, whole cluster of machines down here with this kernel. Same panic message, so I won't repeat it here. These are Supermicro boxes with Xeon CPUs: $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 16 On-line CPU(s) list: 0-15 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 26 Model name: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz Stepping: 5 CPU MHz: 1600.000 CPU max MHz: 2268. CPU min MHz: 1600. BogoMIPS: 4533.36 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K NUMA node0 CPU(s): 0-3,8-11 NUMA node1 CPU(s): 4-7,12-15 Mike.
Bug#850285: /usr/bin/dotlockfile: dotlockfile and lockfile_create exit with error code 4 when used over sshfs
reassign 850285 sshfs merge 850285 778801 thanks On 05/01/17 18:11, Edouard Klein wrote: Package: liblockfile-bin Version: 1.11-1 Severity: normal File: /usr/bin/dotlockfile Dear Maintainer, I tried to use lockfile_create on an sshfs mountpoint. Yes, that doesn't work, because sshfs is not a POSIX filesystem. When you link() a file, the new file has a different inode number, while it should be the same. There are several other programs that don't work over sshfs because of this. I am reassigning this bug to sshfs, and merging it with the other bugs. Mike.
Bug#95326: UUCP-style device locking
tag 95326 +wontfix thanks noone uses uucp anymore...
Bug#837302: cross build produces broken packages containing build architecture ELF objects
I've just uploaded liblockfile 1.11 to unstable- that should fix this bug. Can you check? Thanks Mike.
Bug#837302: cross build produces broken packages containing build architecture ELF objects
On 25/11/16 06:02, Helmut Grohne wrote: On Thu, Nov 24, 2016 at 09:32:33PM +0100, Miquel van Smoorenburg wrote: In liblockfile 1.10-1, I've rewritten debian/rules to use debhelper. Does that fix the bug? Partially. You replaced the install -s invocation with dh_strip and the dh_strip knows how cross works, but the ./configure invocation is left unchanged and thus still configures for the build architecture. Often enough indirecting "./configure" via "dh_auto_configure --" solves this, but liblockfile uses very old autotools that may necessitate setting CC explicitly. I ran 'autoconf' to generate a new 'configure', that hadn't been done this millenium yet, so it was about time :) I stripped down debian/rules to just override_dh_auto_configure like you proposed, and an override for fixperms. That seems to do the trick; without explicitly setting the architecture the library files end up in /usr/lib/x86_64-linux-gnu now. I'm going to work on fixing the other bugs that are still open, then I'll release 1.11. Thanks for the help so far! Mike.
Bug#837302: cross build produces broken packages containing build architecture ELF objects
On 10/09/16 14:14, Helmut Grohne wrote: liblockfile cross builds supposedly successfully, but the resulting packages contain build architecture ELF executables. Switching to host architecture triplet prefixed tools fixes that. Please consider applying the attached patch. In liblockfile 1.10-1, I've rewritten debian/rules to use debhelper. Does that fix the bug? Mike.
Bug#749062: mdadm: add containers to emergency config file
Package: mdadm Version: 3.3-2 Severity: normal If no mdadm.conf file is found in initramfs, the local-top mdadm script will create one on the fly like this: echo DEVICE partitions $CONFIG $MDADM --examine --scan $CONFIG However, this config will fail to assemble Intel RAID (imsm) arrays, since those are containers and that needs to be explicitly added to the DEVICE line. Also, from the manpage: If no DEVICE line is present, then DEVICE partitions contain- ers is assumed. So please add containers to the DEVICE line or just leave out the DEVICE line completely. Thanks Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748387: liblockfile: missing debian/copyright
On 16/05/14 22:06, Jonathan Nieder wrote: I noticed it while trying to read the copyright file through packages.qa.debian.org. Looks like the binary packages are okay, and the information's there in the source package --- the path is just wrong. Yes. I really need to dh-ize the debian directory. I did see the light quite some time ago but I never got around to updating liblockfile. I'm putting it on the agenda. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742041: sabredav 1.7.11 available
Package: php-sabre-dav Version: 1.7.6+dfsg-2 Severity: minor Since the last packaging of 1.7.x there have been quite a few bugfix-releases, but recently a security-related release was done (1.7.11), see below. This doesn't really affect testing and unstable, since jessie has PHP 5.5 where this isn't an issue, but but there is a wheezy-backport where this probably is a security problem. So I've set the severity to minor (not quite sure what to do here for backports). Please update to the latest 1.7.x or 1.8.x - thanks. Mike. 1.7.11 Evert Pot evert released this 20 days ago · 583 commits to master since this release This release fixes a security issue and an issue related to large files in SabreDAV. XEE issue Previous SabreDAV versions had a security issue, if running on the following PHP versions PHP 5.3, older than 5.3.23 PHP 5.4, older than 5.4.13 PHP 5.5 is not affected by this. You are strongly recommended to upgrade, as the security issue could expose local files or easily trigger a DOS attack. More information here: http://websec.io/2012/08/27/Preventing-XEE-in-PHP.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684712: Status
On 18-01-14 3:46 PM, Bastian Blank wrote: Hi What is the status of this patch? I failed to find anything in the current LVM2 release (2.02.104). See the messages posted in December 2013 at https://bugzilla.redhat.com/show_bug.cgi?id=862085 . I'm not quite sure what the best course of action is now. It appears that what began with a simple patch is being grown into a Project, and I have no idea who is going to take that on. I would say 'integrate the patch, THEN see if you can generalize stuff with libblkid or (of all things) udev. But I'm not sure how that would be taken. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699434: grub-installer: support for Intel Matrix Raid
On 02/12/13 10:59, Dmitrijs Ledkovs wrote: Hello Miquel, On 31 January 2013 12:40, Miquel van Smoorenburg miqu...@debian.org wrote: This is by far the most intrusive patch - all the others are trivial. Description: - move make_device_map() upwards so that we can call it earlier in the script. Also, if $md_bootdev is set, add a (otherwise unused) (md/0) entry to device.map - otherwise grub-probe freaks out on upgrades. - add is_mdraid_bootable(). It checks if the device is a Intel Matrix Raid device, in RAID1 mode. If not it returns false. Otherwise it sets $md_dev, $md_devs, $md_super and $md_level, and returns true. Why is it limited to only imsm raid1 ? Because it's the only thing I could test, and at the time ddf support was kind of wonky. So I thought it best to leave that out. Also, only RAID1 is because I could not get grub to install on the MD device- it didn't accept that. And for example, grub-mkdevicemap doesn't create an entry for /dev/md... yet. So right now the code finds the devices underlying the RAID1 array and installs grub on all of them. Someone needs to fix grub so that it understands MD devices directly. Or the current version might already do that, I haven't checked in a while. mdadm supports imsm superblock format levels 0,1,5,10 ddf superblock format levels 0,1,3,4,5,1E,5E,5EE,6 with extensions of there off (stripped, mirrored, concatenated and spanned). Would it not be best to simply check for imsm || ddf superblock types? Given that mdadm supports most of the above RAID levels. Sure. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699430: debian-installer: support for Intel Matrix Raid (RST, imsm)
Package: debian-installer Tags: patch This is a metabug for other bugs I filed against grub-installer, partman-auto, partman-base, mdadm and lvm2. I noticed that linux mdraid has working support for Intel Matrix Raid (aka Intel Rapid Storage Technology), called imsm in mdadm. This is a form of fakeraid, like dmraid. Dmraid has never been really supported in Debian, and upstream development has also ceased. It looks like mdraid is the way forward. I have added support for installing on mdraid based Intel Matrix raid to the debian-installer, the lvm2 package, and mdadm. With these patches applied I can install and boot Debian Wheezy without any trouble on an Intel Matrix RAID RAID1 array - even when combined with lvm. Patches are available, the bug reports will be tagged as blocking for this metabug, and are: grub-installer: - also detect mdadm fakeraid underneath lvm, if it's just one array - install grub on each disk of the underlying array - add md/0 entry to device.map so grub-probe works (for upgrades etc) partman-auto: - don't hide /dev/md* arrays if they are provisioned on whole-disk devices - in that case the md array itself is partitionable, e.g. for md-fakeraid like imsm (Intel Matrix raid). partman-base: - init.d/parted: Skip devices that are part of a mdraid device lvm2: - lvm2 already filters mdraid superblocks, now also filter IMSM superblocks Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699431: partman-auto: don't hide whole-disk partitionable mdraid arrays
Package: partman-auto
Version: 106
Tags: patch
See metabug 699430, http://bugs.debian.org/699430 :
(debian-installer: support for Intel Matrix Raid (RST, imsm)
* don't hide /dev/md* arrays if they are provisioned on whole-disk
devices - in that case the md array itself is partitionable,
e.g. for md-fakeraid like imsm (Intel Matrix raid).
Thanks
diff -ruN 00-ORIG/partman-auto-106/debian/changelog
partman-auto-106/debian/changelog
--- 00-ORIG/partman-auto-106/debian/changelog 2012-12-12 05:52:35.0
+
+++ partman-auto-106/debian/changelog 2013-01-29 14:52:14.946726850 +
@@ -1,3 +1,11 @@
+partman-auto (106+1) unstable; urgency=low
+
+ * don't hide /dev/md* arrays if they are provisioned on whole-disk
+devices - in that case the md array itself is partitionable,
+e.g. for md-fakeraid like imsm (Intel Matrix raid).
+
+ -- Miquel van Smoorenburg miqu...@debian.org Tue, 29 Jan 2013 15:50:37
+0100
+
partman-auto (106) unstable; urgency=low
[ Updated translations ]
diff -ruN 00-ORIG/partman-auto-106/lib/auto-shared.sh
partman-auto-106/lib/auto-shared.sh
--- 00-ORIG/partman-auto-106/lib/auto-shared.sh 2011-02-07 02:00:27.0
+
+++ partman-auto-106/lib/auto-shared.sh 2013-01-29 14:49:59.644371625 +
@@ -208,6 +208,28 @@
free_space=$(partition_after $id)'
}
+is_wholedisk_mdraid () {
+ local device=`echo $1 | sed -e 's!/\([0-9]*\)$!\1!'`
+ local mddisk=${device#/dev/}
+ local ret=0
+ local d
+
+ [ -d /sys/block/$mddisk/md ] || return 1
+
+ for d in /sys/block/$mddisk/slaves/*; do
+ case $d in
+ dm-*|md*)
+ ;;
+ *p[0-9]|*p[0-9][0-9])
+ ret=1
+ break
+ ;;
+ esac
+ done
+
+ return $ret
+}
+
get_auto_disks() {
local dev device dmtype
@@ -217,7 +239,12 @@
device=$(cat $dev/device)
# Skip software RAID (mdadm) devices (/dev/md/X and /dev/mdX)
- $(echo $device | grep -Eq /dev/md/?[0-9]*$) continue
+ # unless it's a whole-disk partitionable array
+ if echo $device | grep -Eq /dev/md/?[0-9]*$; then
+ if ! is_wholedisk_mdraid $device; then
+ continue
+ fi
+ fi
# Skip device mapper devices (/dev/mapper/),
# except for dmraid or multipath devices
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699432: partman-base: parted: skip devices that are part of a mdraid device
Package: partman-base
Version: 163
Tags: patch
See metabug 699430, http://bugs.debian.org/699430 :
(debian-installer: support for Intel Matrix Raid (RST, imsm)
* init.d/parted: Skip devices that are part of a mdraid device
Thanks
diff -ruN 00-ORIG/partman-base-163/debian/changelog
partman-base-163/debian/changelog
--- 00-ORIG/partman-base-163/debian/changelog 2012-12-21 13:49:25.0
+
+++ partman-base-163/debian/changelog 2013-01-29 14:53:17.923821518 +
@@ -1,3 +1,9 @@
+partman-base (163+1) unstable; urgency=low
+
+ * init.d/parted: Skip devices that are part of a mdraid device
+
+ -- Miquel van Smoorenburg miqu...@debian.org Tue, 29 Jan 2013 15:50:37
+0100
+
partman-base (163) unstable; urgency=low
* Revert add debhelper token to postinst
diff -ruN 00-ORIG/partman-base-163/init.d/parted partman-base-163/init.d/parted
--- 00-ORIG/partman-base-163/init.d/parted 2011-01-19 04:56:34.0
+
+++ partman-base-163/init.d/parted 2013-01-29 14:52:38.359133765 +
@@ -15,6 +15,20 @@
return 1
}
+part_of_mdraid () {
+ local holder
+ local dev=${1#/dev/}
+ for holder in /sys/block/$dev/holders/*; do
+ local mddev=${holder##*/}
+ case $mddev in
+ md[0-9]|md[0-9][0-9]|md[0-9][0-9][0-9])
+ return 0
+ ;;
+ esac
+ done
+ return 1
+}
+
part_of_sataraid () {
local raiddev
for raiddev in $(dmraid -r -c); do
@@ -86,6 +100,11 @@
fi
fi
+ # Skip devices that are part of a mdraid device
+ if part_of_mdraid $device; then
+ continue
+ fi
+
# Skip devices that are part of a dmraid device
if type dmraid /dev/null 21 \
dmraid -r -c /dev/null 21; then
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699434: grub-installer: support for Intel Matrix Raid
Package: grub-installer
Version: 183
Tags: patch
See metabug 699430, http://bugs.debian.org/699430 :
(debian-installer: support for Intel Matrix Raid (RST, imsm)
* Support for mdadm fakeraid (currently only IMSM formatted disks):
- also detect mdadm fakeraid underneath lvm, if it's just one array
- install grub on each disk of the underlying array
- add md/0 entry to device.map so grub-probe works (for upgrades etc)
This is by far the most intrusive patch - all the others are trivial.
Description:
- move make_device_map() upwards so that we can call it earlier
in the script. Also, if $md_bootdev is set, add a (otherwise
unused) (md/0) entry to device.map - otherwise grub-probe
freaks out on upgrades.
- add is_mdraid_bootable(). It checks if the device is a Intel
Matrix Raid device, in RAID1 mode. If not it returns false.
Otherwise it sets $md_dev, $md_devs, $md_super and $md_level,
and returns true.
- if installing on an lvm device, it finds the underlying device,
and checks if it's a single mdraid array. If so $disc_under_lvm
is set.
- if we're installing on a mdraid device and is_mdraid_bootable()
is true, we set $disc_offered to the mdraid device, and set
the $default_bootdev variable to all the underlying real disks.
- when installing on an mdraid device, always create the grub device.map
- do not try to guess the bootdevice if we already set $default_bootdev
Note that effectively this patch does NOT change any existing
behaviour if you are not trying to install on an Intel Matrix Raid
RAID1 array. As that wasn't supported before anyway, there is
no chance on regression.
Thanks
diff -ruN 00-ORIG/grub-installer-1.83/debian/changelog
grub-installer-1.83/debian/changelog
--- 00-ORIG/grub-installer-1.83/debian/changelog2012-10-27
06:07:35.0 +
+++ grub-installer-1.83/debian/changelog2013-01-29 15:03:58.462971942
+
@@ -1,3 +1,12 @@
+grub-installer (1.83+1) unstable; urgency=low
+
+ * Support for mdadm fakeraid (currently only IMSM formatted disks):
+- also detect mdadm fakeraid underneath lvm, if it's just one array
+- install grub on each disk of the underlying array
+- add md/0 entry to device.map so grub-probe works (for upgrades etc)
+
+ -- Miquel van Smoorenburg miqu...@debian.org Tue, 29 Jan 2013 15:50:37
+0100
+
grub-installer (1.83) unstable; urgency=low
[ Milan Kupcevic ]
diff -ruN 00-ORIG/grub-installer-1.83/grub-installer
grub-installer-1.83/grub-installer
--- 00-ORIG/grub-installer-1.83/grub-installer 2012-10-25 01:01:57.0
+
+++ grub-installer-1.83/grub-installer 2013-01-29 14:56:40.103337917 +
@@ -217,6 +217,69 @@
echo $ids
}
+make_device_map () {
+ # If you're preseeding (hd0) et al, stop - preseed OS device names
+ # instead. However, for backward compatibility we ensure that a
+ # device.map exists if you do this.
+ [ $grub_version = grub2 ] || return 0
+ [ ! -e $device_map ] || return 0
+ local no_floppy
+ case $1 in
+ \(fd*|fd*)
+ no_floppy=
+ ;;
+ *)
+ no_floppy=--no-floppy
+ ;;
+ esac
+ $chroot $ROOT grub-mkdevicemap $no_floppy
+ if [ -n $md_bootdev ]
+ then
+ # This is lame- shouldn't need this, but otherwise
+ # grub-probe freaks out.
+ echo (md/0)$md_bootdev $ROOT/boot/grub/device.map
+ fi
+}
+
+is_mdraid_bootable () {
+ local device=$1
+ local mddisk=${device#/dev/}
+ local super
+ local level=`cat /sys/block/$mddisk/md/level 2/dev/null ||:`
+ local array_metadata=`cat /sys/block/$mddisk/md/metadata_version
2/dev/null ||:`
+ case $array_metadata in
+ external:/md*)
+ local ctdisk=${array_metadata#external:/}
+ ctdisk=${ctdisk%/*}
+ super=`cat /sys/block/$ctdisk/md/metadata_version
2/dev/null ||:`
+ super=${super#external:}
+ ;;
+ esac
+ # Right now mdadm only supports imsm fakeraid, and grub doesn't know
+ # about it at all but raid1 works regardless. So restrict to imsm +
raid1.
+ if [ $level = raid1 ] [ $super = imsm ]
+ then
+ # Find the disks that make up the array to that grub can
+ # be installed onto all of them. As soon as grub supports
+ # imsm raid we should be able to install directly to the
+ # md device instead.
+ local mddisks=`echo /sys/block/$mddisk/md/dev-* |
+ sed -ne 's!/sys/block/md[0-9]\+/md/dev-\([^
\*]\+\)!/dev/\1!pg'`
+ if [ -n $mddisks ]; then
+ md_devs=$mddisks
+ md_super=$super
+ md_level=$level
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
Ping? See also bug #699430, http://bugs.debian.org/699430 . Would you mind if I did an NMU if the debian-installer patches are accepted? Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
On 01/31/2013 02:11 PM, Bastian Blank wrote: On Thu, Jan 31, 2013 at 01:53:40PM +0100, Miquel van Smoorenburg wrote: Ping? See also bug #699430, http://bugs.debian.org/699430 . Would you mind if I did an NMU if the debian-installer patches are accepted? lvm2 is blocked by d-i right now. As I had to cheat already to not use t-p-u, I don't consider this viable for Wheezy. Wouldn't it be possible to upload a new version to unstable, then after that upload 2.02.95-4.1 to t-p-u with just this patch? It's not that this is just a fix for the installer. It's that if someone is using lvm2 on an Intel Matrix Raid array via mdadm, which is a working and supported configuration on wheezy, and for some reason one of the disks is kicked out of the array, LVM2 /will/ detect lvm vg's and lv's on that disk/pv - creating chaos and very possibly data loss. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
On 01/31/2013 02:49 PM, Bastian Blank wrote: On Thu, Jan 31, 2013 at 02:27:56PM +0100, Miquel van Smoorenburg wrote: On 01/31/2013 02:11 PM, Bastian Blank wrote: lvm2 is blocked by d-i right now. As I had to cheat already to not use t-p-u, I don't consider this viable for Wheezy. Wouldn't it be possible to upload a new version to unstable, then after that upload 2.02.95-4.1 to t-p-u with just this patch? No. This can only be introduced via unstable according to the effective rules. And I already told you, I won't accept it. It's that if someone is using lvm2 on an Intel Matrix Raid array via mdadm, which is a working and supported configuration on wheezy, and for some reason one of the disks is kicked out of the array, LVM2 /will/ detect lvm vg's and lv's on that disk/pv - creating chaos and very possibly data loss. And? Dataloss is cause for a bug with severity critical. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699430: debian-installer: support for Intel Matrix Raid (RST, imsm)
On 01/31/2013 02:27 PM, Michael Tokarev wrote: 31.01.2013 16:14, Miquel van Smoorenburg wrote: [] I have added support for installing on mdraid based Intel Matrix raid to the debian-installer, the lvm2 package, and mdadm. With these patches applied I can install and boot Debian Wheezy without any trouble on an Intel Matrix RAID RAID1 array - even when combined with lvm. Out of curiocity, did you actually test the latest mdadm package? I did a few more changes on top of your patch, but I don't have any hardware where I can try it, so I've no idea if it actually works or not... Yes, I did. Yesterday I took the latest snapshot from the wheezy installer media, and replaced the debs/udebs with the ones that I updated, replaced mdadm with the latest version from unstable (-5), and built a new image. It all worked fine, installing, booting, rebooting, etc. Thanks, Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693227: missing driver for ISCI (Intel C600 SAS) (not iscsi!)
On 11/14/2012 05:37 PM, Ben Hutchings wrote: On Wed, 2012-11-14 at 14:08 +0100, Miquel van Smoorenburg wrote: Package: debian-installer Severity: critical The debian installer images are missing the isci.ko module. This makes it impossible to install wheezy on any computer that has its disks connected to an Intel C600 SAS controller (standard on lots of motherboards). NOTE: I'm not talking about iscsi (i-scsi), but isci. [...] This was already reported as #690886 and the fix is pending. Ah OK, thanks. I couldn't find that bug anymore, and I thought that maybe that bug was closed because someone read isci as iscsi (I sometimes confuse those as well). Apologies for the duplicate report. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693227: missing driver for ISCI (Intel C600 SAS) (not iscsi!)
Package: debian-installer Severity: critical The debian installer images are missing the isci.ko module. This makes it impossible to install wheezy on any computer that has its disks connected to an Intel C600 SAS controller (standard on lots of motherboards). NOTE: I'm not talking about iscsi (i-scsi), but isci. The squeeze installer *does* include this driver. Look: ** WHEEZY: $ wget http://d-i.debian.org/daily-images/amd64/daily/hd-media/initrd.gz $ bsdtar tvfz initrd.gz | grep isci.ko $ ** SQUEEZE: $ wget http://ftp.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/hd-media/initrd.gz $ bsdtar tvfz initrd.gz | grep isci.ko -rw-r--r-- 1 0 0 148392 Sep 26 17:13 lib/modules/2.6.32-5-amd64/kernel/drivers/scsi/isci/isci.ko Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691929: mod_fcgid: requests with chunked encoding have no body available to FCGI backend
Package: libapache2-mod-fcgid Version: 1:2.3.6-1.1 Severity: grave Tags: patch wheezy sid I installed Sabredav as a webdav server, running under mod_fcgid. When uploading files with OSX Finder, all files were zero bytes big. This appears to be a issue with mod_fcgid. The issue is known in the Apache bug tracker, and a patch is available. I tested the patch and it solved the problem for me. https://issues.apache.org/bugzilla/show_bug.cgi?id=53332 Requests with Transfer-Encoding: chunked (notably from OS/X Finder WebDAV PUT) don't have a Content-Length header, and so the FCGI CONTENT_LENGTH doesn't get set. Because of the spec, conforming backends don't read any of the body of the request. Because this results in data loss, I've set the severity to 'grave'. Please include this patch in libapache2-mod-fcgid. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
Hello, I was wondering if you are planning on uploading a new version of the lvm2 package soon. I filed bug 684712, and I'd like to see a lvm2 package with that patch included. Background: I have a set of patches for the debian installer to make it possible to install wheezy on a Intel Matrix RAID array. However for that I need a fixed version of LVM2 that doesn't by accident detect the VGs from a disk that has been kicked out (for whatever reason) of a RAID1 array. I also had patches for mdadm and parted, those have already been applied (though mdadm is still in experimental). Thanks, Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690886: installation-reports: wheezy: isci.ko driver missing
Package: installation-reports Severity: important The installer does not include the isci.ko driver for the Intel SAS controller. The 3.2.0-3 kernel in the archive does include the driver; it's just that it's not included in any udeb. I've unpacked all udebs from pool/main/l/linux from both the beta1 and beta3 ISO netinst images, but the isci.ko driver just isn't included. Please fix :) Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
I submitted the patch to automatically filter disks with ddf and
imsm superblocks to the linux-lvm mailinglist. I got some helpful
comments and a patch review from Alasdair G Kergon. I rewrote
the patch based on the review, sent it to the mailinglist and
submitted it in the lvm2 (actually, redhat) bug tracker at
https://bugzilla.redhat.com/show_bug.cgi?id=862085
I'm sure this patch will be included in upstream in one of the
upcoming releases.
Attached is the debian version of the patch (v3).
Suggested changelog entry:
* lvm already filters disks that have a mdraid signature, now
filter DDF and IMSM formatted disks as well - also see
https://bugzilla.redhat.com/show_bug.cgi?id=862085
Thanks.
Mike.
diff -ruN ../work.o/lvm2-2.02.95/debian/patches/lvm-filter-imsm-ddf.patch lvm2-2.02.95/debian/patches/lvm-filter-imsm-ddf.patch
--- ../work.o/lvm2-2.02.95/debian/patches/lvm-filter-imsm-ddf.patch 1970-01-01 00:00:00.0 +
+++ lvm2-2.02.95/debian/patches/lvm-filter-imsm-ddf.patch 2012-10-17 20:33:24.875265105 +
@@ -0,0 +1,245 @@
+From: Miquel van Smoorenburg mik...@xs4all.net
+To: Alasdair G Kergon a...@redhat.com
+Cc: LVM general discussion and development linux-...@redhat.com
+Subject: [linux-lvm] [PATCH] automatically filter disks with imsm or ddf superblocks, v3
+Date: Sat, 22 Sep 2012 18:37:37 +0200
+Message-ID: 20120922163737.gb6...@xs4all.net
+
+The only change wrt v2 is that this fixes a small cosmetic bug
+in debug output.
+
+##
+
+lvm.conf has a setting called md_component_detection, which makes lvm
+ignore disks with a linux md raid superblock. This patch adds detection
+of more raid superblock formats, ddf and imsm.
+
+Index: lvm2-2.02.95/lib/Makefile.in
+===
+--- lvm2-2.02.95.orig/lib/Makefile.in 2012-02-28 18:35:05.0 +
lvm2-2.02.95/lib/Makefile.in 2012-10-17 20:32:07.418009678 +
+@@ -54,6 +54,8 @@
+ device/dev-cache.c \
+ device/dev-io.c \
+ device/dev-md.c \
++ device/dev-ddf.c \
++ device/dev-imsm.c \
+ device/dev-swap.c \
+ device/dev-luks.c \
+ device/device.c \
+Index: lvm2-2.02.95/lib/device/dev-ddf.c
+===
+--- /dev/null 1970-01-01 00:00:00.0 +
lvm2-2.02.95/lib/device/dev-ddf.c 2012-10-17 20:32:07.418009678 +
+@@ -0,0 +1,69 @@
++/*
++ * Copyright (C) 2004 Luca Berra
++ * Copyright (C) 2004-2008 Red Hat, Inc. All rights reserved.
++ * Copyright (C) 2012 Miquel van Smoorenburg
++ *
++ * This file is part of LVM2.
++ *
++ * This copyrighted material is made available to anyone wishing to use,
++ * modify, copy, or redistribute it subject to the terms and conditions
++ * of the GNU Lesser General Public License v.2.1.
++ *
++ * You should have received a copy of the GNU Lesser General Public License
++ * along with this program; if not, write to the Free Software Foundation,
++ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
++ */
++
++#include lib.h
++#include metadata.h
++#include xlate.h
++#include crc.h
++
++#define DDF_MAGIC 0xDE11DE11
++struct ddf_header {
++ uint32_t magic;
++ uint32_t crc;
++ char guid[24];
++ char revision[8];
++ char padding[472];
++} __attribute__ ((packed));
++
++/*
++ * Returns -1 on error
++ */
++int dev_is_ddf(struct device *dev, uint64_t *sb)
++{
++ struct ddf_header hdr;
++ uint64_t size, sb_offset;
++ uint32_t crc;
++ int ret = 0;
++
++ if (!dev_get_size(dev, size)) {
++ stack;
++ return -1;
++ }
++
++ if (!dev_open_readonly(dev)) {
++ stack;
++ return -1;
++ }
++
++ /* Also calculate CRC so we have at least 8 bytes to check */
++ sb_offset = (size - 1) SECTOR_SHIFT;
++ if (dev_read(dev, sb_offset, 512, hdr)
++ xlate32_be(hdr.magic) == DDF_MAGIC) {
++ crc = xlate32_be(hdr.crc);
++ hdr.crc = 0x;
++ if (calc_crc(0, (const uint8_t *)hdr, 512) == crc)
++ ret = 1;
++ }
++
++ if (!dev_close(dev))
++ stack;
++
++ if (ret sb)
++ *sb = sb_offset;
++
++ return ret;
++}
++
+Index: lvm2-2.02.95/lib/device/dev-imsm.c
+===
+--- /dev/null 1970-01-01 00:00:00.0 +
lvm2-2.02.95/lib/device/dev-imsm.c 2012-10-17 20:32:07.418009678 +
+@@ -0,0 +1,55 @@
++/*
++ * Copyright (C) 2004 Luca Berra
++ * Copyright (C) 2004-2008 Red Hat, Inc. All rights reserved.
++ * Copyright (C) 2012 Miquel van Smoorenburg
++ *
++ * This file is part of LVM2.
++ *
++ * This copyrighted material is made available to anyone wishing to use,
++ * modify, copy, or redistribute it subject to the terms and conditions
++ * of the GNU Lesser General Public License v.2.1.
++ *
++ * You should have received a copy of the GNU Lesser General Public License
++ * along with this program; if not, write to the Free Software Foundation,
++ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
++ */
++
++#include lib.h
++#include metadata.h
++
++#define IMSM_SIGNATURE Intel Raid ISM Cfg Sig
Bug#689419: freeradius: segfaults in rlm_perl
On 4-10-12 10:05 AM, Josip Rodin wrote: On Tue, Oct 02, 2012 at 02:47:26PM +0200, Miquel van Smoorenburg wrote: Package: freeradius Version: 2.1.12+dfsg-1.1 Severity: important Freeradius can dynamically grow and shrink its thread pool. When growing the thread pool, multiple threads will call perl_clone at the same time, which can result in segfaults. The call to perl_clone should be protected with a mutex. This was reported in http://lists.freeradius.org/pipermail/freeradius-devel/2011-November/006568.html and the patch was integrated for the 2.2.0 release. There hasn't been a 2.1.x release with this patch yet. The patch for 2.1.x is here: https://github.com/alandekok/freeradius-server/commit/ecb3cd1dbedb764ab98532dae5e0b5bfc9571b00 Did you intend to file this as important and not serious or? I wasn't sure. We are hitting this problem in production, but if you don't use rlm_perl freeradius works fine otherwise. So for freeradius in total I'd say a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone., while for the rlm_perl module it would be more like it makes the package unsuitable for release. Perhaps I should have tagged it serious, it can always be downgraded if the maintainer doesn't agree, right? Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689419: freeradius: segfaults in rlm_perl
Package: freeradius Version: 2.1.12+dfsg-1.1 Severity: important Freeradius can dynamically grow and shrink its thread pool. When growing the thread pool, multiple threads will call perl_clone at the same time, which can result in segfaults. The call to perl_clone should be protected with a mutex. This was reported in http://lists.freeradius.org/pipermail/freeradius-devel/2011-November/006568.html and the patch was integrated for the 2.2.0 release. There hasn't been a 2.1.x release with this patch yet. The patch for 2.1.x is here: https://github.com/alandekok/freeradius-server/commit/ecb3cd1dbedb764ab98532dae5e0b5bfc9571b00 Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684708: mdadm: support external metadata arrays correctly
Package: mdadm
Version: 3.2.5-1
[version 2 of the patch]
The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon
is not included in the .udeb for the installer.
This means that if you have an array with external metadata (ddf or,
more widely used, imsm - Intel Matrix Raid) that it will come up
readonly. This causes the installer to hang or the system not being
able to boot if root is on that array.
The attached patch does the following:
- it makes sure mdadm is included in the initramfs and the udeb package
- it adds a mdadm-waitidle script that runs just before reboot/halt. For
arrays that are still running, it calls mdadm --wait-clean to wait
for the array to go idle. This is needed so that the array is marked
clean, otherwise it will start to resync at the next boot.
- it adds a few lines to /etc/init.d/mdadm for the start and stop actions:
o start: if a mdmon pidfile is found in /run/mdadm, restart mdmon
o stop: link pidfiles of mdmon processes into /run/sendsigs.omit.d,
and make sure that happens before sendsigs runs.
- RUNDIR in /etc/init.d/mdadm is set to /run. This is sure to be ok:
mdadm itself is already compiled with rundir hardcoded to /run.
Note that I've made sure that this actually doesn't do /anything/
if you do not have running MD arrays with external metadata. Iow,
this should not break anything, or cause regressions.
I have added support for installation on Intel Matrix raid (imsm)
arrays using mdadm to d-i, and I'll be sending patches to the debian-boot
list soon. Please consider this patch for inclusion in wheezy.
diff -ruN x/mdadm-3.2.5/debian/changelog mdadm-3.2.5/debian/changelog
--- x/mdadm-3.2.5/debian/changelog 2012-05-25 18:05:23.0 +
+++ mdadm-3.2.5/debian/changelog 2012-09-22 19:25:28.520705389 +
@@ -1,3 +1,18 @@
+mdadm (3.2.5-1+1) unstable; urgency=low
+
+ * also install mdmon in udeb and initramfs, so imsm arrays can work
+ * /etc/init.d/mdadm: change RUNDIR to /run instead of /var/run
+ * /etc/init.d/mdadm start: if a mdmon pidfile is found in /run/mdadm,
+restart mdmon (-t --all)
+ * /etc/init.d/mdadm stop: link pidfiles of mdmon processes into
+/run/sendsigs.omit.d, and make sure that happens before sendsigs runs.
+ * add script mdadm-waitidle that runs just before reboot/halt. For each
+array with external metadata that is still running, it sets
+sync_action to idle, and uses mdadm --wait-clean to wait for the
+array to go idle (yes it has a short timeout)
+
+ -- Miquel van Smoorenburg miqu...@debian.org Sat, 22 Sep 2012 21:16:22 +0200
+
mdadm (3.2.5-1) unstable; urgency=low
[ Michael Tokarev ]
diff -ruN x/mdadm-3.2.5/debian/initramfs/hook mdadm-3.2.5/debian/initramfs/hook
--- x/mdadm-3.2.5/debian/initramfs/hook 2012-05-25 17:31:37.0 +
+++ mdadm-3.2.5/debian/initramfs/hook 2012-08-01 22:32:50.925671675 +
@@ -49,6 +49,7 @@
}
MDADM=/sbin/mdadm
+MDMON=/sbin/mdmon
[ -x $MDADM ] || exit 0
[ -r /usr/share/initramfs-tools/hook-functions ] || exit 0
@@ -56,6 +57,7 @@
# copy the binary as early as possible
copy_exec $MDADM /sbin
+copy_exec $MDMON /sbin
# copy all modules into the initramfs, just for safety.
# we copy raid456 / raid5+raid6 because the hook script just won't do
diff -ruN x/mdadm-3.2.5/debian/mdadm-waitidle mdadm-3.2.5/debian/mdadm-waitidle
--- x/mdadm-3.2.5/debian/mdadm-waitidle 1970-01-01 00:00:00.0 +
+++ mdadm-3.2.5/debian/mdadm-waitidle 2012-09-22 19:14:34.236895943 +
@@ -0,0 +1,70 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: mdadm-waitidle
+# Required-Start:
+# Required-Stop:
+# Should-Stop: halt reboot kexec
+# X-Stop-After: umountroot
+# Default-Start:
+# Default-Stop: 0 6
+# Short-Description: Wait for MD arrays to become idle
+# Description: Waits until all MD arrays with external metadata are
+#in idle and synced state before halt/reboot.
+### END INIT INFO
+#
+set -eu
+
+MDADM=/sbin/mdadm
+test -x $MDADM || exit 0
+test -f /proc/mdstat || exit 0
+
+. /lib/lsb/init-functions
+
+case ${1:-} in
+ start)
+;;
+ stop)
+# See which arrays have external metadata
+arrays=
+cd /sys/block
+for md in md*
+do
+ metadata=`cat $md/md/metadata_version 2/dev/null ||:`
+ case $metadata in
+external:[-/]*)
+ arrays=$arrays $md
+ ;;
+ esac
+done
+
+# Only take action for arrays with external metadata
+[ -n $arrays ] || exit 0
+log_action_begin_msg Waiting for MD arrays to become idle
+sync
+err=
+for md in $arrays; do
+ # Stop any sync action
+ if [ -w $md/md/sync_action ]; then
+echo idle $md/md/sync_action ||:
+ fi
+ # Wait for the array to become idle (max 5 secs)
+ if ! $MDADM --wait-clean /dev/$md /dev/null 21; then
+err=1
+ fi
+done
+if [ -n $err ]
+then
+ log_action_end_msg 1
+ sleep 1
+else
Bug#684713: parted: support for partitioned MD devices
On 26-09-12 4:40 PM, Cyril Brulebois wrote: Hi Miquel, background: I'm reviewing changes to udeb-producing packages to see which ones we'd like to get into wheezy before the next debian-installer release. Miquel van Smoorenburg miqu...@debian.org (13/08/2012): However, there is one minor oversight/bug in the kernel: the sysfs range key is still set to 1 for md arrays. That means libparted thinks that it's not possible to partition that device, where in fact it is. Given there was already a patch on the parted side, am I right to assume this was also reported against the kernel? If it is, I guess Debian linux kernel maintainers would be happy to merge the patches fixing this bug. Ah, this was fixed another way in the upstream package, by using a different kernel interface (just a different sysfs file, really). That is the patch I then backported to the debian parted package. So there is no need to fix the kernel. Note that I think it is useful to get this into the installer- it's a bugfix after all. However to be able to actually do something meaningful with it, we need an updated lvm2 package as well (working on that with upstream, I prefer to fix bugs in upstream packages first, then backport them), an updated mdadm package (only needs a few changes to the debian part, but the maintainers are mostly ignoring me), and ofcourse a few small(ish) changes to several installer packages. I haven't sent patches or filed bugs for the installer packages, trying to get lvm2 and mdadm fixed first. Thanks Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
I'm working with upstream to get a cleaned up version of this patch into lvm2 proper. Please do not apply the patch attached to this bug report yet, hopefully there will soon be a backported-from-upstream patch. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684713: bug 684713 - support for partitioned MD devices
Is anyone planning to upload a new parted version to the archive anytime soon? If not, I'll probably do an NMU to fix bug 684713. Thanks, Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684708: mdadm: support external metadata arrays correctly
On 13.08.2012 14:10, Miquel van Smoorenburg wrote: Package: mdadm Version: 3.2.5-1 Severity: serious Tags: patch wheezy sid The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon is not included in the .udeb for the installer. Here is a revised patch. I proposed the patch to mdmon.c (to symlink the pidfile into /run/sendsigs.omit.d/) on the linux-raid mailinglist, and Neil Brown remarked why not do that in an init script just before sendsigs runs. Which is ofcourse a good idea, no changes to mdmon.c required, just 3 lines added to /etc/init.d/mdadm. I was careful to ensure that if you do not have a raid device with external metadata, this patch does exactly nothing. And on systems with a raid device with external metadata it will enhance data integrity due to /etc/init.d/mdadm-waitidle. Thanks, Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684708: mdadm: support external metadata arrays correctly
On 13.08.2012 14:10, Miquel van Smoorenburg wrote:
Package: mdadm
Version: 3.2.5-1
Severity: serious
Tags: patch wheezy sid
The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon
is not included in the .udeb for the installer.
[this time with patch attached, oops.]
Here is a revised patch. I proposed the patch to mdmon.c (to symlink the
pidfile into /run/sendsigs.omit.d/) on the linux-raid mailinglist, and
Neil Brown remarked why not do that in an init script just before
sendsigs runs. Which is ofcourse a good idea, no changes to mdmon.c
required, just 3 lines added to /etc/init.d/mdadm.
I was careful to ensure that if you do not have a raid device with
external metadata, this patch does exactly nothing. And on systems with
a raid device with external metadata it will enhance data integrity due
to /etc/init.d/mdadm-waitidle.
Thanks,
Mike.
Binary files x/mdadm-3.2.5/debian/.rules.swp and mdadm-3.2.5/debian/.rules.swp
differ
diff -ruN x/mdadm-3.2.5/debian/changelog mdadm-3.2.5/debian/changelog
--- x/mdadm-3.2.5/debian/changelog 2012-05-25 18:05:23.0 +
+++ mdadm-3.2.5/debian/changelog2012-09-03 17:54:14.582811602 +
@@ -1,3 +1,14 @@
+mdadm (3.2.5-1+1) unstable; urgency=low
+
+ * also install mdmon in udeb and initramfs, so imsm arrays work
+ * link pidfiles of mdmons into /run/sendsigs.omit.d in the stop section
+of /etc/init.d/mdadm, and make sure that script runs before sendsigs.
+ * add script mdadm-waitidle that runs just before reboot/halt. For all
+arrays that are still running, it sets safe_mode_delay to a low version,
+sets sync_action to idle, and waits for the array(s) to go idle.
+
+ -- Miquel van Smoorenburg miqu...@debian.org Mon, 06 Aug 2012 23:29:32
+0200
+
mdadm (3.2.5-1) unstable; urgency=low
[ Michael Tokarev ]
diff -ruN x/mdadm-3.2.5/debian/initramfs/hook mdadm-3.2.5/debian/initramfs/hook
--- x/mdadm-3.2.5/debian/initramfs/hook 2012-05-25 17:31:37.0 +
+++ mdadm-3.2.5/debian/initramfs/hook 2012-08-01 22:32:50.925671675 +
@@ -49,6 +49,7 @@
}
MDADM=/sbin/mdadm
+MDMON=/sbin/mdmon
[ -x $MDADM ] || exit 0
[ -r /usr/share/initramfs-tools/hook-functions ] || exit 0
@@ -56,6 +57,7 @@
# copy the binary as early as possible
copy_exec $MDADM /sbin
+copy_exec $MDMON /sbin
# copy all modules into the initramfs, just for safety.
# we copy raid456 / raid5+raid6 because the hook script just won't do
diff -ruN x/mdadm-3.2.5/debian/mdadm-waitidle mdadm-3.2.5/debian/mdadm-waitidle
--- x/mdadm-3.2.5/debian/mdadm-waitidle 1970-01-01 00:00:00.0 +
+++ mdadm-3.2.5/debian/mdadm-waitidle 2012-08-06 21:49:22.138176669 +
@@ -0,0 +1,76 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: mdadm-waitidle
+# Required-Start:
+# Required-Stop:
+# Should-Stop: halt reboot kexec
+# X-Stop-After: umountroot
+# Default-Start:
+# Default-Stop: 0 6
+# Short-Description: Wait for MD arrays to become idle
+# Description: This script waits until all MD arrays are
+#in idle and synced state before halt/reboot.
+### END INIT INFO
+#
+set -eu
+
+. /lib/lsb/init-functions
+
+case ${1:-} in
+ start)
+;;
+ stop)
+cd /sys/block
+for md in md*
+do
+ if [ -d $md/md/ ]
+ then
+if [ -w $md/md/safe_mode_delay ]; then
+ echo 0.05 $md/md/safe_mode_delay ||:
+fi
+if [ -w $md/md/sync_action ]; then
+ echo idle $md/md/sync_action ||:
+fi
+array_found=1
+ fi
+done
+[ -z $array_found ] exit 0
+
+log_action_begin_msg Waiting for MD arrays to become idle
+sync
+start=`date +%s`
+secs=0
+while [ $secs -lt 10 ]
+do
+ secs=$((`date +%s` - $start))
+ active=
+ for md in md*
+ do
+# We wait for normal writes, but not too long for resyncs/rebuilds.
+state=`cat $md/md/array_state 2/dev/null || echo unknown`
+sync=`cat $md/md/sync_action 2/dev/null || echo idle`
+if [ $state = active ] ([ $sync = idle ] || [ $secs -lt 3 ])
+then
+ active=1
+fi
+ done
+ [ -n $active ] || break
+ sleep 0.2
+done
+
+if [ -n $active ]
+then
+ log_action_end_msg 1
+ sleep 1
+else
+ log_action_end_msg 0
+fi
+;;
+
+ *)
+echo Usage: ${0:-} {stop} 2
+exit 1;;
+
+esac
+
+exit 0
diff -ruN x/mdadm-3.2.5/debian/mdadm.init mdadm-3.2.5/debian/mdadm.init
--- x/mdadm-3.2.5/debian/mdadm.init 2012-05-10 20:22:16.0 +
+++ mdadm-3.2.5/debian/mdadm.init 2012-09-03 17:52:37.545176785 +
@@ -9,7 +9,7 @@
### BEGIN INIT INFO
# Provides: mdadm
# Required-Start:$local_fs $syslog mdadm-raid
-# Required-Stop: $local_fs $syslog mdadm-raid
+# Required-Stop: $local_fs $syslog sendsigs mdadm-raid
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: MD monitoring daemon
@@ -64,6 +64,10
Bug#684713: support for partitioned linux md devices
On 24-08-12 9:01 AM, Jim Meyering wrote: However, there is one minor oversight/bug in the kernel: the sysfs range key is still set to 1 for md devices. That means libparted thinks that it's not possible to partition that device, when in fact it is. The attached patch reckognizes that situation: if running on a kernel = 2.6.28, and the device is a PED_DEVICE_MD, and the sysfs 'range' key is set to '1', _device_get_partition_range() returns MAX_NUM_PARTS instead. Thanks for the patch. FYI, Petr Uzel made the following change in v3.0-61-gca97da9: * libparted/arch/linux.c (_device_get_partition_range): Use /sys/block/DEV/ext_range instead of range sysfs file Oh cool, that fixes the same bug. I was working of the debian version so I didn't notice it was already fixed. Sorry for the noise, please discard my patch. ext_range was added in kernel 2.6.28 (released 25 Dec 2008, almost 4 years ago) - I wonder if using ext_range instead of range should be made conditional depending on KERNEL_VERSION, or are kernels 2.6.28 sufficiently ancient that it's not worth worrying about? For debian it doesn't really matter I guess. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684713: support for partitioned linux md devices
Package: parted Version: 2.3-10 Severity: serious Tags: patch wheezy sid Background: I have added support to the debian installer for installation on Intel Matrix Raid (imsm) arrays as supported by mdadm (I'll be submitting patches to debian-boot soon). When installing on such an array, partitions are created directly on the array (e.g. /dev/md0). Before kernel 2.6.28, partitionable md arrays were seperate from 'normal' md arrays (different dev_t's), but since 2.6.28 that has been consolidated. At the same time a new sysfs key that indicates the max number of partitions has been introduced- the old key is called range and for md devices is always set to 1. The new key is called ext_range and contains the correct value. libparted should use the new key, otherwise it cannot partition md devices. Upstream has already changed to use the ext_range key instead of range: http://anonscm.debian.org/gitweb/?p=parted/parted.git;a=commitdiff;h=ca97da905bd21f2a4371f4717f7c46a936af6b2c commit ca97da905bd21f2a4371f4717f7c46a936af6b2c Author: Petr Uzel petr.u...@suse.cz Date: Sat Nov 26 15:45:08 2011 +0100 libparted: use ext_range to find out largest possible partition Parted uses /sys/block/DEV/range file to find out how many partitions can the blockdevice hold and uses this number in its algorithm for informing the kernel about modified partitions. This works fine for most devices, however, it fails on partitionable MD arrays, because these have 1 in range file. Using ext_range should be safer and work for all devices. * libparted/arch/linux.c (_device_get_partition_range): Use /sys/block/DEV/ext_range instead of range sysfs file * NEWS: Mention the change. Addresses: http://bugzilla.novell.com/567652 Attached is a backport of the patch to the version in wheezy/unstable. Please consider this patch for wheezy. Suggested changelog entry: * backport md-partitions.patch: libparted/arch/linux.c (_device_get_partition_range): Use /sys/block/DEV/ext_range instead of range sysfs file http://anonscm.debian.org/gitweb/?p=parted/parted.git;a=commitdiff;h=ca97da905bd21f2a4371f4717f7c46a936af6b2c commit ca97da905bd21f2a4371f4717f7c46a936af6b2c Author: Petr Uzel petr.u...@suse.cz Date: Sat Nov 26 15:45:08 2011 +0100 libparted: use ext_range to find out largest possible partition Parted uses /sys/block/DEV/range file to find out how many partitions can the blockdevice hold and uses this number in its algorithm for informing the kernel about modified partitions. This works fine for most devices, however, it fails on partitionable MD arrays, because these have 1 in range file. Using ext_range should be safer and work for all devices. * libparted/arch/linux.c (_device_get_partition_range): Use /sys/block/DEV/ext_range instead of range sysfs file Addresses: http://bugzilla.novell.com/567652 diff -u a/libparted/arch/linux.c b/libparted/arch/linux.c --- a/libparted/arch/linux.c2012-08-24 12:06:18.0 + +++ b/libparted/arch/linux.c2012-08-24 12:10:31.176877539 + @@ -2403,7 +2403,7 @@ /* * The number of partitions that a device can have depends on the kernel. - * If we don't find this value in /sys/block/DEV/range, we will use our own + * If we don't find this value in /sys/block/DEV/ext_range, we will use our own * value. */ static unsigned int @@ -2414,7 +2414,7 @@ FILE* fp; boolok; -r = snprintf(path, sizeof(path), /sys/block/%s/range, +r = snprintf(path, sizeof(path), /sys/block/%s/ext_range, last_component(dev-path)); if (r 0 || r = sizeof(path)) return MAX_NUM_PARTS;
Bug#684708: mdadm: support external metadata arrays correctly
On 20-08-12 11:42 AM, Michael Tokarev wrote: There's one more thing missing in there: mdmon should be re-started from real root after switching from rootfs -- the takeover. I guess it needs to be added to mdadm-raid. Is that really necessary? Can't we just leave it as-is, so the number of changes is minimized for now? On systems that don't have external metadata arrays (i.e. most of them) mdmon won't be running anyway. BTW, why mdadm-waitidle is a separate script? Can't we fold it into mdadm-raid directly? Well no, because it needs to run after all filesystems have been unmounted and root is read-only. Unless ofcourse you change mdadm-raid to run after root has been remounted read-only, but I do not know what consequences that change would have. The more I think about this all, the more it looks like it is too heavily change for wheezy. I understand the situation, but I still think it is not a good idea in general. Oh well. Well I still think this is more a bugfix than a new feature, since right now the functionality is there, it's just broken. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
On 08/14/2012 11:38 PM, Alasdair G Kergon wrote:
On Mon, Aug 13, 2012 at 12:25:04PM +0200, Miquel van Smoorenburg wrote:
This patch makes sure that disks with signatures of one of these
metadata formats are also filtered out. To minimize the chance of
regressions, it only does this if md is actually running (i.e.
/proc/mdstat is present).
Why is /proc/mdstat relevant?
Do the signatures not appear without it?
Otherwise that check shouldn't be added.
I was just being cautious. In theory, it could be that someone has
re-used a disk that had a ddf or imsm signature, and if nothing has
overwritten that signature in the mean time such a setup might now break
with lvm. Unless ofcourse md raid was activated, in which case mdadm in
initrd would have triggered on it (in debian, mdadm is started before
lvm) and would have broken the system in a different way..
OTOH, mdadm had the same theoretical issue when it started to support
imsm/ddf and apparently that worked out ok, so probably that check
should be dropped.
And I'm not sure that it's exclusively 'md' (dmraid?) so the code might
need to go in a function with a different name.
I guess. What about the attached patch? The only thing is that I did not
bother to create seperate ddf_component_detection and
imsm_component_detection settings in lvm.conf, for now that's all lumped
under the md_component_detection setting.
Thanks,
Mike.
Description: Also automatically filter DDF and IMSM formatted disks
Author: Miquel van Smoorenburg miqu...@debian.org
Index: lvm2-2.02.95/lib/device/dev-ddf.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ lvm2-2.02.95/lib/device/dev-ddf.c 2012-08-15 16:18:08.019582071 +
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012 Miquel van Smoorenburg
+ *
+ * This file is part of LVM2.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions
+ * of the GNU Lesser General Public License v.2.1.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include lib.h
+#include metadata.h
+#include xlate.h
+#include crc.h
+
+#define DDF_MAGIC 0xDE11DE11
+struct ddf_header {
+ uint32_t magic;
+ uint32_t crc;
+ char guid[24];
+ char revision[8];
+ char padding[472];
+};
+
+/*
+ * Returns -1 on error
+ */
+int dev_is_ddf(struct device *dev, uint64_t *sb)
+{
+ struct ddf_header hdr;
+ uint32_t crc;
+ int ret = 0;
+ uint64_t size, sb_offset;
+
+ if (!dev_get_size(dev, size)) {
+ stack;
+ return -1;
+ }
+
+ if (!dev_open_readonly(dev)) {
+ stack;
+ return -1;
+ }
+
+ /* Also calculate CRC so we have at least 8 bytes to check */
+ sb_offset = size - 512;
+ if (dev_read(dev, sb_offset, 512, hdr)
+ (hdr.magic == xlate32(DDF_MAGIC))) {
+ crc = hdr.crc;
+ hdr.crc = 0x;
+ if (xlate32(calc_crc(0, (const uint8_t *)hdr, 512)) == crc)
+ ret = 1;
+ }
+
+ if (!dev_close(dev))
+ stack;
+
+ if (ret sb)
+ *sb = sb_offset;
+
+ return ret;
+}
+
Index: lvm2-2.02.95/lib/device/dev-imsm.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ lvm2-2.02.95/lib/device/dev-imsm.c 2012-08-15 16:18:16.955745514 +
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2012 Miquel van Smoorenburg
+ *
+ * This file is part of LVM2.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions
+ * of the GNU Lesser General Public License v.2.1.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include lib.h
+#include metadata.h
+
+#define IMSM_SIGNATURE Intel Raid ISM Cfg Sig.
+#define IMSM_SIG_LEN (strlen(IMSM_SIGNATURE))
+
+/*
+ * Returns -1 on error
+ */
+int dev_is_imsm(struct device *dev, uint64_t *sb)
+{
+ char imsm_signature[IMSM_SIG_LEN];
+ int ret = 0;
+ uint64_t size, sb_offset;
+
+ if (!dev_get_size(dev, size)) {
+ stack;
+ return -1;
+ }
+
+ if (!dev_open_readonly(dev)) {
+ stack;
+ return -1;
+ }
+
+ sb_offset = size - 1024;
+ if (dev_read(dev, sb_offset, IMSM_SIG_LEN, imsm_signature)
+ memcmp(imsm_signature, IMSM_SIGNATURE, IMSM_SIG_LEN) == 0)
+ ret = 1;
+
+ if (!dev_close(dev))
+ stack;
+
+ if (ret sb)
+ *sb = sb_offset;
+
+ return ret;
+}
+
Index: lvm2-2.02.95/lib/device/device.h
===
--- lvm2-2.02.95.orig/lib/device/device.h 2012-08-15 15:04:03.757865705 +
+++ lvm2-2.02.95/lib/device/device.h 2012-08-15 15:04:19.042146729 +
@@ -101,6 +101,8 @@
/* Does device contain md
Bug#684708: mdadm: support external metadata arrays correctly
On 08/13/2012 01:43 PM, Michael Tokarev wrote: On 13.08.2012 14:10, Miquel van Smoorenburg wrote: Package: mdadm Version: 3.2.5-1 Severity: serious Tags: patch wheezy sid The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon is not included in the .udeb for the installer. This means that if you have an array with external metadata (ddf or, more widely used, imsm - Intel Matrix Raid) that it will come up readonly. This causes the installer to hang or the system not being able to boot if root is on that array. I'm not sure this is the right course of actions -- speaking of the initramfs part, not about the d-i part. What's wrong with the array being started read-only? Root filesystem has always been mounted readonly in initrd/initramfs. There's no fsck tool included in initramfs. Once we switch to real root, we may start mdmon and remount filesystem(s) read-write as appropriate, after fsck'ing them etc. Why the system is not being able to boot if root is on such an array? Ah. You could ofcourse start mdmon very early in the bootprocess once you've switched to the real rootfilesystem, but that sounds fragile to me. mdadm automatically starts mdmon when needed, for the right array, at the right time. If you include mdmon in the initramfs, you do not need extra initscripts, you can debug stuff if you happen to get dropped in an initramfs prompt, you can boot with init=/bin/bash to repair things and easily mount the rootfs rw, etc. - it adds a mdadm-waitidle script that runs just before reboot/halt. For all arrays that are still running, it sets safe_mode_delay to a low version, sets sync_action to idle, and waits for the array(s) to go idle. This is needed so that the array is clean, otherwise it will start to resync at the next boot. This is risky - we may never finish shutdown. This is especially risky for things like raid - eg, stalled raid (resync) thread (we've seen these more than once) -- in such cases current code will shut down, but with this wait it wont anymore. Especially useful for remote systems. Such an approach should be tested with extra care, I'm not sure we have resources to do that for wheezy. Generally it is a good idea I think. Well no... /etc/init.d/mdadm-waitidle doesn't do anything if you don't have external metadata arrays, it runs for all arrays in parallel, and it has a timeout of a couple of seconds. It will NOT block shutdown. The mdadm/mdmon documentation in fact says that you have to do this, and there is a special mdadm mode for it: mdadm --wait-clean --scan. You are supposed to run that after unmounting the rootfs. I have chosen a different implementation in /etc/init.d/mdadm-waitidle, because I think it is faster, and I did not want to patch mdadm. - it adds 2 lines of code to mdmon.c so that it symlinks its pidfile into /run/sendsigs.omit.d - mdmon should not be killed at shutdown, we still need it after the rootfs has been unmounted. And I'm not sure this is needed, either: it can trivially be done in the initscript. Hmm, not if you start/stop arrays (other than the rootfs ofcourse...) manually with mdadm, since mdadm takes care of starting/stopping mdmon for you. Because it does that, it should also take care of /run/sendsigs.omit.d, which is trivial (just a symlink). I have added support for installation on Intel Matrix raid (imsm) arrays using mdadm to d-i, and I'll be sending patches to the debian-boot list soon. Please consider this patch for inclusion in wheezy. So far I think the only real change there is the inclusion of mdmon to the udeb, the other changes are a bit questionable for wheezy. The changes only apply to systems with external metadata arrays, which are broken right now anyway if I'm not mistaken- the mdadm in initramfs starts all arrays, but right now nothing starts mdmon.. This is not a new feature, it's a bugfix. (*) ofcourse it needs to be verified - the takeover after booting into real system. I can't do it, since I don't have any spare system right now to install debian onto imsm array. I can only verify that the new takeover does not harm regular boot process without imsm arrays. One slight problem: mdadm only supports imsm on systems that actually have the Intel Matrix raid option rom installed. There are a lot of those systems, even laptops, but you do have to have one lying around. This change - mdmon in initramfs - might be included to wheezy, it isn't a dramatic change. But I still don't think it is a good idea in general -- using native md arrays is a much better way. I agree, but the advantage of imsm raid is that the BIOS knows about it. So if a disk is broken, the system still boots. Also you can share the RAID setup with other OSes. But yes, we should really have BIOSes that understand linux md raid .. Thank you, Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
On 13-08-12 12:57 PM, Bastian Blank wrote: On Mon, Aug 13, 2012 at 12:25:04PM +0200, Miquel van Smoorenburg wrote: This patch makes sure that disks with signatures of one of these metadata formats are also filtered out. To minimize the chance of regressions, it only does this if md is actually running (i.e. /proc/mdstat is present). Is this patch applied upstream? No, it isn't. I have been tasked with getting the debian-installer to install on imsm (Intel Matrix sataraid) arrays, and this is one of the things I had to fix - otherwise lvm detects existing LVM arrays three times, once on the MD RAID1 device and twice on the underlaying disks... I have also fixed stuff in mdadm (existing but incomplete support for imsm) and libparted (bugs), and updated several installer udebs. Since I think it's might be worth it to have support for this in the main debian release, I thought I'd start by filing bugs against the packages I updated/fixed. I know it's late in the release cycle, the freeze has started, so it's very possible I'm too late, but in that case it's unstable material. I have to start somewhere, you know :) Should I submit this to upstream first? Or are you guys in the habit of doing that? Thanks, Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
On 14-08-12 11:05 PM, Miquel van Smoorenburg wrote: On 13-08-12 12:57 PM, Bastian Blank wrote: On Mon, Aug 13, 2012 at 12:25:04PM +0200, Miquel van Smoorenburg wrote: This patch makes sure that disks with signatures of one of these metadata formats are also filtered out. To minimize the chance of regressions, it only does this if md is actually running (i.e. /proc/mdstat is present). Is this patch applied upstream? No, it isn't. I have been tasked with getting the debian-installer to install on imsm (Intel Matrix sataraid) arrays To clarify: by the company I work for, not by some debian team. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684708: mdadm: support external metadata arrays correctly
Package: mdadm
Version: 3.2.5-1
Severity: serious
Tags: patch wheezy sid
The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon
is not included in the .udeb for the installer.
This means that if you have an array with external metadata (ddf or,
more widely used, imsm - Intel Matrix Raid) that it will come up
readonly. This causes the installer to hang or the system not being
able to boot if root is on that array.
The attached patch does a couple of things:
- it makes sure mdadm is included in the initramfs and the udeb package
- it adds a mdadm-waitidle script that runs just before reboot/halt. For all
arrays that are still running, it sets safe_mode_delay to a low version,
sets sync_action to idle, and waits for the array(s) to go idle.
This is needed so that the array is clean, otherwise it will start
to resync at the next boot.
- it adds 2 lines of code to mdmon.c so that it symlinks its pidfile
into /run/sendsigs.omit.d - mdmon should not be killed at shutdown,
we still need it after the rootfs has been unmounted.
I have added support for installation on Intel Matrix raid (imsm)
arrays using mdadm to d-i, and I'll be sending patches to the debian-boot
list soon. Please consider this patch for inclusion in wheezy.
Mike.
Binary files orig/mdadm-3.2.5/debian/.rules.swp and mdadm-3.2.5/debian/.rules.swp differ
diff -ruN orig/mdadm-3.2.5/debian/changelog mdadm-3.2.5/debian/changelog
--- orig/mdadm-3.2.5/debian/changelog 2012-05-25 20:05:23.0 +0200
+++ mdadm-3.2.5/debian/changelog 2012-08-06 23:30:04.171100029 +0200
@@ -1,3 +1,14 @@
+mdadm (3.2.5-1+1) unstable; urgency=low
+
+ * also install mdmon in udeb and initramfs, so imsm arrays work
+ * mdmon now automatically makes a symlink in /run/sendsigs.omit.d to its pidfile
+ * create /run/sendsigs.omit.d/ in local-top script
+ * add script mdadm-waitidle that runs just before reboot/halt. For all
+arrays that are still running, it sets safe_mode_delay to a low version,
+sets sync_action to idle, and waits for the array(s) to go idle.
+
+ -- Miquel van Smoorenburg miqu...@debian.org Mon, 06 Aug 2012 23:29:32 +0200
+
mdadm (3.2.5-1) unstable; urgency=low
[ Michael Tokarev ]
diff -ruN orig/mdadm-3.2.5/debian/initramfs/hook mdadm-3.2.5/debian/initramfs/hook
--- orig/mdadm-3.2.5/debian/initramfs/hook 2012-05-25 19:31:37.0 +0200
+++ mdadm-3.2.5/debian/initramfs/hook 2012-08-02 00:32:50.925671675 +0200
@@ -49,6 +49,7 @@
}
MDADM=/sbin/mdadm
+MDMON=/sbin/mdmon
[ -x $MDADM ] || exit 0
[ -r /usr/share/initramfs-tools/hook-functions ] || exit 0
@@ -56,6 +57,7 @@
# copy the binary as early as possible
copy_exec $MDADM /sbin
+copy_exec $MDMON /sbin
# copy all modules into the initramfs, just for safety.
# we copy raid456 / raid5+raid6 because the hook script just won't do
diff -ruN orig/mdadm-3.2.5/debian/initramfs/script.local-top mdadm-3.2.5/debian/initramfs/script.local-top
--- orig/mdadm-3.2.5/debian/initramfs/script.local-top 2012-05-10 22:22:16.0 +0200
+++ mdadm-3.2.5/debian/initramfs/script.local-top 2012-08-06 17:32:30.162720885 +0200
@@ -53,6 +53,9 @@
# handle /dev/md/X nodes
mkdir -p /dev/md
+# mdmon wants this directory to exist
+mkdir -p /run/sendsigs.omit.d
+
CONFIG=/etc/mdadm/mdadm.conf
# in case the hook failed to install a configuration file, this is our last
# attempt... the emergency procedure... drumroll
diff -ruN orig/mdadm-3.2.5/debian/mdadm-waitidle mdadm-3.2.5/debian/mdadm-waitidle
--- orig/mdadm-3.2.5/debian/mdadm-waitidle 1970-01-01 01:00:00.0 +0100
+++ mdadm-3.2.5/debian/mdadm-waitidle 2012-08-06 23:49:22.138176669 +0200
@@ -0,0 +1,76 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: mdadm-waitidle
+# Required-Start:
+# Required-Stop:
+# Should-Stop: halt reboot kexec
+# X-Stop-After: umountroot
+# Default-Start:
+# Default-Stop: 0 6
+# Short-Description: Wait for MD arrays to become idle
+# Description: This script waits until all MD arrays are
+#in idle and synced state before halt/reboot.
+### END INIT INFO
+#
+set -eu
+
+. /lib/lsb/init-functions
+
+case ${1:-} in
+ start)
+;;
+ stop)
+cd /sys/block
+for md in md*
+do
+ if [ -d $md/md/ ]
+ then
+if [ -w $md/md/safe_mode_delay ]; then
+ echo 0.05 $md/md/safe_mode_delay ||:
+fi
+if [ -w $md/md/sync_action ]; then
+ echo idle $md/md/sync_action ||:
+fi
+array_found=1
+ fi
+done
+[ -z $array_found ] exit 0
+
+log_action_begin_msg Waiting for MD arrays to become idle
+sync
+start=`date +%s`
+secs=0
+while [ $secs -lt 10 ]
+do
+ secs=$((`date +%s` - $start))
+ active=
+ for md in md*
+ do
+# We wait for normal writes, but not too long for resyncs/rebuilds.
+state=`cat $md/md/array_state 2/dev/null || echo unknown`
+sync=`cat $md/md/sync_action 2/dev/null || echo idle
Bug#684712: lvm2: automatically filter imsm and ddf formatted disks
Package: lvm2
Version: 2.02.95-4
Tags: patch wheezy sid
Severity: important
Currently, lvm automatically filters out mdraid devices. That is a
good thing, otherwise it could accidentally activate volume groups
on disks that are part of a mdraid array.
For quite some time now, the mdraid subsystem (mainly through mdadm)
supports more metadata formats than native mdraid only. These are
the 'imsm' (Intel Matrix Raid) and 'ddf' formats.
This patch makes sure that disks with signatures of one of these
metadata formats are also filtered out. To minimize the chance of
regressions, it only does this if md is actually running (i.e.
/proc/mdstat is present).
Background: I have added support for installation on Intel Matrix raid (imsm)
arrays using mdadm to d-i, and I'll be sending patches to the debian-boot
list soon. Please consider this patch for inclusion in wheezy.
Changelog entry:
* lvm already filters disks that have a mdraid signature, now also filter
DDF and IMSM formatted disks as well - but only if MD is actually running.
Mike.
Description: Also automatically filter DDF and IMSM formatted disks
Author: Miquel van Smoorenburg miqu...@debian.org
--- lvm2-2.02.95.orig/lib/device/dev-md.c
+++ lvm2-2.02.95/lib/device/dev-md.c
@@ -16,6 +16,7 @@
#include lib.h
#include metadata.h
#include xlate.h
+#include crc.h
#include filter.h
#ifdef linux
@@ -29,6 +30,18 @@
- MD_RESERVED_SECTORS)
#define MD_MAX_SYSFS_SIZE 64
+#define IMSM_SIGNATURE Intel Raid ISM Cfg Sig.
+#define IMSM_SIG_LEN (strlen(IMSM_SIGNATURE))
+
+#define DDF_MAGIC 0xDE11DE11
+struct ddf_header {
+ uint32_t magic;
+ uint32_t crc;
+ char guid[24];
+ char revision[8];
+ char padding[472];
+};
+
static int _dev_has_md_magic(struct device *dev, uint64_t sb_offset)
{
uint32_t md_magic;
@@ -42,6 +55,34 @@ static int _dev_has_md_magic(struct devi
return 0;
}
+static int _dev_has_imsm_superblock(struct device *dev, uint64_t dev_size)
+{
+ char imsm_signature[IMSM_SIG_LEN];
+
+ if (dev_read(dev, dev_size - 1024, IMSM_SIG_LEN, imsm_signature)
+ memcmp(imsm_signature, IMSM_SIGNATURE, IMSM_SIG_LEN) == 0)
+ return 1;
+
+ return 0;
+}
+
+static int _dev_has_ddf_superblock(struct device *dev, uint64_t dev_size)
+{
+ struct ddf_header hdr;
+ uint32_t crc;
+
+ /* Also calculate CRC so we have at least 8 bytes to check */
+ if (dev_read(dev, dev_size - 512, 512, hdr)
+ (hdr.magic == xlate32(DDF_MAGIC))) {
+ crc = hdr.crc;
+ hdr.crc = 0x;
+ if (xlate32(calc_crc(0, (const uint8_t *)hdr, 512)) == crc)
+ return 1;
+ }
+
+ return 0;
+}
+
/*
* Calculate the position of the superblock.
* It is always aligned to a 4K boundary and
@@ -86,6 +127,7 @@ int dev_is_md(struct device *dev, uint64
int ret = 1;
md_minor_version_t minor;
uint64_t size, sb_offset;
+ struct stat st;
if (!dev_get_size(dev, size)) {
stack;
@@ -114,6 +156,18 @@ int dev_is_md(struct device *dev, uint64
goto out;
} while (++minor = MD_MINOR_VERSION_MAX);
+ /* Only check for ddf/imsm if md is actually running. */
+ if (stat(/proc/mdstat, st) 0)
+ goto out;
+
+ /* Check if it is a ddf container device */
+ if (_dev_has_ddf_superblock(dev, size))
+ goto out;
+
+ /* Check if it is an imsm container device */
+ if (_dev_has_imsm_superblock(dev, size))
+ goto out;
+
ret = 0;
out:
Bug#684713: parted: support for partitioned MD devices
Package: parted Version: 2.3-10 Severity: serious Tags: patch wheezy sid Background: I have added support to the debian installer for installation on Intel Matrix Raid (imsm) arrays as supported by mdadm (I'll be submitting patches to debian-boot soon). When installing on such an array, partitions are created directly on the array (e.g. /dev/md0). Before kernel 2.6.28, partitionable md arrays were seperate from 'normal' md arrays (different dev_t's), but since 2.6.28 that has been consolidated. However, there is one minor oversight/bug in the kernel: the sysfs range key is still set to 1 for md arrays. That means libparted thinks that it's not possible to partition that device, where in fact it is. The attached patch reckognizes that situation: if running on a kernel = 2.6.28, and the device is a PED_DEVICE_MD, and the sysfs 'range' key is set to '1', _device_get_partition_range() returns MAX_NUM_PARTS instead. Please consider this patch for wheezy. Suggested changelog entry: * starting at kernel 2.6.28, MD devices can be partitioned, but the sysfs range key only shows support for one partition/device. Ignore that setting if it's set to 1 and the kernel version is = 2.6.28. Mike. Index: parted-2.3/libparted/arch/linux.c === --- parted-2.3.orig/libparted/arch/linux.c 2010-05-10 10:57:54.0 + +++ parted-2.3/libparted/arch/linux.c 2012-08-05 13:24:14.449768577 + @@ -2415,6 +2415,11 @@ ok = fscanf(fp, %d, range) == 1; fclose(fp); + /* starting at 2.6.28 partitions are OK but range doesn't show it */ + if (dev-type == PED_DEVICE_MD range == 1 + _get_linux_version() = KERNEL_VERSION (2,6,28)) + ok = 0; + /* (range = 0) is none sense.*/ return ok range 0 ? range : MAX_NUM_PARTS; }
Bug#674894: preseeding: Partitions are not aligned when forcing GPT
I reopened this bug, because I would like this bug to be fixed in a point-release of squeeze. If that is not possible or against policy, feel free to close this bug. Otherwise I ask that, if in a pointrelease an updated installer is shipped, you consider adding this patch to partman-base. Thank you partman-base-147-align-gpt.patch --- partman-base/parted_server.c2010-10-04 22:16:53.0 +0200 +++ partman-base-158/parted_server.c2012-07-02 14:57:03.0 +0200 @@ -1,6 +1,7 @@ #include parted/parted.h #include sys/types.h #include sys/wait.h +#include sys/stat.h #include unistd.h #include stdio.h #include string.h @@ -608,10 +609,16 @@ ped_disk_set_flag(disk, PED_DISK_CYLINDER_ALIGNMENT, devices[index].alignment == ALIGNMENT_CYLINDER); -else +else if (0 != strcmp(disk-type-name, gpt)) /* If the PED_DISK_CYLINDER_ALIGNMENT flag isn't - available, then (confusingly) we should assume - that *only* cylinder alignment is available. */ + available, then there are two alternatives: + either the disk label format is too old to know + about modern alignment (#579948), or it's too new + to care about cylinder alignment (#674894). The + only format currently known to fall into the + latter category is GPT; for the others, we should + assume that *only* cylinder alignment is + available. */ devices[index].alignment = ALIGNMENT_CYLINDER; } } -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650265: dma: cannot deliver mail to smtp server
Package: dma
Version: 0.0.2010.06.17-6
Severity: grave
DMA often fails to deliver mail to my smtp server, keeping messages
in the queue until they expire. They then fail to bounce as well.
That's why I set the severity to grave - it causes dataloss,
at least for me.
This is because it sometimes doesn't read the entire line
in the SMTP conversation up to \r\n. I suspect that happends when
the remote system doesn't send the entire line in one TCP packet,
which is probably unusual (it might be an anti-spam measure),
but valid. Example from strace:
10035 connect(6, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr(194.109.6.51)}, 16) = 0
10035 read(6, 220 smtp-vbr11.xs4all.nl ESMTP Sendmail 8.13.8, 2048) = 46
10035 write(6, EHLO newsfeed5.news.xs4all.nl\r\n, 31) = 31
10035 read(6, /8.13.8; Mon, 28 Nov 2011 11:34:52 +0100 (CET)\r\n, 2048) = 48
10035 sendto(5, 21Nov 28 11:34:52 dma[1580fa.612b00]: remote delivery
deferred: smtp.xs4all.nl [194.109.6.51] failed after EHLO: invalid syntax in
reply from server, 150, MSG_NOSIGNAL, NULL, 0) = 150
As you can see, dma reads the first 46 bytes of the SMTP welcome
line, then sends an EHLO, then wants to read the reply to the EHLO
but gets the rest of the SMTP welcome line, and errors out.
Mike.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650268: dma: invalid Received: line syntax
Package: dma Version: 0.0.2010.06.17-6 Severity: normal dma adds an invalid Received: line to outgoing mail: Received: from news (uid 9) (envelope-from n...@myserver.xs4all.nl) id 1a8d7 by myserver.xs4all.nl (DragonFly Mail Agent) Sat, 19 Nov 2011 03:40:01 +0100 sendmail does this, spot the difference: Received: (from root@localhost) by someserver.xs4all.nl (8.13.8/8.13.8/Submit) id pASB00Nq034531; Mon, 28 Nov 2011 12:00:00 +0100 (CET) (envelope-from root) According to RFC2822, the syntax of the Received: line should be: received= Received: name-val-list ; date-time CRLF As you can see, the semi-colon between the name-val-list and date-time is missing in dma's received line. This makes (anti-spam) systems that parse Received: line headers complain. It might also add to the spamminess score of mail sent by dma. It should probably look more like: Received: from news (uid 9) by myserver.xs4all.nl (DragonFly Mail Agent) id 1a8d7; Sat, 19 Nov 2011 03:40:01 +0100 (envelope-from n...@myserver.xs4all.nl) .. but just adding the semicolon is enough to make it rfc2822-compliant. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650265: dma: cannot deliver mail to smtp server
tag 650265 +patch
thanks
This should go into stable too if possible.
Description: Read reponse from smtp server up to crlf
Author: Miquel van Smoorenburg miqu...@cistron.nl
Last-Update: 2011-11-28
--- a/net.c 2011-11-28 12:27:29.0 +0100
+++ b/net.c 2011-11-28 13:00:39.145291582 +0100
@@ -166,6 +166,14 @@
}
len += rlen;
}
+ /* read up to \n */
+ if (memchr(buff + pos, '\n', len - pos) == NULL) {
+ if (len sizeof(buff))
+ continue;
+ strcpy(neterr, line too long in reply from server);
+ return (-1);
+ }
+
/*
* If there is an external buffer with a size bigger than zero
* and as long as there is space in the external buffer and
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650268: dma: invalid Received: line syntax
tag 650268 +patch thanks This probably should go into stable as well, I guess. Description: Add semicolon before date in received: header Author: Miquel van Smoorenburg miqu...@cistron.nl Last-Update: 2011-11-28 --- a/mail.c2011-11-28 12:27:29.0 +0100 +++ b/mail.c2011-11-28 13:02:11.077291647 +0100 @@ -174,7 +174,7 @@ error = fprintf(bounceq.mailf, Received: from MAILER-DAEMON\n \tid %s\n - \tby %s (%s)\n + \tby %s (%s);\n \t%s\n X-Original-To: %s\n From: MAILER-DAEMON \n @@ -452,7 +452,7 @@ Received: from %s (uid %d)\n \t(envelope-from %s)\n \tid %s\n - \tby %s (%s)\n + \tby %s (%s);\n \t%s\n, username, getuid(), queue-sender, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637465: liblockfile: package liblockfile1 in control file but not in files list
On 11-08-11 8:31 PM, Sven Joachim wrote:
This upload dropped the liblockfile{1,-bin} packages, making
liblockfile-dev uninstallable. From my debuild log:
Thanks, sorry about that. I fixed it, but:
Your package contains new components which requires manual editing of
the override file. It is ok otherwise, so please be patient. New
packages are usually added to the override file about once a week.
.. so it might take a few days before it becomes visible.
Mike.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595154: grub2: configure wants to install on md_d0p1 instead of md_d0
Package: grub2 Version: 1.98+20100804-4 Severity: normal When installing grub2 on a system that boots from a partitioned mdraid (after applying the fixes in #595071), the configure step asks me for disks to install on: /dev/sda /dev/sdb /dev/md_d0p1 Grub2 should be installed on /dev/md_d0, but somehow the configure step offers /dev/md_d0p1 instead. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595066: grub2: doesn't reckognize partioned mdraid disks
Package: grub2
Version: 1.96+20090709-1
Severity: important
Currently grub2 doesn't reckognize a system that boots from
a partitionable mdraid disk, as I have. So the upgrade I did
from lenny/grub-legacy to squeeze/grub2 failed.
The main block device is called /dev/md_d0 and the partitions
are md_d0p1, md_d0p2 etc.
It turns out that grub2 does have all the code to make this work,
but it looks like it hasn't been tested much and so regressed.
It needs 2 fixes for it to work, attached as patches.
1. grub2-md_d0-osdev.patch
A problem description and this patch (for a slightly earlier
grub version) can be found at http://savannah.gnu.org/bugs/?29903
(Original author as in the bugreport)
2. grub2-md_d0-grubdev.patch
When grub gets the real mdraid name from mdadm, the partition
information is lost. This patch adds it back.
(Author is me)
With these fixes applied I can grub-install /dev/md_d0 and
have a booting system.
Mike.
diff -ruN x/grub2-1.98+20100804/util/i386/pc/grub-setup.c grub2-1.98+20100804/util/i386/pc/grub-setup.c
--- x/grub2-1.98+20100804/util/i386/pc/grub-setup.c 2010-08-04 05:40:55.0 +0200
+++ grub2-1.98+20100804/util/i386/pc/grub-setup.c 2010-08-27 18:37:31.0 +0200
@@ -824,7 +824,7 @@
char **devicelist;
int i;
- devicelist = grub_util_raid_getmembers (dest_dev);
+ devicelist = grub_util_raid_getmembers (argv[optind]);
for (i = 0; devicelist[i]; i++)
{
diff -ruN x/grub2-1.98+20100804/util/raid.c grub2-1.98+20100804/util/raid.c
--- x/grub2-1.98+20100804/util/raid.c 2010-06-03 01:13:14.0 +0200
+++ grub2-1.98+20100804/util/raid.c 2010-08-24 23:09:09.0 +0200
@@ -59,22 +59,15 @@
grub_util_raid_getmembers (char *name)
{
int fd, ret, i, j;
- char *devname;
char **devicelist;
mdu_version_t version;
mdu_array_info_t info;
mdu_disk_info_t disk;
- devname = xmalloc (strlen (name) + 6);
- strcpy (devname, /dev/);
- strcpy (devname+5, name);
-
- fd = open (devname, O_RDONLY);
+ fd = open (name, O_RDONLY);
if (fd == -1)
-grub_util_error (can't open %s: %s, devname, strerror (errno));
-
- free (devname);
+grub_util_error (can't open %s: %s, name, strerror (errno));
ret = ioctl (fd, RAID_VERSION, version);
if (ret != 0)
--- x/grub2-1.98+20100804/kern/emu/getroot.c 2010-08-02 21:44:02.0 +0200
+++ grub2-1.98+20100804/kern/emu/getroot.c 2010-08-30 15:27:20.0 +0200
@@ -657,6 +657,16 @@
}
}
+/* restore partition info */
+if (name
+ !strncmp (os_dev, /dev/md_d, 9)
+ (buf = strchr (os_dev, 'p')) != NULL)
+ {
+char *newname = malloc (strlen (name) + strlen (buf + 1) + 2);
+sprintf (newname, %s,%s, name, buf + 1);
+free (name);
+name = newname;
+ }
out:
close (mdadm_pipe[0]);
waitpid (mdadm_pid, NULL, 0);
Bug#595071: grub2: doesn't reckognize partioned mdraid disks
Package: grub2
Version: 1.98+20100804-4
Severity: important
Currently grub2 doesn't reckognize a system that boots from
a partitionable mdraid disk, as I have. So the upgrade I did
from lenny/grub-legacy to squeeze/grub2 failed.
The main block device is called /dev/md_d0 and the partitions
are md_d0p1, md_d0p2 etc.
It turns out that grub2 does have all the code to make this work,
but it looks like it hasn't been tested much and so regressed.
It needs 2 fixes for it to work, attached as patches.
1. grub2-md_d0-osdev.patch
A problem description and this patch (for a slightly earlier
grub version) can be found at http://savannah.gnu.org/bugs/?29903
(Original author as in the bugreport)
2. grub2-md_d0-grubdev.patch
When grub gets the real mdraid name from mdadm, the partition
information is lost. This patch adds it back.
(Author is me)
With these fixes applied I can grub-install /dev/md_d0 and
have a booting system.
Mike.
diff -ruN x/grub2-1.98+20100804/util/i386/pc/grub-setup.c grub2-1.98+20100804/util/i386/pc/grub-setup.c
--- x/grub2-1.98+20100804/util/i386/pc/grub-setup.c 2010-08-04 05:40:55.0 +0200
+++ grub2-1.98+20100804/util/i386/pc/grub-setup.c 2010-08-27 18:37:31.0 +0200
@@ -824,7 +824,7 @@
char **devicelist;
int i;
- devicelist = grub_util_raid_getmembers (dest_dev);
+ devicelist = grub_util_raid_getmembers (argv[optind]);
for (i = 0; devicelist[i]; i++)
{
diff -ruN x/grub2-1.98+20100804/util/raid.c grub2-1.98+20100804/util/raid.c
--- x/grub2-1.98+20100804/util/raid.c 2010-06-03 01:13:14.0 +0200
+++ grub2-1.98+20100804/util/raid.c 2010-08-24 23:09:09.0 +0200
@@ -59,22 +59,15 @@
grub_util_raid_getmembers (char *name)
{
int fd, ret, i, j;
- char *devname;
char **devicelist;
mdu_version_t version;
mdu_array_info_t info;
mdu_disk_info_t disk;
- devname = xmalloc (strlen (name) + 6);
- strcpy (devname, /dev/);
- strcpy (devname+5, name);
-
- fd = open (devname, O_RDONLY);
+ fd = open (name, O_RDONLY);
if (fd == -1)
-grub_util_error (can't open %s: %s, devname, strerror (errno));
-
- free (devname);
+grub_util_error (can't open %s: %s, name, strerror (errno));
ret = ioctl (fd, RAID_VERSION, version);
if (ret != 0)
--- x/grub2-1.98+20100804/kern/emu/getroot.c 2010-08-02 21:44:02.0 +0200
+++ grub2-1.98+20100804/kern/emu/getroot.c 2010-08-30 15:27:20.0 +0200
@@ -657,6 +657,16 @@
}
}
+/* restore partition info */
+if (name
+ !strncmp (os_dev, /dev/md_d, 9)
+ (buf = strchr (os_dev, 'p')) != NULL)
+ {
+char *newname = malloc (strlen (name) + strlen (buf + 1) + 2);
+sprintf (newname, %s,%s, name, buf + 1);
+free (name);
+name = newname;
+ }
out:
close (mdadm_pipe[0]);
waitpid (mdadm_pid, NULL, 0);
Bug#563074: hostname: FQ hostnames, -s option etc
Package: hostname Version: 3.01 Severity: normal I know it's a recurring theme, but IMO hostname is broken when you use a FQDN as the hostname. There are people who say you should not do that - and yet there are OSes that do this by default. In our case, we're converting FreeBSD boxes to Debian boxes and existing software assumes a FQDN as hostname. Now the current hostname can /set/ a FQDN as hostname: # hostname test.xs4all.nl (no errors) .. but it is impossible to print it: # hostname test However, the long hostname was set: # uname -n test.xs4all.nl The manpage says: GET NAME When called without any arguments, the program displays the current names: hostname will print the name of the system as returned by the gethost‐ name(2) function. This is not true. The manpage also says: -s, --short Display the short host name. This is the host name cut at the first dot. It now appears that -s is the default and there is no way to turn it off. Please fix hostname to follow the manpage. Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528494: vim-tiny: move to /bin?
According to James Vega: In looking at the following request for vim-tiny to provide /bin/vi I noticed that elvis-tiny already provides such a binary. In order to fullfil this request, I'd like to ask that elvis-tiny switch to using alternatives for /bin/vi. The plan that I would like to move forward with is for both vim-tiny and elvis-tiny to provide their binary under /bin and then use alternatives to provide /usr/bin/vi and /bin/vi (as a slave of the /usr/bin/vi alternative). This looks similar to what elvis-tiny is already doing except it has an odd /bin/vi binary (generated from debian/wrapper.c) doing the work instead of utilizing alternatives. Well, the original bug submission #528494 talks about that- you cannot have different 'vi' binaries in /bin and /usr/bin, since that would be very inconsistent. What /bin/vi in elvis-tiny does is very simple: - if /usr/bin/vi exists, execute it (common case) - else if /bin/elvis-tiny exists execute it (/usr not available) - else print error and exit This way you always get /usr/bin/vi, even if /bin is in your PATH first, unless /usr/bin/vi doesn't exist. We could work together to allow multiple '*vi-tiny' packages to be installed, in that case we should really do the following: - each *vi-tiny package sets an alternative for /bin/vi-tiny - each *vi-tiny package depends on vi-tiny-common - vi-tiny-common is basically the /bin/vi from elvis-tiny, as described above, where it tries to execute /bin/vi-tiny instead of /bin/elvis-tiny However, to me this sounds as a lot of work for very little gain. We already have the elvis-tiny package to provide a small vi clone for situations where /usr is not available. This would be a rescue situation. Is it really neccesary to be able to choose between tons of vi-clones in that case ? Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524474: apache2: FollowSymlinks / SymlinksIfOwnerMatch ignored with server-side-includes
Package: apache2 Version: 2.2.9-10+lenny2 Severity: grave Tags: patch security lenny sid 1. BUG DESCRIPTION The Options settings FollowSymlinks and SymlinksIfOwnerMatch are ignored for files included using SSI when the files are symlinks and located in the same directory. Even when the FollowSymlinks and SymlinksIfOwnerMatch are NOT set, symlinks are still followed, and ownership is not checked. This means a user can set a symlink to any file on the system readable by the Apache user, even outside the DocumentRoot, and read it through HTTP, even if the administrator disabled this by not setting FollowSymlinks and SymlinksIfOwnerMatch. The bug is present in all current 2.2.x versions, so both in 2.2.9 (lenny) and 2.2.11 (sid). 2. HOW TO REPRODUCE Reproduce with: * server settings Options FollowSymlinks # usually the default VirtualHost testhost ServerName testhost.test.tld Directory /var/www/ Options Indexes IncludesNoExec # note no FollowSymlinks /VirtualHost * index.shtml file: Pre!--#include file=foo.txt--/PreP Pre!--#include file=root_link_to_foo.txt--PreP Pre!--#include file=user_link_to_foo.txt--Pre * data files / links: -rw-r--r-- 1 root root25 Sep 7 11:47 foo.txt lrwxrwxrwx 1 root root10 Sep 7 12:32 root_link_to_foo.txt - foo.txt lrwxrwxrwx 1 wwwwww 7 Sep 7 15:09 user_link_to_foo.txt - foo.txt (the last link is used to check if SymlinksIfOwnerMatch works) The index.shmtl files will now show the contents of 'foo.txt' three times, even though it should error out on the symlinks. 3. PATCH This issue has already been addressed by the Apache developers and the fix will be included in the next 2.2.x and 2.3.x releases. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=45959 The patch applies cleanly to 2.2.9 and works. It's here: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/server/request.c?r1=733754r2=733753pathrev=733754view=patch Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506707: grub-pc: regression: no longer able to specify both vga and serial console
Package: grub-pc Version: 1.96+20080724-12 Severity: normal I just upgraded one of our servers to grub-pc, to see what the new grub is going to be like. First of all, the kernel command line options were migrated wrong (it only copied the first option and ignored the rest). But that's not the subject of this bugreport. All of our servers have a serial console connection so that we can manage them remotely. Our supermicro servers also have a bios that supports serial connections. However sometimes you need to boot a machine while standing next to it, with a screen and keyboard connected. For that we always used the following grub setting in menu.lst: # Set serial to ttyS0,9600 and use both serial and vga console. serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1 terminal serial console It appear that with the new setup using /etc/default/grub there is no way to specify terminal serial AND terminal console. It's one of them, but not both. I think that for many servers like ours this is a serious regression of functionality. I hacked around it by putting the serial config in /etc/grub.d/02_somefile , but it would be nice if this could be fixed properly. I'd like to be able to use: GRUB_SERIAL_COMMAND=serial --unit=0 --speed=9600 GRUB_TERMINAL=serial console Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505851: liblockfile1: Lockfiles get stale after 10 seconds instead of 5 minutes
Woah, that's bad. I'll fix it asap Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499786: lib32gcc1: missing GCC_4.* symbols
Package: lib32gcc1 Version: 1:4.3.1-9 Tags: lenny Severity: grave lib32gcc1 is lenny does not have the GCC_4.* symbols included, so it's impossible to run any 32 bits binaries that depend on these symbols. A simple C hello world program works for some reason, but as soon as you link with some libraries - say /emul/ia32-linux/usr/lib/libstdc++.so.6 - it fails. This also means it's not possible to compile (at least c++) binaries in 32 bit mode that can also run on amd64. A simple hello.c compile: $ g++ -m32 hello.c $ ./a.out ./a.out: /emul/ia32-linux/lib/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /emul/ia32-linux/usr/lib/libstdc++.so.6) Trying to work around this with -static-libgcc breaks just as bad (perhaps this is a seperate bug): $ g++ -m32 -static-libgcc hello.c /usr/lib/gcc/x86_64-linux-gnu/4.3.1/32/libstdc++.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status Something is very wrong :( The 'raidutils' package needs to compile a 32 bit binary on amd64 because it needs to call 32 bit ioctl()s (there are no working 64 bit equivalents in the kernel) and it can't compile right now under lenny because of this (I'm going to suggest that the binaries are compiled with '-static', perhaps that works). Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498822: raidutils-0.6.6-8 doesn't work on lenny amd64 after all :(
So, the binary from unstable doesn't appear to work on a standard
lenny (I just installed one from scratch in a container
just for this purpose):
# raidutil
raidutil: /emul/ia32-linux/lib/libgcc_s.so.1: version `GCC_4.2.0' not found
(required by /emul/ia32-linux/usr/lib/libstdc++.so.6)
This is caused by bug #499786. I'm not sure if that will be fixed
soon, so I've created a work-around.
The first thing I noticed when building raidutils-0.6.6-8 under lenny:
# apt-get install debhelper autoconf linux-kernel-headers libc6-dev-i386
g++-multilib
Package linux-kernel-headers is a virtual package provided by:
linux-libc-dev 2.6.26-5
You should explicitly select one to install.
E: Package linux-kernel-headers has no installation candidate
If I fix that by installing linux-libc-dev manually, I can start
to compile which fails with:
$ debian/rules build
dh_testdir
[...]
checking whether the C++ compiler works... configure: error: cannot run C++
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make: *** [config.status] Error 1
And that's because of bug # 499786 .
This can be worked around by adding -static/-all-static to LDFLAGS
(see patch, -all-static is a libtool thing) for the amd64
case in debian/rules.
Suggested patch attached. I'm a little fuzzy on the policy here,
I'm not sure if in this case you should upload to unstable,
testing-proposed-updates, or both. Perhaps
[EMAIL PROTECTED] can be of assistence.
Mike.
diff -ruN raidutils-0.0.6.b4/debian/changelog raidutils-0.0.6/debian/changelog
--- raidutils-0.0.6.b4/debian/changelog 2008-09-22 13:09:04.0 +0200
+++ raidutils-0.0.6/debian/changelog 2008-09-22 13:27:37.0 +0200
@@ -1,3 +1,11 @@
+raidutils (0.0.6-9) unstable; urgency=high
+
+ * Compile with -static because lib32gcc1 is broken (see bug #499786)
+ * Build-depend on linux-libc-dev instead of linux-kernel-headers
+ * This should also go into testing (lenny)
+
+ -- Patch Submitter [EMAIL PROTECTED] Mon, 22 Sep 2008 12:12:50 +0200
+
raidutils (0.0.6-8) unstable; urgency=low
* Include amd64 plus all 32-bit (4-byte pointer) architectures listed in
diff -ruN raidutils-0.0.6.b4/debian/control raidutils-0.0.6/debian/control
--- raidutils-0.0.6.b4/debian/control 2008-09-22 13:09:04.0 +0200
+++ raidutils-0.0.6/debian/control 2008-09-22 12:13:27.0 +0200
@@ -2,7 +2,7 @@
Section: admin
Priority: optional
Maintainer: Barak A. Pearlmutter [EMAIL PROTECTED]
-Build-Depends: debhelper (= 7), autoconf (= 2.58), linux-kernel-headers, libc6-dev-i386 [amd64], g++-multilib [amd64]
+Build-Depends: debhelper (= 7), autoconf (= 2.58), linux-libc-dev, libc6-dev-i386 [amd64], g++-multilib [amd64]
Standards-Version: 3.8.0
Homepage: http://i2o.shadowconnect.com
diff -ruN raidutils-0.0.6.b4/debian/rules raidutils-0.0.6/debian/rules
--- raidutils-0.0.6.b4/debian/rules 2008-09-22 13:09:04.0 +0200
+++ raidutils-0.0.6/debian/rules 2008-09-22 13:01:04.0 +0200
@@ -20,6 +20,8 @@
ifeq (amd64,$(DEB_BUILD_ARCH))
CFLAGS += -m32
CXXFLAGS += -m32
+CONF_LDFLAGS += -static
+BUILD_LDFLAGS += -all-static
endif
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -34,7 +36,8 @@
config.status: configure
dh_testdir
- CFLAGS=$(CFLAGS) CXXFLAGS=$(CXXFLAGS) ./configure \
+ CFLAGS=$(CFLAGS) CXXFLAGS=$(CXXFLAGS) LDFLAGS=$(CONF_LDFLAGS) \
+ ./configure \
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) \
--prefix=/usr --mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info
@@ -43,7 +46,7 @@
build-stamp: config.status
dh_testdir
- $(MAKE)
+ $(MAKE) LDFLAGS=$(BUILD_LDFLAGS)
touch build-stamp
clean:
Bug#498822: raidutils-0.6.6-8 doesn't work on lenny amd64 after all :(
close 498822 thanks On Mon, 2008-09-22 at 13:30 +0200, Miquel van Smoorenburg wrote: So, the binary from unstable doesn't appear to work on a standard lenny (I just installed one from scratch in a container just for this purpose): That was a mistake. I used a 'standard' base lenny image which happened to have old files laying around in it, /emul/ia32-linux/lib/libgcc_s.so.1 should not have been in there :(( raidutils-0.6.6-8 does indeed work fine now I fixed this. Another day wasted. Oh well. :] Perhaps this part is still valid: The first thing I noticed when building raidutils-0.6.6-8 under lenny: # apt-get install debhelper autoconf linux-kernel-headers libc6-dev-i386 g++-multilib Package linux-kernel-headers is a virtual package provided by: linux-libc-dev 2.6.26-5 You should explicitly select one to install. E: Package linux-kernel-headers has no installation candidate If I fix that by installing linux-libc-dev manually, I can start to compile But I'm closing this bug anyway. Apologies for the inconvenience. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499786: lib32gcc1: missing GCC_4.* symbols
close 499786 thanks On Mon, 2008-09-22 at 14:41 +0200, Aurelien Jarno wrote: lib32gcc1 is lenny does not have the GCC_4.* symbols included, so it's impossible to run any 32 bits binaries that depend on these symbols. $ ./a.out ./a.out: /emul/ia32-linux/lib/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /emul/ia32-linux/usr/lib/libstdc++.so.6) /emul/ia32-linux/lib/libgcc_s.so.1 does not come from a Debian package, so the problem is likely to be a problem on your setup. Thanks for the unbelievably quick reply, I'm impressed ! I must apologize - I spent half a day on this, and now it turns out that the test-image I used to install a lenny openvz container contained files that should not be there :( I'm closing this bug, and then I'm getting some coffee and some fresh air. Thanks again, Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498822: raidutils: doesn't work on 64 bit archs (lenny, fixed in unstable)
Package: raidutils Version: 0.0.6-6 Severity: important Tags: lenny [ please forward this to [EMAIL PROTECTED] ] The raidutils package builds on most or all current debian architectures, but it doesn't work on any 64 bit arch. This was reported earlier in bug #477105, which has been closed because this has been fixed in 0.0.6-7. The version in unstable is 0.0.6-8. Changelog: raidutils (0.0.6-8) unstable; urgency=low * Include amd64 plus all 32-bit (4-byte pointer) architectures listed in http://wiki.debian.org/ArchitectureSpecificsMemo in debian/control architecture field (closes: #495828) -- Barak A. Pearlmutter [EMAIL PROTECTED] Wed, 20 Aug 2008 20:46:54 +0100 raidutils (0.0.6-7) unstable; urgency=low * do not ignore clean error in debian/rules (lintian) * target only on 32-bit architectures, and those 64-bit architectures that admit to a GCC -m32 flag (presently only amd64), because the involved ioctl() is 32-bit even on 64-bit systems (closes: #477105) * rev deb pol, rev to dh 7 -- Barak A. Pearlmutter [EMAIL PROTECTED] Wed, 20 Aug 2008 14:20:19 +0100 Since this is a fix for a severity important bug in a package of priority optional, and the fixed package is available in unstable, please include 0.0.6-8 in lenny. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477105: raidutils: doesn't work on 64 bit archs
On Thu, 2008-05-01 at 08:16 +0100, Barak A. Pearlmutter wrote: Do you happen to know if the same -m32 switch can be used on all 64-bit architectures: not just AMD64 but also ALPHA, SPARC, etc.? Hmm no, I wouldn't know, really. Does Alpha have a 32 bit mode anyway ? I know sparc does. Let's see .. what 64 bit archs do we have: ** ALPHA Linux escher 2.6.18-6-alpha-smp #1 SMP Mon Feb 11 10:15:54 UTC 2008 alpha [EMAIL PROTECTED]:~$ vi hello.c [EMAIL PROTECTED]:~$ cc -Wall -o hello64 hello.c [EMAIL PROTECTED]:~$ cc -Wall -m32 -o hello32 hello.c cc1: error: unrecognized command line option -m32 ** HPPA Can't test it, no public developer machine available. ** SPARC Can't test it, no public developer machine available. However this appears to be a 32 bit distribution with extra 64 bit support. I think packages are built in 32 bit mode by default ? ** IA64 [EMAIL PROTECTED]:~$ cc -Wall -o hello64 hello.c [EMAIL PROTECTED]:~$ cc -Wall -m32 -o hello32 hello.c cc1: error: unrecognized command line option -m32 ** AMD64 We know this works. As far as I can check, only amd64 has support for compiling and running 32-bit programs on a 64-bit platform. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477105: raidutils: doesn't work on 64 bit archs
On Mon, 2008-04-21 at 01:22 +0100, Barak A. Pearlmutter wrote: Thanks for the patch. I will dupload it shortly. In addition, the patch makes sure that the raidutils package is built for just i386 and amd64 - it supports only the Adaptec DPT ZCR controllers, which can only be found on x86 boards as far as I know. I'd imagine the Adaptec PCI cards would work on any system with a PCI bus. Well, I was thinking about the ZCR cards which are the Zero Channel Raid cards. It means that the motherboard has an Adaptec SCSI controller on board, and there is an extra slot in which you can put the 2000/2005/2010/2015 ZCR controller. These boards are typically x86 boards. There might exist stand-alone PCI cards that you can put into any system with a PCI bus, you're right about that. Didn't think of that. There is some SPARC-specific stuff in the sources, which I assume is because that configuration actually exists. Good point. Perhaps it would make more sense to just disallow some specific non-amd64 64-bit architectures. You seem to know more about this i2o 64-bit cleanliness issue than me: what do you think? I think I was just being short-sighted by assuming all the dpt_i2o cards are of the ZCR variety and that only x86 boards use them. That doesn't have to be true as you pointed out, so if dpt_raidutils builds on all architectures I do not see a reason not to support that. Oh, the i2o 64-bit cleanliness, how do I know about that.. well, I've tried to fix the raidutils code before to actually work in 64-bit mode, and it would be a lot, really a LOT of work. It assumes pointers == long == 32 bits everywhere. Not only that, but the ioctl interface in the kernel also assumes that, so you'd have to put all data buffers for the ioctls in memory 4G (mmap(MAP_32BIT) ?). I've used the 32 bit package on 64 bit systems for a while now, and recently I found out that it finally is possible to compile 32-bit C++ code in a 64 bit environment .. hence this bugreport. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465090: liblockfile: should this package be orphaned?
reopen 465090 thanks On Sat, 2008-04-05 at 12:05 +1000, Aníbal Monsalve Salazar wrote: On Sun, Feb 10, 2008 at 05:43:52PM +0100, Luk Claes wrote: While reviewing some packages, your package came up as a package that should maybe be orphaned by its maintainer, because: * many bugs without comment from the maintainer * no recent upload from the maintainer (last upload in 2004) On 6 Jan 2007, asked Miguel about the maintainership of this package and the response was an automatic mail message. This is in my procmail logfile: From [EMAIL PROTECTED] Sat Jan 06 12:50:54 2007 Subject: maintainership of the debian package liblockfile Folder: /var/mail/miquels/new/1168084254.22235_2.ds141 3387 I have no idea as to why a) you received a bounce or b) why I didn't see that message. I'm not dead, honestly. I'll upload a new package soon. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477105: raidutils: doesn't work on 64 bit archs
Package: raidutils
Version: 0.0.6
Severity: important
Tags: patch
The raidutils package builds on most or all current debian
architectures, but it doesn't work on any 64 bit arch.
This is because the ioctl() interface of the i2o layer in the
kernel isn't 64 bit clean. Neither is the code in raidutils.
Fortunately though, the kernel 32 bit compatibility
layer does work. So, if you run a 32-bit i2o management app
on a 64-bit kernel, it works just fine.
The patch below builds the raidutils on amd64 in 32-bit mode,
so that it actually works. It does give some build warnings
which probably should be looked at - but it works.
In addition, the patch makes sure that the raidutils package
is built for just i386 and amd64 - it supports only the Adaptec
DPT ZCR controllers, which can only be found on x86 boards
as far as I know.
I'm not sure if the severity of this report should be important
or grave. In my case, not having a working management app means
not being able to monitor the raid status, which could result
in data loss, so 'grave' might be appropriate. I've left it
as 'important' for now.
#
diff -ruN t/raidutils-0.0.6/debian/control raidutils-0.0.6/debian/control
--- t/raidutils-0.0.6/debian/control2008-04-21 00:56:34.0 +0200
+++ raidutils-0.0.6/debian/control 2008-04-21 01:20:58.0 +0200
@@ -2,12 +2,12 @@
Section: admin
Priority: optional
Maintainer: Barak A. Pearlmutter [EMAIL PROTECTED]
-Build-Depends: debhelper (= 5), autoconf (= 2.58), linux-kernel-headers
+Build-Depends: debhelper (= 5), autoconf (= 2.58), linux-kernel-headers,
libc6-dev-i386 [amd64], g++-multilib [amd64]
Standards-Version: 3.7.3
Homepage: http://i2o.shadowconnect.com
Package: dpt-i2o-raidutils
-Architecture: any
+Architecture: i386, amd64
Conflicts: raidutils ( 0.0.6-6)
Depends: ${shlibs:Depends}, ${misc:Depends}
Provides: dtp-i2o-raidutils
@@ -21,7 +21,7 @@
array, activate/silence the alarm, and query array/disk status.
Package: raidutils
-Architecture: any
+Architecture: i386, amd64
Depends: dpt-i2o-raidutils
Description: Transition Package for raidutils rename to dpt-i2o-raidutils
The package previously named raidutils, used for manipulating some
diff -ruN t/raidutils-0.0.6/debian/rules raidutils-0.0.6/debian/rules
--- t/raidutils-0.0.6/debian/rules 2008-04-21 00:56:34.0 +0200
+++ raidutils-0.0.6/debian/rules2008-04-21 01:24:07.0 +0200
@@ -11,9 +11,16 @@
# from having to guess our platform (since we know it already)
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
+DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
CFLAGS = -Wall -g
+CXXFLAGS = -Wall -g
+
+# When building on amd64, build 32 bit binaries.
+ifeq (amd64,$(DEB_BUILD_ARCH))
+CFLAGS += -m32
+CXXFLAGS += -m32
+endif
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
@@ -27,7 +34,7 @@
config.status: configure
dh_testdir
# Add here commands to configure the package.
- CFLAGS=$(CFLAGS) ./configure --host=$(DEB_HOST_GNU_TYPE)
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info
+ CFLAGS=$(CFLAGS) CXXFLAGS=$(CXXFLAGS) ./configure
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
build: build-stamp
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397933: xen-tools: don't run disable-tls on amd64
Package: xen-tools
Version: 2.7-1
Severity: normal
If you run a 64 bit xen dom0/domU, the disable-tls script should not be run.
The TLS issue doesn't exist on a 64 bit kernel, not even on 32 bit
userland (--arch i386). Disabling TLS cripples libpthread.
The script already errors for 64 bit installs:
case ${dist} in
etch|sid)
logMessage Installing xen-aware libc6
installDebianPackage ${prefix} libc6-xen
;;
On 64 bit platforms, libc6-xen doesn't exist.
# pwd
/usr/lib/xen-tools
# ls -ld */*-disable-tls
-rwxr-xr-x 1 root root 504 2006-11-07 23:36 centos4.d/10-disable-tls*
-rwxr-xr-x 1 root root 832 2006-11-07 23:36 debian.d/10-disable-tls*
-rwxr-xr-x 1 root root 832 2006-11-07 23:36 etch.d/10-disable-tls*
-rwxr-xr-x 1 root root 504 2006-11-07 23:36 fedora.d/10-disable-tls*
-rwxr-xr-x 1 root root 649 2006-11-07 23:36 gentoo.d/10-disable-tls*
-rwxr-xr-x 1 root root 832 2006-11-07 23:36 sarge.d/10-disable-tls*
-rwxr-xr-x 1 root root 832 2006-11-07 23:36 sid.d/10-disable-tls*
-rwxr-xr-x 1 root root 504 2006-11-07 23:36 stentz.d/10-disable-tls*
Suggestion: exclude /usr/lib/xen-tools/*/*-disable-tls from the
xen-tools package on 64 bit platforms.
Mike.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397797: no serial console support in xen kernel
Package: linux-image-2.6.18-2-xen-amd64 Version: 2.6.18-4 Severity: important The xen kernel package doesn't have serial console support, while the non-xen version does. This is because in the xen version the 8250 serial driver is built as a module ... Xen will probably be used in datacenters a lot, where serial console support is usually very important, so please fix this, thanks :) # grep 8250 /boot/config-2.6.18-2-xen-amd64 CONFIG_SERIAL_8250=m CONFIG_SERIAL_8250_PCI=m CONFIG_SERIAL_8250_PNP=m CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set CONFIG_SERIAL_8250_RSA=y # grep 8250 /boot/config-2.6.18-2-amd64 CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set CONFIG_SERIAL_8250_RSA=y Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396477: network-bridge script exits prematurely
Package: xen-utils-common
Version: 3.0+hg11624-2
Severity: normal
I'm running etch with xen 3.0.3 with a hand-compiled 2.6.18.1
kernel. The /etc/xen/scripts/network-bridge fails to run,
because it (effectively) does this:
set -e
modprobe netloop /dev/null 21
As I do not have a netloop module (where is it supposed to come
from ? The 2.6.18.1 xen-patched kernel doesn't have the string
netloop in there anywhere) the script exits right there.
The following patch fixes it:
--- network-bridge.ORIG 2006-10-08 19:04:48.0 +0200
+++ network-bridge 2006-11-01 00:13:36.0 +0100
@@ -59,7 +59,7 @@
findCommand $@
evalVariables $@
-modprobe netloop /dev/null 21
+modprobe netloop /dev/null 21 || true
vifnum=${vifnum:-$(ip route list | awk '/^default / { print $NF }' | sed
's/^[^0-9]*//')}
vifnum=${vifnum:-0}
Mike.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328582: /etc/init.d/umountfs: swapoff should be called before unmounting localfs and not after?
On Fri, 2005-09-16 at 13:47 +0200, Marcel Sebek wrote: On Fri, Sep 16, 2005 at 10:55:37AM +0200, johannes wrote: hi all, i'm using a swapfile in a file on a local filesystem /data/swapfile (not a swap partition!) during shutdown /etc/init.d/umountfs first tries to unmount all local filesystems and then deactivates all swap but unmounting of the partitition wich has the swapfile /data fails because the swapfile is still active if i change /etc/init.d/umountfs in such a way that it first calls swapoff and then unmounts the local filesystems it works correctly It already does that, in the (misnamed) umountnfs.sh script which runs before umountfs read it. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323233: initscripts: extra procfs filesystem (e.g. /chroots/sid/proc) not umounted
On Mon, 2005-08-15 at 18:57 +0300, Timo Juhani Lindfors wrote: Package: initscripts Version: 2.86.ds1-1 Severity: normal /etc/init.d/umountfs does not seem to umount procfs at all. This is normally not a problem since /proc can be left mounted. However, in my setup I have multiple proc filesystems mounted for chroots: FILE: /etc/dchroot.conf sid /chroots/sid FILE: /etc/fstab /dev/hdb1 /chroots ext2 defaults auto 0 2 proc /chroots/sid/proc proc defaults auto 0 0 When I shutdown the machine /chroots/sid/proc is not umounted and keeps /chroots busy so it can't be umounted either. This causes long fsck on every bootup for /dev/hdb1. Procfs *is* unmounted, in the increasingly badly named /etc/init.d/umountnfs.sh . Perhaps you made local changes and umountnfs.sh wasn't upgraded ? It should say @(#)umountnfs 2.85-23 29-Jul-2004 at the top of the file. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322219: acknowledged by developer (Re: Bug#322219: sysv-rc: package install requires /usr/sbin/update-rc.d, which is part of this package)
On Fri, 2005-08-12 at 20:41 +0200, Raphael Wegmann wrote: Debian Bug Tracking System sagte: This is an automatic notification regarding your Bug report #322219: sysv-rc: package install requires /usr/sbin/update-rc.d, which is part of this package, which was filed against the sysv-rc package. It has been closed by one of the developers, namely Thomas Hood [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact the developer, by replying to this email. [...] Thanks for the report. Migrating from Knoppix to Debian is not supported. I do not think that Debian can be expected to take into account what happens when people try to migrate from other distributions. -- Thomas Hood Hello. I can accept, that you don't support distribution migrations, but I still think, that it's a bug for a package to require a program (namely update-rc.d) which is included in the package itself. The only possiblilty to solve this chicken- egg problem is to use --force options. No. Sysv-rc is an essential package (actually virtually essential), and installed when you're installing debian for the first time. You cannot remove it, or sysvinit, or any other essential packages. That is unsupported. Not a bug. Also, sysv-rc does not depend on its own update-rc.d. It _does_ link /usr/sbin/update-rc.d to a dummy version from the sysvinit package on package removal, which is needed for a brief moment to keep dpkg happy when you replace sysv-rc with file-rc (or another equivalent package). I think your problem was that you removed sysvinit as well. When you're doing stuff like that, you're working around the packaging system, and you're on your own. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284426: Trivial, annoying warning at boot time
On Thu, 2005-08-11 at 02:44 +0200, Javier Fernández-Sanguino Peña wrote: On Wed, Aug 10, 2005 at 06:37:30PM +0200, Miquel van Smoorenburg wrote: Actually, perhaps sysvinit should be a project on alioth with more than one developer doing the work. Sysvinit and related packages are more than just packaging. Sure, but, in the meantime, are you open to me uploading the attached NMU? It's just a cleanup of many of the bugs in the BTS which do not introduce fundamental changes to the initscripts. The only behaviour changes are introduced in #289562 and #85221. The rest bugfixes are either needed changes to the code (#284426) or documentation improvements. Are you OK with this NMU? If so, I will submit it to the DELAYED queue (just in case you regret saying 'go ahead'). I had a look at the diff, and it looks fine to me. Please go ahead! Mike.
Bug#322217: halt and bootmisc.sh is not in the initscripts package
On Tue, 2005-08-09 at 21:20 +0200, Raphael Wegmann wrote: Package: initscripts Version: 2.86.ds1-1 Severity: important When I remove /etc/init.d/halt and /etc/init.d/bootmisc.sh before I call apt-get --reinstall install initscripts, the files halt and bootmisc.sh do not get restored. Right. That is because they are marked as conffiles. So this is exactly what is supposed to happen. It's simply how dpkg works, nothing I can do about that. Closing bugreport. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284426: Trivial, annoying warning at boot time
On Mon, 2005-08-08 at 23:25 +0200, Thomas Hood wrote: Miquel van Smoorenburg wrote: And, if you do so, please also fix #314351, which can be trivially fixed. There are also some other trivial fixes: #289562, #311741, #281782, #269894, and #268713. If you could fix those too some people will really appreciate it. None of these look either important or annoying enough to merit NMUing. I'd rather wait until the maintainer wakes up and says something. I am alive, but right now I have almost no time for debian-related work. Miquel needs co-maintainers. I'd volunteer, but Debian hasn't seen fit to make me an official maintainer yet. Go ahead and NMU. Actually, perhaps sysvinit should be a project on alioth with more than one developer doing the work. Sysvinit and related packages are more than just packaging. Only thing is I know squat about alioth/sourceforge. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284426: Trivial, annoying warning at boot time
On Thu, 2005-07-14 at 20:16 +0100, Andrew Suffield wrote: On Thu, Jul 14, 2005 at 05:20:26PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: Andrew, can you please NMU initscripts and fix the obnoxious #284426 bug? (Note #281651 and #316431 are also duplicates, and I'm merging them) I'm pretty much planning on doing that if I don't hear anything from the maintainer before I get home from debconf (so, Monday). And, if you do so, please also fix #314351, which can be trivially fixed. There are also some other trivial fixes: #289562, #311741, #281782, #269894, and #268713. If you could fix those too some people will really appreciate it. None of these look either important or annoying enough to merit NMUing. I'd rather wait until the maintainer wakes up and says something. I am alive, but right now I have almost no time for debian-related work. If I had time, the first thing I would clean up is my house, and then the debian packages, but alas. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316615: initscripts: Deconfiguring network interfaces hangs while shutdown/reboot
reassign 316615 netbase thanks On Tue, 2005-07-05 at 11:21 +0200, Raoul Verveer wrote: 3) the if-else construction in the stop part of the script, regarding verbosity, doesn't seem to work (while the sh syntax looks ok to me btw). What script, exactly ? The /etc/init.d/networking script It is definitely also a problem in Debian. But you're right anyway: The /etc/init.d/networking script is not in initscripts, but in base/netbase. Oops, I'm sorry... OK reassigning the bug Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316615: initscripts: Deconfiguring network interfaces hangs while shutdown/reboot
On Sat, 02 Jul 2005 11:34:27, [EMAIL PROTECTED] wrote: Package: initscripts Version: 2.86-5ubuntu6 Severity: important Tags: patch While shutting down or rebooting, the system hangs om the /etc/init.d/networking script, while Deconfiguring network interfaces I'm running ubuntu myself, but after searching the web i found the same problem also resides on sarge. Never heard about it, AFAICR I found 3(!) problems causing it! In my case I had to fix all 3 of the problems before it finally worked. 1) An important cause of this is that the networking script is called after unmounting local filesystems, causing the /etc/network/ifstate file to be read-only if it's on the root partition. So in /etc/rc0.d and /etc/rc6.d the umountfs script should be S40umountfs (like in woody) instead of S34umountfs. This is probably an Ubuntu thing. Debian uses S40umountfs 2) The loopback interface should be excluded from shutting down (again: like in woody). Well, sysvinit or initscripts doesn't shut down the loopback interface. 3) the if-else construction in the stop part of the script, regarding verbosity, doesn't seem to work (while the sh syntax looks ok to me btw). What script, exactly ? I think you filed this bugreport to the wrong package. The problems all seem to be in Ubuntu versions of the package, or in the ifupdown package. Please reassign the bug. Mike.
Bug#314351: initscripts: bootclean.sh seems broken
On Thu, 2005-06-16 at 11:27 +0200, Michael Prokop wrote: Package: initscripts Version: 2.86.ds1-1 Followup-For: Bug #314351 JFYI: The problem seems to be related to one of the latest versions of findutils (here findutils 4.2.22-1). I know. You're about the 4th or 5th person to file a bug. I can not fix it anytime soon, I have no time between work vacation right now. Sorry. BTW: Shouldn't initscripts depend on findutils? No, findutils is an essential package. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311839: umountfs: give a shell if some fs are still rw
On Fri, 03 Jun 2005 19:20:48, Nicolas George wrote: Package: initscripts Version: 2.86.ds1-1 Severity: wishlist Sometimes, the unmounting or remounting read-only of some filesystems fails for some reason (is busy, for example), causing a fsck on the next boot. That should not happen, in fact cannot happen on an unmodified system. Or it would be a bug. In that case, one may wish to get a basic root shell to correct the problem. Suggested addition: at the end of umountfs, something like that: if [ x$ROOT_SHELL_IF_UMOUNT_FAILS = xyes ]; then if grep -qE '^/dev/(root|hd|sd|discs|ide|scsi)[^ ]* [^ ]*.*\rw\' /proc/mounts echo Some filesystems still mounted rw. Please fix and exit. sh fi fi I'm not going to implement this. It adds complexity for no gain. Mike.
Bug#311146: sysv-rc: Segmentation fault
On Sun, 2005-05-29 at 10:40 +0200, Christian Tremel wrote: Package: sysv-rc Version: 2.86.ds1-1 Severity: normal -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: sparc (sparc64) Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information Message at boot time: /etc/init.d/rcS: line58 148 Segmentation fault $i start - message repeats 3 times - boot continues but no network is configured - no network available, some dependend services failed - system unuseable! Temp workaround: boot process finished-login - #/etc/init.d/network restart -#init 1 - init 2 - restart failed services. Since sysv-rc is just a bunch of shell scripts, there's no way it can cause a segmentation violation. Something it is calling (a shell, or some utility from /bin or /usr/bin) is actually what is failing. Could be a local fs corruption problem. Or a sparc-specific problem. You need to find out what exactly is failing, and file a bug report against the appropriate package. There's nothing more I can say without seeing the entire bootlog (the lines before and after Segmentation fault). I'll close this report in a few days since it I don't think it has anything to do with sysv-rc. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310989: sysv-rc: update-rc.d doesn't work on services with dots in their names
On Fri, 2005-05-27 at 16:24 +0200, Jesús M. Navarro wrote: Package: sysv-rc Version: 2.86.ds1-1 Severity: normal I had to change priority level for mountall.sh, so I run the following command: mithrandir:~# update-rc.d -n mountall.sh start 46 S. update-rc.d: error: expected runlevel [0-9S] (did you forget . ?) Since update-rc.d uses a dot '.' to separate start and stop levels it parses badly the dot at mountall.sh. This behaviour should be corrected. Eh, no. You need to do update-rc.d -n mountall.sh start 46 S .. Note the space between the S and the .. Closing bugreport. Mike.
Bug#310064: initscripts: init S doesn't shut down X properly
On Sat, 2005-05-21 at 21:27 +0930, Arthur Marsh wrote: Package: initscripts Version: 2.86.ds1-1 Severity: important I previously have used init S from both an xterm and from a console login to enter single user mode then re-enter multi-user mode with X and networking, but presently init S from an xterm leaves X in an unusable state and init S from a console login doesn't shut down X properly and I get the message that xdm is already running when returning to multiuser mode only X is then unusable. That is completely correct. init s changes to the single-user mode runlevel but DOES NOT kill any user processes. You're supposed to go to runlevel 1 first. So use init 1 to go to single user mode, or even better, use the standard and more portable command shutdown now which effectively does an init 1 for you. Not a bug, closing. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301511: sysklogd: hangs the whole system
On Sat, 14 May 2005 08:22:56, GOTO Masanori wrote: I have not reappeared sysklogd breakage yet, but IMHO this problem is potentially existed - I agreed Miquel's proposal. Miquel, did you confirm this problem using sysklogd? If this patch fixes this bug, I think we should do NMU for sarge. Yes, the reason I filed this bug was not theoretical - the servers I run regularly hung completely because lots of processes on the box blocked (cron calls syslog() ), and the process table got full. No way to login, not even on the serial console (login calls syslog() too!), no way to recover .. Mike.
Bug#134473: [Pkg-shadow-devel] Bug#134473: Is someone able to understand what is requested in #134473?
On Mon, 16 May 2005 23:35:40, Martin Quinson wrote: On Mon, May 16, 2005 at 06:29:50PM +0200, Christian Perrier wrote: I must confess that I have absolutely no idea of what the bug submitter is requesting in http://bugs.debian.org/134473 Has anyone a rough idea? A new option to the low level tools allowing to specify on which files to work on. Rational: on nis server, you don't want to allow the user of your company to log onto your nis server, you want them to be added in the DB managed by the nis server. You don't want to modify /etc/passwd but /var/yp/ypfiles/etc/passwd. At least, that's what I understand from this mail, I've no personal opinion, beside the relative simplicity of the corresponding patch. I'm CCing debian NIS packager (hello Miquel) to see what he think about it. [For the context, shadow packaging just changed into a team effort, and we're doing massive bug triage] Well actually nowadays Mark Brown does most (the last few releases, all) of the work on NIS. But it's probably not a bad idea to make the tools more flexible. It sure beats vi :) Mike.
Bug#301511: sysklogd: hangs the whole system
Christian Hammers wrote: For what it's worth, I also tried Miguel's ctime-hang.c on both a Sarge i386 and a Sid amd64 machine with 2.6 kernels and can reproduce the hang in 10 of 10 attempts. I also re-ran the ctime-hang.c test program on i386 uniprocessor and SMP, and amd64 SMP (all up-to-date sarge and 2.6 kernel) and ctime-hang.c locked every time right away. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305787: not installable: ia32-libs: Depends: lsb-release but it is not installable
Then you will have to find out why the lsb-release package is not installable, which is not the case for the copies of this package present in the Debian archive proper. This seems to be an amd64-specific problem with lsb-release. It's because of: Package: lsb-release Architecture: alpha arm hppa ia64 i386 m68k mips mipsel powerpc s390 sh sparc Description: LSB release command lsb-release maintainer, please add amd64 to the arcitecture list, or if you don't want to do this re-assign this bug back to ia32-libs so that ia32-libs can be fixed not to depends on lsb-release but use some other command to find out if it is running on Debian (is this to differentiate between Debian and Ubuntu or something?) Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305856: ia32-libs: please add /lib/libgcc_s.so.1
Package: ia32-libs Version: 1.2 Could you please add libgcc_s.so.1 to the ia32-libs package ? I just found out that the raidutils package doesn't work in 64 bit mode but the 32 bits version does and is installable with --force-architecture - however it needs libgcc_s.so.1 (BTW I'm running sarge) Thanks Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305856: ia32-libs: please add /lib/libgcc_s.so.1
Never mind, I found libgcc_s.so.1 in lib32gcc1. I'm not sure why that's a seperate package for just one lib, perhaps that's something that can be fixed. In the mean time I am closing the bug. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#258290: sysvinit: cannot find console device 136:0 in /dev
On Fri, 2005-04-15 at 15:09 +0200, Rolf Leggewie wrote: Package: sysvinit Version: 2.86.ds1-1 Followup-For: Bug #258290 Miquel, I also experience this bug. From http://lists.debian.org/debian-user/2005/03/msg03785.html I understand you are not placing too high a priority on following up on these bugs. My computer runs sarge and does not have udev, I still get the error cannot find console device 136:0 in /dev upon trying to start bootlog. You say these bugs are hard to troubleshoot since people often do not respond back to questions. What is the device 136:0? If I knew that I'd send you more meaningful output. Let me know any questions you may have. That's /dev/pts/0, but that error message doesn't make much sense. I'm not going to fix bootlogd, though. That would be patching a bad design. We need a completely different approach. Bootlogd, in it's current form, needs to go away (and will go away). Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303265: sysvinit: Last does not display IPv6 addresses correctly
On Thu, 2005-04-07 at 11:44 +0100, Jason Cormie wrote: Miquel van Smoorenburg wrote: last handles IPv6 in utmp/wtmp correctly as far as I know, but I also know that ssh did not in previous versions at least. Not sure what current versions do. So I guess last just shows you what actually is logged in /var/log/wtmp, and if it's junk, it's junk ... I may have been jumping to conclusions. I think the culprit is sessreg being called by gdm when someone logs in here is some output last c511094 mc3273.uad.a mc3273.uad.ac.uk Thu Apr 7 09:18 - 09:19 (00:01) last -i c511094 mc3273.uad.a 112.191.21.64Thu Apr 7 09:18 - 09:19 (00:01) (the ip should be 193.60.161.86) Have looked at wtmp and yes you are right the false ip is in there. OK, closing this bug. Feel free to re-open it and reassign it to gdm or sessreg. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303247: sysv-rc: update-rc.d does not add links to /etc/rcS.d
On Sat, 09 Apr 2005 18:36:36, Michael Gebetsroither wrote: * Miquel van Smoorenburg [EMAIL PROTECTED] [050406 15:30]: Perhaps your shell or something in your environment does this. Maybe zsh auto-completion or whatever ? Perhaps that messes up the call to update-rc.d ? You are right the shell messed it up, sorry. OK. I'm curious as to what setting caused the shell to do this, however. Meanwhile I'm closing this bug. Mike.
Bug#303247: sysv-rc: update-rc.d does not add links to /etc/rcS.d
On Wed, 2005-04-06 at 11:16 +0200, Michael Gebetsroither wrote:
* Thomas Hood [EMAIL PROTECTED] [050405 21:45]:
$ sudo touch /etc/init.d/dummy
$ sudo chmod ugo+x /etc/init.d/dummy
[EMAIL PROTECTED]:/etc/init.d$ sudo update-rc.d -n dummy start 37 S .
Adding system startup for /etc/init.d/dummy ...
/etc/rcS.d/S37dummy - ../init.d/dummy
[EMAIL PROTECTED] ~ # touch /etc/init.d/dummy
[EMAIL PROTECTED] ~ # chmod ugo+x /etc/init.d/dummy
[EMAIL PROTECTED] ~ # update-rc.d -n dummy start 37 S .
sort: read failed: .: Is a directory
I don't understand where that sort: read failed: .: Is a directory
comes from. It's definitely not a message from update-rc.d.
Perhaps your shell or something in your environment does this. Maybe zsh
auto-completion or whatever ? Perhaps that messes up the call to
update-rc.d ?
added the -w switch to the perl skript update-rc.d
What you could do is to add this temporarily to the top of that script:
print CALLED WITH ARGS: , join(':', @ARGV), \n;
.. and see what it prints. If it is something else than
-n:dummy:start:37:S:. then something is mucking with the command line
options to update-rc.d before it is even called.
Mike.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
