Tag Archives: rhel

Tip: Edit grub kernel command line in RHEL 7 or CentOS 7

Easy with virt-customize. In this example I’m adding the nosmt option to the command line:

$ virt-customize -a rhel7.img \
    --edit '/etc/default/grub:
      s/^GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="nosmt /' \
    --run-command 'grub2-mkconfig -o /boot/grub2/grub.cfg'

Leave a comment

Filed under Uncategorized

libguestfs for RHEL 7.5 preview

As usual I’ve placed the proposed RHEL 7.5 libguestfs packages in a public repository so you can try them out.

Thanks to Pino Toscano for doing the packaging work.

Leave a comment

Filed under Uncategorized

Gigabyte Cavium ARM servers

http://b2b.gigabyte.com/products/list.aspx?s=92&p=190&v=1029&ck=102

Gigabyte just announced a bunch of full ARM servers, with between 32 and 96 cores. They are based around the Cavium ThunderX processors that we’ve had at Red Hat for a while so they should run RHEL either out of the box or very soon after release.

Leave a comment

Filed under Uncategorized

Gigabyte MP30-AR0: IPMI

IPMI works out of the box. I’m using FreeIPMI to test this (not ipmitool) since FreeIPMI is a lot easier to use.

You need to know that:

  1. The default user name is admin and the default password is password.
  2. You have to use the dedicated management interface, marked “f” in the software reference guide (the ethernet port above the two USB sockets).

Here are the sensors:

$ ipmi-sensors -h 192.168.0.104 -u admin -p password
Caching SDR repository information: /home/rjones/.freeipmi/sdr-cache/sdr-cache-moo.192.168.0.104
Caching SDR record 34 of 34 (current record ID 205) 
ID  | Name       | Type                   | Reading    | Units | Event
4   | CPU0_TEMP  | Temperature            | 49.00      | C     | 'OK'
9   | DIMM_P0_A0 | Temperature            | N/A        | C     | N/A
10  | DIMM_P0_A1 | Temperature            | N/A        | C     | N/A
12  | DIMM_P0_B0 | Temperature            | N/A        | C     | N/A
13  | DIMM_P0_B1 | Temperature            | N/A        | C     | N/A
15  | DIMM_P0_C0 | Temperature            | N/A        | C     | N/A
16  | DIMM_P0_C1 | Temperature            | N/A        | C     | N/A
18  | DIMM_P0_D0 | Temperature            | N/A        | C     | N/A
19  | DIMM_P0_D1 | Temperature            | N/A        | C     | N/A
59  | P12V       | Voltage                | 11.83      | V     | 'OK'
60  | P5V        | Voltage                | 5.11       | V     | 'OK'
61  | P3V3       | Voltage                | 3.33       | V     | 'OK'
62  | P5V_STBY   | Voltage                | 5.13       | V     | 'OK'
64  | P_VBAT     | Voltage                | 3.07       | V     | 'OK'
65  | P_VCCP     | Voltage                | 0.97       | V     | 'OK'
66  | P_1V2_HUB  | Voltage                | 1.20       | V     | 'OK'
67  | P_VDDQ_AB  | Voltage                | 1.50       | V     | 'OK'
68  | P_VDDQ_CD  | Voltage                | 1.50       | V     | 'OK'
71  | P_0V9_VDD  | Voltage                | 0.96       | V     | 'OK'
72  | P_1V5_VDD  | Voltage                | 1.52       | V     | 'OK'
73  | P_2V5_VDD  | Voltage                | 2.50       | V     | 'OK'
74  | P_1V8_VDD  | Voltage                | 1.82       | V     | 'OK'
136 | CPU0_FAN   | Fan                    | 4000.00    | RPM   | 'OK'
138 | SYS_FAN1   | Fan                    | N/A        | RPM   | N/A
139 | SYS_FAN2   | Fan                    | N/A        | RPM   | N/A
140 | SYS_FAN3   | Fan                    | N/A        | RPM   | N/A
141 | SYS_FAN4   | Fan                    | N/A        | RPM   | N/A
190 | CPU0       | Processor              | N/A        | N/A   | 'Processor Presence detected'
202 | MB_TEMP1   | Temperature            | 37.00      | C     | 'OK'
203 | MB_TEMP2   | Temperature            | 31.00      | C     | 'OK'
204 | MB_TEMP3   | Temperature            | 28.00      | C     | 'OK'
205 | SEL        | Event Logging Disabled | N/A        | N/A   | 'OK'

Continue reading

Leave a comment

Filed under Uncategorized

Gigabyte MP30-AR0: RHEL running with ACPI

Turns out that acpi=off is only needed by the RHEL 7.2 installer kernel. After installation, ACPI works fine. That might be because the installer kernel is older than the current RHEL 7 kernel. dmesg output after the break.

Continue reading

2 Comments

Filed under Uncategorized

Gigabyte MP30-AR0: RHEL is running

dmesg and other stuff after the break.

