As you know, each filesystem instance is unique, and we can use UUID which is generated by mkfs to identify the specified filesystem. Fstabe can use the UUID to mount the specified filesystem on the directory which is specified in the /etc/fstab.
udev will create following soft-link, once we mount the device(s) on directory successfully.
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
Thus Kdump maybe fail to the find UUID, once user specifies the device in kdump.conf.
In order to fix this issue, we can use blkid to point out the UUID.
Here is some content from blkid manpage. - Note that blkid reads information directly from devices and for non-root users it returns cached unverified information. - Avoid using the symlinks directly; it is not reliable to use the symlinks without verification.
[1] The structure of lvm volume. [root@localhost ~]# ls -al /dev/testvg/ total 0 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest03 -> ../dm-2
Signed-off-by: Minfei Huang mhuang@redhat.com --- mkdumprd | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/mkdumprd b/mkdumprd index 28ecdd7..4e69526 100644 --- a/mkdumprd +++ b/mkdumprd @@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() { - local i _tmp _dev + local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do + for i in /dev/mapper/* /dev/disk/by-id/*; do _tmp=$(udevadm info --query=name --name="$i" 2>/dev/null) if [ "$_tmp" = "$_dev" ]; then echo $i @@ -45,6 +45,18 @@ get_persistent_dev() { fi done
+ if [ "x" != "x""$(blkid $1 | grep "UUID")" ]; then + _uuid=`blkid $1 | grep "UUID" | awk '{print $2}'` + _uuid=${_uuid#*"} + _uuid=${_uuid%"*} + _dev=/dev/disk/by-uuid/$_uuid + _tmp=$(udevadm info --query=name --name=$_dev 2>/dev/null) + if [ "x" != "x"$_tmp ]; then + echo $_dev + return + fi + fi + perror "WARNING: Persistent device name of $1 not found. Using $1 as dump target name" echo $1 }
On 06/15/15 at 04:33pm, Minfei Huang wrote:
As you know, each filesystem instance is unique, and we can use UUID which is generated by mkfs to identify the specified filesystem. Fstabe can use the UUID to mount the specified filesystem on the directory which is specified in the /etc/fstab.
udev will create following soft-link, once we mount the device(s) on directory successfully.
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
Thus Kdump maybe fail to the find UUID, once user specifies the device in kdump.conf.
In order to fix this issue, we can use blkid to point out the UUID.
Here is some content from blkid manpage.
- Note that blkid reads information directly from devices and for
non-root users it returns cached unverified information.
- Avoid using the symlinks directly; it is not reliable to use the
symlinks without verification.
[1] The structure of lvm volume. [root@localhost ~]# ls -al /dev/testvg/ total 0 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest03 -> ../dm-2
Signed-off-by: Minfei Huang mhuang@redhat.com
mkdumprd | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/mkdumprd b/mkdumprd index 28ecdd7..4e69526 100644 --- a/mkdumprd +++ b/mkdumprd @@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() {
- local i _tmp _dev
local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do
- for i in /dev/mapper/* /dev/disk/by-id/*; do
Minfei, in your test case, why it did not fall into /dev/mapper/*?
_tmp=$(udevadm info --query=name --name="$i" 2>/dev/null) if [ "$_tmp" = "$_dev" ]; then echo $i@@ -45,6 +45,18 @@ get_persistent_dev() { fi done
- if [ "x" != "x""$(blkid $1 | grep "UUID")" ]; then
_uuid=`blkid $1 | grep "UUID" | awk '{print $2}'`_uuid=${_uuid#*\"}_uuid=${_uuid%\"*}_dev=/dev/disk/by-uuid/$_uuid_tmp=$(udevadm info --query=name --name=$_dev 2>/dev/null)if [ "x" != "x"$_tmp ]; thenecho $_devreturnfi- fi
- perror "WARNING: Persistent device name of $1 not found. Using $1 as dump target name" echo $1
}
2.1.0
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 06/18/15 at 10:06am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
...
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
@@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() {
- local i _tmp _dev
local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do
- for i in /dev/mapper/* /dev/disk/by-id/*; do
Minfei, in your test case, why it did not fall into /dev/mapper/*?
Hi, Dave.
For the above testcase, the btrfs contains three devices, /dev/dm-0, /dev/dm-1, /dev/dm-2. Kdump will fail to find the filesystem UUID, once we pass the /dev/dm-1 or /dev/dm-2 to the function get_persistent_dev, because the soft-link points to the /dev/dm-0.
Thanks Minfei
On 06/18/15 at 01:50pm, Minfei Huang wrote:
On 06/18/15 at 10:06am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
..
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
@@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() {
- local i _tmp _dev
local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do
- for i in /dev/mapper/* /dev/disk/by-id/*; do
Minfei, in your test case, why it did not fall into /dev/mapper/*?
Hi, Dave.
For the above testcase, the btrfs contains three devices, /dev/dm-0, /dev/dm-1, /dev/dm-2. Kdump will fail to find the filesystem UUID, once we pass the /dev/dm-1 or /dev/dm-2 to the function get_persistent_dev, because the soft-link points to the /dev/dm-0.
Is there any device mapper managed device name in directory /dev/mappper/?
On 06/18/15 at 02:54pm, Dave Young wrote:
On 06/18/15 at 01:50pm, Minfei Huang wrote:
On 06/18/15 at 10:06am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
..
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
@@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() {
- local i _tmp _dev
local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do
- for i in /dev/mapper/* /dev/disk/by-id/*; do
Minfei, in your test case, why it did not fall into /dev/mapper/*?
Hi, Dave.
For the above testcase, the btrfs contains three devices, /dev/dm-0, /dev/dm-1, /dev/dm-2. Kdump will fail to find the filesystem UUID, once we pass the /dev/dm-1 or /dev/dm-2 to the function get_persistent_dev, because the soft-link points to the /dev/dm-0.
Is there any device mapper managed device name in directory /dev/mappper/?
In my testcase, there is only three devices which are managed by device-mapper.
[root@localhost ~]# ls -al /dev/mapper/ total 0 drwxr-xr-x. 2 root root 120 Jun 18 15:07 . drwxr-xr-x. 21 root root 3360 Jun 18 15:07 .. crw-------. 1 root root 10, 236 Jun 18 14:01 control lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest03 -> ../dm-2 [root@localhost ~]# ls -al /dev/disk/by-uuid/ total 0 drwxr-xr-x. 2 root root 120 Jun 18 15:07 . drwxr-xr-x. 4 root root 80 Jun 18 14:01 .. lrwxrwxrwx. 1 root root 10 Jun 18 14:01 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 18 14:01 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 18 15:07 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-1 lrwxrwxrwx. 1 root root 10 Jun 18 14:01 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 [root@localhost ~]# btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
On 06/18/15 at 03:11pm, Minfei Huang wrote:
On 06/18/15 at 02:54pm, Dave Young wrote:
On 06/18/15 at 01:50pm, Minfei Huang wrote:
On 06/18/15 at 10:06am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
..
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
@@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() {
- local i _tmp _dev
local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do
- for i in /dev/mapper/* /dev/disk/by-id/*; do
Minfei, in your test case, why it did not fall into /dev/mapper/*?
Hi, Dave.
For the above testcase, the btrfs contains three devices, /dev/dm-0, /dev/dm-1, /dev/dm-2. Kdump will fail to find the filesystem UUID, once we pass the /dev/dm-1 or /dev/dm-2 to the function get_persistent_dev, because the soft-link points to the /dev/dm-0.
Is there any device mapper managed device name in directory /dev/mappper/?
In my testcase, there is only three devices which are managed by device-mapper.
[root@localhost ~]# ls -al /dev/mapper/ total 0 drwxr-xr-x. 2 root root 120 Jun 18 15:07 . drwxr-xr-x. 21 root root 3360 Jun 18 15:07 .. crw-------. 1 root root 10, 236 Jun 18 14:01 control lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest03 -> ../dm-2
So what is the device in /proc/mounts, only one device like /dev/dm-0?
If this is the case, how does one mount the device manually, just use one of them is ok? If it is right then we have no problem in our code?
Do we need bring up the 3 dm devices in 2nd kernel?
Thanks Dave
On 06/19/15 at 10:17am, Dave Young wrote:
On 06/18/15 at 03:11pm, Minfei Huang wrote:
On 06/18/15 at 02:54pm, Dave Young wrote:
On 06/18/15 at 01:50pm, Minfei Huang wrote:
On 06/18/15 at 10:06am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
..
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
@@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() {
- local i _tmp _dev
local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do
- for i in /dev/mapper/* /dev/disk/by-id/*; do
Minfei, in your test case, why it did not fall into /dev/mapper/*?
Hi, Dave.
For the above testcase, the btrfs contains three devices, /dev/dm-0, /dev/dm-1, /dev/dm-2. Kdump will fail to find the filesystem UUID, once we pass the /dev/dm-1 or /dev/dm-2 to the function get_persistent_dev, because the soft-link points to the /dev/dm-0.
Is there any device mapper managed device name in directory /dev/mappper/?
In my testcase, there is only three devices which are managed by device-mapper.
[root@localhost ~]# ls -al /dev/mapper/ total 0 drwxr-xr-x. 2 root root 120 Jun 18 15:07 . drwxr-xr-x. 21 root root 3360 Jun 18 15:07 .. crw-------. 1 root root 10, 236 Jun 18 14:01 control lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest03 -> ../dm-2
So what is the device in /proc/mounts, only one device like /dev/dm-0?
From my testing, I find that the device which show in /proc/mounts is
always the smallest device name. For example:
If there is three device to be integrated a filesystem, like /dev/vdb, /dev/vdc, /dev/vdd, /dev/vdb is always showed in /proc/mounts or df list. But I do not have enough testcases to confirm it.
But the device is random in /dev/disk/by-uuid/*, if there is testcase like above. Maybe the UUID points to /dev/vdb for this time, but it changes after rebooting.
If this is the case, how does one mount the device manually, just use one of them is ok? If it is right then we have no problem in our code?
Yes, we can use any one in the device set to mount the filesystem. like below.
mount -t btrfs /dev/vdc /mnt/btrfs/
But the device showed in /proc/mounts is /dev/vdb.
Do we need bring up the 3 dm devices in 2nd kernel?
I think so, but I do not test this case via network, since the kernel will bring up all of the local device.
IMO, we shall fix the issue one by one. Since there is no user to complain such sort of issue, we can make kdump handle the local devices firstly.
Thanks Minfei
On 06/19/15 at 10:50am, Minfei Huang wrote:
On 06/19/15 at 10:17am, Dave Young wrote:
On 06/18/15 at 03:11pm, Minfei Huang wrote:
On 06/18/15 at 02:54pm, Dave Young wrote:
On 06/18/15 at 01:50pm, Minfei Huang wrote:
On 06/18/15 at 10:06am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
..
> > $ ls -l /dev/disk/by-uuid/ > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 > > In gereral, we can use device name to find the filesystem UUID in > /dev/disk. But it fails, if a filesystem is integrated by seveal > devices, like btrfs. Following is the structure of btrfs. > > $ btrfs filesystem show /mnt/btrfs > Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 > Total devices 3 FS bytes used 240.00KiB > devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 > devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 > devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03 > > When we list the content of /dev/disk/by-uuid, we can find > /dev/dm-0[1] points to the corresponding UUID. > > $ ls -al /dev/disk/by-uuid/ > total 0 > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 > lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0 > > @@ -30,14 +30,14 @@ perror() { > } > > get_persistent_dev() { > - local i _tmp _dev > + local i _tmp _dev _uuid > > _dev=$(udevadm info --query=name --name="$1" 2>/dev/null) > [ -z "$_dev" ] && { > perror_exit "Kernel dev name of $1 is not found." > } > > - for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do > + for i in /dev/mapper/* /dev/disk/by-id/*; do
Minfei, in your test case, why it did not fall into /dev/mapper/*?
Hi, Dave.
For the above testcase, the btrfs contains three devices, /dev/dm-0, /dev/dm-1, /dev/dm-2. Kdump will fail to find the filesystem UUID, once we pass the /dev/dm-1 or /dev/dm-2 to the function get_persistent_dev, because the soft-link points to the /dev/dm-0.
Is there any device mapper managed device name in directory /dev/mappper/?
In my testcase, there is only three devices which are managed by device-mapper.
[root@localhost ~]# ls -al /dev/mapper/ total 0 drwxr-xr-x. 2 root root 120 Jun 18 15:07 . drwxr-xr-x. 21 root root 3360 Jun 18 15:07 .. crw-------. 1 root root 10, 236 Jun 18 14:01 control lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest03 -> ../dm-2
So what is the device in /proc/mounts, only one device like /dev/dm-0?
From my testing, I find that the device which show in /proc/mounts is always the smallest device name. For example:
If there is three device to be integrated a filesystem, like /dev/vdb, /dev/vdc, /dev/vdd, /dev/vdb is always showed in /proc/mounts or df list. But I do not have enough testcases to confirm it.
But the device is random in /dev/disk/by-uuid/*, if there is testcase like above. Maybe the UUID points to /dev/vdb for this time, but it changes after rebooting.
If this is the case, how does one mount the device manually, just use one of them is ok? If it is right then we have no problem in our code?
Yes, we can use any one in the device set to mount the filesystem. like below.
mount -t btrfs /dev/vdc /mnt/btrfs/
But the device showed in /proc/mounts is /dev/vdb.
Do we need bring up the 3 dm devices in 2nd kernel?
I think so, but I do not test this case via network, since the kernel will bring up all of the local device.
Why kdump fails during your test? Kdump kernel only bring up /dev/dm-0? /dev/dm-1 and /dev/dm-2 are missing in your test?
If they are all brought up in kdump kernel then what is the problem?
BTW, I think you should focus on one issue, maybe investigating on ipv6 first, these two issues can conflict in code...
Thanks Dave
On 06/19/15 at 10:57am, Dave Young wrote:
On 06/19/15 at 10:50am, Minfei Huang wrote:
On 06/19/15 at 10:17am, Dave Young wrote:
On 06/18/15 at 03:11pm, Minfei Huang wrote:
On 06/18/15 at 02:54pm, Dave Young wrote:
On 06/18/15 at 01:50pm, Minfei Huang wrote:
On 06/18/15 at 10:06am, Dave Young wrote: > On 06/15/15 at 04:33pm, Minfei Huang wrote: > > $ ls -l /dev/disk/by-uuid/ > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 > > > > In gereral, we can use device name to find the filesystem UUID in > > /dev/disk. But it fails, if a filesystem is integrated by seveal > > devices, like btrfs. Following is the structure of btrfs. > > > > $ btrfs filesystem show /mnt/btrfs > > Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 > > Total devices 3 FS bytes used 240.00KiB > > devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 > > devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 > > devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03 > > > > When we list the content of /dev/disk/by-uuid, we can find > > /dev/dm-0[1] points to the corresponding UUID. > > > > $ ls -al /dev/disk/by-uuid/ > > total 0 > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 > > lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 > > lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0 > > > > @@ -30,14 +30,14 @@ perror() { > > } > > > > get_persistent_dev() { > > - local i _tmp _dev > > + local i _tmp _dev _uuid > > > > _dev=$(udevadm info --query=name --name="$1" 2>/dev/null) > > [ -z "$_dev" ] && { > > perror_exit "Kernel dev name of $1 is not found." > > } > > > > - for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do > > + for i in /dev/mapper/* /dev/disk/by-id/*; do > > Minfei, in your test case, why it did not fall into /dev/mapper/*?
Hi, Dave.
For the above testcase, the btrfs contains three devices, /dev/dm-0, /dev/dm-1, /dev/dm-2. Kdump will fail to find the filesystem UUID, once we pass the /dev/dm-1 or /dev/dm-2 to the function get_persistent_dev, because the soft-link points to the /dev/dm-0.
Is there any device mapper managed device name in directory /dev/mappper/?
In my testcase, there is only three devices which are managed by device-mapper.
[root@localhost ~]# ls -al /dev/mapper/ total 0 drwxr-xr-x. 2 root root 120 Jun 18 15:07 . drwxr-xr-x. 21 root root 3360 Jun 18 15:07 .. crw-------. 1 root root 10, 236 Jun 18 14:01 control lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 18 15:07 testvg-lvtest03 -> ../dm-2
So what is the device in /proc/mounts, only one device like /dev/dm-0?
From my testing, I find that the device which show in /proc/mounts is always the smallest device name. For example:
If there is three device to be integrated a filesystem, like /dev/vdb, /dev/vdc, /dev/vdd, /dev/vdb is always showed in /proc/mounts or df list. But I do not have enough testcases to confirm it.
But the device is random in /dev/disk/by-uuid/*, if there is testcase like above. Maybe the UUID points to /dev/vdb for this time, but it changes after rebooting.
If this is the case, how does one mount the device manually, just use one of them is ok? If it is right then we have no problem in our code?
Yes, we can use any one in the device set to mount the filesystem. like below.
mount -t btrfs /dev/vdc /mnt/btrfs/
But the device showed in /proc/mounts is /dev/vdb.
Do we need bring up the 3 dm devices in 2nd kernel?
I think so, but I do not test this case via network, since the kernel will bring up all of the local device.
Why kdump fails during your test? Kdump kernel only bring up /dev/dm-0? /dev/dm-1 and /dev/dm-2 are missing in your test?
Ok, I will paste the instance result to show you the problem.
The specified conf in 1st kernel: [root@localhost tmp]# cat /etc/kdump.conf | grep -v ^# path /mnt/btrfs/var/crash core_collector makedumpfile -F -l --message-level 1 -d 31 default shell force_rebuild 1
The conf generated by kdump. [root@localhost tmp]# cat etc/kdump.conf core_collector makedumpfile -F -l --message-level 1 -d 31 default shell force_rebuild 1 btrfs path /var/crash
You can find that the option btrfs misses the value in the kdump.conf which is generated by kdump.
If the conf is correct, the value will be "/dev/disk/by-uuid/e3d72630-fef0-4314-8f20-f4527783f375". [root@localhost tmp]# cat etc/kdump.conf core_collector makedumpfile -F -l --message-level 1 -d 31 default shell force_rebuild 1 btrfs /dev/disk/by-uuid/e3d72630-fef0-4314-8f20-f4527783f375 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ path /var/crash
If they are all brought up in kdump kernel then what is the problem?
BTW, I think you should focus on one issue, maybe investigating on ipv6 first, these two issues can conflict in code...
Ok. I will hang on this patch, and continue once I have enough time.
Thanks Minfei
On 06/15/15 at 04:33pm, Minfei Huang wrote:
As you know, each filesystem instance is unique, and we can use UUID which is generated by mkfs to identify the specified filesystem. Fstabe can use the UUID to mount the specified filesystem on the directory which is specified in the /etc/fstab.
udev will create following soft-link, once we mount the device(s) on directory successfully.
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
Thus Kdump maybe fail to the find UUID, once user specifies the device in kdump.conf.
In order to fix this issue, we can use blkid to point out the UUID.
Here is some content from blkid manpage.
- Note that blkid reads information directly from devices and for
non-root users it returns cached unverified information.
- Avoid using the symlinks directly; it is not reliable to use the
symlinks without verification.
[1] The structure of lvm volume. [root@localhost ~]# ls -al /dev/testvg/ total 0 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest03 -> ../dm-2
Signed-off-by: Minfei Huang mhuang@redhat.com
mkdumprd | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/mkdumprd b/mkdumprd index 28ecdd7..4e69526 100644 --- a/mkdumprd +++ b/mkdumprd @@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() {
- local i _tmp _dev
local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do
- for i in /dev/mapper/* /dev/disk/by-id/*; do _tmp=$(udevadm info --query=name --name="$i" 2>/dev/null) if [ "$_tmp" = "$_dev" ]; then echo $i
@@ -45,6 +45,18 @@ get_persistent_dev() { fi done
- if [ "x" != "x""$(blkid $1 | grep "UUID")" ]; then
_uuid=`blkid $1 | grep "UUID" | awk '{print $2}'`_uuid=${_uuid#*\"}_uuid=${_uuid%\"*}_dev=/dev/disk/by-uuid/$_uuid_tmp=$(udevadm info --query=name --name=$_dev 2>/dev/null)if [ "x" != "x"$_tmp ]; thenecho $_devreturnfi- fi
Thinking more about it, You may need fix it in dracut, and then backport to mkdumprd.
It is btrfs specific so only doing this for btrfs case is better..
perror "WARNING: Persistent device name of $1 not found. Using $1 as dump target name" echo $1}
2.1.0
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 06/18/15 at 10:12am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
As you know, each filesystem instance is unique, and we can use UUID which is generated by mkfs to identify the specified filesystem. Fstabe can use the UUID to mount the specified filesystem on the directory which is specified in the /etc/fstab.
udev will create following soft-link, once we mount the device(s) on directory successfully.
$ ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3
In gereral, we can use device name to find the filesystem UUID in /dev/disk. But it fails, if a filesystem is integrated by seveal devices, like btrfs. Following is the structure of btrfs.
$ btrfs filesystem show /mnt/btrfs Label: none uuid: b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 Total devices 3 FS bytes used 240.00KiB devid 1 size 1.00GiB used 232.25MiB path /dev/mapper/testvg-lvtest01 devid 2 size 1.00GiB used 92.88MiB path /dev/mapper/testvg-lvtest02 devid 3 size 500.00MiB used 220.25MiB path /dev/mapper/testvg-lvtest03
When we list the content of /dev/disk/by-uuid, we can find /dev/dm-0[1] points to the corresponding UUID.
$ ls -al /dev/disk/by-uuid/ total 0 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 21b7296c-13b3-4c9f-8b80-07a76ca26a49 -> ../../vda1 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 6a808f08-1391-4fe5-90e3-107371a72742 -> ../../vda2 lrwxrwxrwx. 1 root root 10 Jun 15 15:45 dc97ae60-2abf-4804-8122-6cae176274e3 -> ../../vda3 lrwxrwxrwx. 1 root root 10 Jun 15 15:48 b7ee07cd-6b28-43ec-aaed-af269bbcc0c9 -> ../../dm-0
Thus Kdump maybe fail to the find UUID, once user specifies the device in kdump.conf.
In order to fix this issue, we can use blkid to point out the UUID.
Here is some content from blkid manpage.
- Note that blkid reads information directly from devices and for
non-root users it returns cached unverified information.
- Avoid using the symlinks directly; it is not reliable to use the
symlinks without verification.
[1] The structure of lvm volume. [root@localhost ~]# ls -al /dev/testvg/ total 0 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest01 -> ../dm-0 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest02 -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 15 15:48 lvtest03 -> ../dm-2
Signed-off-by: Minfei Huang mhuang@redhat.com
mkdumprd | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/mkdumprd b/mkdumprd index 28ecdd7..4e69526 100644 --- a/mkdumprd +++ b/mkdumprd @@ -30,14 +30,14 @@ perror() { }
get_persistent_dev() {
- local i _tmp _dev
local i _tmp _dev _uuid
_dev=$(udevadm info --query=name --name="$1" 2>/dev/null) [ -z "$_dev" ] && { perror_exit "Kernel dev name of $1 is not found." }
- for i in /dev/mapper/* /dev/disk/by-uuid/* /dev/disk/by-id/*; do
- for i in /dev/mapper/* /dev/disk/by-id/*; do _tmp=$(udevadm info --query=name --name="$i" 2>/dev/null) if [ "$_tmp" = "$_dev" ]; then echo $i
@@ -45,6 +45,18 @@ get_persistent_dev() { fi done
- if [ "x" != "x""$(blkid $1 | grep "UUID")" ]; then
_uuid=`blkid $1 | grep "UUID" | awk '{print $2}'`_uuid=${_uuid#*\"}_uuid=${_uuid%\"*}_dev=/dev/disk/by-uuid/$_uuid_tmp=$(udevadm info --query=name --name=$_dev 2>/dev/null)if [ "x" != "x"$_tmp ]; thenecho $_devreturnfi- fi
Thinking more about it, You may need fix it in dracut, and then backport to mkdumprd.
It is btrfs specific so only doing this for btrfs case is better..
We have already a bug for cleaning up get persistant dev functions: https://bugzilla.redhat.com/show_bug.cgi?id=1077921
perror "WARNING: Persistent device name of $1 not found. Using $1 as dump target name" echo $1}
2.1.0
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 06/18/15 at 01:46pm, Dave Young wrote:
On 06/18/15 at 10:12am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
Thinking more about it, You may need fix it in dracut, and then backport to mkdumprd.
It is btrfs specific so only doing this for btrfs case is better..
We have already a bug for cleaning up get persistant dev functions: https://bugzilla.redhat.com/show_bug.cgi?id=1077921
Hi, Dave.
I think a bit for this issue. How about do the cleanup firstly? As Vivek suggested, we can define the get_persistent_dev function in kdump-lib.sh. Thus mkdumprd and dracut-module-setup.sh can use this function.
Above is the fisrt section, then I can post a patch to fix the btrfs issue.
For dracut, I do not want to fix it now, since there is no customer to complain about it. If the bug needs to be fixed, I can post a patch to fix it.
Thanks Minfei
On 06/18/15 at 07:45pm, Minfei Huang wrote:
On 06/18/15 at 01:46pm, Dave Young wrote:
On 06/18/15 at 10:12am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
Thinking more about it, You may need fix it in dracut, and then backport to mkdumprd.
It is btrfs specific so only doing this for btrfs case is better..
We have already a bug for cleaning up get persistant dev functions: https://bugzilla.redhat.com/show_bug.cgi?id=1077921
Hi, Dave.
I think a bit for this issue. How about do the cleanup firstly? As Vivek suggested, we can define the get_persistent_dev function in kdump-lib.sh. Thus mkdumprd and dracut-module-setup.sh can use this function.
I agree that doing cleanup first is better. dracut-modules-setup.sh directly use the dracut lib function, but since mkdumprd can not use it so we copied one to mkdumprd.
Maintain two copies is bad, so we need make mkdumprd to use the dracut function.
Above is the fisrt section, then I can post a patch to fix the btrfs issue.
For dracut, I do not want to fix it now, since there is no customer to complain about it. If the bug needs to be fixed, I can post a patch to fix it.
We should be aligh with dracut functions, moving functions to dracut if it is general thing.
Thanks Dave
On 06/18/15 at 10:12am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
Here is some content from blkid manpage.
- Note that blkid reads information directly from devices and for
non-root users it returns cached unverified information.
- Avoid using the symlinks directly; it is not reliable to use the
symlinks without verification.
Thinking more about it, You may need fix it in dracut, and then backport to mkdumprd.
It is btrfs specific so only doing this for btrfs case is better..
Hi, Dave.
As blkid manpage mentioned, reading symlink (soft-link) does not recommend. All will be solved, once we use blkid to get the filesystem UUID, including the btrfs issue.
But I will think a bit about this patch, and comment it later.
Thanks Minfei
perror "WARNING: Persistent device name of $1 not found. Using $1 as dump target name" echo $1}
2.1.0
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 06/18/15 at 01:54pm, Minfei Huang wrote:
On 06/18/15 at 10:12am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
Here is some content from blkid manpage.
- Note that blkid reads information directly from devices and for
non-root users it returns cached unverified information.
- Avoid using the symlinks directly; it is not reliable to use the
symlinks without verification.
Thinking more about it, You may need fix it in dracut, and then backport to mkdumprd.
It is btrfs specific so only doing this for btrfs case is better..
Hi, Dave.
As blkid manpage mentioned, reading symlink (soft-link) does not recommend. All will be solved, once we use blkid to get the filesystem UUID, including the btrfs issue.
Minfei, I did not mean to change the symlink code, instead I talked about the whole get_presistant_dev function cleanup.
But I will think a bit about this patch, and comment it later.
Thanks Minfei
perror "WARNING: Persistent device name of $1 not found. Using $1 as dump target name" echo $1}
2.1.0
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 06/18/15 at 02:53pm, Dave Young wrote:
On 06/18/15 at 01:54pm, Minfei Huang wrote:
On 06/18/15 at 10:12am, Dave Young wrote:
On 06/15/15 at 04:33pm, Minfei Huang wrote:
Here is some content from blkid manpage.
- Note that blkid reads information directly from devices and for
non-root users it returns cached unverified information.
- Avoid using the symlinks directly; it is not reliable to use the
symlinks without verification.
Thinking more about it, You may need fix it in dracut, and then backport to mkdumprd.
It is btrfs specific so only doing this for btrfs case is better..
Hi, Dave.
As blkid manpage mentioned, reading symlink (soft-link) does not recommend. All will be solved, once we use blkid to get the filesystem UUID, including the btrfs issue.
Minfei, I did not mean to change the symlink code, instead I talked about the whole get_presistant_dev function cleanup.
Hi, Dave.
Replied it in another mail in this thread, you can check it.
Thanks Minfei
-
Dave Young -
Minfei Huang