On Wed, Jul 27, 2016 at 09:35:22PM +0300, Gilboa Davara wrote: > Hello all, > > I need help trying to debug a weird bug that I'm hitting. > I've got a server with fairly large storage (>100TB) that needs to > handle very-small-files. > Due to performance considerations I decided to split the large array > into 128 ext4 partitions (rather than use a single xfs partition). > > I recently upgraded the server to F24 (w/ kernel 4.5.5, 4.6.4 refuses > to boot on the machine) and I'm now facing a weird problem: On boot, > systemd fails to mount all the partition dropping to emergency shell. > > At least as far as I can see, udev fails to create some symbolic links > under /dev/<LVMVGName>, even though it has no issues creating the same > symbolic links under /dev/mapper/<LVMVGName>-<LVMLGName>_PXX. > On the other hand systemd still uses the broken /dev/<LVMVGName> > device units, even though we moved all the entries in fstab to > /dev/mapper/<LVMVGName>-<LVMLGName>_PXX and manually ran > systemd-fstab-generator. > > Valid mapper: > $ ls -l /dev/mapper/VolRoot-LogStorageMData_P* | wc -l > 128 > > Invalid VGName: > $ ls -l /dev/VolRoot/LogStorageMData_P* | wc -l > 95 <--- Should be 128. > > fstab: > $ cat /etc/fstab | grep VolRoot-LogStorageMData_P | wc -l > 128 > > systemd broken unit files: > $ systemctl -a --no-pager | /bin/grep dev-VolRoot-LogStorageMData | wc -l > 95 <--- Should be 128. It is possible that udevd is failing for whatever reason... but apart from the fact that some of the devices links are missing you don't provide any info. At the minimum: boot logs, and information which links are missing. Note that just running the generator by hand has no effect. You need systemctl daemon-reload to reload the units, but that will re-run the generators by itself. I'd suggest commenting out (or adding "noauto") the mount points in /etc/fstab, (and of course also disabling any units which make use of them if they are not conditionalized), and debugging in a booted system. It's most likely to be easier this way. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