Continue reading

7 Comments

Filed under Uncategorized

Gigabyte MP30-AR0

This is the Gigabyte MP30-AR0 which now forms the top “layer” of my cluster (I had to retire one of the AMD boards in order to scavenge the RAM for this).

20160304_141928.jpg

The Gigabyte uses the APM X-gene1, which is an 8 core ARM processor. This is rather old now — I’ve had a Mustang at home with the same processor for a couple of years now and the chip design itself is 3+ years old. It uses Cortex A53 cores. Even APM have a newer X-gene 2. Nevertheless it has two very big advantages over the alternatives:

  1. You can actually buy it. I had this one shipped overnight from UK supplier Xcase.
  2. It’s (sort of — see below) server class hardware, unlike the very cheap but ultimately crap development boards based on phone chips.

A particularly annoying thing at the moment is that Gigabyte are claiming this board is SBSA compliant, but then they ship it with u-boot as firmware. However UEFI firmware can be downloaded, see this thread, so it should run RHEL.

Here are the boot messages to the u-boot prompt:

U-Boot 2013.04 (Jun 02 2015 - 10:54:10)         REV: 1.15.01-F05 ( uart0 )

CPU0: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
     32 KB ICACHE, 32 KB DCACHE
     SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
Boot from SPI-NOR
Slimpro FW:
        Ver: 2.4 (build 01.15.01.00 2015/05/22)
        TPC: disabled
        AVS: supported (margin: -0mV)
        RST: supported
        PWROFF: supported
        PMD: 970 mV
        SOC: 950 mV
Board: GIGABYTE MP30AR0 - AppliedMicro APM883408-xNA24SPT Customer Board
I2C:   ready

DRAM: 32 GiB @ 1600MHz...
SF: Detected MX25L25635F with page size 64 KiB, total 32 MiB

MMC:   X-Gene SD/SDIO/eMMC: 0
PCIE0: (RC) link down
PCIE2: (RC) X1 GEN-1 link up
PCIE3: (RC) link down
  00:00.0     - 10e8:e004 - Bridge device
   01:00.0    - 1a03:1150 - Bridge device
    02:00.0   - 1a03:2000 - Display controller
Video: ASPEED VGA Card (1a03, 2000) found @(2:0:0)
Mode: 1024x768x32 48kHz 60Hz
In:    serial
Out:   vga
Err:   serial
CPUs:  11111111
Net:   eth0
USB0:   scanning bus 0 for devices... XHCI: WARN: Didn't find a matching TT
3 USB Device(s) found
USB1:   scanning bus 1 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
XHCI: ep 0x1 - rounding interval to 128 microframes
XHCI-ERR: xhci_submit_async_int !
Register 1 keyboards
Hit any key to stop autoboot:  0 

15 Comments

Filed under Uncategorized

Tip: Updating RHEL 7.1 cloud images using virt-customize and subscription-manager

Red Hat provide RHEL KVM guest and cloud images. At time of writing, the last one was built in Feb 2015, and so undoubtedly contains packages which are out of date or insecure.

You can use virt-customize to update the packages in the cloud image. This requires the libguestfs subscription-manager feature which will only be available in RHEL 7.3, but see here for RHEL 7.3 preview packages. Alternatively you can use Fedora ≥ 22.

$ virt-customize \
  -a rhel-guest-image-7.1-20150224.0.x86_64.qcow2 \
  --sm-credentials 'USERNAME:password:PASSWORD' \
  --sm-register --sm-attach auto \
  --update
[   0.0] Examining the guest ...
[  17.2] Setting a random seed
[  17.2] Registering with subscription-manager
[  28.8] Attaching to compatible subscriptions
[  61.3] Updating core packages
[ 976.8] Finishing off
  1. You should probably use --sm-credentials USERNAME:file:FILENAME to specify your password using a file, rather than having it exposed on the command line.
  2. The command above will leave the image template registered to RHN. To unregister it, add --sm-unregister at the end.

3 Comments

Filed under Uncategorized

How to rebuild libguestfs from source on RHEL or CentOS 7

Three people have asked me about this, so here goes. You will need a RHEL or CentOS 7.1 machine (perhaps a VM), and you may need to grab extra packages from this preview repository. The preview repo will go away when we release 7.2, but then again 7.2 should contain all the packages you need.

You’ll need to install rpm-build. You could also install mock (from EPEL), but in fact you don’t need mock to build libguestfs and it may be easier and faster without.

Please don’t build libguestfs as root. It’s not necessary to build (any) packages as root, and can even be dangerous.

Grab the source RPM. The latest at time of writing is libguestfs-1.28.1-1.55.el7.src.rpm. When 7.2 comes out, you’ll be able to get the source RPM using this command:

yumdownloader --source libguestfs

I find it helpful to build RPMs in my home directory, and also to disable the libguestfs tests. To do that, I have a ~/.rpmmacros file that contains:

