df command output shows partly dm-X devices and partly lvm mapper devices,
Hi all,
After upgrading our vmware template server from debian wheezy to debian jessie the output of the df command seems broken with regards to the root and /usr mount. We are using LVM on this machine. I've been searching for quite some time for a solution, but lack of linux knowledge is bothering me to get it fixed. The system seems to run fine without issues. I can temporarely resolve the issue (untill next boot) by doing a lazy umount and a new mount of for example the /usr but I have no clue how to do this for the root partition. I found a thread that something has changed in the way df presents the devices, however it is not consistent in our case (it shows a mix of both) and it seems to go wrong at an earlier stage during boot. Who can help me out what is going on with the mounting at boot phase and better yet, how to fix this? Either show all dm devices or mapper devices is fine with me although I have a slight preference for the mapper names as it makes it more obvious LVM is being used. Please find below some outputs. REFS I found already, but is not entirely our issue: https://groups.google.com/forum/#!to...st/QxmQtwfYpr8 Any input is appreciated. Code:
df -h 11:12 Code:
mount 11:12 Code:
cat /proc/mounts 11:14 Code:
cat /etc/fstab 11:15 |
You might need to look for udev rules for dm and lvm ( specially if there are any blacklists ).also check the lvm.conf for any hints.
Also check multipath configuration file if multipathd running. if everything looks OK, run the equivilant of "udevadm trigger" in debian. NOTE : I am not very familiar with Debian. However i think it should give you hints to troubleshoot. |
Hi nooneknowme,
I need to delve into this udev stuff. I have been reading a little about it, but the linux boot sequence in detail is still very unclear to me unfortunately. Some things happen in the initram which needs to be rebuild upon changes in the udev config if I understand correctly. This is not yet in my league :) Maybe someone who can explain the details of the debian boot process a little more in depth, especially with regards to finding drives and the mounting process involving udef and multipathing ? By the way, I do not see any multipath deamon running. Thanks ! |
Why do you care ?.
Just goes to prove you should be concentrating on the mount point, not the (simulated) device it reside on. |
Quote:
But I have no clue where to start (noob). What service does the initial mounting and where is the configuration hidden ? |
no one who can put me on the right track?
Some more info. I found some weird things going on in the dmesg log. The 2 misbehaving mountpoints are mounted somewhere in the boot-process. A little later they are re-mounted (?) I can not see this behavior for the other logical volumes. How can I analyze what service(s) is (are) doing these activities during the boot process? What is causing this behavior? Code:
[ 0.994887] sr 1:0:0:0: Attached scsi CD-ROM sr0 Code:
[ 5.657373] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input3 |
Does lvm show the correct behaviour?
If there are no other problems, I would treat any discrepancies between /proc and mount to be "spurious" and not in need of explanation. |
Quote:
It looks ok, lvs,pvs,vgs all give normal responses. I admit it seems something cosmetic but i want to be sure, before I roll-out this as a template machine, that it will not cause issues. Soon you will have a few machines running on it in a live environment and than - as always - the shit shows up. So if you guys know some commands / tests I can run to make sure all is ok I guess i have to put my need/urgency voor cleanliness aside :). By the way; I also tried installing from scratch (using the jessie dvd iso)... it exposes the same problem. Even worse, now more drives show up as dm-x. To me this looks like a bug somewhere but I can not pinpoint it exactly with my knowledge level of Debian. Never had this issue with wheezy or squeeze |
So basically, you have a load of unused dm-x nodes plus some nodes properly used via dev-mapper???
Never tried it, but the dmsetup command might be useful, especially Code:
dmsetup ls |
Well the mounts (nodes?) are all in use.
This command showing CORRECT results once again : Code:
dmsetup ls 18:55 Most other tooling does not seem to bother. Really weird this.... Code:
df 18:57 |
Do you have an ordinary (non-LVM) /boot partition?
If not, this could be the cause of your problems (possibly). |
Quote:
When installing debian with LVM from distro dvd, doesn't it take care automatically of this ? Boot has ID 83 (not 8e), looks ok (?) Code:
fdisk -l output : |
It's a bit small but possibly /dev/sda1 (only 243MB) could conceivably be your /boot partition.
But apparently my answer has been superseded.:) You used to need a separate /boot for LVM - but GRUB2 can now handle LVM files. You will still need a (ext2 etc) partition to hold the GRUB2 files - I'd guess that's actually /dev/sda1. Comment:- Why do you have two disks - one is only 8GB and the other is only 50GB? |
Quote:
This is a template machine with only basic configuration. After deploying it must be tweaked depending on its use (hence the use of LVM and so on). A spamfilter appliance or chat server do not required much space. Why there are two disks is a little beyond the scope of the thread ;) there's some history behind it... Any more thoughts on why the phenomenon occurs ? |
How about this for a total guess for this phenomena?
During the boot process, / & /usr are both need to be mounted early on, but these correspond to dm-0 & dm-2. When LVM is started it does (just possibly) a second mount of / & /usr - which would follow the contents of /proc. It may be related to the layout of your fstab entries? I use LVM in a script to do backups on an external disk, so I don't have any LVM fstab entries, instead I use mount and umount commands. These do not mention "mapper" at all - for example Code:
mount /dev/vgname/lvname /mnt/mountpoint -t ext4 -o rw Code:
/dev/mapper/vgname-lvname Perhaps you could add a "test" lvname with a fstab entry in the above style, just to see what happens? |
All times are GMT -5. The time now is 03:17 AM. |