Hello,
After repeated failing efforts to restore CentOS 7 backups (taken using mondorescue software), I have found that all my CentOS 7 installations (VMs under KVM) have the same /boot/grub2/device.map, which seemingly refers to two HDs, although the VMs in fact include only one (virtual) HD.
For example: /boot/grub2/device.map
# this device map was generated by anaconda (hd0) /dev/vda (hd1) /dev/vda
Here is the hardware of the VM:
# parted -l Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/centos-swap: 2147MB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B 2147MB 2147MB linux-swap(v1)
Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/centos-root: 18.8GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags:
Number Start End Size File system Flags 1 0.00B 18.8GB 18.8GB xfs
Model: Virtio Block Device (virtblk) Disk /dev/vda: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1 1049kB 525MB 524MB primary xfs boot 2 525MB 21.5GB 20.9GB primary lvm
This is NOT the case with my CentOS 5 and CentOS 6 VMs, which all have a "correct" device map, with a single (hda0) entry.
Is the above behavior expected? If not, what should be the expected way of operation and what may be the cause of it?
I am trying to understand where something may be going wrong, so please help.
Many Thanks! Nick
On 29/12/2016 11:24 πμ, Nikolaos Milas wrote:
...I have found that all my CentOS 7 installations (VMs under KVM) have the same /boot/grub2/device.map, which seemingly refers to two HDs, although the VMs in fact include only one (virtual) HD. ... This is NOT the case with my CentOS 5 and CentOS 6 VMs, which all have a "correct" device map, with a single (hda0) entry.
Is the above behavior expected? If not, what should be the expected way of operation and what may be the cause of it?
I am trying to understand where something may be going wrong, so please help.
Hello,
I never got a reply on this, so I repeat the question:
Is it normal in CentOS 7 to have a device map with two entries esp. when the (physical or virtual) hardware has only one hd ?
Is the following normal?
/boot/grub2/device.map:
# this device map was generated by anaconda (hd0) /dev/vda (hd1) /dev/vda
Please advise!
Thanks, Nick
On 01/04/2017 03:07 AM, Nikolaos Milas wrote:
Is it normal in CentOS 7 to have a device map with two entries esp. when the (physical or virtual) hardware has only one hd ?
I don't see that on VMs that I manage. Some of the physical machines that I manage do have duplicates in the device.map.
On 4/1/2017 7:37 μμ, Gordon Messmer wrote:
I don't see that on VMs that I manage. Some of the physical machines that I manage do have duplicates in the device.map.
Thank you Gordon for your feedback!
Can others please report the content of /boot/grub2/device.map on their CentOS 7 (physical or virtual) installations?
And can any tech geek please explain when why do we have these duplicates and if they are intentional or not?
Thanks, Nick
On Thu, Jan 5, 2017 at 4:04 AM, Nikolaos Milas nmilas@noa.gr wrote:
On 4/1/2017 7:37 μμ, Gordon Messmer wrote:
I don't see that on VMs that I manage. Some of the physical machines that
I manage do have duplicates in the device.map.
Thank you Gordon for your feedback!
Can others please report the content of /boot/grub2/device.map on their CentOS 7 (physical or virtual) installations?
On my CentOS7 installs I find dups too.
Physical # this device map was generated by anaconda (hd0) /dev/sda (hd1) /dev/sda
Virtual (KVM VM) # this device map was generated by anaconda (hd0) /dev/vda (hd1) /dev/vda
Also seeing duplicates on a CentOS 7 kvm vm
# this device map was generated by anaconda (hd0) /dev/vda (hd1) /dev/vda
On Thu, Jan 5, 2017 at 12:32 PM, Mike - st257 silvertip257@gmail.com wrote:
On Thu, Jan 5, 2017 at 4:04 AM, Nikolaos Milas nmilas@noa.gr wrote:
On 4/1/2017 7:37 μμ, Gordon Messmer wrote:
I don't see that on VMs that I manage. Some of the physical machines
that
I manage do have duplicates in the device.map.
Thank you Gordon for your feedback!
Can others please report the content of /boot/grub2/device.map on their CentOS 7 (physical or virtual) installations?
On my CentOS7 installs I find dups too.
Physical # this device map was generated by anaconda (hd0) /dev/sda (hd1) /dev/sda
Virtual (KVM VM) # this device map was generated by anaconda (hd0) /dev/vda (hd1) /dev/vda
-- ---~~.~~--- Mike // SilverTip257 // _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 5/1/2017 11:04 πμ, Nikolaos Milas wrote:
Can others please report the content of /boot/grub2/device.map on their CentOS 7 (physical or virtual) installations?
Thank you all for your reports. Since it seems this is generally the case with CentOS 7, does anyone also have access to RHEL 7 installations to verify if this is the case with these installations as well?
And can any tech geek please explain when/why do we have these "duplicates" and if they are intentional or not?
Any feedback regarding this "issue" and its possible repercussions will be appreciated!
Thanks a lot, Nick
On 01/06/2017 07:11 AM, Nikolaos Milas wrote:
Any feedback regarding this "issue" and its possible repercussions will be appreciated!
Probably none. That file indicates which Linux device file corresponds to the (hdX) references in grub.cfg. I'm not really sure it's even used under grub2, since I don't see any of the (hdX) references in grub.cfg on the system I checked.
Gordon Messmer wrote:
On 01/06/2017 07:11 AM, Nikolaos Milas wrote:
Any feedback regarding this "issue" and its possible repercussions will be appreciated!
Probably none. That file indicates which Linux device file corresponds to the (hdX) references in grub.cfg. I'm not really sure it's even used under grub2, since I don't see any of the (hdX) references in grub.cfg on the system I checked.
It's used. I can assure you of that, having had to fight one or two systems back and bootable again....
mark