New answers tagged

1

You need to tell the kernel that the partition table has changed after you make any changes to partition tables with fdisk, cfdisk, or parted etc. There are two main ways of doing this: Reboot. The kernel will detect the new partition table and use it automatically. run partprobe as root. This will tell the kernel to scan the block-device partitions and ...


0

I have the same issue on my RHEL 7 machine. But it use GRUB2. When I remove those rd_LVM_LV= in kernel args. Press e before booting, remove those rd_LVM_LV= in kernel args, type CTRL+x I can then boot successfully. Steps to permanently solve on RHEL 7: Open /etc/default/grub remove those rd_LVM_LV= in "GRUB_CMDLINE_LINUX" Run grub2-mkconifg to create a ...


2

This is a warning based on information provided by the kernel. Misalignment mostly has performance impacts; on SSDs it may result in additional wear. It won't cause corruption! Software RAID 10 + LVM on mixed drives, sector alignment? has lots of useful information on this, including recipes to set things up correctly.


0

"Solution" found..update to grub I prefer lilo,but strange doesn't work with this procedure.


1

Adding a single 4TB drive to your multi-mirror array destroys any ability to trust in the redundancy that RAID is supposed to provide. It would be safe if you could add a second 4TB drive, but (as you have no spare drive ports) you can't do that without removing one of the existing disks. If I were you, I'd remove one of the mirror disks, add a second 4TB ...


0

As a workaround you could change your setup and use cached LVM volume (/dev/vg_server17/kvm163_img in your setup) as a PV for another VG where snapshots would work. Have verified such setup on Debian Jessie. It works well, however, require some changes to configuration. To workaround duplicate PVs detected by LVM (cache origin and cached device have same ...


1

This appears to be a bug in older versions of LVM. A bug that could be corrected by compiling from source with a different set of flags to add support for thin devices. I can not speak for the SystemRescueCD you mentioned, because I have never used it, but it may be using an older version of LVM, for whatever reason, which may have this very bug. Since ...


0

You may have leftover metadata from earlier partitioning. Like a boot partition that is used without LVM but which has LVM metadata because an installer prepared it to be used via LVM. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/452350 (German) https://debianforum.de/forum/viewtopic.php?f=33&t=154131 Yes this is not a full-blown solution, but ...


0

I'm not sure what LVM did to the data on disk, but I once had some success using gpart on a disk that had its whole partition table wiped out. testdisk seems to be a similar tool. I'd make a full disk-level backup first. Good luck. :)


0

Does anyone have any idea about this as yet ? Why are there blank entries in the device mapper table ? [root@www ~]# dmsetup table lsi_ccfafeaadcb: 0 240121727 linear 22:64 0 vg_data-lv_ftpBERPCMC: vg_data-lv_ftpROC: vg_data-lv_ftpAZI: vg_data-lv_ftpBAX: vg_data-lv_ftpBER: vg_data-lv_ftpPAST: vg_data-lv_ftpBERTEX: vg_data-lv_ftpWURTH: vg_data-lv_ftpTEA:


1

With the help above from Alexander Batischev, and some very useful information from Reddit user cookie_enthusiast on the /r/linuxquestions page on Reddit, I managed to get this working. It turns out that GRUB2 works well with UUIDs, and not so well with device names. With this knowledge in mind, we need the following 4 UUIDs at hand, before we can ...


0

LVM itself doesn't care what the underlying storage is: SATA, SCSI; HDD, SSD; local, networked; physical, virtual; etc. Different types of disks have different performance characteristics, so you may want to put the different types of disks in different groups anyway. But this is not required. You may also want to span groups over different storage types ...


0

LVM is pretty flexible, but moving the beginning of a physical volume is one thing that it can't do, as far as I know. However, you don't need to move the beginning of a PV to add more space, only to reduce it. To add more storage space, just use the free space as a PV and add it to the volume group. Give a name to the free space: make a partition. You can ...


0

LVM (Logical Volume Manager) is a subsystem. At the lowest level is a PV (Physical Volume). Within the PV is a VG (Volume Group) and within the VG are the LVs (Logical Volumes). You seem to be asking how to move or resize the PV corresponding to /dev/sda4. In order to do this you first need to deactivate the VG. (gparted > deactivate partition.) Note that ...


2

If you have LVM on it, the easy way out is to make a new partition of the free space, set it up as physical volume in LVM and add that physical volume to your volume group. You're probably right that gparted won't touch the partition as it is in use.



Top 50 recent answers are included