Reverting UEFI boot to MBR boot for CentOS/Redhat 6 on the HP z230

Why would you want to do this? In my case it is because the HP z230 workstation I am maintaining has two disks in software RAID1 and while /boot can be on a RAID1 array, and the boot loader can be installed in the MBR of both disks, so that boot can continue even if one disk fails, UEFI doesn't (as far as I know) provide this redundancy. If you know different, please write that up.

I had already configured UEFI boot on the workstation. This is what I had to do to change to MBR boot when I discovered that UEFI doesn't provide redundancy.

First do all the required kernel updates and check that UEFI boot works.

Then copy the contents of /usr/share/grub/x86_64-redhat to /boot/grub. The OS installer doesn't install the grub helper files when it detects that UEFI boot is active.

Next copy /boot/efi/EFI/redhat/grub.conf to /boot/grub. This is the reason for doing the kernel updates first so that grub.conf is up to date.

Shutdown and go into the BIOS and disable UEFI so the boot method is Legacy MBR.

Boot with the CentOS install DVD and select rescue mode. You'll need to let the rescue OS mount the root filesystem on /mnt/sysimage so that you can run grub-install. Get a shell and do chroot /mnt/sysimage, then run grub-install /dev/sda and grub-install /dev/sdb to install the boot loader on both disks.

Reboot and remove the DVD before startup. Now GRUB should boot from the hard disk. It also wanted to do a selinux relabel so plan for some downtime in case this happens.

Addendum 2016-11-10: Also ensure that /etc/grub.conf is a symlink to ../../boot/grub/grub.conf and not to the one in the EFI boot partition, otherwise kernel package updates will update the wrong grub.conf.

The instructions are for the HP z230 but may be applicable to your workstation. This assumes that your BIOS supports the legacy MBR boot method in addition to UEFI.

Adventures with USB to SATA/PATA bridges

If you have a spare SATA hard drive or DVD burner, or a PATA DVD burner lying around, you may be tempted, like me, to connect it to your computer using a USB adaptor, to function as an outboard drive, using one of the many identical adaptors you can buy on eBay for a few dollars. You will need an external power supply of course, and I'm assuming you have one lying around too. All these experiments were done on a Raspberry Pi 2.

The first one I bought looked like this. It also came with a SATA cable and a Molex to SATA power adapter cable. Note the there are two PATA interfaces, one for 3.5 inch HDs and DVDs and one for 2.5 inch HDs on opposite sides. For the 2.5 inch HDs no power supply is needed, as the power comes from USB.

The lsusb command shows that this uses the JMicron 20337 chip:

ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge

There are a couple of quirks with it. The first is that the chip will not be detected unless the HD/DVD side is plugged in and powered up. The other is that the 40 pin (3.5 inch) PATA side can be plugged into the HD/DVD offset by one pin if you are not careful, because the plug is slightly narrower than the socket, and the key is also a bit smaller than the slot. The second is that the Molex power connector may jam against the PATA connector. In fact this is a cause of accidental offset if you plug the Molex connector in first. The problem is a wing on the connector near the wire end that makes it take up more room. I snipped off one wing with cutters.

Using this adaptor with a DVD burner was fine, the drive appeared as /dev/sr0, and I was able to use brasero to burn optical media. However experience with 3.5 inch SATA HDs was unsatisfactory. If data rates are too fast, the chip is apt to disconnect and then the Linux driver tries to reset the USB interface but this never works. It seemed to work ok with 2.5 inch laptop PATA drives. The disk appears as /dev/sda, as the SD card drive is /dev/mm-something.

I bought a second USB adaptor, this time only for SATA devices. This one came as a rather fat USB dongle with SATA and e-SATA sockets on the side. You may have to use a hub if it blocks other USB sockets on your computer from being used. The lsusb command shows that this uses the JMicron 20329 chip.

ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge

There is an intriguing message in the system log:

Quirks match for vid 152d pid 2329: 8020

I haven't looked at the driver source, but the message seems to suggest that the driver copes with this one better. When I used it with a SATA HD, there were no disconnects and resets. So this is the one I will use to interface to the HD, using the 20337 only for the DVD drive.

You may see USB adapters that plug directly onto the back of the drive. Those are for 2.5 inch drives only as the power comes from USB.

