Bug#487758: /sbin/blkid: blkid shows not anymore connected devices, even after reboot
Package: e2fsprogs Version: 1.40.11-1 Severity: critical File: /sbin/blkid Justification: causes serious data loss Normally my root device is /dev/sda6. When I connect an ext. sata before next boot my root device becomes /dev/sdb6 and the ext. sata is sda, because the external is connected to sata port 1 on the mainboard and the system disk is connected to sata port 4 on the mainboard. But not today: sda is obvious the external disk and sdb the internal, but mount tells me that sda6 is my root device. gparted tells me that there is no sda6, because my external disk doesn't contain a 6th partition blkid tells me that there is a sda6 and a sdb6 with the same uuid (there should only be sdb6) What could it be related to? Where is that salad from? grub2 (as kernel parameter I give root=UUID=uuid) in my fstab I use UUID=uuid for mounting the root partition These settings woked all the time fine. After a reboot and disconnecting the external sata blkid still shows the partitions of the external disk as if they is still connected, but it's not. I detected this problem today in the morning. I think one of the updates in the last 3 weeks or my switch to grub2 is responsible for that. I know that this bug could be related to some other programs, but I did not know, where to put it elsewhere and blkid showed me something wrong. I think this bug is important, because I and some other admins I know rely on blkid and the device names and given information (in this case the 'unique' UUID) for mounting, deleting, rsyncing or other things, done in scripts (possibly in a cron job), which in this case can cause serious data loss. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages e2fsprogs depends on: ii e2fslibs 1.40.11-1 ext2 filesystem libraries ii libblkid1 1.40.11-1 block device id library ii libc6 2.7-12 GNU C Library: Shared libraries ii libcomerr21.40.11-1 common error description library ii libss21.40.11-1 command-line interface parsing lib ii libuuid1 1.40.11-1 universally unique id library e2fsprogs recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#487758: /sbin/blkid: blkid shows not anymore connected devices, even after reboot
Processing commands for [EMAIL PROTECTED]: severity 487758 normal Bug#487758: /sbin/blkid: blkid shows not anymore connected devices, even after reboot Severity set to `normal' from `critical' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487758: /sbin/blkid: blkid shows not anymore connected devices, even after reboot
severity 487758 normal thanks On Tue, Jun 24, 2008 at 12:10:35AM +0200, Holger Fischer wrote: Package: e2fsprogs Version: 1.40.11-1 Severity: critical File: /sbin/blkid Justification: causes serious data loss Normally my root device is /dev/sda6. When I connect an ext. sata before next boot my root device becomes /dev/sdb6 and the ext. sata is sda, because the external is connected to sata port 1 on the mainboard and the system disk is connected to sata port 4 on the mainboard. But not today: sda is obvious the external disk and sdb the internal, but mount tells me that sda6 is my root device. gparted tells me that there is no sda6, because my external disk doesn't contain a 6th partition Mount sometimes lies; if /etc/mtab has the wrong information, it's going report the wrong information. blkid tells me that there is a sda6 and a sdb6 with the same uuid (there should only be sdb6) What could it be related to? Where is that salad from? blkid deliberately doesn't delete cached information for non-existent devices. Since /dev/sda6 doesn't exist, it didn't remove it from the blkid cache. If /dev/sda6 existed as a device, it would tried to validate it, and removed the cache entry if the validation failed. In the case where a device is missing, this is not a problem. In the case where device names are bouncing around, it can mean that that the when you lookup a device by LABEL or UUID, you will get multiple names, and when using the lookup, you can get the wrong (i.e., stale) device name. This will cause a mount to fail, but it won't necessarily lead to serious data loss, unless the script is seriously fragile (i.e., not checking error returns, etc.,). By your usage, it *could* possibly lead to serious data loss if a script depends on the program in some bad/wierd way, any bug could be classified as critical. Blkid isn't itself causing serious data loss, so it's not critical. It is a bug in that we should return a validated device in preference to the non-validated device, and I'll work to fix it quickly. But I don't consider this a RC bug. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