%_topdir	%(echo $HOME)/rpmbuild
%_smp_mflags	-j5
%libguestfs_runtests   0

You may wish to adjust %_smp_mflags. A good value to choose is 1 + the number of cores on your machine.

I’ll assume at this point that the reason you want to rebuild libguestfs is to apply a patch (otherwise why aren’t you using the binaries we supply?), so first let’s unpack the source tree. Note I am running this command as non-root:

rpm -i libguestfs-1.28.1-1.55.el7.src.rpm

If you set up ~/.rpmmacros as above then the sources should be unpacked under ~/rpmbuild/SPECS and ~/rpmbuild/SOURCES.

Take a look at least at the libguestfs.spec file. You may wish to modify it now to add any patches you need (add the patch files to the SOURCES/ subdirectory). You might also want to modify the Release: tag so that your package doesn’t conflict with the official package.

You might also need to install build dependencies. This command should be run as root since it needs to install packages, and also note that you may need packages from the repo linked above.

yum-builddep libguestfs.spec

Now you can rebuild libguestfs (non-root!):

rpmbuild -ba libguestfs.spec

With the tests disabled, on decent hardware, that should take about 10 minutes.

The final binary packages will end up in ~/rpmbuild/RPMS/ and can be installed as normal:

yum localupdate x86_64/*.rpm noarch/*.rpm

You might see errors during the build phase. If they aren’t fatal, you can ignore them, but if the build fails then post the complete log to our mailing list (you don’t need to subscribe) so we can help you out.

8 Comments

Filed under Uncategorized

Odd/scary RHEL 5 bug

Yesterday my colleague gave me a RHEL 5 VM disk image which failed to boot after converting it using the latest virt-v2v.  Because it booted before conversion but not afterwards, the fingers naturally pointed at something that we were doing during the conversion process. Which is not unusual as v2v conversion is highly complex.

Screenshot_xen-pv-rhel5.8-x86_64
The “GRUB _” prompt after conversion

The thing is that we don’t reinstall grub during conversion, but we do edit a few grub configuration files. Could editing grub configuration cause this error?

I wanted to understand what the grub-legacy “GRUB _” prompt means. There are lots and lots and lots of people reporting this bug (eg), but as is often the case I could find no coherent explanation anywhere of what grub-legacy means when it gets into this state. Lots of the blind leading the blind, and random suggestions about how people had rescued such machines (probably coincidentally), but no hard data anywhere. So I had to go back to first principles and debug qemu to find out what’s happening just before the message is printed.

Tip: To breakpoint qemu when the Master Boot Record (first sector) is loaded, do:

target remote tcp::1234
set architecture i8086
b *0x7c00
cont

After an evening of debugging, I found that it’s the first sector (known in grub-legacy as “stage 1”) which prints the GRUB<space> message. (The same happens to be true of grub2). The stage 1 boot sector has, written into it at a fixed offset, the location of the /boot/grub/stage2 file, ie. the literal disk start sector and length of this file. It sends BIOS int $0x13 commands to load those sectors into memory at address 0x8000, and jumps there to start the stage 2 of grub. The boot sector is 512 bytes, so there’s no luxury to do anything except print 5 characters. It’s after the stage2 file has been loaded when all the nice graphical stuff happens.

Unfortunately in the image after conversion, the stage2 data loaded into memory was all zeroes, and that’s why the boot fails and you see GRUB<space><cursor> and then the VM crashes.

The mystery was how conversion could be changing the location of the /boot/grub/stage2 file so that it could no longer be loaded at the fixed offset encoded in the boot sector.

This morning it dawned on me what was really happening …

The new virt-v2v tries very hard to avoid copying any unused data from the guest, just to save time. No point wasting time copying deleted files and empty space. This makes virt-v2v very fast, but it has an unusual side-effect: If a file is deleted on the source, the contents of the file are not copied over to the target, and turn into zeroes.

It turns out if you take the source disk image and simply zero all of the empty space in /boot, then the source doesn’t boot either, even though virt-v2v is not involved. Yikes … this could be a bug in RHEL 5. Grub is generating a bootloader that references a deleted file.

This is where we are right now with this bug. It appears that a valid sequence of steps can make a RHEL 5 bootloader that references a deleted file, but still works as long as you never overwrite the sectors used by that file.

I have written a simple test script that you can download to find out if your RHEL ≤ 6 virtual machines could be affected by this problem. I’m interested if anyone else sees this. I ran the test over a selection of RHEL 3 – 5 guests, and could not find any which had the problem, but my collection is not very extensive, and there are likely to be common modes in how they were created.

The next steps will likely be to test a lot more RHEL 5 installs to see if this bug is really common or a strange one-off. I will also probably add a workaround to virt-v2v so it doesn’t trim the boot partition — the reason is that we cannot go back and fix old RHEL 5 installs, we have to work with them if they are broken. If it turns out to be a real bug in RHEL 5 then we will need to issue a fix for that.

3 Comments

Filed under Uncategorized