All the devices mentioned here are USB 2.0. USB 3.0 adapters are available, and only worth it for SATA HDs, but I don't have a great need for speed so I'll let them get cheaper before I buy one.

How to display Korean characters on openSUSE Leap 42.1

If you do a web search for this you will find a confusing amount of information for various distros. Some of it will relate to Korean keyboard input. At the moment I just want to display Korean characters instead of a square box with the Unicode; input comes later.

It turns out that the openSUSE developers have made it really easy. Here is the Reddit post that solved my problem: Korean fonts in openSUSE

There isn't much I can add to this solution except to mention that it installed a whole bunch of packages to cater for input methods (several, which I intend to explore later), KDE, Mozilla (Firefox and Thunderbird), Libreoffice, and even GIMP. So all those subsystems are sorted out in one fell swoop.

The other thing I want to mention is that other languages can be added to the secondary support list in YaST so presumably this solution will work for those.

I'm sorry if this doesn't help you with other distros. Hopefully your distro implemented a comprehensive solution in the configuration tool. Try that before you delve too deeply into the system.

"$@" is a shell idiom

TL;DR: Use "$@" when you want to pass arguments unchanged to a function or program.

When you read the shell documentation you will see that there are two main ways to refer to all the arguments for passing to a function or program: $* and "$@". What is the difference? This test script will demonstrate it:

#!/bin/sh

testargs() {
       echo testargs: $# arguments

       showargs $*
       showargs "$@"
}

showargs() {
       echo showargs: $# arguments
       for i
       do
               echo $i
       done
}

testargs 1 2 3
testargs word 'quoted phrase' word

The result should be:

testargs: 3 arguments
showargs: 3 arguments
1
2
3
showargs: 3 arguments
1
2
3
testargs: 3 arguments
showargs: 4 arguments
word
quoted
phrase
word
showargs: 3 arguments
word
quoted phrase
word

As you can see, the difference is manifest when an argument has whitespace. "$@" preserves the arguments, not parsing it again to break up at whitespace in arguments. Think if it as an idiom meaning pass arguments verbatim.

Why would you ever use $* though? Here's a place where you shouldn't use "$@".

su -c "$*" user

If you were to use "$@" and it contained multiple arguments, only the first argument would be used by -c and the others would follow, causing a syntax error. This however means that if you want to pass arguments with whitespace to -c, you have to quote them and escape the quotes too.

Installing Linuxmint 18 on RAID 1

TL;DR: Can't be done easily.

I had a PC with dual disks that I was running under openSUSE Leap 42.1 in RAID 1. I wanted to install Linuxmint 18 on it before giving it away.

First problem I encountered was that the partitioner in the installer knows nothing about RAID.

After some reading I found that the solution is to use gparted to create the RAID partitions first. But gparted didn't know how to do this. I figured out that the mdadm tool was missing, so I did:

apt-get install mdadm

Note that this installs to RAM as it's a live filesystem so needs to be redone if the install is restarted. Also there are some post-install script errors but mdadm gets installed.

Now with gparted I could create the RAID partitions and assemble them. Alternatively it can be done from the command line:

mdadm --assemble --scan

Now md0 and md1 appeared on the list of "disks" in the partitioner and I could assign them to / and /home.

The system installation went fine until it was time to install GRUB. It failed when it couldn't do

grub-install /dev/sdb /dev/sda

Changing the target to just /dev/sda and clicking Continue did nothing. This seems to be an installer bug.

So I did this from the command line:

mount /dev/md0 /mnt
grub-install --root-directory=/mnt /dev/sda
umount /mnt

When I rebooted from disk it stopped at the GRUB prompt. So I tried to boot manually.

grub> linux /boot/vmlin.... --root=/dev/md0
grub> initrd /boot/initrd...
grub> boot

The ... are where you should use TAB completion to select the kernel and initramfs images respectively. Unfortunately this failed when systemd tried to mount the root partition. The reason is that the raid modules are not present in the stock initramfs file. This was built by the Linuxmint 18 distributors.

At this point I gave up. Obviously Linuxmint 18 isn't designed to support this kind of RAID installation. If you want to go further you should rebuild the initramfs with the RAID modules included. Do let us know if you overcome this next hurdle.

And remember if you get it to work, you should install the mdadm package permanently, as it's not part of the default package set.