Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import_precheck fails on CentOS 7 #1736

Open
charlesomer opened this issue Aug 26, 2021 · 2 comments
Open

import_precheck fails on CentOS 7 #1736

charlesomer opened this issue Aug 26, 2021 · 2 comments
Assignees

Comments

@charlesomer
Copy link

charlesomer commented Aug 26, 2021

Fails since lsblk on CentOS 7 is version 2.23.2 which I believe is quite old and doesn't support --json.

* WARN: Failed to execute lsblk: lsblk: exit status 1, stderr: lsblk: unrecognized option '--json'

Works fine on CentOS 8 which uses lsblk version 2.32.1

@charlesomer charlesomer changed the title import_precheck fails on CentOS 7 import_precheck fails on CentOS 7 Aug 26, 2021
@ak89224
Copy link

ak89224 commented Aug 26, 2021

Hey,
Faced the same issue today only,
Centos-7 don't have support for the latest util-linux package, you can check the centos mirror index here http://mirror.centos.org/centos/7/os/x86_64/Packages/
and the central package index for linux/unix as well here https://pkgs.org/download/util-linux

Although as a workaround I'm doing the pre-checks manually, its just check for the root device disk to be mounted at '/' by allMounts.listPhysicalDevicesForMount("/") listing all the physical devices and set the root device on which mount path '/' is available which you can check using lsblk -a . In my case rootDevice is sda

[root@localhost ~]# lsblk -a
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   20G  0 disk
├─sda1   8:1    0  524M  0 part /boot
└─sda2   8:2    0 19.5G  0 part /
sdb      8:16   0   16G  0 disk
└─sdb1   8:17   0   16G  0 part [SWAP]
sdc      8:32   0  250G  0 disk
└─sdc1   8:33   0  250G  0 part /data
sdd      8:48   0   20G  0 disk
├─sdd1   8:49   0  524M  0 part
└─sdd2   8:50   0 19.5G  0 part
sde      8:64   0   20G  0 disk
└─sde1   8:65   0   20G  0 part /var/log

Other check it does that if there are multiple mount paths except '/' then they all should belong to some physical drive (which is obvious) and the physical device is other than the rootDevice (in my case sda) then these mount paths will be omitted from image import. and same is case if same mount path is mounted to multiple devices. So, in my case only '/' and '/boot' mount path will be there and rest will be omitted (excluded) from import. (WIP: Will update if it creates some issues)
Note : In this 2nd check it'll only give you warnings.

And the last check it performs for the MBR partition type. All the partition on all the disk should be of MBR.
You can use parted -l to determine the type of partition table. Eg:

[root@localhost ~]# sudo parted -l
Model: VBOX HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  551MB   549MB   primary  xfs          boot
 2      551MB   21.5GB  20.9GB  primary  xfs


Model: VBOX HARDDISK (scsi)
Disk /dev/sdb: 17.2GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  17.2GB  17.2GB  primary  linux-swap(v1)


Model: VBOX HARDDISK (scsi)
Disk /dev/sdc: 268GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  268GB  268GB  primary  xfs


Model: VBOX HARDDISK (scsi)
Disk /dev/sdd: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  551MB   549MB   primary  xfs
 2      551MB   21.5GB  20.9GB  primary  xfs


Model: VBOX HARDDISK (scsi)
Disk /dev/sde: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  21.5GB  21.5GB  primary  xfs

The Partition Table field shows that I am using a msdos MBR partition table (the one still commonly used for Linux and Windows) on both disks. From the man page parted can create (and thus hopefully identify) the following types of partition table (or more broadly `disk label'):

bsd
dvh
gpt    - this is a GPT partition table
loop   - this is raw disk access without a partition table
mac
msdos  - this is a standard MBR partition table
pc98
sun
Update

The command for listing a single partition if there are multiple drives. For /dev/sda you would do:

parted /dev/sda print

For these checks see the src code : here

--------------Updated------------

Based on a community thread in order to import your VM Instance; You must meet these necessary requirements for the Source VM instance and the OVF file in order to import your instance to GCP:

Source VM requirements:

  1. The following requirements must be met by the VM that is used to create the OVF file:

    • Virtual disks must be in VMDK or VHD formats.
    • Virtual disks must be configured with MBR boot. UEFI is not supported.
    • Virtual disks must not be encrypted.
    • To verify that your VM meets the requirements, you can run the pre-check tool as it can provided useful information when debugging any issues you may encounter.
  2. The operating system for the source VM should meet the following requirements:

    • For all Windows operating systems, PowerShell version 3 or later must be installed. PowerShell versions earlier than 3.0 can cause issues with the startup and shutdown scripts used during the import process.
    • For all Linux distributions, the boot disk must have GRUB installed.

OVF file requirements:

  1. The following requirements must be met by the OVF file:

    • The OVF files must provide Level 1 portability as described in the OVF specification document. Virtual appliances that meet Level 2 portability can be imported, but any custom extensions such as source hypervisor-specific details are ignored during the import process.
    • The OVF file must contain only one VM. If more than one VM is present, only the first VM is imported.
    • The first disk in the OVF file must be bootable.

Hope this helps :) !

@EricEdens
Copy link
Contributor

Thanks for the report; we'll take a look!

EricEdens added a commit that referenced this issue Sep 2, 2021
This refactors `cli_tools/import_precheck` to achieve the following:

1. Move implementation to a different package than `main`, to allow gomock to be used.
2. Add comments and documentation
3. Change the copyright formatting to match the rest of  `compute-image-tools`

This works toward fixing #1736
EricEdens added a commit that referenced this issue Sep 17, 2021
Prior to this PR, the system's block device hierarchy was fetched using lsblk --json. This caused errors in systems that did not support this flag for lsblk, eg #1736.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants