openSUSE 12.2 with GRUB2 with entire root partition in LVM

It took me a long evening to figure it out how to do it, but it is possible to install an openSUSE 12.2 with GRUB2 on a disk with GTP partition table and have the entire root partition within LVM (and in my case even have the LVM in a MD RAID). The current openSUSE installer (partitioning and bootloader) does not fully support this use case, but they will however install it correctly even though the warning messages shown might be misleading.

These are my partitions (adapt them to your use case):

  • sda (GPT partition table: gpt_sync_mbr)
    1. 7.84 MB primary, flags: bios_grub (do not format or mount)
    2. 8 GB primary, flags: raid (raid1, md0), swap
    3. ? GB primary, flags: raid (raid1, md1), LVM
  • sdb (same as sda)
    • Note: the first partition of both disks is not part of any raid. The sda1 partition has to be synced manually once after installation to its pendant on sdb.

The first partition has to be unformatted and unmounted and have the flag bios_grub set. This can be done with parted by running (for both disks):

(parted) toggle 1 bios_grub on
(parted) select /dev/sdb
(parted) toggle 1 bios_grub on

This will allow GRUB2 to find space to install its core.img to.

There is more than one way to do this kind of installation. But with YaST you can not (yet) create set the bios_grub flag during installation. Here are two ways which should work pretty nicely (I took the latter):

  1. Prepare the partition setup before booting the installation media. Make sure to have all partitions setup correctly (including the flags you need). There is no need to create the RAID and LVM beforehand – of course you could, but this is something where YaST has a pretty nice and intuitive graphical UI for. During the installation also make sure that YaST uses the existing partition setup. The default is to propose an own partition setup.
  2. Start the installation with the plain and empty disks. Do the partitioning via YaST (make sure to use a GTP partition table; see the export button within the YaST partitioner). Let the system do the installation and ignore the warnings that are shown. While the installation process is installing the packages do this:
    1. Press Ctrl+Alt+Shift+X to open an xterm
    2. In the xterm run parted and set the flags for the first partitions of each disk
    3. If you finish this before YaST installs the bootloader everything work smoothly
      If you do not manage to do this before the YaST installs the bootloader it will popup an error message with warnings that your setup is totally unsupported and will not be able to boot. Just ignore the warning, but to not yet press the OK button. Continue to toggle the flags in the xterm and close parted. When done, press the OK button of the warning message and YaST will try again to install the bootloader and now will succeed without any error message.

The bootloader will only be installed on /dev/sda by default. So after the first boot sync the content of the first partition of sda to the first one on sdb (e.g. using dd).

openSUSE 11.2

openSUSE 11.2 is now available

OpenSUSE_11.2_468x60Are you new to linux and want to learn about it or have never used it before? Then now its your turn to download openSUSE 11.2 and give it a try. Besides the installation DVD images you can also download LiveCD images to run linux on your computer without installation – the harddisk will not be touched. Find more information in the openSUSE wiki about whats new in this release.

Hacking a Seagate hard disk

I will document here how to hack a Seagate hard disk that ran into one of these annoying firmware bugs that affected the Seagate Barracuda 7200.11 series lately. If you want to know more about the background you may want to start with the first part of the story.

The friend who brought me the disk kindly came by the next day to help with the operation. According to the recipes I found here and here, we had to connect the hard drives service port to a serial console via a RS232-TTL converter. My friend prepared the RS232-TTL converter, brought a stable power supply as we needed 5V to operate. My task was to prepare the operating table, find a serial cable and a computer with a serial port, a two-pin-connector with wires and to get to know minicom.

So and here is how we did it:

RS232-TTL converter
RS232-TTL converter

First we connected the converter to the devices. The docking station of my notebook has a serial port, so I connected it via a serial cable to the converter. The three wires coming from the converter had to be connected the hard drive directly. We fixed the ground wire with a screw of the board. The Rx and Tx connectors had to be connected to the Tx and Rx connectors of the drive (so just cross them). Thats where we used the two-pin-connector. On the drive the pin next to the SATA connector is the Rx and next to this one is Tx. The other two are reserved and we did not need them.


The most tricky part was about to be next. We had to interrupt the power supply for the motor of the platters but keep everything else connected properly. And it must be possible to remove this interruption during the operation. We unscrew all screws a little and pushed a piece of paper between the contacts of the board and the connector, and fastened the screws just a bit.


So much for the preparation. Let’s start. Here is my minicomrc I used to communicate with the drives firmware:

$ cat minirc.seagateBug
# Machine-generated file - use "minicom -s" to change parameters.
pu port             /dev/ttyS0
pu baudrate         38400
pu bits             8
pu parity           N
pu stopbits         1

Now we connected the the SATA power cable to the drive and let minicom establish the serial connection. And really, I got first contact with the drive:

img_6584Even the error codes the drive dumped to the screen were correct according to the recipe. So we were on the right track. Now it was just about to properly retype the commands into minicom and patiently wait for the drive to complete the commands. Here is a screenshot with some comments in it.

Hacking the firmware (commented)
Hacking the firmware (commented)

Then finally we were done. But we did not repair the drive, but only reactivated it. Now it can run into the same bug again any time (but only on startup, so we would notice). So we tried to prevent as many restarts as we could. The first thing I did was connect it to an external SATA-2-firewire case and use the first startup of the disk to backup all important data. The second thing I did was connect the drive to the onboard connectors of my workstation and boot from the firmware upgrade CD I downloaded from the Seagate website the day before and deployed the new firmware to finally get rid of the bug.

In the end the disk felt quite well back in its original machine. Fortunately we had nothing more to fix within the installed system (yes, it was the other operating system).

Btw. the commands we sent to the drive took serveral seconds each to process, so we had to wait for for them to finish. Disconnecting power too early would have broken the disk. Thats why I connected all vital systems to my UPS for this hack. If you happen to have such a Seagate drive, my deepest regrets to you and good luck for your recovery hack.