[opensuse-factory] df has gotten too wordy
For several years, I've been using this: alias df='df --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=cgroup ' so as to see only freespace on physical storage. Previously, with 4.1.6 kernel, this was typical output: # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda23 5655815 5055667 309295 95% / /dev/sda9 4436818 895247 3496509 21% /home /dev/sda10 24346966 4773 23113223 1% /pub /dev/sda1 396623 320125 56019 86% /disks/boot /dev/sda12 5655815 4490037 874924 84% /disks/stw5 /dev/sda11 1998813 884869 1011532 47% /usr/local nfssrv:/pub 236732960 28928264 205381920 13% /nfs/nfssrv/pub With current TW's 4.3.3 it's more verbose: Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part23 5655815 5055450 309512 95% / /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part11 1998813 884869 1011532 47% /usr/local /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part1 396623 320125 56019 86% /disks/boot /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part9 4436818 895247 3496509 21% /home /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part12 5655815 4489935 875026 84% /disks/stw5 /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part10 24346966 4773 23113223 1% /pub nfssrv:/pub 236732960 28928248 205381928 13% /nfs/nfssrv/pub Even in this email the problem will be obvious. Did the new linux-tools do this? Is there some way to recover the shorter line lengths with human memorable names? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
12.01.2016 23:01, Felix Miata пишет:
With current TW's 4.3.3 it's more verbose: Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part23 5655815 5055450 309512 95% / /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part11 1998813 884869 1011532 47% /usr/local /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part1 396623 320125 56019 86% /disks/boot /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part9 4436818 895247 3496509 21% /home /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part12 5655815 4489935 875026 84% /disks/stw5 /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part10 24346966 4773 23113223 1% /pub nfssrv:/pub 236732960 28928248 205381928 13% /nfs/nfssrv/pub
Even in this email the problem will be obvious.
Which problem? Anyway, could you show "dmsetup status"? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2016-01-12 23:11 (UTC+0300):
Felix Miata composed:
With current TW's 4.3.3 it's more verbose: Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part23 5655815 5055450 309512 95% / /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part11 1998813 884869 1011532 47% /usr/local /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part1 396623 320125 56019 86% /disks/boot /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part9 4436818 895247 3496509 21% /home /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part12 5655815 4489935 875026 84% /disks/stw5 /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part10 24346966 4773 23113223 1% /pub nfssrv:/pub 236732960 28928248 205381928 13% /nfs/nfssrv/pub
Even in this email the problem will be obvious.
s/email the prob/email one prob/
Which problem?
Question should have been better written, but one problem is that in email pastes it will wrap, as will also in small terminal windows or on e.g. 80x25 screens.
Anyway, could you show "dmsetup status"?
Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH: 0 976773168 multipath 2 0 0 0 1 1 A 0 1 2 8:0 A 0 0 1 Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part23: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part9: 0 18024867 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part22: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part8: 0 14747607 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part19: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part21: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part7: 0 4241097 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part18: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part20: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part6: 0 514017 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part17: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part5: 0 16002 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part16: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part4: 0 2 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part15: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part3: 0 514080 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part29: 0 312576642 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part14: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part2: 0 819315 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part28: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part13: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part1: 0 819252 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part27: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part12: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part26: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part11: 0 4096512 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part25: 0 11470347 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part10: 0 49158837 linear Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part24: 0 11470347 linear I've since discovered that $SUBJECT only happens when booting with 4.3.3's 36562K hostonly=no initrd (which takes >12 minutes to boot). With 4.3.3's 9437K hostonly=yes initrd (which takes <5 minutes to boot), the familiar terse format is restored. Long boot times described: http://www.spinics.net/lists/linux-initramfs/msg04210.html -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
13.01.2016 01:01, Felix Miata пишет:
Andrei Borzenkov composed on 2016-01-12 23:11 (UTC+0300):
Felix Miata composed:
With current TW's 4.3.3 it's more verbose: Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part23 5655815 5055450 309512 95% / /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part11 1998813 884869 1011532 47% /usr/local /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part1 396623 320125 56019 86% /disks/boot /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part9 4436818 895247 3496509 21% /home /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part12 5655815 4489935 875026 84% /disks/stw5 /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part10 24346966 4773 23113223 1% /pub nfssrv:/pub 236732960 28928248 205381928 13% /nfs/nfssrv/pub
Even in this email the problem will be obvious.
s/email the prob/email one prob/
Which problem?
Question should have been better written, but one problem is that in email pastes it will wrap, as will also in small terminal windows or on e.g. 80x25 screens.
Anyway, could you show "dmsetup status"?
Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH: 0 976773168 multipath 2 0 0 0 1 1 A 0 1 2 8:0 A 0 0 1
So your system decided to use multipath for disk. I remember similar question on forums. I do not think it really depends on kernel version, because kernel does not create those mappings by itself. For some reasons multipath got added to initrd when it was rebuilt for new kernel. You could try to boot from live media and recreate initrd; I'm afraid that doing it from live system now would pick up multipath again. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2016-01-13 06:28 (UTC+0300):
Felix Miata composed:
Andrei Borzenkov composed on 2016-01-12 23:11 (UTC+0300):
Felix Miata composed:
With current TW's 4.3.3 it's more verbose: Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part23 5655815 5055450 309512 95% / ...
Anyway, could you show "dmsetup status"?
Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH: 0 976773168 multipath 2 0 0 0 1 1 A 0 1 2 8:0 A 0 0 1
So your system decided to use multipath for disk.
Looks to me like Stefan's response was on the right track.
I remember similar question on forums. I do not think it really depends on kernel version, because kernel does not create those mappings by itself. For some reasons multipath got added to initrd when it was rebuilt for new kernel.
You could try to boot from live media and recreate initrd;
Should I want to after already having built second initrd (via chroot) that hasn't the problem?
I'm afraid that doing it from live system now would pick up multipath again.
The 36562K initial initrd was built on its initial installation with dracut configured with hostonly=yes. When I rebuilt it after changing dracut configuration to hostonly=no, and adddriver changes, the quicker booting 9437K result uses the traditional short names. I don't see any point building same initrd a third time. I have now set it immutable, so we shall see what happens on installing the next kernel that comes along, hopefully soon now that 4.4 is past RC. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
13.01.2016 06:48, Felix Miata пишет:
Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH: 0 976773168 multipath 2 0 0 0 1 1 A 0 1 2 8:0 A 0 0 1
So your system decided to use multipath for disk.
Looks to me like Stefan's response was on the right track.
I remember similar question on forums. I do not think it really depends on kernel version, because kernel does not create those mappings by itself. For some reasons multipath got added to initrd when it was rebuilt for new kernel.
You could try to boot from live media and recreate initrd;
Should I want to after already having built second initrd (via chroot) that hasn't the problem?
I'm afraid that doing it from live system now would pick up multipath again.
The 36562K initial initrd was built on its initial installation
Do you omit critical piece of information intentionally? It is not the first time it happens.
with dracut configured with hostonly=yes. When I rebuilt it after changing dracut configuration to hostonly=no, and adddriver changes, the quicker booting 9437K result uses the traditional short names.
Are you absolutely sure which one was built with hostonly=yes? Or to put it differently - how you determine whether initrd was built using hostonly mode?
I don't see any point building same initrd a third time. I have now set it immutable, so we shall see what happens on installing the next kernel that comes along, hopefully soon now that 4.4 is past RC.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2016-01-13 07:08 (UTC+0300):
Felix Miata composed:
The 36562K initial initrd was built on its initial installation
Do you omit critical piece of information intentionally?
Hard to say, since I can't tell what bit(s) of the statement make it critical. The 36562K size and the fact that it was the initial one built for that kernel version were provided 2016-01-12 22:48 (UTC-0500), in my previous post that you replied to, but not in the thread's OP, written before I noticed that $SUBJECT was logically connected to the huge hostonly initrd.
It is not the first time it happens.
Some people don't have eidetic memories. I'm one of them.
with dracut configured with hostonly=yes. When I rebuilt it after changing dracut configuration to hostonly=no, and adddriver changes, the quicker booting 9437K result uses the traditional short names.
Are you absolutely sure which one was built with hostonly=yes?
There have been only two built for that kernel on that installation so far. The larger is the older. The smaller is the newer, built after finding the initial was huge and producing unusually huge boot delay.
Or to put it differently - how you determine whether initrd was built using hostonly mode?
Examine the timestamps: http://fm.no-ip.com/Tmp/SUSE/Factory/ This is the dracut.conf file in place prior to the day's zypper update: http://fm.no-ip.com/Tmp/SUSE/Factory/dracut.conf.07 Note it contains hostonly="no" uncommented. http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default1 is the initrd that resulted from using it. Only today I noticed that dracut.conf has been deprecated, so I did a bit of research, replaced my /etc/dracut.conf version with the .rpmsave version, then did some editing. Intermediate edits have all been lost. This is the final result of editing: http://fm.no-ip.com/Tmp/SUSE/Factory/modules.conf It lives in /etc/dracut.conf.d/ to provide the customizations I thought I would like. Only after completing the editing did I build the new initrd: http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default2 The original 36562K one is: http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default1 Whether the original was built after doing some preliminary editing I cannot remember definitively, but I'm pretty sure all edits were done after building the initial. Andrei Borzenkov composed on 2016-01-13 07:21 (UTC+0300):
@Felix: do you have /etc/multipath.conf on your system? Do you have it in initrd that exhibits this problem? Could you show content of both?
/etc/multipath.conf does not exist. Grepping multipath in lsinitrd output produces no results in the /etc/ tree. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
13.01.2016 08:25, Felix Miata пишет:
with dracut configured with hostonly=yes. When I rebuilt it after changing dracut configuration to hostonly=no, and adddriver changes, the quicker booting 9437K result uses the traditional short names.
Are you absolutely sure which one was built with hostonly=yes?
There have been only two built for that kernel on that installation so far. The larger is the older. The smaller is the newer, built after finding the initial was huge and producing unusually huge boot delay.
Or to put it differently - how you determine whether initrd was built using hostonly mode?
Examine the timestamps: http://fm.no-ip.com/Tmp/SUSE/Factory/
This is the dracut.conf file in place prior to the day's zypper update: http://fm.no-ip.com/Tmp/SUSE/Factory/dracut.conf.07
Note it contains hostonly="no" uncommented.
/etc/dracut.conf.d takes precedence and sets hostonly=yes so this line should have no effect.
http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default1 is the initrd that resulted from using it.
Only today I noticed that dracut.conf has been deprecated, so I did a bit of research, replaced my /etc/dracut.conf version with the .rpmsave version, then did some editing. Intermediate edits have all been lost. This is the final result of editing:
http://fm.no-ip.com/Tmp/SUSE/Factory/modules.conf
It lives in /etc/dracut.conf.d/ to provide the customizations I thought I would like.
Only after completing the editing did I build the new initrd: http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default2
The original 36562K one is: http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default1
I cannot download either of them, and I still am not sure I understand which one is "bad" one.
Whether the original was built after doing some preliminary editing I cannot remember definitively, but I'm pretty sure all edits were done after building the initial.
Andrei Borzenkov composed on 2016-01-13 07:21 (UTC+0300):
@Felix: do you have /etc/multipath.conf on your system? Do you have it in initrd that exhibits this problem? Could you show content of both?
/etc/multipath.conf does not exist. Grepping multipath in lsinitrd output produces no results in the /etc/ tree.
Could you send "journalctl -b" when booting with "bad" initrd? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2016-01-13 10:44 (UTC+0300):
Felix Miata composed:
Or to put it differently - how you determine whether initrd was built using hostonly mode?
Examine the timestamps: http://fm.no-ip.com/Tmp/SUSE/Factory/
This is the dracut.conf file in place prior to the day's zypper update: http://fm.no-ip.com/Tmp/SUSE/Factory/dracut.conf.07
Note it contains hostonly="no" uncommented.
/etc/dracut.conf.d takes precedence and sets hostonly=yes so this line should have no effect.
Then what made the initrd 4X typical size?
http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default1 is the initrd that resulted from using it.
Only today I noticed that dracut.conf has been deprecated, so I did a bit of research, replaced my /etc/dracut.conf version with the .rpmsave version, then did some editing. Intermediate edits have all been lost. This is the final result of editing:
It lives in /etc/dracut.conf.d/ to provide the customizations I thought I would like.
Only after completing the editing did I build the new initrd: http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default2
The original 36562K one is: http://fm.no-ip.com/Tmp/SUSE/Factory/i0nitrd-4.3.3-5-default1
I cannot download either of them, and I still am not sure I understand which one is "bad" one.
Oops. I failed to notice they were -rw-------. Now they're -rw-r--r--. Both are bad in that both cause a boot delay of at least 3 minutes. The older/4X larger one is bad re $SUBJECT.
Whether the original was built after doing some preliminary editing I cannot remember definitively, but I'm pretty sure all edits were done after building the initial.
Andrei Borzenkov composed on 2016-01-13 07:21 (UTC+0300):
@Felix: do you have /etc/multipath.conf on your system? Do you have it in initrd that exhibits this problem? Could you show content of both?
/etc/multipath.conf does not exist. Grepping multipath in lsinitrd output produces no results in the /etc/ tree.
Could you send "journalctl -b" when booting with "bad" initrd?
http://fm.no-ip.com/Tmp/SUSE/Factory/journalHPG33tw.txt -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
13.01.2016 11:46, Felix Miata пишет:
Andrei Borzenkov composed on 2016-01-13 10:44 (UTC+0300):
Felix Miata composed:
Or to put it differently - how you determine whether initrd was built using hostonly mode?
Examine the timestamps: http://fm.no-ip.com/Tmp/SUSE/Factory/
This is the dracut.conf file in place prior to the day's zypper update: http://fm.no-ip.com/Tmp/SUSE/Factory/dracut.conf.07
Note it contains hostonly="no" uncommented.
/etc/dracut.conf.d takes precedence and sets hostonly=yes so this line should have no effect.
Then what made the initrd 4X typical size?
I do not know. I do not see any difference in generated initrd whether or not I use "hostonly=no" in /etc/dracut.conf.
@Felix: do you have /etc/multipath.conf on your system? Do you have it in initrd that exhibits this problem? Could you show content of both?
/etc/multipath.conf does not exist. Grepping multipath in lsinitrd output produces no results in the /etc/ tree.
Could you send "journalctl -b" when booting with "bad" initrd?
OK, this is yet another difference between traditional and systemd-enabled dracut - systemd service does not check for/etc/multipath.conf and always starts multipathd. You can suppress multipath using rd.multipath=0 (or nompath which should also affect normal system). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2016-01-12 21:01, Felix Miata wrote:
Previously, with 4.1.6 kernel, this was typical output: # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda23 5655815 5055667 309295 95% / /dev/sda9 4436818 895247 3496509 21% /home /dev/sda10 24346966 4773 23113223 1% /pub /dev/sda1 396623 320125 56019 86% /disks/boot /dev/sda12 5655815 4490037 874924 84% /disks/stw5 /dev/sda11 1998813 884869 1011532 47% /usr/local nfssrv:/pub 236732960 28928264 205381920 13% /nfs/nfssrv/pub
With current TW's 4.3.3 it's more verbose: Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part23 5655815 5055450 309512 95% /
Even in this email the problem will be obvious. Did the new linux-tools do this? Is there some way to recover the shorter line lengths with human memorable names?
This is interesting. It would appear your system switched from using sd_mod to dm_mod behind your back. Normally, that is not something that happens just by changing the kernel version. But it is possible in some contrived scenarios, enumerated below. First, some observations: - symlink handling in df did not change; coreutils-8.24-3.5 continues to NOT dereference /dev/mapper/BLAH to its underlying /dev/dm-X when displaying the mountpoint list. - similarly, util-linux-2.27.1-2.1's mount(8) continues to NOT dereference /dev/mapper/BLAH, or df would be showing dm-X. - similarly, the kernel continues to NOT dereference /dev/mapper/BLAH either when invoking mount(2), or df would be showing dm-X. Hypothesis 1. Your /dev/sda{11..23} in the old kernel were actually dm_mod devices in the first place, created by the kpartx(8) utility, and something in kpartx changed. Hypothesis 2. Your /dev/sda{11..23} in the old kernel were driven by CONFIG_EFI_PARTITION / CONFIG_MSDOS_PARTITION, and you have disabled these config options in a new custom kernel (so it cannot read partition tables), causing udev to invoke kpartx(8) to read the partition table ANYWAY, giving the partitions new device names. You can check the major,minor number of the /dev/sda* entries to gather this missing information to either abolish or develop on these hypotheses. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 12.01.2016 um 23:50 schrieb Jan Engelhardt:
Hypothesis 1. Your /dev/sda{11..23} in the old kernel were actually dm_mod devices in the first place, created by the kpartx(8) utility, and something in kpartx changed.
Hypothesis 2. Your /dev/sda{11..23} in the old kernel were driven by CONFIG_EFI_PARTITION / CONFIG_MSDOS_PARTITION, and you have disabled these config options in a new custom kernel (so it cannot read partition tables), causing udev to invoke kpartx(8) to read the partition table ANYWAY, giving the partitions new device names.
Hypothesis 3 (backed by experience): This happens when creating a "monster initrd" with mkinitrd. Then multipath and other features are included and you can be happy if the system boots at all. And if it does, the devices are named "strange". Been there, experienced that, when trying to prepare a system for a "hardware change" (actually trying to change a KVM guest from virtio to virtio-scsi). It's a shame that this is nowadays easier in windows than in Linux, just sysprep your machine before exchanging the hardware. In linux you need to know exactly what hardware you'll need at next boot or have a rescue medium ready. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
13.01.2016 02:20, Stefan Seyfried пишет:
Hypothesis 3 (backed by experience): This happens when creating a "monster initrd" with mkinitrd. Then
dracut is configured to create hostonly initrd by default; mkinitrd does not disable it. So the question is where it comes from.
multipath and other features are included and you can be happy if the system boots at all. And if it does, the devices are named "strange".
Well ... that somehow conflicts with intention to have universal initrd that "just works". ... Hmm ... actually it is not that simple. In-initrd multipath is activated only if /etc/multipath.conf in initrd exists. And by default there is no /etc/multipath.conf at all; dracut builds one only if installed in hostonly mode and system is already using multipath. @Felix: do you have /etc/multipath.conf on your system? Do you have it in initrd that exhibits this problem? Could you show content of both?
Been there, experienced that, when trying to prepare a system for a "hardware change" (actually trying to change a KVM guest from virtio to virtio-scsi).
It's a shame that this is nowadays easier in windows than in Linux, just sysprep your machine before exchanging the hardware.
In linux you need to know exactly what hardware you'll need at next boot or have a rescue medium ready.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2016-01-12 23:50 (UTC+0100):
Felix Miata wrote: ...
With current TW's 4.3.3 it's more verbose: Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/Hitachi_HCS5C1050CLA382_JC0550HV2DJZTH-part23 5655815 5055450 309512 95% / ... Even in this email the problem will be obvious. Did the new linux-tools do this? Is there some way to recover the shorter line lengths with human memorable names?
This is interesting. It would appear your system switched from using sd_mod to dm_mod behind your back. Normally, that is not something that happens just by changing the kernel version. But it is possible in some contrived scenarios, enumerated below.
First, some observations:
- symlink handling in df did not change; coreutils-8.24-3.5 continues to NOT dereference /dev/mapper/BLAH to its underlying /dev/dm-X when displaying the mountpoint list.
- similarly, util-linux-2.27.1-2.1's mount(8) continues to NOT dereference /dev/mapper/BLAH, or df would be showing dm-X.
- similarly, the kernel continues to NOT dereference /dev/mapper/BLAH either when invoking mount(2), or df would be showing dm-X.
Hypothesis 1. Your /dev/sda{11..23} in the old kernel were actually dm_mod devices in the first place, created by the kpartx(8) utility, and something in kpartx changed.
Hypothesis 2. Your /dev/sda{11..23} in the old kernel were driven by CONFIG_EFI_PARTITION / CONFIG_MSDOS_PARTITION, and you have disabled these config options in a new custom kernel (so it cannot read partition tables), causing udev to invoke kpartx(8) to read the partition table ANYWAY, giving the partitions new device names.
You can check the major,minor number of the /dev/sda* entries to gather this missing information to either abolish or develop on these hypotheses.
Rebooted temporarily using the big original initrd: # ll /dev/sda* brw-rw---- 1 root disk 8, 0 Jan 13 03:42 /dev/sda brw-rw---- 1 root disk 8, 1 Jan 13 03:42 /dev/sda1 brw-rw---- 1 root disk 8, 10 Jan 13 03:42 /dev/sda10 brw-rw---- 1 root disk 8, 11 Jan 13 03:42 /dev/sda11 brw-rw---- 1 root disk 8, 12 Jan 13 03:42 /dev/sda12 brw-rw---- 1 root disk 8, 13 Jan 13 03:42 /dev/sda13 brw-rw---- 1 root disk 8, 14 Jan 13 03:42 /dev/sda14 brw-rw---- 1 root disk 8, 15 Jan 13 03:42 /dev/sda15 brw-rw---- 1 root disk 259, 0 Jan 13 03:42 /dev/sda16 brw-rw---- 1 root disk 259, 1 Jan 13 03:42 /dev/sda17 brw-rw---- 1 root disk 259, 2 Jan 13 03:42 /dev/sda18 brw-rw---- 1 root disk 259, 3 Jan 13 03:42 /dev/sda19 brw-rw---- 1 root disk 8, 2 Jan 13 03:42 /dev/sda2 brw-rw---- 1 root disk 259, 4 Jan 13 03:42 /dev/sda20 brw-rw---- 1 root disk 259, 5 Jan 13 03:42 /dev/sda21 brw-rw---- 1 root disk 259, 6 Jan 13 03:42 /dev/sda22 brw-rw---- 1 root disk 259, 7 Jan 13 03:42 /dev/sda23 brw-rw---- 1 root disk 259, 8 Jan 13 03:42 /dev/sda24 brw-rw---- 1 root disk 259, 9 Jan 13 03:42 /dev/sda25 brw-rw---- 1 root disk 259, 10 Jan 13 03:42 /dev/sda26 brw-rw---- 1 root disk 259, 11 Jan 13 03:42 /dev/sda27 brw-rw---- 1 root disk 259, 12 Jan 13 03:42 /dev/sda28 brw-rw---- 1 root disk 259, 13 Jan 13 03:42 /dev/sda29 brw-rw---- 1 root disk 8, 3 Jan 13 03:42 /dev/sda3 brw-rw---- 1 root disk 8, 4 Jan 13 03:42 /dev/sda4 brw-rw---- 1 root disk 8, 5 Jan 13 03:42 /dev/sda5 brw-rw---- 1 root disk 8, 6 Jan 13 03:42 /dev/sda6 brw-rw---- 1 root disk 8, 7 Jan 13 03:42 /dev/sda7 brw-rw---- 1 root disk 8, 8 Jan 13 03:42 /dev/sda8 brw-rw---- 1 root disk 8, 9 Jan 13 03:42 /dev/sda9 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Felix Miata -
Jan Engelhardt -
Stefan Seyfried