Bug#435983: mount: fails to detect LABEL=foo filesystems
On 8/9/07, Touko Korpela [EMAIL PROTECTED] wrote: On Thu, Aug 09, 2007 at 09:48:45AM +0100, James Youngman wrote: On 8/7/07, Touko Korpela [EMAIL PROTECTED] wrote: Please tell udev version installed. And please show mdadm version and configuration. # dpkg -l udev mdadm Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii mdadm 2.6.2-2tool to administer Linux MD arrays (software ii udev 0.114-2/dev/ and hotplug management daemon orbital:~# cat /etc/mdadm/mdadm.conf DEVICE partitions ARRAY /dev/md1 level=raid1 num-devices=2 UUID=0e6624e4:a9cd6984:f20ceecf:919b57cd ARRAY /dev/md0 level=raid1 num-devices=2 UUID=fcd276e7:ea94c8d0:0d41aa71:22d0670d spares=1 ARRAY /dev/md2 level=raid1 num-devices=2 UUID=ca5a9e9b:b1d43782:c9b96cb6:728e3dae ARRAY /dev/md3 level=raid1 num-devices=2 UUID=54b26978:997db266:f00a6e1e:efeca1cb MAILADDR root orbital:~# cat /proc/mdstat Personalities : [raid1] md3 : active raid1 sdb3[0] sda3[1] 116312640 blocks [2/2] [UU] md2 : active raid1 sdb2[0] sda2[1] 122070208 blocks [2/2] [UU] md0 : active(auto-read-only) raid1 hda3[0] hde3[1] 995904 blocks [2/2] [UU] md1 : active raid1 hda6[0] sdb1[2](S) hde6[1] 250003392 blocks [2/2] [UU] unused devices: none -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435983: mount: fails to detect LABEL=foo filesystems
On 8/7/07, Touko Korpela [EMAIL PROTECTED] wrote: Please tell udev version installed. ~$ dpkg -l udev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii udev 0.114-2/dev/ and hotplug management daemon $ debconf-show udev debconf: DbDriver passwords warning: could not open /var/cache/debconf/passwords.dat: Permission denied udev/new_kernel_needed: false udev/reboot_needed: $ dpkg --status udev Package: udev Status: install ok installed Priority: important Section: admin Installed-Size: 940 Maintainer: Marco d'Itri [EMAIL PROTECTED] Architecture: i386 Version: 0.114-2 Replaces: initramfs-tools (= 0.41) Depends: libc6 (= 2.6-1), libselinux1 (= 2.0.15), libvolume-id0 (= 0.113), debconf (= 0.5) | debconf-2.0, lsb-base (= 3.0-6) Pre-Depends: debconf (= 1.4.69) | debconf-2.0 Conflicts: hotplug, initscripts ( 2.85-16), lvm-common ( 1.5.13), module-init-tools ( 3.2.2-1), initramfs-tools ( 0.39), hal ( 0.5.6-2), makedev ( 2.3.1-80), klibc-utils (= 1.4.19-1), multipath-tools ( 0.4.7-2) Conffiles: /etc/modprobe.d/pnp-hotplug 57e7aba8b91e5a19028a0303065a1901 /etc/modprobe.d/display_class 34eba9ad8e27d458fc5efbaa3a88f2a5 /etc/modprobe.d/blacklist c8770183ed0c9f92b7a7d7fba17a82df /etc/init.d/udev 55c8d6f187f340aba0f4b85425f48f02 /etc/init.d/udev-mtab 82a581c2e19b357c35c83124dd0caaa3 /etc/udev/udev.conf 3f1d43d19e4e26fc4f87bbaa542ff12a /etc/udev/run.rules a5625f4c4c541beb546206ee0e5e277f /etc/udev/links.conf 50f175cab5d8c503598a157b6e485e1b /etc/udev/compat-full.rules 659b834be979c31d82f9acdf93ea9a66 /etc/udev/persistent-input.rules cc058acc1f41fa6b42aad44879c0ff81 /etc/udev/persistent.rules a165cf8371ee03c9ceb79a79f62b6997 /etc/udev/cd-aliases-generator.rules 3a3dbd5c53c4f1483584f9b4a1a94e11 /etc/udev/udev.rules ae413acf9642c9b537ca7cd4bee0bd71 /etc/udev/devfs.rules 7e073717976a9e23dc802ec14a6be823 /etc/udev/hotplug.rules 9adb481d6122dc08527f630a9d2ec753 /etc/udev/permissions.rules b3cbbeac6047decccda7acec7d2c64ed /etc/udev/persistent-net-generator.rules b629bc89c46df58da0d75858081bb74b /etc/udev/compat.rules 465b423d2d5b52ee2be30e16dfbe4cfb /etc/scsi_id.config 90c176456f98d5f9407cc8a7540ae1d8 Description: /dev/ and hotplug management daemon udev is a daemon which dynamically creates and removes device nodes from /dev/, handles hotplug events and loads drivers at boot time. It replaces the hotplug package and requires a 2.6.15 or newer kernel version. You are using 2.6.18-4-xen-686 kernel from etch? Is xen in use? Aha. Until you mentioned this, I had not recalled that the 2.6.15 kernel I was running was in fact a self-built kernel. I normally don't boot the Xen kernel, I normally use the 2.6.15 kernel, but I had not remembered that that's also a custom kernel. $ dpkg -l linux-image-2.6.15 linux-xen0-2.6.18-4-xen-686 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii linux-image-2.6.15 jy.1.0 Linux kernel binary image for version 2.6.15 ii linux-xen0-2.6.18-4-xe Custom.1 Linux xen kernel binary image for version 2.6.18-4-xen-686 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435983: mount: fails to detect LABEL=foo filesystems
On 8/8/07, Marco d'Itri [EMAIL PROTECTED] wrote: On Aug 04, James Youngman [EMAIL PROTECTED] wrote: LABEL=foo entries can no longer be mounted; I love generalizations... So, whatever populates /dev/disk/by-label is not aware of (LVM2 MD), This is the real problem. The mdadm maintainer needs to integrate in his package support for persistent device names (i.e. install the appropriate rules file). Really? But the missing entries in /dev/disk/by-label are the LVM logical volumes, not the MD devices.I don't directly mount any of the MD devices. James. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435983: mount: fails to detect LABEL=foo filesystems
On 8/9/07, Marco d'Itri [EMAIL PROTECTED] wrote: Really. But if your problems are caused by LVM devices then you should talk with the LVM maintainers too. OK. But FWIW I would have appreciated some advance warning that the configuration I was using [*] was deprecated and support would be withdrawn soon, before the support was actually withdrawn. [*] The configuration I'm using which is not supported is having filesystems mounted via LABEL= in /etc/fstab where the corresponding entry does not exist in /dev/disk/by-label/. Thanks, James. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435983: mount: fails to detect LABEL=foo filesystems
On 8/5/07, LaMont Jones [EMAIL PROTECTED] wrote: On Sat, Aug 04, 2007 at 02:43:04PM +0100, James Youngman wrote: Everything worked fine 'til I upgraded... So, whatever populates /dev/disk/by-label is not aware of (LVM2 MD), and since mount no longer itself supports LABEL= directly, mount fails to mopunt perfectly good filesystems. This makes the system unusable. The latest mdadm package seems to provide hooks for vol_id to populate /dev/disk/*. I expect that the latest LVM does as well.. In any case, it would appear to be a bug in udev or lvm for not populating the table that libvolume-id is using. Does the lvm2 package in sid fix the issue? I upgraded to that just now in order to answer your question. It does not fix the issue. ii lvm2 2.02.26-1+b1 The Linux Logical Volume Manager FWIW, fsck still works fine in this configuration; the filesystems can be checked but not mounted. IMO, if we're going to withdraw a feature that people are depending on in order to boot (and I have been depending on it for the past four years), we should really provide people with a warning and some time window in which to change their configuration. James. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435983: mount: fails to detect LABEL=foo filesystems
Package: mount Version: 2.13~rc2-5 Severity: critical Justification: breaks the whole system Everything worked fine 'til I upgraded... LABEL=foo entries can no longer be mounted; this causes the system to be wholly unusable if (say) /usr is mounted via a labelled filesystem. I've been using LABEL=foo on Debian systems since about 2003, and this is the first time I've had a problem with doing it. My fstab file looks like this:- # /etc/fstab: static file system information. LABEL=usr-src /usr/srcext3defaults0 6 LABEL=backups /backupsext3defaults,ro 0 9 LABEL=/export /export ext3defaults,ro 0 10 If I try to mout a filesystem, I get this result:- # mount /usr/src mount: special device /dev/disk/by-label/usr-src does not exist There are entries in /dev/disk/by-label for devices on /def/hda[0-9], but most of my filesystems are on LVM2 volumes (and the physical volumes are either RAID0 or RAID1 volumed managed by MD). So, whatever populates /dev/disk/by-label is not aware of (LVM2 MD), and since mount no longer itself supports LABEL= directly, mount fails to mopunt perfectly good filesystems. This makes the system unusable. Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription ii lvm2 2.02.06-4 The Linux Logical Volume Manager -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-xen-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages mount depends on: ii libc62.6-5 GNU C Library: Shared libraries ii libselinux1 2.0.15-2+b1 SELinux shared libraries ii libvolume-id00.113-3 libvolume_id shared library Versions of packages mount recommends: ii nfs-common1:1.1.0-13 NFS support files common to client -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432948: patch for debian bug 432948
The script /etc/init.d/mdadm-raid uses set -u. That means that an
error occurs if we refer to a variable which is unset. Unfortunately
mdadm-raid calls log-daemon-msg with no value for $2. The end result
is that /etc/init.d/mdadm-raid stop will fail.
/lib/lsb/init-functions does not suffer from this problem because it
uses the shell construct ${foo:-} to supply a default value for the
shell variable foo when referring to it. In this example the default
value is the empty string, which suits us just fine.
Applying this patch allows /etc/init.d/mdadm-raid to complete
successfully.
--- lsb-base-logging.sh 2007/07/20 08:38:56 1.1
+++ lsb-base-logging.sh 2007/07/20 08:43:13
@@ -52,7 +52,7 @@
# HACK! If usplash is running when GDM/KDM starts the terminal
# gets crazy. Enforce usplash ends before running GDM/KDM. (yes,
# start kills it)
-if [ $2 = gdm ] || [ $2 = kdm ]; then
+if [ ${2:-} = gdm ] || [ ${2:-} = kdm ]; then
DO_NOT_SWITCH_VT=yes /etc/init.d/usplash start
fi
@@ -107,7 +107,7 @@
fi
fi
-if [ $COL ] [ -x $TPUT ]; then
+if [ ${COL:-} ] [ -x ${TPUT:-} ]; then
printf \r
$TPUT hpa $COL
if [ $1 -eq 0 ]; then
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428794: Me too
This just bit me, too. It looks like we have multiple options to fix this, has one been selected? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Update of bug #14619 (project findutils): Open/Closed:Open = Closed Fixed Release:None = 4.2.27 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Update of bug #14619 (project findutils): Status:None = Fixed Assigned to:None = jay ___ Follow-up Comment #15: I have applied an edited form of this patch to the current development code (since I already had some changes in the developement code and I went a bit fiurther in trying to be clear). ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #13, bug #14619 (project findutils): Andreas, did you intend both patch files to be applied, or just one of them? (I also must figure out where the upstream perm.texi file comes from) ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #6, bug #14619 (project findutils): I've moved the other issue that Eroc discovered to bug #14748. Andreas, do you have any further thoughts on this? If you still believe it's a bug I'll refer to the POSIX documentation and try to figure out a way forward. However, if in any case you're also happy that this is not a software bug, do you have any thoughts on how we can improve the documentation to explain things better? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
On Fri, Oct 07, 2005 at 08:19:45AM -0600, Eric Blake wrote: The man page no longer documents the obsolete -perm +mode, which, as I stated earlier, really only makes sense for symbolic modes starting with 'a', or for numeric modes. The man page is wrong in stating that you must specify 'u', 'g', or 'o' in symbolic mode. Noted, thanks. Also, it is unfortunate that there is no syntax for specifying files with a permission bit explicitly off, besides an exact match. That's what \! -perm is for... It might be nice if there were some sort of permission masking syntax - something like - -perm /pattern/mask. For example, -perm /u+r-x/u+rx would explicitly select files that the user can read but not execute (examining both bits of the mask to see if the file meets the pattern within that mask), while ignoring the u+w,go+rwx bits. You're really asking for the functionality of access() not -perm. It's very hard to simulate access via -perm, because you would need to make these checks: 1. If user is the owner of the file, a) succeed if -perm -400 \! -perm -100 b) otherwise fail 2. If the user is a member of the group which owns the file, a) succeed if -perm -040 \! -perm -010 b) otherwise fail 3. Otherwise, a) succeed if -perm -004 \! -perm -001 b) otherwise fail I did try coding an example answer but when I realised that I was using a second level of nested $(...) and was only implementing (2), I gave up because I wouldn't have the time to test it. In any case, the above fails to take into account ACLs or other special properties of the filesystem. Are you really seeking an -access primitive with which one might write -access read -a \! -access execute ? Regards, James. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #2, bug #14619 (project findutils): Does -perm /... do what you expected -perm +... to do? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313081: [bug #13381] infinite loop with -follow.
Update of bug #13381 (project findutils): Severity: 3 - Normal = 6 - Security Status:None = Fixed Assigned to:None = jay ___ Follow-up Comment #1: NB: THIS BUG IS A SECURITY HOLE (denial of updatedb service by users, possibly denial of service to security checks based on find). Please note the list of affected versions of findutils. The problem was introduced because safely_chdir() in find.c now sometimes avoids needing to stat the destination directory, and so stat_buf was left unpopulated. This problem is fixed by the attached patch, which has been committed into the development code. The scope of the security problem extends only to the indefinite loop, the problem does not result in users being able to persuade find to process parts of the filesystem that should be excluded. Having said this, this bug only occurs if the -L option was used, which normally should not be the case with any security checks - because they should not follow symbolic links, in general. The next release of findutils will include this fix. The NEWS file will outline the severity of the problem. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13381 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313081: [bug #13381] infinite loop with -follow.
Update of bug #13381 (project findutils): Open/Closed:Open = Closed Release:None = 4.2.19 Fixed Release:None = 4.2.22 ___ Follow-up Comment #2: You can download a release of findutils in which this problem is fixed from ftp://alpha.gnu.org/gnu/findutils. The releases on alpha.gnu.org are for testing purposes, so please take the time to download the release and verify that your problem has been solved. Once the release has been sufficiently tested, it can be uploaded to ftp.gnu.org for everybody to use it. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13381 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293666: Duplicate bug report
Bug 293725 appears to be a duplicate of 293666 (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293666) which is of severity 'Grave'. James. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
