Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
Hi, unfortunately the build of coreutils 8.20-1 has not made it to i386 and other architectures. Also Wheezy is affected by this issue. Any chance that this get fixed in Wheezy as well? Thanks Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
Control: tags -1 + fixed-upstream Control: severity -1 important It seems that this was worked-around upstream in http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1e18d8416f9ef43bf08982cabe54220587061a08. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
reassign 653073 coreutils found 653073 6.10-6 thanks On Thu, Nov 08, 2012 at 12:30:48PM -0500, Samuel Bronson wrote: Control: tags -1 + fixed-upstream Control: severity -1 important It seems that this was worked-around upstream in http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1e18d8416f9ef43bf08982cabe54220587061a08. Thanks. Reassigning to coreutils, since this isn't a sysvinit issue. Setting version back to oldstable, since this is present in all releases to date. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
Package: initscripts Version: 2.88dsf-22 Followup-For: Bug #653073 This happen even if there no uuid mount in fstat : $ LC_ALL=C df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 19228308 15989032 2262524 88% / udev 1795456 0 1795456 0% /dev tmpfs 360312344 359968 1% /run /dev/disk/by-uuid/5f80d55a-8b6a-42c1-a9ab-0979e1a875f8 19228308 15989032 2262524 88% / tmpfs5120 0 5120 0% /run/lock tmpfs 720620132 720488 1% /run/shm /dev/sdc4 $ cat /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/sdc2 / ext3defaults,errors=remount-ro 0 1 [...] -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages initscripts depends on: ii coreutils 8.13-3 ii debianutils 4.2.1 ii libc6 2.13-26 ii lsb-base3.2-28.1 ii mount 2.20.1-1.2 ii sysv-rc 2.88dsf-22 ii sysvinit-utils 2.88dsf-22 ii ucf 3.0025+nmu2 Versions of packages initscripts recommends: ii e2fsprogs 1.42-1 ii psmisc 22.15-2 initscripts suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
In addition to this, df also reports bind mounts where Filesystem is the device of the bind mount source and the Mounted on is the bind mount destination. Is this intended? It sure is very impractical on my system with many bind mounts and it doesn't say where the bind mount originates from really. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
Since this bug was making my life miserable, I patched df to fix its
output. The attached patch hides rootfs type mount points, and
canonicalizes device paths when displaying them.
Result:
Filesystem Size Used Avail Use% Mounted on
udev495M 0 495M 0% /dev
tmpfs 100M 696K 100M 1% /run
/dev/sda129G 27G 1.4G 96% /
tmpfs 200M 340K 200M 1% /run/shm
The rootfs part of the patch is about as good a fix as I think we're going
to get. There's nothing wrong with the device path canonicalization
(it will handle correctly all cases including remote devices, special devices,
deleted or inaccessible device files, even relative devices), but
df is not the best place to put it; fixing klibc would be better.
--
see shy jo
diff -ur old/coreutils-8.13/lib/mountlist.c coreutils-8.13/lib/mountlist.c
--- old/coreutils-8.13/lib/mountlist.c 2011-04-24 13:21:45.0 -0400
+++ coreutils-8.13/lib/mountlist.c 2012-01-04 14:30:08.178037951 -0400
@@ -154,6 +154,7 @@
(strcmp (Fs_type, autofs) == 0\
|| strcmp (Fs_type, none) == 0 \
|| strcmp (Fs_type, proc) == 0 \
+ || strcmp (Fs_type, rootfs) == 0 \
|| strcmp (Fs_type, subfs) == 0 \
/* for NetBSD 3.0 */ \
|| strcmp (Fs_type, kernfs) == 0 \
diff -ur old/coreutils-8.13/src/df.c coreutils-8.13/src/df.c
--- old/coreutils-8.13/src/df.c 2011-07-28 06:38:27.0 -0400
+++ coreutils-8.13/src/df.c 2012-01-04 14:45:08.393554354 -0400
@@ -447,7 +447,7 @@
uintmax_t used;
bool negate_used;
double pct = -1;
- char* cell;
+ char* cell = NULL;
size_t field;
if (me_remote show_local_fs)
@@ -486,8 +486,6 @@
alloc_table_row ();
- if (! disk)
-disk = -; /* unknown */
if (! fstype)
fstype = -; /* unknown */
@@ -537,7 +535,16 @@
switch (field)
{
case DEV_FIELD:
- cell = xstrdup (disk);
+ if (! disk) {
+ cell = xstrdup (-); /* unknown */
+ }
+ else if (! me_remote disk[0] == '/') {
+ /* Avoid long disk paths like /dev/disk/by-uuid/UUID by
+ * canonicalizing if possible. */
+cell = canonicalize_file_name (disk);
+ }
+ if (! cell)
+cell = xstrdup (disk);
break;
case TYPE_FIELD:
signature.asc
Description: Digital signature
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
The df output has two distinct problems, which will have separate solutions. Regarding the duplicate rootfs entry, I had thought (from d-i) that it was possible to use pivot_root and then umount the initrd afterwards. However, hpa tells me that the rootfs is the cwd for kernel threads so cannot be unmounted. It might also be used as the hardcoded head of the linked list of active mounts, if they haven't found a better data structure yet in the kernel.. :P So this seems to be a limitation of linux, and short of going back to a /etc/mtab file, df needs to be fixed to either paper over the problem with a special case exclude of the rootfs, or take one of the general purpose approaches for hiding non-available filesystems that have been discussed. Or violate the least surprise of every user who looks at df and sees two root filesystems, but I personally don't think that is a good option. Regarding the ugly uuid display, a recent release of coreutils actually made this worse. It used to wrap long device paths: tmpfs 200M 340K 200M 1% /run/shm /dev/disk/by-uuid/6a7e9145-b76d-4bcf-a243-67c65891549a 29G 27G 2.0G 93% / But that's not really a fix, and was removed due to it breaking naive scripts that did not use df -P. The proper fix is to make klibc-utils's mount (and perhaps also busybox's), do the same path canonicalization that /bin/mount does. That canonicalization is why mounting by uuid does not normally cause the problem: joey@gnu:~sudo mount /dev/disk/by-uuid/e55f93bc-53ce-4111-af1e-8feb07759362 /mnt joey@gnu:~df /mnt Filesystem Size Used Avail Use% Mounted on /dev/sdb1 917G 737G 181G 81% /mnt joey@gnu:~sudo umount /mnt joey@gnu:~sudo mount --no-canonicalize /dev/disk/by-uuid/e55f93bc-53ce-4111-af1e-8feb07759362 /mnt joey@gnu:~df /mnt Filesystem Size Used Avail Use% Mounted on /dev/disk/by-uuid/e55f93bc-53ce-4111-af1e-8feb07759362 917G 737G 181G 81% /mnt If klibc-utils somehow cannot be fixed, the only other option would be to make df try to canonicalize paths, but that would be problimatic to get right (imagine running df in a chroot without /dev etc). Also, it would not fix anything else that displays mounted devices, such as perhaps GUI programs. -- see shy jo signature.asc Description: Digital signature
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
RL - initramfs mount command line RL - initramfs busymox mount binary RL - initramfs /dev [but should be udev] Does your fstab have any UUID in it? We were told that's what we should use. Does your df(1) or mount(1) output also have none, some, or all of them? Is there a way to get back the readable sda stuff without ripping the UUID stuff out of fstab? Is the UUID stuff more readable than the short sda strings? I have no idea what is causing it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
On Sat, Dec 24, 2011 at 10:21:26PM +0800, jida...@jidanni.org wrote: RL - initramfs mount command line RL - initramfs busymox mount binary RL - initramfs /dev [but should be udev] Does your fstab have any UUID in it? No. I use LVM. We were told that's what we should use. This is correct advice. Does your df(1) or mount(1) output also have none, some, or all of them? None, due to using LVM. Is there a way to get back the readable sda stuff without ripping the UUID stuff out of fstab? Is the UUID stuff more readable than the short sda strings? I have no idea what is causing it. This is why I asked you to investigate the origin in my previous message. It's likely it originates from the rootfs being mounted in the initramfs. If you are using an initramfs. It's possible that it could be corrected by tweaking the script run in the initramfs. But I really can't speculate here; it's something you would need to investigate for yourself. I mentioned potential culprits in my previous message. If you mount using root= on the kernel command-line, rather than an initramfs, it may also be the case that the UUID is the only thing available to the kernel in early boot, and this is preserved. Readability of the strings is not really related here. UUIDs are used for unambiguity when referring to a specific partition, given that on modern systems device names are not guaranteed to be stable. While it would be preferable for readability to use shorter strings, this is not strictly a bug--it's obviously correct, just not in the most readable format. I would suggest that you add 'break=bottom' to your kernel command-line, and check in the initramfs whether the root device UUID exists, and if so if it is a symlink to the short-form device name. I would then mount the rootfs onto e.g. /mnt and check /proc/mounts to compare mounting the short and long names. I would then do the same on a normally booted system to compare how mount behaves here. If it's doing something odd in the initramfs, maybe we can fix it to behave the same as on a real system. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
RL root= on the kernel command-line, rather than an initramfs, it may RL also be the case that the UUID is the only thing available to RL the kernel in early boot, and this is preserved. That must be the case. RL Readability of the strings is not really related here. UUIDs RL are used for unambiguity when referring to a specific partition, RL given that on modern systems device names are not guaranteed to RL be stable. While it would be preferable for readability to use RL shorter strings, this is not strictly a bug--it's obviously RL correct, just not in the most readable format. OK, I can get used to the new way, I just wish it was consistent. I.e., I wish $ mount, and $ df, would either use all the /proc/partitions names or all the UUID names or all the names they found in fstab, instead of treating root different. RL I would suggest that you add 'break=bottom' to your kernel RL command-line, and check in the initramfs whether the root RL device UUID exists, and if so if it is a symlink to the RL short-form device name. I would then mount the rootfs onto RL e.g. /mnt and check /proc/mounts to compare mounting the short RL and long names. I would then do the same on a normally booted RL system to compare how mount behaves here. If it's doing RL something odd in the initramfs, maybe we can fix it to behave RL the same as on a real system. Errr... too deep water for me, however I have some basic conclusions that I will post in a wider post... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
On Fri, Dec 23, 2011 at 11:46:18PM +0800, jida...@jidanni.org wrote: RL == Roger Leigh rle...@codelibre.net writes: RL I would suggest checking what is in /etc/mtab and /proc/mounts. RL /etc/mtab was changed to be a symlink to /proc/mounts. If you RL are mounting by UUID, then I think this is to be expected. Yes I see the same situation there too. But in all cases it only affects /, even though as you see I mount many filesystems by UUID. It only started acting this way today. This is presumably because the rootfs is mounted by the initramfs, while everything else is mounted by init scripts using regular mount(8). Note that the extra detail is in general an improvement--mtab previously excluded information such as some mount options. I would suggest identifying /why/ the rootfs was mounted recording the long UUID. Candidates are: - initramfs mount command line - initramfs busymox mount binary - initramfs /dev [but should be udev] Should be fairly simple to address. Note that this is not a bug in initscripts--it's simply reporting what's really there, rather than hiding the real situation as before. I would suggest reassigning to the appropriate package once this has been identified. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
X-debbugs-Cc: rle...@debian.org
Package: initscripts
Version: 2.88dsf-16
I have little idea of which package causes
$ { df; mount;}|grep disk
/dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287800
729240 29% /
/dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 on / type ext3
(rw,noatime,errors=remount-ro,commit=333,barrier=1,data=ordered)
to thus report the root file system, instead of its
$ ls -l /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78
lrwxrwxrwx 1 root root 11 12-23 22:00
/dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 - ../../sda11
short name.
$ grep UUID /etc/fstab
UUID=551e44e1-2cad-42cf-a716-f2e6caf9dc78 / ext3
defaults,commit=333,noatime,errors=remount-ro 0 1
UUID=355d426a-cbfc-4faf-91d6-4f9405199517 /home ext3
defaults,commit=333,noatime 0 2
UUID=34610b6a-70a3-48d9-b135-96907dc2ba16 /var ext3 defaults,commit=333,noatime
0 2
UUID=1d11e0e3-26d7-42be-89d2-00fbe939dc1c /usr ext3 defaults,commit=333,noatime
0 2
shows that the others are UUIDs in /etc/fstab but don't become ugly as
such when reported by mount or df.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
On Fri, Dec 23, 2011 at 10:23:27PM +0800, jida...@jidanni.org wrote:
X-debbugs-Cc: rle...@debian.org
Package: initscripts
Version: 2.88dsf-16
I have little idea of which package causes
$ { df; mount;}|grep disk
/dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287800
729240 29% /
short name.
$ grep UUID /etc/fstab
UUID=551e44e1-2cad-42cf-a716-f2e6caf9dc78 / ext3
defaults,commit=333,noatime,errors=remount-ro 0 1
I would suggest checking what is in /etc/mtab and /proc/mounts.
/etc/mtab was changed to be a symlink to /proc/mounts. If you
are mounting by UUID, then I think this is to be expected.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
23:43 ~$ cat /etc/mtab rootfs / rootfs rw 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=248048k,nr_inodes=62012,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=50564k,mode=755 0 0 /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 / ext3 rw,noatime,errors=remount-ro,commit=333,barrier=1,data=ordered 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=101128k 0 0 tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=101128k 0 0 /dev/sda6 /home ext3 rw,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0 /dev/sda7 /var ext3 rw,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0 /dev/sda8 /usr ext3 rw,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0 /dev/sda9 /var/cache/wwwoffle ext3 rw,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0 /dev/sda10 /music ext3 rw,nosuid,nodev,noexec,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0 /dev/sdg2 /mnt/usb/cf ext3 rw,noatime,errors=remount-ro,barrier=1,data=ordered 0 0 $ ll /etc/mtab lrwxrwxrwx 1 root root 12 12-23 22:00 /etc/mtab - /proc/mounts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?
RL == Roger Leigh rle...@codelibre.net writes: RL I would suggest checking what is in /etc/mtab and /proc/mounts. RL /etc/mtab was changed to be a symlink to /proc/mounts. If you RL are mounting by UUID, then I think this is to be expected. Yes I see the same situation there too. But in all cases it only affects /, even though as you see I mount many filesystems by UUID. It only started acting this way today. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
