Hello,
I'm struggling to make a cloned CentOS 7 VM (under KVM) to work.
The VM was cloned using mondorestore. Restore appears successful but the VM won't boot; see:
http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-04.png
I booted with CentOS 7 disk in troubleshooting mode (where the virtual disk was automatically mounted without issues) and I tried to repair:
http://iweb.noa.gr/files/centos7/el7-rescue-scratchvm-20170502-01.png
Also:
# grub2-mkconfig -o /boot/grub2/grub.cfg ... /usr/sbin/grub2-probe: error: unknown filesystem.
I then tried to repair using: https://sourceforge.net/p/boot-repair-cd/home/Home/ but it didn't manage to solve the problem. (It reported success but the VM still won't boot.)
More interesting was the effort with the supergrub2 disk: http://www.supergrubdisk.org/super-grub2-disk/
This managed to identify the available "boot methods" and allowed me to boot correctly. See screenshots:
http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-00.png http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-01.png http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-02.png
Once I logged in, I checked /etc/fstab and /boot/grub2/grub.cfg but I didn't see any obvious problem. The are here as well:
http://iweb.noa.gr/files/centos7/fstab http://iweb.noa.gr/files/centos7/grub.cfg
However, I also followed these directions: https://www.techbrown.com/reinstall-grub2-boot-loader-centos-7-rhel-7.shtml to rebuild grub2.conf. The commands were completed successfully.
Unfortunately, the OS still won't boot: same issue, see:
http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-04.png
I again tried to boot using the supergrub2 disk; this time the boot method detection produced the (slightly different) list you see in image:
http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-05.png
Using the supergrub2 disk I can boot and login successfully. Otherwise (i.e. directly) the box won't boot.
As I know little about grub2 (and low-level linux) to troubleshoot the issue, can you please help identify and correct the problem? Why the VM always refuses to boot?
Which is the reported device (on image -04) that remains unrecognized? I looked into /boot/grub/grub2.cfg but I didn't see any such UUID there. Where may it be referenced to be used during the boot process?
Note: I never have such issues when restoring (using mondorestore) CentOS 5 or CentOS 6 mondoarchive backups (even on dissimilar virtual hardware).
Can you please help me identify the problem, based on the above info, and make the VM normally bootable?
Many thanks, Nick
On Wed, May 3, 2017 at 11:24 AM, Nikolaos Milas nmilas@noa.gr wrote:
Hello,
I'm struggling to make a cloned CentOS 7 VM (under KVM) to work.
The VM was cloned using mondorestore. Restore appears successful but the VM won't boot; see:
http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-04.png
Does the UUID of root filesystem in /etc/fstab match the actual UUID as reported by blkid? And remove /etc/lvm/cache/.cache if it exists
Marcelo
"¿No será acaso que esta vida moderna está teniendo más de moderna que de vida?" (Mafalda)
On 3/5/2017 10:41 μμ, Marcelo Roccasalva wrote:
Does the UUID of root filesystem in /etc/fstab match the actual UUID as reported by blkid? And remove/etc/lvm/cache/.cache if it exists
Thank you Marcelo for replying,
The directory /etc/lvm/cache/ is empty.
And, yes, the UUID matches:
# blkid /dev/vda1: UUID="297e2939-d6f5-431a-9813-9848368ee306" TYPE="xfs" /dev/vda2: UUID="OR1eUA-1hhb-PCff-qybQ-rLt4-JuTN-EcWX61" TYPE="LVM2_member" /dev/sr0: UUID="2017-03-16-21-15-06-00" LABEL="ISOIMAGE" TYPE="iso9660" PTTYPE="PMBR" /dev/mapper/centos-root: UUID="fcee6215-e97a-4a4f-9473-5115f8559683" TYPE="xfs" /dev/mapper/centos-swap: UUID="b220b45f-ae22-4393-a74d-90b03d37c41b" TYPE="swap"
# cat /etc/fstab # # /etc/fstab # Created by anaconda on Thu Dec 8 13:40:06 2016 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/centos-root / xfs defaults 0 0 UUID=297e2939-d6f5-431a-9813-9848368ee306 /boot xfs defaults 0 0 /dev/mapper/centos-swap swap swap defaults 0 0 10.201.40.34:/data/col1/noc-bkups-1 /mnt/dd2500-1 nfs auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0 0
Any other ideas?
Thanks, Nick
On Wed, May 3, 2017 at 4:55 PM, Nikolaos Milas nmilas@noa.gr wrote:
On 3/5/2017 10:41 μμ, Marcelo Roccasalva wrote:
Does the UUID of root filesystem in /etc/fstab match the actual UUID as reported by blkid? And remove/etc/lvm/cache/.cache if it exists
Thank you Marcelo for replying,
The directory /etc/lvm/cache/ is empty.
Dumb question: the file starts with a dot, doesn't show up in "ls" without "-a".
And, yes, the UUID matches:
Even dumber question: the erroring UUID exist in the origin of the cloned guest? I guess you have rebuilt initramfs a few times now, so I believe it is irrelevant...
Never used mondorestore to clone a VM, have you done it successfully before?
# blkid /dev/vda1: UUID="297e2939-d6f5-431a-9813-9848368ee306" TYPE="xfs" /dev/vda2: UUID="OR1eUA-1hhb-PCff-qybQ-rLt4-JuTN-EcWX61" TYPE="LVM2_member" /dev/sr0: UUID="2017-03-16-21-15-06-00" LABEL="ISOIMAGE" TYPE="iso9660" PTTYPE="PMBR" /dev/mapper/centos-root: UUID="fcee6215-e97a-4a4f-9473-5115f8559683" TYPE="xfs" /dev/mapper/centos-swap: UUID="b220b45f-ae22-4393-a74d-90b03d37c41b" TYPE="swap"
# cat /etc/fstab # # /etc/fstab # Created by anaconda on Thu Dec 8 13:40:06 2016 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/centos-root / xfs defaults 0 0 UUID=297e2939-d6f5-431a-9813-9848368ee306 /boot xfs defaults 0 0 /dev/mapper/centos-swap swap swap defaults 0 0 10.201.40.34:/data/col1/noc-bkups-1 /mnt/dd2500-1 nfs auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0 0
Any other ideas?
Thanks,
Nick
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 4/5/2017 5:20 μμ, Marcelo Roccasalva wrote:
Dumb question: the file starts with a dot, doesn't show up in "ls" without "-a".
Of course, I check with ls -la.It is empty indeed.
Even dumber question: the erroring UUID exist in the origin of thecloned guest? I guess you have rebuilt initramfs a few times now, so I believe it is irrelevant...
Interestingly, I see in the origin VM, the same UUID as in the cloned guest. See below.
I don't know anything about rebuilding initramfs; the whole restore process is automatic. (There is a manual method too, but I have not been successful with it either.)
# blkid /dev/mapper/centos-root: UUID="fcee6215-e97a-4a4f-9473-5115f8559683" TYPE="xfs" /dev/vda2: UUID="cey71w-b81q-w1se-0Cww-X2cr-Milx-dWw15Z" TYPE="LVM2_member" /dev/vda1: UUID="297e2939-d6f5-431a-9813-9848368ee306" TYPE="xfs" /dev/mapper/centos-swap: UUID="b220b45f-ae22-4393-a74d-90b03d37c41b" TYPE="swap"
# cat /etc/fstab /dev/mapper/centos-root / xfs defaults 0 0 UUID=297e2939-d6f5-431a-9813-9848368ee306 /boot xfs defaults 0 0 /dev/mapper/centos-swap swap swap defaults 0 0 10.201.40.34:/data/col1/noc-bkups-1 /mnt/dd2500-1 nfs auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0 0
Any ideas?
Never used mondorestore to clone a VM, have you done it successfully before?
I have always had success in all my (numerous) restores/clones with CentOS 5 and 6.
I have not managed to have a fully successful (i.e. bootable) restore/clone of a CentOS 7 system yet (due to the above issue).
Thanks, Nick
On Thu, May 4, 2017 at 11:43 AM, Nikolaos Milas nmilas@noa.gr wrote:
On 4/5/2017 5:20 μμ, Marcelo Roccasalva wrote:
Dumb question: the file starts with a dot, doesn't show up in "ls" without "-a".
Of course, I check with ls -la.It is empty indeed.
Even dumber question: the erroring UUID exist in the origin of thecloned guest? I guess you have rebuilt initramfs a few times now, so I believe it is irrelevant...
Interestingly, I see in the origin VM, the same UUID as in the cloned guest. See below.
I don't know anything about rebuilding initramfs; the whole restore process is automatic. (There is a manual method too, but I have not been successful with it either.)
In rescue mode, you should recreate initramfs. In /lib/modules you have directories with the installed kernel versions. I guess you shoud take note of the name of then latest one and run:
dracut -f /boot/initramfs-<kernel_version>.img <kernel_version>
replacing <kernel_version> with the noted directory name...
On 4/5/2017 5:56 μμ, Marcelo Roccasalva wrote:
dracut -f /boot/initramfs-<kernel_version>.img <kernel_version>
I did:
# dracut -f /boot/initramfs-3.10.0-514.10.2.el7.x86_64.img 3.10.0-514.10.2.el7.x86_64
and it ended without reporting any error. However, when I rebooted, nothing changed ("no such device: <UUID>. Entering rescue mode...").
Am I missing something?
Thanks, Nick
On Thu, May 4, 2017 at 1:12 PM, Nikolaos Milas nmilas@noa.gr wrote:
On 4/5/2017 5:56 μμ, Marcelo Roccasalva wrote:
dracut -f /boot/initramfs-<kernel_version>.img <kernel_version>
I did:
# dracut -f /boot/initramfs-3.10.0-514.10.2.el7.x86_64.img 3.10.0-514.10.2.el7.x86_64
when you boot via supergrub2, you get this kernel version (uname -r)? every kernel has it own initramfs where some binaries, libraries, modules and configuration files get copied from the running VM, so you need to boot from a newly created initramfs (which you find in grub2.conf)
On 5/5/2017 2:22 πμ, Marcelo Roccasalva wrote:
when you boot via supergrub2, you get this kernel version (uname -r)? every kernel has it own initramfs where some binaries, libraries, modules and configuration files get copied from the running VM, so you need to boot from a newly created initramfs (which you find in grub2.conf)
[Note: I am working on a fresh restored/cloned installation and I have executed on it your previous command (dracut...).]
As you can see here:
http://iweb.noa.gr/files/centos7/supergrub2-scratchvm-20170503-00.png
...I can select the kernel with which I boot. I select the latest one (marked blue in the image), which is also the one for which I have run the initramfs rebuild command.
This indeed is the kernel version reported by the OS.
I am still trying to find out how to make the OS load at boot...
Nick
Are the correct volumes referenced in your /etc/default/grub file?
On May 4, 2017 11:12:11 AM CDT, Nikolaos Milas nmilas@noa.gr wrote:
On 4/5/2017 5:56 μμ, Marcelo Roccasalva wrote:
dracut -f /boot/initramfs-<kernel_version>.img <kernel_version>
I did:
# dracut -f /boot/initramfs-3.10.0-514.10.2.el7.x86_64.img 3.10.0-514.10.2.el7.x86_64
and it ended without reporting any error. However, when I rebooted, nothing changed ("no such device: <UUID>. Entering rescue mode...").
Am I missing something?
Thanks, Nick
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 5/5/2017 5:11 πμ, Barry Brimer wrote:
Are the correct volumes referenced in your /etc/default/grub file?
Thanks Barry for your feedback.
Here is the output:
http://iweb.noa.gr/files/centos7/scratchvm-data-20170505-01.png
What can you tell from that?
Cheers, Nick
On Fri, May 5, 2017 at 11:54 AM, Nikolaos Milas nmilas@noa.gr wrote:
On 5/5/2017 5:11 πμ, Barry Brimer wrote:
Are the correct volumes referenced in your /etc/default/grub file?
Thanks Barry for your feedback.
Here is the output:
http://iweb.noa.gr/files/centos7/scratchvm-data-20170505-01.png
What can you tell from that?
Cheers,
Nick _______________________________________________
Just a guess, as you already tested many things I remember in the past I had problems when the boot partition was not marked as active. I don't know if still relevant. Could you verify, if /dev/sda is your boot disk, with the command
fdisk -l /dev/sda ?
Something like this with the star in the "Boot" column:
[root@ractorshe ~]# fdisk -l /dev/vda
Disk /dev/vda: 10.7 GB, 10737418240 bytes, 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000cb2a3
Device Boot Start End Blocks Id System /dev/vda1 * 2048 20971519 10484736 83 Linux [root@ractorshe ~]#
BTW: are you using virt-manager to configure/run your VMs? Or direct virsh commans or what?
HIH, Gianluca
On 5/5/2017 1:19 μμ, Gianluca Cecchi wrote:
Could you verify, if /dev/sda is your boot disk, with the command
fdisk -l /dev/sda ?
It's /dev/vda in my case:
# fdisk -l /dev/vda
Disk /dev/vda: 21.5 GB, 21474836480 bytes, 41943040 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x942d1f03
Device Boot Start End Blocks Id System dev/vdal * 2048 1026047 512000 83 Linux dev/vda2 * 1026048 41943039 20458496 8e Linux LVM
Hmm, it seems that the boot flag should be removed from /dev/vda2 partition? (How we do that?)
BTW: are you using virt-manager to configure/run your VMs? Or direct virsh commans or what?
It's a hosted VPS service, and I have a virtual console to the VM.
Thanks, Nick
On 5/5/2017 1:42 μμ, Nikolaos Milas wrote:
Hmm, it seems that the boot flag should be removed from /dev/vda2 partition?
Actually, I tried this and left the boot flag only to /dev/vda1. I rebooted and I am still getting the same error. :-(
I was hoping we were close to a solution...
Nick
On Fri, May 5, 2017 at 12:52 PM, Nikolaos Milas nmilas@noa.gr wrote:
On 5/5/2017 1:42 μμ, Nikolaos Milas wrote:
Hmm, it seems that the boot flag should be removed from /dev/vda2
partition?
Actually, I tried this and left the boot flag only to /dev/vda1. I rebooted and I am still getting the same error. :-(
I was hoping we were close to a solution...
Nick _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
what do you get when you boot the VM (I imagine with supergrub2 you described) and run this
lspci lspci -kn
in particular in respect with scsi devices ad kernel modules used eg in a VM of mine under oVirt
[root@ractorshe ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 Unclassified device [00ff]: Red Hat, Inc Virtio RNG 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device 00:04.0 SCSI storage controller: Red Hat, Inc Virtio SCSI 00:05.0 Communication controller: Red Hat, Inc Virtio console 00:06.0 SCSI storage controller: Red Hat, Inc Virtio block device [root@ractorshe ~]#
[root@ractorshe ~]# lspci -kn 00:00.0 0600: 8086:1237 (rev 02) Subsystem: 1af4:1100 00:01.0 0601: 8086:7000 Subsystem: 1af4:1100 00:01.1 0101: 8086:7010 Subsystem: 1af4:1100 Kernel driver in use: ata_piix Kernel modules: ata_piix, pata_acpi, ata_generic 00:01.2 0c03: 8086:7020 (rev 01) Subsystem: 1af4:1100 Kernel driver in use: uhci_hcd 00:01.3 0680: 8086:7113 (rev 03) Subsystem: 1af4:1100 Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4 00:02.0 00ff: 1af4:1005 Subsystem: 1af4:0004 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:03.0 0200: 1af4:1000 Subsystem: 1af4:0001 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:04.0 0100: 1af4:1004 Subsystem: 1af4:0008 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:05.0 0780: 1af4:1003 Subsystem: 1af4:0003 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:06.0 0100: 1af4:1001 Subsystem: 1af4:0002 Kernel driver in use: virtio-pci Kernel modules: virtio_pci [root@ractorshe ~]#
On 5/5/2017 1:57 μμ, Gianluca Cecchi wrote:
what do you get when you boot the VM (I imagine with supergrub2 you described) and run this
lspci lspci -kn
Here you are:
# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon 00:04.0 SCSI storage controller: Red Hat, Inc Virtio block device 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
# lspci -kn 00:00.0 0600: 8086:1237 (rev 02) Subsystem: 1af4:1100 00:01.0 0601: 8086:7000 Subsystem: 1af4:1100 00:01.1 0101: 8086:7010 Subsystem: 1af4:1100 Kernel driver in use: ata_piix Kernel modules: ata_piix, pata_acpi, ata_generic 00:01.2 0c03: 8086:7020 (rev 01) Subsystem: 1af4:1100 Kernel driver in use: uhci_hcd 00:01.3 0680: 8086:7113 (rev 03) Subsystem: 1af4:1100 Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4 00:02.0 0300: 1013:00b8 Subsystem: 1af4:1100 Kernel driver in use: cirrus Kernel modules: cirrus 00:03.0 00ff: 1af4:1002 Subsystem: 1af4:0005 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:04.0 0100: 1af4:1001 Subsystem: 1af4:0002 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:05.0 0200: 1af4:1000 Subsystem: 1af4:0001 Kernel driver in use: virtio-pci Kernel modules: virtio_pci
Nick
On 05/05/2017 12:57, Gianluca Cecchi wrote:
grub-install /dev/vda2 didn't work ?
On Fri, May 5, 2017 at 12:52 PM, Nikolaos Milas nmilas@noa.gr wrote:
On 5/5/2017 1:42 μμ, Nikolaos Milas wrote:
Hmm, it seems that the boot flag should be removed from /dev/vda2
partition?
Actually, I tried this and left the boot flag only to /dev/vda1. I rebooted and I am still getting the same error. :-(
I was hoping we were close to a solution...
Nick _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
what do you get when you boot the VM (I imagine with supergrub2 you described) and run this
lspci lspci -kn
in particular in respect with scsi devices ad kernel modules used eg in a VM of mine under oVirt
[root@ractorshe ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 Unclassified device [00ff]: Red Hat, Inc Virtio RNG 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device 00:04.0 SCSI storage controller: Red Hat, Inc Virtio SCSI 00:05.0 Communication controller: Red Hat, Inc Virtio console 00:06.0 SCSI storage controller: Red Hat, Inc Virtio block device [root@ractorshe ~]#
[root@ractorshe ~]# lspci -kn 00:00.0 0600: 8086:1237 (rev 02) Subsystem: 1af4:1100 00:01.0 0601: 8086:7000 Subsystem: 1af4:1100 00:01.1 0101: 8086:7010 Subsystem: 1af4:1100 Kernel driver in use: ata_piix Kernel modules: ata_piix, pata_acpi, ata_generic 00:01.2 0c03: 8086:7020 (rev 01) Subsystem: 1af4:1100 Kernel driver in use: uhci_hcd 00:01.3 0680: 8086:7113 (rev 03) Subsystem: 1af4:1100 Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4 00:02.0 00ff: 1af4:1005 Subsystem: 1af4:0004 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:03.0 0200: 1af4:1000 Subsystem: 1af4:0001 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:04.0 0100: 1af4:1004 Subsystem: 1af4:0008 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:05.0 0780: 1af4:1003 Subsystem: 1af4:0003 Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:06.0 0100: 1af4:1001 Subsystem: 1af4:0002 Kernel driver in use: virtio-pci Kernel modules: virtio_pci [root@ractorshe ~]# _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Fri, May 5, 2017 at 2:05 PM, Bernard Lheureux < bernard.lheureux@bbsoft4.org> wrote:
On 05/05/2017 12:57, Gianluca Cecchi wrote:
grub-install /dev/vda2 didn't work ?
As this is a CentOS 7.x system, I would say this, if you want to install it on MBR:
grub2-install /dev/vda
as detailed here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Was this one of the command you already tried?
On 5/5/2017 3:15 μμ, Gianluca Cecchi wrote:
... grub2-install /dev/vda ... Was this one of the command you already tried?
Yes, I have tried that multiple times, both from Troubleshooting Mode (booting using CentOS 7 Installation CD) and from within the actual system (booted using super-grub2 disk).
I always get (from troubleshooting mode):
# grub2-install --root-directory=/mnt/sysimage/ /dev/vda Installing for i386-pc platform. grub2-install: error: unknown filesystem.
or (from within the OS):
# grub2-install /dev/vda Installing for i386-pc platform. grub2-install: error: unknown filesystem.
How can I fix that?
Nick
On Fri, May 5, 2017 at 2:38 PM, Nikolaos Milas nmilas@noa.gr wrote:
On 5/5/2017 3:15 μμ, Gianluca Cecchi wrote:
...
grub2-install /dev/vda ... Was this one of the command you already tried?
Yes, I have tried that multiple times, both from Troubleshooting Mode (booting using CentOS 7 Installation CD) and from within the actual system (booted using super-grub2 disk).
I always get (from troubleshooting mode):
# grub2-install --root-directory=/mnt/sysimage/ /dev/vda Installing for i386-pc platform. grub2-install: error: unknown filesystem.
or (from within the OS):
# grub2-install /dev/vda Installing for i386-pc platform. grub2-install: error: unknown filesystem.
How can I fix that?
Nick _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
BTW: see also this paragraph in the provided RH EL link: 24.7.3. Resetting and Reinstalling GRUB 2
But i think is not your problem....
Also, after changing partitions flag does your fdisk command reflect the change? Is the error during boot the same as the one provided in your first e-mail?
One final thing. When I had to change boot settings, I made different steps in choot environment in respect of the indication inside the image you sent.
Specifically
Verify if your boot partition is already mounted under /mnt/sysimage/boot in your current environment If it is mounted on another mount point in your live env go and umount it and run mount /dev/vda1 /mnt/sysimage/boot
then chroot /mnt/sysimage
when you are in chrooted environment, probably you don't have special files for vda and vda1 because they are dinamically created; verify with
ls -l /dev/vda*
If this is the case, go and create them
mknod -m 660 /dev/vda b 253 0 mknod -m 660 /dev/vda1 b 253 1
at this point
grub2-install /dev/vda and let see the output of the command and its exit code
at this point exit chrooted environment (exit) umount /mnt/sysimage/boot
reboot and see if anything changes
HIH, Gianluca
On 5/5/2017 3:45 μμ, Gianluca Cecchi wrote:
BTW: see also this paragraph in the provided RH EL link: 24.7.3. Resetting and Reinstalling GRUB 2
But i think is not your problem....
Yes, I have done that, without change in behavior.
Also, after changing partitions flag does your fdisk command reflect the change?
Yes.
Is the error during boot the same as the one provided in your first e-mail?
Yes.
One final thing. When I had to change boot settings, I made different steps in choot environment in respect of the indication inside the image you sent.
Specifically
Verify if your boot partition is already mounted under /mnt/sysimage/boot in your current environment
Yes, it is:
sh-4.2# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/live-rw 2.0G 1.1G 930M 54% / devtmpfs 979M 0 979M 0% /dev tmpfs 1001M 4.0K 1001M 1% /dev/shm tmpfs 1001M 8.3M 993M 1% /run tmpfs 1001M 0 1001M 0% /sys/fs/cgroup /dev/sr0 680M 680M 0 100% /run/install/repo tmpfs 1001M 300K 1001M 1% /tmp /dev/mapper/centos-root 18G 1.5G 16G 9% /mnt/sysimage /dev/vdal 497M 192M 306M 39% /mnt/sysimage/boot /tmpfs 1001M 0 1001M 0% /mnt/sysimage/dev/shm
If it is mounted on another mount point in your live env go and umount it and run mount /dev/vda1 /mnt/sysimage/boot
Didn't need to.
then chroot /mnt/sysimage
OK, I did so:
sh-4.2# chroot /mnt/sysimage bash-4.2#
when you are in chrooted environment, probably you don't have special files for vda and vda1 because they are dinamically created; verify with
ls -l /dev/vda*
It seems I do have such files:
bash-4.2# ls -la /dev/vda* brw-rw----. 1 root disk 252, 0 May 5 16:49 vda brw-rw----. 1 root disk 252, 1 May 5 16:49 vdal brw-rw----. 1 root disk 252, 2 May 5 16:49 vda2
If this is the case, go and create them
mknod -m 660 /dev/vda b 253 0 mknod -m 660 /dev/vda1 b 253 1
Didn't need to.
at this point
grub2-install /dev/vda and let see the output of the command and its exit code
As usual:
bash-4.2# grub2-install /dev/vda Installing for i386-pc platform. grub2-install: error: unknown filesystem.
at this point exit chrooted environment (exit) umount /mnt/sysimage/boot
reboot and see if anything changes
Didn't do it, because grub2-install above failed, so nothing changed.
I am very puzzled with "unknown filesystem".
Thanks for your time and help! I am looking forward to reaching a solution!
All the best, Nick
On 5/5/2017 8:29 μμ, Nikolaos Milas wrote:
I am very puzzled with "unknown filesystem".
After more googling, I found this bug report with a very recent fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1399487
It seems to me that this may be relevant in our case.
If so, may it be that this fix has not been rolled out to CentOS repos yet?
What is your opinion and your advice/suggestion(s)?
Thanks, Nick
On Fri, May 5, 2017 at 2:46 PM, Nikolaos Milas nmilas@noa.gr wrote:
On 5/5/2017 8:29 μμ, Nikolaos Milas wrote:
I am very puzzled with "unknown filesystem".
After more googling, I found this bug report with a very recent fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1399487
It seems to me that this may be relevant in our case.
If so, may it be that this fix has not been rolled out to CentOS repos yet?
What is your opinion and your advice/suggestion(s)?
Yes, it's relevant, and the solution appears to be:
xfs_admin -U restore /dev/vdal
On 5/5/2017 9:10 μμ, Marcelo Roccasalva wrote:
xfs_admin -U restore /dev/vdal
Bingo!
I had to unmount the boot partition (being in Troubleshooting mode), run the above command, which provided a new UUID and at last the partition was recognized as xfs. (I forgot to copy the output to paste here.)
I then mounted the boot partition again, chrooted, grub2-install'ed successfully, exited and rebooted.
The VM started booting, seemingly well, but after some time it took me to emergency mode. ("Give root password for maintenance or type Ctrl-D to continue.")
I'll have to check that tomorrow... I need some sleep now (it's after midnight over here - in Athens, Greece).
[Perhaps I should have manually edited /etc/fstab as well to enter the new UUID?]
Anyway, that was a good progress! Thanks for your great cooperation.
I'll keep you updated. Cheers, Nick
On 6/5/2017 12:20 πμ, Nikolaos Milas wrote:
[Perhaps I should have manually edited /etc/fstab as well to enter the new UUID?]
Yes, that was it!
The VM booted fine after /etc/fstab update!
Case closed. It was a tricky one!
Thank you all for your feedback and kind assistance!
Cheers, Nick
On 6/5/2017 12:09 μμ, Nikolaos Milas wrote:
The VM booted fine after /etc/fstab update!
I did another test, which was also successful.
Below follows the output from the process (after booting in troubleshooting mode using the CentOS 7 media disk):
1) Continue
2) Read-only mount
3) Skip to shell
4) Quit (Reboot)
Please make a selection from the above: 1 ======================================================= ======================================================= Rescue Mount
Your system has been mounted under /mmt/sysimage.
If you would like to make your system the root environment, run the command:
chroot /mnt/sysimage Please press <return> to get a shell. When finished, please exit from the shell and your system will reboot. sh-4.2# umount /dev/vda1 sh-4.2# xfs_admin -U restore /dev/vda1 Clearing log and setting UUID writing all SBs new UUID = b05227b2-7c86-4ccf-81ff-204a9a80f789 sh-4.2# mount /dev/vda1 /mmt/sysimage/boot sh-4.2# chroot /mnt/sysimage bash-4.2# grub2-install /dev/vda Installing for i386-pc platform. Installation finished. No error reported. bash-4.2# nano /etc/fstab bash-4.2# exit sh-4.2#
Note also that after logging into the (finally bootable) OS, we should follow the directions: "Resetting and Reinstalling GRUB 2".
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Best regards, Nick
On Fri, May 5, 2017 at 7:46 PM, Nikolaos Milas nmilas@noa.gr wrote:
On 5/5/2017 8:29 μμ, Nikolaos Milas wrote:
I am very puzzled with "unknown filesystem".
After more googling, I found this bug report with a very recent fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1399487
It seems to me that this may be relevant in our case.
If so, may it be that this fix has not been rolled out to CentOS repos yet?
What is your opinion and your advice/suggestion(s)?
Thanks,
Nick
Ah... I never used xfs for /boot. Also on CentOS 7 I tipically format it with ext4.
Marcelo Roccasalva wrote:
On Wed, May 3, 2017 at 4:55 PM, Nikolaos Milas nmilas@noa.gr wrote:
On 3/5/2017 10:41 μμ, Marcelo Roccasalva wrote:
Does the UUID of root filesystem in /etc/fstab match the actual UUID as reported by blkid? And remove/etc/lvm/cache/.cache if it exists
The directory /etc/lvm/cache/ is empty.
Dumb question: the file starts with a dot, doesn't show up in "ls" without "-a".
<snip>
It shouldn't. Std. *Nix "hidden file".
mark
On 3/5/2017 5:24 μμ, Nikolaos Milas wrote:
Using the supergrub2 disk I can boot and login successfully. Otherwise (i.e. directly) the box won't boot.
In the meantime, I also tried rescatux (https://sourceforge.net/projects/rescatux/) repair disk; it failed as well. The situation remains the same.
How can we fix this cloned CentOS 7 installation to become bootable?
Please advise!
Thanks, Nick
-
Barry Brimer -
Bernard Lheureux -
Gianluca Cecchi -
m.roth＠5-cent.us -
Marcelo Roccasalva -
Nikolaos Milas