Installation on Thinkpad T530 without UEFI

Orim · 2013-09-24 11:32:04

Hey there,

I got a new Laptop at work, and I'm trying to install Archlinux on that.
The entire installation procedure works without problems but I can't get grub to actually boot anything.

Some details:
I've removed all Win8 partitions as I'm not using Windows anyway.
I disabled UEFI Secure Boot in the BIOS.
I'm using the non-uefi usb drive to install Arch, so I do know that I can boot from non-uefi drives.
I've set up a LVM with a root, home and boot partition. So I do need grub2 to boot from inside the lvm.

I've followed the wiki on installing grub into the MBR https://wiki.archlinux.org/index.php/GR … ode_region
But when I call

grub-install --recheck /dev/sda

I get a ton of error messages like this:

WARNING: Failed to connect to lvmetad: No such file or directory. Falling back to normal scanning.
/run/lvm/lvmetad.socket: connect failed: No such file or directory.

This is repeated over and over again.

The last error then is this:

EFI distributor id isn't specified.

It seems to want to install the UEFI stuff after all, doesn't it?
Why? And how can I tell grub to not do that?
Or is it something else?

But It does actually create a /boot/grub directory and everything.
And grub-mkconfig does create a config file while printing the same errors as grub-install.
It just doesn't boot.

the.ridikulus.rat · 2013-09-24 15:55:45

I fixed the Archwiki GRUB page. You need to delete all the existing GRUB files in /boot/grub (and maybe /boot/efi) and reinstall grub as per https://wiki.archlinux.org/index.php/GR … ll_to_Disk.

# grub-install --target=i386-pc --recheck --debug /dev/sda

But I suggest using UEFI if you can (even if you are not dual-booting Windows), either using grub or gummiboot or refind (gummiboot recommended because it is in [core] repo).

Last edited by the.ridikulus.rat (2013-09-24 15:56:35)

Orim · 2013-09-25 08:47:30

That works, thanks a lot.
But I still get all the warnings about lvmetad. Doesn't look too friendly when installing a bootloader.
I guess the i386-pc has nothing to do with the actual platform? Maybe you could put that in the wiki as well?
I was wondering if I had to change it to amd64-pc or something.

Why do you suggest to use UEFI?
Isn't that like an evil, anti-linux, closed-off abomination? Just asking, I don't know much about uefi
What's the advantage of using it for a single OS system?

srs5694 · 2013-09-25 14:59:16

Orim wrote:

Why do you suggest to use UEFI?
Isn't that like an evil, anti-linux, closed-off abomination? Just asking, I don't know much about uefi
What's the advantage of using it for a single OS system?

I can't speak for the.ridikulus.rat, but your perception of EFI/UEFI is distorted. EFI is actually an open-source firmware implementation; however, it uses the BSD license, and most implementations on motherboards include proprietary code and so are closed-source. EFI is not anti-Linux at all. You're probably thinking of Microsoft's Secure Boot requirements, which have caused problems for Linux -- but there are also opportunities in that.

For more on EFI generally, you might want to read my Managing EFI Boot Loaders for Linux page, and in particular the first sub-page on EFI boot principles. The Wikipedia article on EFI is also worth reading.

EFI has advantages for a single-OS computer, including faster boots, access to EFI runtime services, and Secure Boot. Some of these advantages apply to only some EFIs, though, and some are still barely used by Linux, but may be better used in the future.

cfr · 2013-09-27 02:43:02

You might want to consider using a GPT partition table rather than MBR, as well. Especially, if I were you I would do more than just delete the Windows partitions - I would delete the existing partition map and start from scratch. But I don't have any especially good evidence for this view other than a sense that things generally work best when you partition with tools from the OS you are installing (except for dual boot where this isn't possible for both, of course). But perhaps I am just superstitious.

If you switch to EFI, GPT may be especially useful since some firmware likes EFI/GPT and BIOS/MBR combos best.

srs5694 · 2013-09-27 17:24:05

cfr wrote:

You might want to consider using a GPT partition table rather than MBR, as well. Especially, if I were you I would do more than just delete the Windows partitions - I would delete the existing partition map and start from scratch. But I don't have any especially good evidence for this view other than a sense that things generally work best when you partition with tools from the OS you are installing (except for dual boot where this isn't possible for both, of course). But perhaps I am just superstitious.

GPT is much better defined than MBR -- GPT is explicitly defined in the EFI specification, so there is a document you can point to as evidence that a particular disk's GPT is or is not correct. There's no such document for MBR, which evolved in a more ad-hoc way over decades. This helps make the GPT data structures created by different tools more compatible than the MBR data structures. The fact that GPT is newer also helps; there are fewer GPT-aware tools, and therefore less opportunity for some oddball tool to mess things up.

That said, there are weirdnesses and variations in the GPT world. The ones that spring to mind include:

Hybrid MBRs -- This is a standards-violating GPT variant that's most often used on Apple hardware. It modifies the protective MBR (which is intended to keep GPT-unaware tools from messing with GPT disks) so that it duplicates up to three GPT partitions in a way that a GPT-unaware OS can handle. Apple uses it to enable Macs to dual-boot with Windows, since Windows (even GPT-aware versions) treat a disk with a hybrid MBR as an MBR disk, whereas OS X (and also Linux) treats such a disk as a GPT disk. Most GPT-aware partitioning tools will either replace the hybrid MBR with a standard protective MBR or replicate the hybrid MBR data when a disk is modified. Hybrid MBRs can cause a lot of problems if users try to modify them with MBR-only partitioning tools (like all but the latest versions of Linux's fdisk or the standard Windows partitioning tools). They're ugly, dangerous, and should be avoided unless absolutely necessary. If they are necessary, they're created by tools like Apple's Boot Camp, my own GPT fdisk, and the gptsync tool from rEFIt and rEFInd.
Leftover GPT data -- Take a GPT disk and create a fresh MBR partition table on it using Linux's fdisk or Windows partitioning tools. The result is technically an MBR disk; however, these tools won't erase most of the GPT data. libparted (upon which parted, GParted, and several other Linux tools are based) becomes confused by this. Typically, the result is either an error message or (worse) a presentation of the disk as being completely empty. Lots of people have problems because of this libparted quirk/bug.
Unusual GPT settings -- There are certain defaults in GPT that are actually variable. The size of the partition table is a good example of this. Most GPTs include room for 128 partitions, but the GPT spec says that the partition table should be a minimum size (which is specified in terms of bytes, but that works out to 128 partitions). Some tools, like gdisk, enable adjusting this size. Doing so can cause problems with some tools. (libparted used to be one of them, but I think the latest version can cope with unusual partition table sizes.) Some tools violate the standard and create smaller partition tables than the spec permits. Most OSes can cope with this just fine, but some tools flake out. There are a few other ambiguities in the standard that can cause similar problems.
Subtle protective MBR differences -- The protective MBR's format is specified in the GPT spec, but most tools deviate slightly from what the spec says. Most tools don't really care what the protective MBR looks like, although a hybrid MBR can be an exception to this rule. On rare occasion, though, these differences can cause problems. The one exception that springs to my mind was a BIOS that I once had, which hung at boot when it saw a technically correct protective MBR, because that technically correct MBR contains CHS values that are illegal in the traditional MBR scope. GPT fdisk creates such a technically correct MBR, but libparted doesn't, so a libparted-created disk would work on this motherboard whereas a disk partitioned with gdisk would not.
Unicode -- GPT partitions have names, which are encoded as Unicode characters. Some tools, like GParted and (IIRC) the Windows tools, don't even display these names; but others, like parted, gdisk, and (IIRC) the text-mode "diskpart" tool of OS X, do. Unfortunately, including proper Unicode support adds to the complexity of a program, so some forego that support in favor of a simplistic ASCII-to-Unicode algorithm that works fine for ASCII but fails for non-ASCII characters. The OS X "diskpart" tool and gdisk (when compiled with Unicode support) handle Unicode correctly; but parted and gdisk (when compiled without Unicode support) do the simplistic ASCII-only support. This can result in differences in the way non-ASCII characters are displayed in partition names. This is unlikely to cause anything but cosmetic differences in the displays, although I can't rule out the possibility that certain non-ASCII names might cause a program to crash or otherwise misbehave. Such differences could also affect things like the PARTUUID option in a mount command, /etc/fstab file, or kernel option line. (I don't know offhand if the kernel does proper Unicode conversion or the simplistic ASCII-only conversion.) AFAIK, the default names assigned by all common partitioning tools are ASCII-only and so work fine with all programs; you'd need to explicitly set a non-ASCII name (using Greek, Cyrillic, etc. characters) to see these differences.
Partition type codes -- Most tools support only a handful of partition type codes. libparted is particularly noteworthy in this respect because it conflates two different types of data structures into its "flags" -- GPT attributes and partition type codes. GPT fdisk is the only tool I'm aware of that lets you set arbitrary type codes. It's also the only one that supports the type code for Linux-specific filesystems, which is important for keeping Linux partitions from showing up as unformatted disks in Windows. (This support exists in the git-accessible version of parted, but most distributions aren't yet using that version. Arch seems to be no exception to this rule.)

The tools that are most likely to create GPT data structures that Linux users encounter are libparted (via parted, GParted, Palimpsest, and various Linux installers), the GPT fdisk family (gdisk, cgdisk, or sgdisk), the standard Windows tools, and OS X's Disk Utility and diskutil. All of these tools create partitions that are compatible with one another, with the exception of the Unicode support -- and that's important only if you give partitions names that include non-ASCII characters. For Linux/Windows dual-boot systems, I strongly recommend using gdisk to set the type code of Linux partitions to 8300 (gdisk's internal code for the Linux-specific partition code). Thus, I wouldn't worry too much about what tool you use to create your partition table, or even your partitions, although some cleanup of partition type codes might be necessary; and on a Mac (or if you move a disk from a Mac to a PC), you might need to create a hybrid MBR or convert a hybrid MBR into a standard protective MBR.

Orim · 2013-09-28 13:39:56

srs5694 wrote:

For more on EFI generally, you might want to read my Managing EFI Boot Loaders for Linux page, and in particular the first sub-page on EFI boot principles. The Wikipedia article on EFI is also worth reading.

Thank you. I thought I might be wrong about the entire UEFI thing. Now I'm actually glad that I was

cfr wrote:

If you switch to EFI, GPT may be especially useful since some firmware likes EFI/GPT and BIOS/MBR combos best.

I actually tried to set up a GPT but failed. I can't remember why though. Now that it's working I don't want to change it again, especially not on a Notebook
where I can't just put in another harddrive for backup and such. But I'll definitely keep it in mind for my next install, thank you.

@srs5694
Thank your for all the input. Very informative.
As I mentioned above I tried setting up a GPT using fdisk but IIRC could not set the correct partition type. Ah damn, I really can't remember what the problem was.
Now I want to try again...but it'd be unwise to start from scratch now.

However, I am considering to give UEFI another try. If I understand it correctly I could shrink my LVM to create enough room for the EFI partition.
So I don't need to create a new partition table from scratch, or do I?

srs5694 · 2013-09-28 17:01:38

Orim wrote:

As I mentioned above I tried setting up a GPT using fdisk but IIRC could not set the correct partition type. Ah damn, I really can't remember what the problem was.

fdisk isn't a good tool for managing a GPT setup. Only the very latest version of fdisk supports GPT at all, and its GPT support is extremely rudimentary. Your description is exactly correct -- you can't use fdisk to change partition types on GPT disks. If you want to use an fdisk-style user interface for managing GPT disks, you're better off using gdisk, which is modeled after fdisk but provides support for every GPT feature. Alternatively, you could use anything built around libparted (parted, GParted, Palimpsest Disk Utility, etc.). These tools are in-between in terms of GPT feature support, but some of them have other advantages, such as GParted's GUI and the ability to resize partitions and filesystems together.

However, I am considering to give UEFI another try. If I understand it correctly I could shrink my LVM to create enough room for the EFI partition.
So I don't need to create a new partition table from scratch, or do I?

If you're currently using MBR, there's a chance that your firmware won't boot from it. I've done very limited testing on this score, but I have succeeded in booting from MBR disks in EFI mode; but some EFIs might be fussier and require a GPT disk. Of course, you could always use a USB flash drive to hold the EFI System Partition. In fact, that's probably a good way to go if you want to experiment, since you'll be able to set up whatever EFI boot loader(s) you like with virtually no chance of damaging your existing BIOS-mode installation. If you get it working and like booting that way, you can then either try doing an EFI-mode boot from your MBR hard disk or use gdisk to convert your MBR partition table to GPT form. (gdisk can do this without trashing your existing partitions, provided they don't overlap the GPT data structures. libparted-based tools can only do a destructive MBR-to-GPT conversion.)

johnshier · 2014-06-12 14:13:44

A little late to the party but I would caution anyone using rEFInd/UEFI combo on a Lenovo T530. I have major problems with many kernel versions (i.e. 3.8 to 3.12). The machine simply would not boot.

I believe most of the problems were related to: https://bbs.archlinux.org/viewtopic.php?id=156670

I have since switched to grub and all has been well for the last 4 months.

Arch Linux

#1 2013-09-24 11:32:04

Installation on Thinkpad T530 without UEFI

#2 2013-09-24 15:55:45

Re: Installation on Thinkpad T530 without UEFI

#3 2013-09-25 08:47:30

Re: Installation on Thinkpad T530 without UEFI

#4 2013-09-25 14:59:16

Re: Installation on Thinkpad T530 without UEFI

#5 2013-09-27 02:43:02

Re: Installation on Thinkpad T530 without UEFI

#6 2013-09-27 17:24:05

Re: Installation on Thinkpad T530 without UEFI

#7 2013-09-28 13:39:56

Re: Installation on Thinkpad T530 without UEFI

#8 2013-09-28 17:01:38

Re: Installation on Thinkpad T530 without UEFI

#9 2014-06-12 14:13:44

Re: Installation on Thinkpad T530 without UEFI

Board footer