Partitioning hard disk drives for BIOS-MBR, BIOS-GPT and UEFI-GPT in Linux

Introduction

This post was prompted by recent threads in the Gentoo Linux Forums such as the following:

  • partition MBR/GPT fdisk question‘ in which two people asked how to partition a HDD using GPT. One has a computer that only has BIOS firmware; the other has a computer with firmware that supports UEFI and BIOS (user-selectable) and who apparently wanted to boot using BIOS.
  • [SOLVED] installing on UEFI system‘ in which someone asked how to partition a HDD for a computer with UEFI firmware.

These Gentoo Linux users were confused by the instructions in the Gentoo Installation Guide – Preparing the disks. In my opinion the Gentoo Installation Guide is confusing. You do not need a BIOS boot partition (Code EF02) if you want to use a GPT-partitioned HDD with a UEFI computer; you only need a BIOS boot partition on a GPT-partitioned HDD if you want to use it with a BIOS computer. You do not need an ESP (EFI System Partition) if you want to use a GPT-partitioned HDD with a BIOS computer; you only need an ESP (Code EF00) — which must be formatted as FAT32 — if you want to use UEFI.

Coincidentally, recently an Ubuntu user also told me he finds GPT partitioning for UEFI confusing.

So, in the hope of helping people having trouble understanding how to partition a HDD for Linux, I decided to post some information on the two firmware designs and the two partitioning designs, plus list a few (of the many) partitioning schemes that can be used. The purpose of this post is to provide an overview of the designs and possible schemes, not to explain how to use the various partitioning tools or to list the precise steps you must follow. I have tried to avoid going into fine detail (for example the oft-quoted limit of 2TiB for MBR-partitioned HDDs is contigent on 512B sectors).

Firstly, let’s get the terminology straight: you should say ‘UEFI firmware’, not ‘UEFI BIOS’. The latter is an oxymoron. I know that some computer manufacturers and third-party firmware providers use the term ‘UEFI BIOS’, but it is incorrect. The ‘BIOS’ (a.k.a. ‘PC BIOS’) and the UEFI are two different designs of firmware used during the booting process. BIOS firmware and MBR partitioning are older (‘legacy’) designs; UEFI firmware and GPT partitioning are the latest designs, intended to replace BIOS and MBR. See the end of this post for links to articles regarding BIOS, MBR, UEFI and GPT that I recommend you also read.

I personally have not come across computers that support solely UEFI; all the computers I have used allow the user to configure the firmware at boot via the Setup menu to use either UEFI or BIOS. Some UEFI firmware manufacturers show the BIOS support option in the Setup menu as ‘Compatibility Support Module’ (CSM) or ‘Legacy Mode’.

‘Secure Boot’ is one of the touted UEFI features not present in BIOS. Linux expert Roderick W. Smith explains Secure Boot in his article ‘Linux on UEFI: A Quick Installation Guide‘:

One optional feature of UEFI deserves mention: Secure Boot. This feature is designed to minimize the risk of a computer becoming infected with a boot kit, which is a type of malware that infects the computer’s boot loader. Boot kits can be particularly difficult to detect and remove, which makes blocking them a priority. Microsoft requires that all desktop and laptop computers that bear a Windows 8 logo ship with Secure Boot enabled. This type of configuration complicates Linux installation, although some distributions handle this problem better than do others. Do not confuse Secure Boot with EFI or UEFI, though; it’s possible for an EFI computer to not support Secure Boot, and it’s possible to disable Secure Boot even on x86-64 EFI computers that support it. Microsoft requires that users can disable Secure Boot for Windows 8 certification on x86 and x86-64 computers; however, this requirement is reversed for ARM computers—such computers that ship with Windows 8 must not permit the user to disable Secure Boot. Fortunately, ARM-based Windows 8 computers are currently rare. I recommend avoiding them.

GPT-partitioned HDDs have become the norm these days for two principal reasons:

  • the MBR design limits the amount of disk space accessible to a maximum of 2TiB but HDDs larger than 2TiB are now common;
  • Microsoft has standardised on UEFI, and UEFI will not boot an MBR-partitioned HDD (Section 5.2.1 of Version 2.6 of the UEFI Specification specifies that UEFI firmware shall not execute the boot code in an MBR located at the first logical block of a disk with the MBR disk layout).

The ‘Protective MBR’ at the beginning of every GPT-partitioned disk (in the same location on the disk as a legacy MBR would be) is designed to prevent MBR-based disk utilities misrecognising and possibly overwriting GPT-partitioned disks. A fake (i.e. it does not really exist) single partition called the ‘GPT Protective Partition’ (Code EE00) is specified in the Protective MBR to occupy as much of the drive as can be represented in an MBR, namely a maximum of 2TiB in the case of a disk with 512B sectors. Operating systems and tools not designed for GPT disks will read the Protective MBR and detect that the disk contains a single partition of unknown type and with no empty space, and will refuse to modify the disk unless the user deletes this partition. This design (i.e. the Protective MBR and GPT Protective Partition) was devised in order to minimise the possibility of a) legacy software accidentally overwriting a GPT-partitioned HDD; b) GPT-aware software accidentally overwriting an MBR-partitioned HDD (the absence of a partition of type EEh defined in the Protective MBR would indicate to GPT-aware operating systems and tools that the HDD is not GPT-partitioned).

You can use an MBR-partitioned HDD with BIOS; you can use a GPT-partitioned HDD with BIOS; you can use a GPT-partitioned HDD with UEFI; you cannot use an MBR-partitioned HDD with UEFI. If the firmware in your computer has an option to select BIOS mode (some firmware manufacturers refer to this as ‘Compatibility Support Module’ or ‘Legacy Mode’) instead of UEFI and you want to use an MBR on the HDD, you will have to use BIOS. In summary, for Linux your options are BIOS-MBR, BIOS-GPT or UEFI-GPT. I will discuss these three options and provide some possible partitioning schemes in each case.

The layout of a GPT-partitioned HDD is as follows:

The beginning of a GPT-partitioned disk
Protective MBR 512B
Primary GPT Header 512B
Primary Partition Table entries Up to 16KiB (maximum of 128 partitions)

Therefore the unpartitioned space at the beginning of the HDD should be at least 17KiB.

Unlike in the MBR design, the end of a GPT-partitioned disk stores a backup of the partition table:

The end of a GPT-partitioned disk
Secondary Partition Table entries Up to 16KiB (maximum of 128 partitions)
Secondary GPT Header 512B

Therefore the upartitioned space at end of a GPT-partitioned disk should be at least 16.5KiB.

The remainder of a GPT-partitioned disk between the above two areas can contain up to 128 partitions. One partition — normally the first partition is used — must be the ‘ESP’ (EFI System Partition), which should be formatted as FAT32 and have the ‘esp’ and ‘boot’ flags set. The partition code must be EF02. The minimum possible size of a FAT32 partition is 33,549,824B (~32MiB). The required size of the ESP will depend on what is stored in it (for example the now-orphaned ELILO boot loader stored the Linux kernel images in it, whereas the GRUB boot loader does not). The Ubuntu Community Help Wiki specifies a minimum of 100MiB and recommends 200MiB. The Gentoo Installation Guide recommends 128MB.

The versions of GParted and KDE Partition Manager I have used to partition HDDs seem to want to reserve at least 2048 512B sectors of empty space before the first partition (sometimes these two utilities force me to have 4096 512B sectors of empty space before the first partition), so I suggest leaving at least 1MiB of unpartitioned space at the beginning and end of the HDD if you want to partition a disk for GPT using those tools. Actually, for peace of mind you may as well leave 1MiB of empty space at the beginning and end of the disk whatever GUI tools or console commands (parted, fdisk, gdisk, etc.) you use to partition the disk.

By the way, if you wanted to use MBR instead of GPT, the MBR (512B) plus the GRUB embedding area after the MBR (~31KiB) means that 1MiB would also be more than enough for an MBR HDD (see GNU GRUB Manual – 3.4 BIOS installation).

Thus my suggestions for HDD partitioning would be as shown below. Note that the order of the partitions I have adopted below is not obligatory; you can change the order if you wish. I prefer to specify precise sizes for the swap and root partitions, and put /home on the last partition so it can occupy the remainder of the disk, whatever size that may be.

UEFI-GPT

Option 1

This is my preferred option because I can edit /etc/fstab and specify that /boot must not be mounted at boot, thus reducing the possibility of the files in /boot getting corrupted.

UEFI-GPT Option 1
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1
Size: 512 MiB
File system: FAT32
Flags: boot & esp
Code: EF00
Label: ESP
Mount point: /boot/efi
/dev/sda2
Size: 16 GiB for a computer with 16 GiB of RAM*
File system: linux-swap
Flags: None
Code: 8200
Label: SWAP
Mount point: None
/dev/sda3
Size: 512 MiB
File system: ext2
Flags: None
Code: 8300
Label: BOOT
Mount point: /boot    Therefore /boot/grub/ will be on this partition if you use GRUB.
/dev/sda4
Size: e.g. 64 GiB (128 GiB if the drive is big)
File system: ext4
Flags: None
Code: 8300
Label: ROOT
Mount point: / (root)
/dev/sda5
Size: 1.00 MiB less than the remaining disk space
File system: ext4
Flags: None
Code: 8300
Label: HOME
Mount point: /home
1.00 MiB of empty space at the end of the disk.

* You will often see recommendations to make the size of the swap partition the same as the size of the RAM if you want to be able to put the computer into hibernation. In fact, the Linux kernel is normally configured to compress the contents of the RAM image for hibernation, and I personally have seen the disk image of 4GB of RAM compressed to 23% of that size. Nevertheless, if you have a large HDD you may as well just take the easy route and allocate the size of the swap partition to be the same as the RAM size, even if all of the swap partition will never be used in practice. That way you are guaranteed to be able to put the computer into hibernation.

Below is an example of the above partitioning scheme on a virtual UEFI machine with a 64GiB virtual GPT-partitioned HDD:

root # gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 134217728 sectors, 64.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 54B3C38F-1C55-4A19-9BAA-499C4D0D8DD0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00
   2         1050624         5244927   2.0 GiB     8200
   3         5244928         6293503   512.0 MiB   8300
   4         6293504        72353791   31.5 GiB    8300
   5        72353792       134215679   29.5 GiB    8300

root # fdisk -l /dev/sda
Disk /dev/sda: 64 GiB, 68719476736 bytes, 134217728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 54B3C38F-1C55-4A19-9BAA-499C4D0D8DD0

Device        Start       End  Sectors  Size Type
/dev/sda1      2048   1050623  1048576  512M EFI System
/dev/sda2   1050624   5244927  4194304    2G Linux swap
/dev/sda3   5244928   6293503  1048576  512M Linux filesystem
/dev/sda4   6293504  72353791 66060288 31.5G Linux filesystem
/dev/sda5  72353792 134215679 61861888 29.5G Linux filesystem

root # parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 68.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  538MB   537MB   fat32                 boot, esp
 2      538MB   2685MB  2147MB  linux-swap(v1)
 3      2685MB  3222MB  537MB   ext2
 4      3222MB  37.0GB  33.8GB  ext4
 5      37.0GB  68.7GB  31.7GB  ext4

root # blkid
/dev/sda4: LABEL="ROOT" UUID="174ac3e8-f105-4606-bed1-7a1aa22c3631" TYPE="ext4" PARTUUID="01d9c139-fe70-415a-abc6-2351fad33384"
/dev/sda1: UUID="B4C1-7EA5" TYPE="vfat" PARTUUID="d941f728-c386-4f4c-b0c3-aa76f4290774"
/dev/sda2: LABEL="SWAP" UUID="e3ddf9b5-2ae3-4469-a121-0a1a78aa6702" TYPE="swap" PARTUUID="a4daec88-da44-4ae3-8119-01cc81325f03"
/dev/sda3: LABEL="BOOT" UUID="1e24ea9d-5358-4e9b-8667-d7a42e7b6ad7" TYPE="ext2" PARTUUID="b5369ce3-4b44-4d19-be6f-1d226dc71cb3"
/dev/sda5: LABEL="HOME" UUID="87f6a0af-dbed-4587-b810-efca8f269618" TYPE="ext4" PARTUUID="19fd7d00-2d89-4653-af03-e81618a3b70d"

Option 2

You could use this scheme if you are not interested in having /boot on its own partition.

UEFI-GPT Option 2
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1
Size: 512 MiB
File system: FAT32
Flags: boot & esp
Code: EF00
Label: ESP
Mount point: /boot/efi
/dev/sda2
Size: 16 GiB for a computer with 16 GiB of RAM*
File system: linux-swap
Flags: None
Code: 8200
Label: SWAP
Mount point: None
/dev/sda3
Size: e.g. 64 GiB (128 GiB if the drive is big)
File system: ext4
Flags: None
Code: 8300
Label: ROOT
Mount point: / (root)    Therefore /boot (and /boot/grub/) will on this partition too.
/dev/sda4
Size: 1.00 MiB less than the remaining space on the disk
File system: ext4
Flags: None
Code: 8300
Label: HOME
Mount point: /home
1.00 MiB of empty space at the end of the disk.

* See my earlier note regarding hibernation.

Below is an example of the above scheme on a virtual UEFI machine with a 64GiB virtual GPT-partitioned HDD:

root # gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 134217728 sectors, 64.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 54B3C38F-1C55-4A19-9BAA-499C4D0D8DD0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00
   2         1050624         5244927   2.0 GiB     8200
   3         5244928        72353791   32.0 GiB    8300
   4        72353792       134215679   29.5 GiB    8300

root # fdisk -l /dev/sda
Disk /dev/sda: 64 GiB, 68719476736 bytes, 134217728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 54B3C38F-1C55-4A19-9BAA-499C4D0D8DD0

Device        Start       End  Sectors  Size Type
/dev/sda1      2048   1050623  1048576  512M EFI System
/dev/sda2   1050624   5244927  4194304    2G Linux swap
/dev/sda3   5244928  72353791 67108864   32G Linux filesystem
/dev/sda4  72353792 134215679 61861888 29.5G Linux filesystem

root # parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 68.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  538MB   537MB   fat32                 boot, esp
 2      538MB   2685MB  2147MB  linux-swap(v1)
 3      2685MB  37.0GB  34.4GB  ext4
 4      37.0GB  68.7GB  31.7GB  ext4


root # blkid
/dev/sda3: LABEL="ROOT" UUID="fdf2b11a-8c6b-4bb3-9534-477c3ed49d95" TYPE="ext4" PARTUUID="f393129f-ab32-40fb-bf78-3aead3dd4af0"
/dev/sda1: UUID="C024-8A30" TYPE="vfat" PARTUUID="d941f728-c386-4f4c-b0c3-aa76f4290774"
/dev/sda2: LABEL="SWAP" UUID="1f752a05-a1fb-4c5f-ab2e-079715207b4d" TYPE="swap" PARTUUID="a4daec88-da44-4ae3-8119-01cc81325f03"
/dev/sda4: LABEL="HOME" UUID="041e4ab2-d54c-4092-b445-779997ac09ce" TYPE="ext4" PARTUUID="7e1b8dc0-2f38-4260-95af-fbb80bb72156"

Option 3

You could use this scheme if you are not interested in having /boot and /home on their own partitions.

UEFI-GPT Option 3
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1
Size: 512 MiB
File system: FAT32
Flags: boot & esp
Code: EF00
Label: ESP
Mount point: /boot/efi
/dev/sda2
Size: 16 GiB for a computer with 16 GiB of RAM*
File system: linux-swap
Flags: None
Code: 8200
Label: SWAP
Mount point: None
/dev/sda3
Size: 1.00 MiB less than the remaining space on the disk
File system: ext4
Flags: None
Code: 8300
Label: ROOT
Mount point: / (root)    Therefore /boot (and /boot/grub/) and /home will on this partition too.
1.00 MiB of empty space at the end of the disk.

* See my earlier note regarding hibernation.

BIOS-GPT

If you have partitioned a large drive correctly then a computer with BIOS firmware will be able to access partitions larger than 2TiB. One of my computers has BIOS firmware only but can access its 3TiB GPT-partitioned HDDs.

Option 1

This is my preferred option because I can edit /etc/fstab and specify that /boot must not be mounted at boot, thus reducing the possibility of the files in /boot getting corrupted.

BIOS-GPT Option 1
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1   This is the BIOS boot partition
Size: 1.00 MiB
File system: Unformatted
Flags: bios_grub
Code: EF02
Label: Not applicable
Mount point: Not applicable
/dev/sda2
Size: 512 MiB
File system: ext2
Flags: None
Code: 8300
Label: BOOT
Mount point: /boot
/dev/sda3
Size: 16 GiB for a computer with 16 GiB of RAM*
File system: linux-swap
Flags: None
Code: 8200
Label: SWAP
Mount point: None
/dev/sda4
Size: e.g. 64 GiB (128 GiB if the drive is big)
File system: ext4
Flags: None
Code: 8300
Label: ROOT
Mount point: / (root)    Therefore /boot and (/boot/grub/) will on this partition too.
/dev/sda5
Size: 1.00 MiB less than the remaining space on the disk
File system: ext4
Flags: None
Code: 8300
Label: HOME
Mount point: /home
1.00 MiB of empty space at the end of the disk.

* See my earlier note regarding hibernation.

Option 2

You could use this scheme if you are not interested in having /boot on its own partition.

BIOS-GPT Option 2
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1   This is the BIOS boot partition
Size: 1.00 MiB
File system: Unformatted
Flags: bios_grub
Code: EF02
Label: Not applicable
Mount point: Not applicable
/dev/sda2
Size: 16 GiB for a computer with 16 GiB of RAM*
File system: linux-swap
Flags: None
Code: 8200
Label: SWAP
Mount point: None
/dev/sda3
Size: e.g. 64 GiB (128 GiB if the drive is big)
File system: ext4
Flags: None
Code: 8300
Label: ROOT
Mount point: / (root)    Therefore /boot (and /boot/grub/) will on this partition too.
/dev/sda4
Size: 1.00 MiB less than the remaining space on the disk
File system: ext4
Flags: None
Code: 8300
Label: HOME
Mount point: /home
1.00 MiB of empty space at the end of the disk.

* See my earlier note regarding hibernation.

Option 3

You could use this scheme if you are not interested in having /boot and /home on their own partitions.

BIOS-GPT Option 3
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1   This is the BIOS boot partition
Size: 1.00 MiB
File system: Unformatted
Flags: bios_grub
Code: EF02
Label: Not applicable
Mount point: Not applicable
/dev/sda2
Size: 16 GiB for a computer with 16 GiB of RAM*
File system: linux-swap
Flags: None
Code: 8200
Label: SWAP
Mount point: None
/dev/sda3
Size: 1.00 MiB less than the remaining space on the disk
File system: ext4
Flags: None
Code: 8300
Label: ROOT
Mount point: / (root)    Therefore /boot and /home will on this partition too.
1.00 MiB of empty space at the end of the disk.

* See my earlier note regarding hibernation.

BIOS-MBR

Option 1

This is my preferred option because I can edit /etc/fstab and specify that /boot must not be mounted at boot, thus reducing the possibility of the files in /boot getting corrupted.

BIOS-MBR Option 1
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1
Size: 512 MiB
Type: Primary
File system: ext2
Flags: boot
Label: BOOT
Mount point: /boot
/dev/sda2
Size: 16 GiB for a computer with 16 GiB of RAM*
Type: Primary
File system: linux-swap
Flags: None
Label: SWAP
Mount point: None
/dev/sda3
Size: e.g. 64 GiB (128 GiB if the drive is big)
File system: ext4
Flags: None
Label: ROOT
Mount point: / (root)
/dev/sda4
Size: remaining space on the disk
Type: Primary
File system: ext4
Flags: None
Label: HOME
Mount point: /home

* See my earlier note regarding hibernation.

Option 2

You could use this scheme if you are not interested in having /boot on its own partition.

BIOS-MBR Option 2
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1
Size: 16 GiB for a computer with 16 GiB of RAM*
Type: Primary
File system: linux-swap
Flags: None
Label: SWAP
Mount point: None
/dev/sda2
Size: e.g. 64 GiB (128 GiB if the drive is big)
Type: Primary
File system: ext4
Flags: boot
Label: ROOT
Mount point: / (root)    Therefore /boot will be on this partition too.
/dev/sda3
Size: remaining space on the disk
Type: Primary
File system: ext4
Flags: None
Label: HOME
Mount point: /home

* See my earlier note regarding hibernation.

Option 3

You could use this scheme if you are not interested in having /boot and /home on their own partitions.

BIOS-MBR Option 3
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1
Size: 16 GiB for a computer with 16 GiB of RAM*
Type: Primary
File system: linux-swap
Flags: None
Label: SWAP
Mount point: None
/dev/sda2
Size: remaining space on the disk
Type: Primary
File system: ext4
Flags: boot
Label: ROOT
Mount point: / (root)    Therefore /boot and /home will be on this partition too.

* See my earlier note regarding hibernation.

Option 4

If you want to have more than four partitions — let’s say you wanted to have a separate NTFS partition, for example — you would need to use an Extended Partition.

BIOS-MBR Option 4
1.00 MiB of empty space at the beginning of the disk.
/dev/sda1
Size: 512 MiB
Type: Primary
File system: ext2
Flags: boot
Label: BOOT
Mount point: /boot
/dev/sda2
Size: 16 GiB for a computer with 16 GiB of RAM*
Type: Primary
File system: linux-swap
Flags: None
Label: SWAP
Mount point: None
/dev/sda3
Size: Remainder of disk
Type: Extended
File system: Not applicable
Flags: None
Label: Not applicable
Mount point: Not applicable
/dev/sda4
Will not exist
/dev/sda5
Size: e.g. 128GiB
Type: Logical
File system: ext4
Flags: None
Label: ROOT
Mount point: / (root)
/dev/sda6
Size: e.g. 256GiB
Type: Logical
File system: ext4
Flags: None
Label: HOME
Mount point: /home
/dev/sda7
Size: remaining space on the disk
Type: Logical
File system: NTFS
Flags: None
Label: NTFS
Mount point: /media/NTFS

* See my earlier note regarding hibernation.

Below is an example of the above scheme (this happens to be the scheme on my main laptop):

root # fdisk -l /dev/sda
Disk /dev/sda: 698.7 GiB, 750156374016 bytes, 1465149168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x291ba0e7

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sda1            2048     264191     262144   128M 83 Linux
/dev/sda2          264192   33822719   33558528    16G 82 Linux swap / Solaris
/dev/sda3        33822720 1465147391 1431324672 682.5G  5 Extended
/dev/sda5        33824768  302260223  268435456   128G 83 Linux
/dev/sda6       302262272  839133183  536870912   256G 83 Linux
/dev/sda7       839135232 1465147391  626012160 298.5G  7 HPFS/NTFS/exFAT

root # lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,LABEL,PARTFLAGS /dev/sda
NAME   TYPE   SIZE FSTYPE  MOUNTPOINT  LABEL PARTFLAGS
sda    disk 698.7G                           
├─sda1 part   128M ext2    /boot       BOOT  
├─sda2 part    16G swap    [SWAP]      SWAP  
├─sda5 part   128G ext4    /           ROOT  
├─sda6 part   256G ext4    /home       HOME  
└─sda7 part 298.5G ntfs-3g /media/NTFS NTFS

Notice that the boot flag is not set. Nevertheless the laptop boots fine.

Command-line tools

Below are examples of command-line utilities parted, gdisk and fdisk examining a GPT-partitioned HDD and an MBR-partitioned HDD. The original fdisk utility predates the invention of GPT, but the latest versions of fdisk understand the GPT design (you can check this by using the command ‘man fdisk‘). Personally, to partition GPT HDDs from the command line I would use parted or gdisk before fdisk, and to partition MBR HDDs from the command line I would use parted or fdisk before gdisk. Mind you, I like an easy life and so I tend to use the GUI tools GParted or KDE Partition Manager to partition and format an HDD for Linux.

GPT-partitioned HDD

root # parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 68.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name       Flags
 1      2097kB  539MB   537MB   fat32                      boot, esp
 2      539MB   1076MB  537MB   ext2            /boot
 3      1076MB  3223MB  2147MB  linux-swap(v1)  linuxswap
 4      3223MB  37.6GB  34.4GB  ext4            /
 5      37.6GB  68.7GB  31.1GB  ext4            /home

root # gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 134217728 sectors, 64.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9807AF0F-8BD5-4727-A3CD-9995B2705732
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 8125 sectors (4.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            4096         1052671   512.0 MiB   EF00  
   2         1052672         2101247   512.0 MiB   8300  /boot                                                                    
   3         2101248         6295551   2.0 GiB     8200  linuxswap                                                                
   4         6295552        73404415   32.0 GiB    8300  /                                                                        
   5        73404416       134213631   29.0 GiB    8300  /home                                                                    
root # fdisk -l /dev/sda                                                                                           
Disk /dev/sda: 64 GiB, 68719476736 bytes, 134217728 sectors                                                                       
Units: sectors of 1 * 512 = 512 bytes                                                                                             
Sector size (logical/physical): 512 bytes / 512 bytes                                                                             
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                                 
Disklabel type: gpt                                                                                                               
Disk identifier: 9807AF0F-8BD5-4727-A3CD-9995B2705732                                                                             
                                                                                                                                  
Device        Start       End  Sectors  Size Type                                                                                 
/dev/sda1      4096   1052671  1048576  512M EFI System
/dev/sda2   1052672   2101247  1048576  512M Linux filesystem
/dev/sda3   2101248   6295551  4194304    2G Linux swap
/dev/sda4   6295552  73404415 67108864   32G Linux filesystem
/dev/sda5  73404416 134213631 60809216   29G Linux filesystem

MBR-partitioned HDD

root # parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 68.7GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  538MB   537MB   primary  ext2            boot
 2      538MB   2685MB  2147MB  primary  linux-swap(v1)
 3      2685MB  37.0GB  34.4GB  primary  ext4
 4      37.0GB  68.7GB  31.7GB  primary  ext4

root # gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sda: 134217728 sectors, 64.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): F6E9E53E-33BE-44CB-BEFC-D93E03B79B84                                                   
Partition table holds up to 128 entries                                                                        
First usable sector is 34, last usable sector is 134217694                                                     
Partitions will be aligned on 2048-sector boundaries                                                           
Total free space is 2014 sectors (1007.0 KiB)                                                                  

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   8300  Linux filesystem
   2         1050624         5244927   2.0 GiB     8200  Linux swap
   3         5244928        72353791   32.0 GiB    8300  Linux filesystem
   4        72353792       134217727   29.5 GiB    8300  Linux filesystem
root # fdisk -l /dev/sda
Disk /dev/sda: 64 GiB, 68719476736 bytes, 134217728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7b9f1623

Device     Boot    Start       End  Sectors  Size Id Type
/dev/sda1  *        2048   1050623  1048576  512M 83 Linux
/dev/sda2        1050624   5244927  4194304    2G 82 Linux swap / Solaris
/dev/sda3        5244928  72353791 67108864   32G 83 Linux
/dev/sda4       72353792 134217727 61863936 29.5G 83 Linux

Notice the gdisk warning that the last partition would not be viable on a GPT-partitioned HDD because there would not be space for the Secondary GPT. However, as this is an MBR-partitioned HDD for use with a BIOS firmware computer, that does not apply.

A warning note if installing Ubuntu on a UEFI computer

When I installed Ubuntu Desktop 16.04.1 in a virtual machine I encountered a bug (in VirtualBox? in the Ubuntu Installer?) which results in subsequent reboots leaving the virtual machine running the UEFI Shell instead of launching GRUB and booting Ubuntu. To fix that, I did the following as soon as Ubuntu booted from the virtual HDD for the first time after I had clicked ‘Restart Now’ in the ‘Installation Complete’ window:

user $ sudo su
root # mount /dev/sda1 /mnt
root # cd /mnt
root # echo "\EFI\ubuntu\grubx64.efi" > startup.nsh
root # cd
root # umount /dev/sda1
root # exit

This creates the file /boot/efi/startup.nsh required by the UEFI Shell. Then you can reboot and all should work as intended, i.e. the UEFI machine boots to the UEFI Shell which, after a few seconds, launches GRUB.

UPDATE (16 February 2017): A downside to the above approach is the 5-second timeout in the UEFI Shell until startup.nsh is launched. Below is an alternative that avoids having to wait for the 5-second countdown in the UEFI Shell until startup.nsh is launched. The downside is that you must remember to repeat this procedure if a new version of GRUB is installed and there is a new version of /EFI/ubuntu/grubx64.efi.

user $ sudo su
root # mount /dev/sda1 /mnt
root # cd /mnt/EFI/
root # ls
ubuntu
root # ls ubuntu
fw  fwupx64.efi  grub.cfg  grubx64.efi  MokManager.efi  shimx64.efi
root # mkdir BOOT
root # cp ubuntu/grubx64.efi BOOT/BOOTX64.EFI
root # cd
root # umount /dev/sda1
root # exit

See the Arch Linux Wiki article VirtualBox – 2.1 Installation in EFI mode.

A warning note if installing Gentoo on a UEFI computer

To date, the Gentoo Minimal Installation CD does not support UEFI, and therefore I recommend that you use SystemRescueCd instead. It is a Gentoo-based LiveCD with several tools useful for installing Gentoo, including a Web browser so you can access the on-line Gentoo documentation during installation. You can follow the Gentoo Installation Guide verbatim. SystemRescueCd also has a Desktop Environment with various GUI utilities, so you could partition the HDD using GParted instead of the command-line utilities if you wish. SystemRescueCd also comes with various wireless network card drivers and a network manager, so there is a good chance you will be able to connect easily to a wireless network if you prefer (I once used SystemRescueCd to install Gentoo on a laptop using Wi-Fi alone, as a wired connection was not convenient at the time).

How can I find out in Linux if a computer has booted using UEFI?

Check if the RAM-based directory /sys/firmware/efi/ exists. If it does not exist, the computer did not boot using UEFI.

Further Reading

  1. Wikipedia – BIOS
  2. Wikipedia – Master boot record
  3. UEFI Specification Version 2.6, January 2016
  4. Wikipedia – Unified Extensible Firmware Interface
  5. Wikipedia – GUID Partition Table
    Also, the diagram GUID Partition Table Scheme in that article is quite helpful in understanding the layout of a GPT-partitioned HDD.
  6. Wikipedia – BIOS boot partition
    Also, the diagram GNU GRUB 2 in that article is quite helpful in understanding: a) MBR partitioning; b) how GRUB 2 fits on an MBR-partitioned HDD; c) GPT partitioning; d) how GRUB 2 fits on a GPT-partitioned HDD; e) where the BIOS boot partition fits on a GPT-partitioned HDD and how it is used by GRUB 2.
  7. GNU GRUB Manual – 3.4 BIOS installation
  8. Ubuntu Documentation – UEFI
  9. Gentoo Installation Guide – Preparing the disks
  10. Ubuntu Bug Reports – Bug No. 811485 – Ubuntu partman-efi package – EFI SYSTEM PARTITION should be atleast 100 MiB size and formatted as FAT32, not FAT16
  11. Roderick W. Smith’s Web Page

Using an external USB 3.5-inch floppy disk drive in Linux

Back in 2004 I needed to get some files off my old 3.5″ floppy disks, so I bought an external USB floppy disk drive to use with a laptop running Windows XP. The label on the drive gives the manufacturer and model as ‘SmartDisk: FDUSB-TM2, Mitsumi Model #: D353FUE’.

Anyway, today I wanted to throw out some 720KB DD (Double Density) and 1440KB HD (High Density) 3.5″ floppy disks but first needed to check their contents and wipe them. So I dug out the SmartDisk USB drive to see if it would work with the current Gentoo Linux installation on my newest laptop. I was pleased to discover that it does, and below are some notes on how to use it in case anyone else needs to use one of these devices.

Once plugged in to a USB port on my laptop, the lsusb command shows the device has been recognised:

Bus 001 Device 013: ID 03ee:6901 Mitsumi SmartDisk FDD

Note that the Linux floppy driver is not needed for USB floppy disk drives:

root # grep -i CONFIG_BLK_DEV_FD /usr/src/linux/.config
# CONFIG_BLK_DEV_FD is not set

A Linux utility named ufiformat is used to low-level format floppy disks in USB floppy disk drives. A Gentoo Linux ebuild for Version 0.9.9 of ufiformat is listed below, and it can be used in a local overlay under the category sys-fs:

# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=5

DESCRIPTION="USB Floppy Disk formatting tool"
HOMEPAGE="http://www.geocities.jp/tedi_world/format_usbfdd_e.html"
SRC_URI="http://www.geocities.jp/tedi_world/${P}.tar.gz"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""

RDEPEND="sys-fs/e2fsprogs"
DEPEND=${RDEPEND}

The ufiformat utility is straightforward to use:

root # ufiformat --help
Usage: ufiformat [OPTION]... [DEVICE]
Format a floppy disk in a USB floppy disk DEVICE.

  -f, --format [SIZE]  specify format capacity SIZE in KB
                       without -f option, the format of the current media will be used
  -V, --verify         verify the medium after formatting
  -F, --force          do not perform any safety checks
  -i, --inquire        show device information, instead of performing format
                       without DEVICE argument, list USB floppy disk devices
  -v, --verbose        show detailed output
  -q, --quiet          suppress minor output
  -h, --help           show this message

To find the device name, use the blkid command before plugging in the USB cable and again after plugging in the USB cable. The extra device listed the second time will be the floppy disk drive. For example, in my case the new line at the end of the blkid output indicated the drive was /dev/sdd:

/dev/sdd: SEC_TYPE="msdos" UUID="BBBA-37AF" TYPE="vfat"

The fdisk command will confirm that the device is the floppy drive:

root # fdisk -l /dev/sdd
Disk /dev/sdd: 720 KiB, 737280 bytes, 1440 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Note that /dev/sdd will not be listed in the output of blkid if there is no disk in the floppy drive, although the ls command will list /dev/sdd while the drive is connected to the computer.

Notice that there are no devices /dev/fd0, /dev/fd1, /dev/fd2 and /dev/fd3, etc. This does not matter.

root # ls /dev
audio1           dri      i2c-10   kmem          mapper              nvidiactl  sda1       sequencer2  tty0   tty2   tty30  tty41  tty52  tty63    usbmon3     vcs2    vcsa12
autofs           dsp1     i2c-11   kmsg          mcelog              nvram      sda2       sg0         tty1   tty20  tty31  tty42  tty53  tty7     usbmon4     vcs3    vcsa2
block            fb0      i2c-2    log           mem                 pktcdvd    sda3       sg1         tty10  tty21  tty32  tty43  tty54  tty8     v4l         vcs4    vcsa3
bsg              fd       i2c-3    loop-control  memory_bandwidth    port       sda5       sg2         tty11  tty22  tty33  tty44  tty55  tty9     vboxdrv     vcs5    vcsa4
bus              full     i2c-4    loop0         mixer               ptmx       sda6       sg3         tty12  tty23  tty34  tty45  tty56  ttyS0    vboxdrvu    vcs6    vcsa5
char             fuse     i2c-5    loop1         mixer1              pts        sda7       shm         tty13  tty24  tty35  tty46  tty57  ttyS1    vboxnetctl  vcs7    vcsa6
console          hidraw0  i2c-6    loop2         mqueue              random     sdb        snapshot    tty14  tty25  tty36  tty47  tty58  ttyS2    vboxusb     vcs8    vcsa7
core             hidraw1  i2c-7    loop3         network_latency     rfkill     sdb1       snd         tty15  tty26  tty37  tty48  tty59  ttyS3    vcs         vcs9    vcsa8
cpu              hidraw2  i2c-8    loop4         network_throughput  root       sdc        stderr      tty16  tty27  tty38  tty49  tty6   urandom  vcs1        vcsa    vcsa9
cpu_dma_latency  hpet     i2c-9    loop5         null                rtc        sdc1       stdin       tty17  tty28  tty39  tty5   tty60  usbmon0  vcs10       vcsa1   vga_arbiter
cuse             i2c-0    initctl  loop6         nvidia-modeset      rtc0       sdd        stdout      tty18  tty29  tty4   tty50  tty61  usbmon1  vcs11       vcsa10  video0
disk             i2c-1    input    loop7         nvidia0             sda        sequencer  tty         tty19  tty3   tty40  tty51  tty62  usbmon2  vcs12       vcsa11  zero
root # ls -la /dev/fd
lrwxrwxrwx 1 root root 13 Jan 17 02:13 /dev/fd -> /proc/self/fd
root # ls -la /proc/self/fd
total 0
dr-x------ 2 root root  0 Jan 17 04:26 .
dr-xr-xr-x 8 root root  0 Jan 17 04:26 ..
lrwx------ 1 root root 64 Jan 17 04:26 0 -> /dev/pts/1
lrwx------ 1 root root 64 Jan 17 04:26 1 -> /dev/pts/1
lrwx------ 1 root root 64 Jan 17 04:26 2 -> /dev/pts/1
lr-x------ 1 root root 64 Jan 17 04:26 3 -> /proc/17669/fd

To format an HD floppy disk with the FAT file system, I did the following:

root # ufiformat -f 1440 /dev/sdd
geometry: track=80, head=2, sector=18, block=512
done                                   
root # /usr/sbin/mkfs.vfat /dev/sdd
mkfs.fat 4.0 (2016-05-06)
attribute "partition" not found
root # ufiformat -i /dev/sdd
vendor:  MITSUMI
product: USB FDD
write protect: off
media type: 2HD
status      block size   kb
formatted    2880  512 1440
formattable  2880  512 1440
formattable  1232 1024 1232
formattable  2400  512 1200

To format a DD floppy disk with the FAT file system, I did the following:

root # ufiformat -f 720 /dev/sdd
geometry: track=80, head=2, sector=9, block=512
done                                   
root # /usr/sbin/mkfs.vfat /dev/sdd
mkfs.fat 4.0 (2016-05-06)
attribute "partition" not found
root # ufiformat -i /dev/sdd
vendor:  MITSUMI
product: USB FDD
write protect: off
media type: 2DD
status      block size   kb
formatted    1440  512  720
formattable  1440  512  720

I use the KDE Desktop Environment. The Device Notifier widget in the System Tray shows the drive and — once a formatted floppy disk is in the drive — it is possible to use the Device Notifier to mount, open and unmount the floppy disk. However, it is also possible to use the command line:

root # mkdir /mnt/floppy
root # mount /dev/sdd /mnt/floppy
root # ls /mnt/floppy
root # cp /test.txt /mnt/floppy/
root # ls /mnt/floppy
test.txt
root # umount /dev/sdd

Earlier in this post I showed examples of formatting floppy disks using the FAT file system, but it is of course possible to format them using other file systems, such as:

root # mkfs.ext2 /dev/sdd
mke2fs 1.43.3 (04-Sep-2016)
/dev/sdd contains a vfat file system
Proceed anyway? (y,n) y
Creating filesystem with 720 1k blocks and 96 inodes

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

Anyway, I was able to check the contents of the floppies and wipe them before disposing of them. It’s good to know that some old technologies can still be used when needs be. I won’t be throwing out the old floppy disk drive just yet.

Another look at beeps in Linux

Following my previous post I experimented further with the Linux Kernel configuration options for event beeps (sometimes called ‘system beeps’), and I now have a better understanding of how the Kernel options interact (on one of my laptops, at least).

The sound card in my Clevo W230SS laptop has a VIA VT1802S audio codec chip. I looked at the audio circuit schematic in the service manual; one of the digital input pins on the VT1802S is labelled ‘PCBEEP’, and one of its analogue output pins is labelled ‘PCBEEP’ and is connected to the laptop’s speaker circuit. So there is no PC Speaker in this laptop and it emulates the PC Speaker via the laptop’s sound card, as mentioned in my previous post.

Before I describe my latest results, there are a couple of influencing factors I forgot to mention in my previous post:

  • In some computers the BIOS Menu has one or more options for enabling/disabling beeps. The BIOS menu of my Clevo laptop does not have an option to enable/disable all beeps from the (emulated) PC Speaker, but it does have a couple of options to enable/disable ‘Power On Boot Beep’ and ‘Battery Low Alarm Beep’ (I have disabled them both). Anyway, if you are still not getting beeps after trying everything else, be sure to check the BIOS menu just in case it has an option to enable/disable the PC Speaker.

  • Make sure that bell-style is not set to ‘none‘ (you could set it to ‘audible‘ if you wanted to be sure):

    root # grep bell /etc/inputrc
    # do not bell on tab-completion
    #set bell-style none

The Kernel configuration was initially as shown below. With this configuration no beeps were emitted in a VT (Virtual Terminal) or in an X Windows terminal. As explained in my previous post, I therefore configured the XKB Event Daemon to play an audio file (bell.oga) whenever X Windows detects a BEL character (ASCII 007) or Backspace key (ASCII 008).

root # grep PCSP /usr/src/linux/.config
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_PCSPKR_PLATFORM=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_SND_PCSP is not set
root # grep BEEP /usr/src/linux/.config
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1

Then I rebuilt the Kernel with CONFIG_INPUT_PCSPKR=M and CONFIG_SND_PCSP=M:

root # cd /usr/src/linux
root # mount /dev/sda1 /boot
root # make menuconfig
root # make && make modules_install
root # make install
root # grep PCSP /usr/src/linux/.config
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_INPUT_PCSPKR=m
CONFIG_SND_PCSP=m
root # grep BEEP /usr/src/linux/.config
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1

Then I created the file /etc/modprobe.d/blacklist.conf in order to blacklist the modules pcspkr and snd-pcsp so that only I could load them after boot:

root # cat /etc/modprobe.d/blacklist.conf
blacklist pcspkr
blacklist snd-pcsp

Then I added the line ‘options snd-pcsp index=2‘ to the file /etc/modprobe.d/alsa.conf so that the virtual sound card pcsp would not become the default sound card:

root # tail /etc/modprobe.d/alsa.conf
alias /dev/midi snd-seq-oss

# Set this to the correct number of cards.
options snd cards_limit=1

# See https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1313904
options snd-hda-intel patch=,clevo-hda-patch

# See Kernel Help text for CONFIG_SND_PCSP
options snd-pcsp index=2

Then I rebooted and checked that neither module was loaded:

root # lsmod | grep pcsp
root # echo -e '\a'

root #

As neither module was loaded, the situation was the same as before: a) no beep in a VT; b) no beep in Konsole/Yakuake (I will ignore KDE terminal programs anyway because of KDE bug report no. 177861);* c) the same bell.oga beep in xterm due to my use of xkbevd; d) no changes in ALSA Mixer.

* Regarding Konsole and Yakuake, see my update of October 9, 2016 at the bottom of this post.

Then I loaded the module pcspkr:

root # modprobe pcspkr
root # lsmod | grep pcsp
pcspkr                  1875  0
root # echo -e '\a'

root #

There were no changes in ALSA Mixer. But now the BEL character and Backspace in a VT did result in a beep (I’ll call this a ‘pcbeep’ to distinguish it from the different-sounding beep produced using bell.oga). There was the usual bell.oga beep in xterm due to my use of xkbevd. If I stopped xkbevd, there was no pcbeep in X Windows from the shell commands shown in my previous post, although the following commands from any terminal in X Windows (even Konsole/Yakuake) did emit a pcbeep:

user $ sudo sh -c "echo -e '\a' > /dev/console"

user $ sudo sh -c "tput bel > /dev/console"

root # echo -e '\a' > /dev/console

root # tput bel > /dev/console

Then I unloaded the module pcspkr and loaded the module snd-pcsp:

root # modprobe -r pcspkr
root # modprobe snd-pcsp
root # lsmod | grep pcsp
snd_pcsp                7918  1
root # echo -e '\a'

root #

ALSA Mixer showed a new sound card named ‘pcsp‘ (Sound Card 2) with three channels: ‘Master’, ‘Beep’ and ‘BaseFRQ’. I could mute/unmute ‘Beep’ by pressing ‘M’ on the keyboard as usual, and I could toggle ‘BaseFRQ’ between two values:18643 and 37286. The BEL character and Backspace in a VT resulted in a pcbeep. There was the usual bell.oga beep in xterm due to my use of xkbevd. If I stopped xkbevd, there was no pcbeep in X Windows from the shell commands shown in my previous post, although the following commands from any terminal in X Windows (even Konsole/Yakuake) did emit a pcbeep:

user $ sudo sh -c "echo -e '\a' > /dev/console"

user $ sudo sh -c "tput bel > /dev/console"

root # echo -e '\a' > /dev/console

root # tput bel > /dev/console

Muting ‘Beep’ in ALSA Mixer did not mute the bell.oga beeps in X Windows, but it did mute the pcbeeps in the VTs.

Unlike the situation with the pcspkr module, occasionally there were brief low-volume crackles and pops from the laptop’s speakers.

So both drivers worked, but pcspkr performed better, although it could not be muted via ALSA Mixer. My recommendation to use pcspkr rather than snd-pcsp still stands.

Unlike pcspkr, I had to force the unloading of snd-pcsp:

root # modprobe -r snd-pcsp
modprobe: FATAL: Module snd_pcsp is in use.
root # rmmod -f snd_pcsp
root #

I then removed the Kernel’s ‘digital beep’ interface for the Intel HDA driver by rebuilding the Kernel with CONFIG_SND_HDA_INPUT_BEEP=N:

root # cd /usr/src/linux
root # mount /dev/sda1 /boot
root # make menuconfig
root # make && make modules_install
root # make install
root # grep PCSP /usr/src/linux/.config
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_INPUT_PCSPKR=m
CONFIG_SND_PCSP=m
root # grep BEEP /usr/src/linux/.config
# CONFIG_SND_HDA_INPUT_BEEP is not set
root #

After I rebooted, the behaviour was exactly the same as for CONFIG_SND_HDA_INPUT_BEEP=Y and CONFIG_SND_HDA_INPUT_BEEP_MODE=1.

So, there you have it. I believe my previous post was essentially correct regarding the functional design of the Kernel options. If you have a computer without a PC Speaker but it emulates one via the computer’s sound card, you have to set either CONFIG_INPUT_PCSPKR or CONFIG_SND_PCSP to get a beep in a VT, not set just CONFIG_SND_HDA_INPUT_BEEP and CONFIG_SND_HDA_INPUT_BEEP_MODE. However, even when my laptop emits beeps in a VT from the (emulated) PC Speaker, no beeps from the (emulated) PC Speaker are emitted in X Windows unless the user is the root user and the output is redirected to /dev/console. So, if you want to emit beeps in X Windows it is still better in my opinion to use xkbevd to play an audio file of a beep, as described in my previous post.

Update (October 9, 2016): Regarding KDE’s terminal applications emitting beeps, I am currently using KDE Plasma 5.7.5 and have been able to configure Konsole and Yakuake to play an audio file of a beep (as opposed to emitting a pcbeep) as follows:

  • In Konsole, click on ‘Settings’ > ‘Configure Notifications…’, select ‘Bell in Visible Session’ and ensure ‘Play a sound’ is ticked and a file is specified there (I specify /usr/share/sounds/freedesktop/stereo/bell.oga). If you wish, do the same for ‘Bell in Non-Visible Session’.
  • For Yakuake, press F12 to display the Yakuake window, click on the ‘Open Menu’ icon, select ‘Configure Notifications…’, select ‘Bell in Visible Session’ and ensure ‘Play a sound’ is ticked and a file is specified there (I specify /usr/share/sounds/freedesktop/stereo/bell.oga). If you wish, do the same for ‘Bell in Non-Visible Session’.

To beep, or not to beep, that is the question

Introduction

If your computer running Linux has the necessary hardware and is configured appropriately, applications and shell scripts can trigger a beep to signal an event such as an invalid keyboard entry, shutdown initiation, and so on. To check the current situation with your computer, enter the command shown below. Try it first in a Linux VT (virtual terminal) and then in a terminal window in X Windows. Do you hear a beep in each case?

user $ echo -e '\a'

The above command outputs the BEL character (ASCII code 007).

An alternative to the above command is:

user $ echo -e '\007'

Another command that should produce a beep is:

user $ tput bel

The tput utility is part of the ncurses package.

If you install the package app-misc/beep you can also use the ‘beep’ command (enter the command ‘man beep‘ to see its options):

user $ beep

Although you can enter the above-mentioned commands on the command line, they are intended to be used in shell scripts to notify the user about something.

There are thousands of posts on the Web regarding beeps in Linux, the majority of them concerned with disabling beeps because many people find them annoying. Historically, such beeps were emitted by the so-called ‘PC speaker‘. Note that the PC Speaker is not the same as the speakers connected to the sound card in your computer; the term refers to a small internal loudspeaker (moving-coil or piezoelectric) wired directly to the motherboard and intended solely to emit beeps to notify the user about something. Many modern computers, especially laptops, do not have a PC Speaker and either emulate one via the sound card or do nothing at all.

The reason people sometimes use the terms ‘bell’ and ‘ring’ instead of ‘beep’ is because old teletypwriters and teleprinters actually had an electromechanical bell which would ring when a certain dedicated character was received. I use the terms ‘beep’ and ‘bell’ interchangeably, although I prefer to use the term ‘beep’ when talking about audible notifications by computers.

I was motivated to write this post after helping a Gentoo Linux user to get his laptop to produce beeps (see the Gentoo Linux Forums thread ‘i want to beep [solved]‘). Producing a beep in Linux turns out to be more complicated than you would expect, and I’m not sure I fully understand the functional design of the applicable configuration options in the Kernel, nor their relevance (if any) to the X Windows server’s bell. Now, on the face of it the functionality of the applicable Kernel configuration options appears straightforward, but that is not the case in practice. Anyway, let’s look at how I believe a beep can be achieved (and disabled) in Linux…

PC Speaker drivers

Four Kernel options relate directly to a PC Speaker:

CONFIG_HAVE_PCSPKR_PLATFORM

If this is not set in the Kernel then CONFIG_PCSPKR_PLATFORM cannot be enabled.

CONFIG_PCSPKR_PLATFORM

Enable PC-Speaker support

This option allows to disable the internal PC-Speaker
support, saving some memory.

CONFIG_INPUT_PCSPKR

PC Speaker support

Say Y here if you want the standard PC Speaker to be used for
bells and whistles.

If unsure, say Y.

To compile this driver as a module, choose M here: the
module will be called pcspkr.

CONFIG_SND_PCSP

PC-Speaker support (READ HELP!)

If you don’t have a sound card in your computer, you can include a
driver for the PC speaker which allows it to act like a primitive
sound card.
This driver also replaces the pcspkr driver for beeps.

You can compile this as a module which will be called snd-pcsp.

WARNING: if you already have a soundcard, enabling this
driver may lead to a problem. Namely, it may get loaded
before the other sound driver of yours, making the
pc-speaker a default sound device. Which is likely not
what you want. To make this driver play nicely with other
sound driver, you can add this into your /etc/modprobe.conf:
options snd-pcsp index=2

You don’t need this driver if you only want your pc-speaker to beep.
You don’t need this driver if you have a tablet piezo beeper
in your PC instead of the real speaker.

Say N if you have a sound card.
Say M if you don’t.
Say Y only if you really know what you do.

If your computer does have a PC Speaker, you would use either CONFIG_INPUT_PCSPKR or CONFIG_SND_PCSP, but not both. When configuring the Kernel you can specify ‘M’ to build the driver as an external module, in which case you can decide in userspace whether or not to load it. Or you can specify ‘Y’ to build the driver into the Kernel (do not specify both as ‘Y’ simultaneously, though).

If your computer does have a PC Speaker, an advantage of using CONFIG_SND_PCSP instead of CONFIG_INPUT_PCSPKR is that the former adds a virtual sound card named ‘pcsp’ with a channel (without volume control) named ‘Beep’, and you should be able to mute it via ALSA Mixer.

If you have a computer that has a sound card but does not have a PC Speaker (a laptop’s internal speakers are connected to a sound card, not a PC Speaker), the above two drivers do not really apply. I have always disabled them both in the Kernel, as my laptop does not have a PC Speaker.  Update (September 29, 2016): This is not always the case: if a computer uses a sound card to emulate a PC Speaker (typically laptops do this), then you do need to use one of these two drivers if you want to be able to hear event beeps in a VT — see my latest post Another look at beeps in Linux.

However, apparently for some laptops ALSA Mixer shows a channel named ‘Beep’ (with volume control) for the Intel HDA (High Definition Audio) sound card if CONFIG_INPUT_PCSPKR is set to ‘Y’ or ‘M’. I believe such laptops were designed to use their sound card to emulate a PC Speaker. I do not know whether or not the ‘digital beep’ Kernel options (see further on) are set in such cases, but Kernel bug report no. 13651 would appear to indicate that the design intention is for them to be set.

So, already things are confusing.

Of course, if your computer does have a PC Speaker and you don’t want it to emit beeps, set both CONFIG_INPUT_PCSPKR and CONFIG_INPUT_PCSP to ‘N’ in the Kernel. If either already exists as an external module and you do not wish to rebuild the Kernel, make sure the modules pcspkr and snd-pcsp are not loaded (blacklist them, for example).

Digital Beep

Now, there are two other Kernel options relating to event beeps. These are not for driving a PC Speaker, they are to enable the ALSA Intel HDA driver to emit event beeps in lieu of a PC Speaker: the so-called ‘digital beep’. In other words, these two options are intended to provide an alternative to using a PC Speaker. The two options are:

CONFIG_SND_HDA_INPUT_BEEP

Support digital beep via input layer

Say Y here to build a digital beep interface for HD-audio
driver. This interface is used to generate digital beeps.

CONFIG_SND_HDA_INPUT_BEEP_MODE

Digital beep registration mode (0=off, 1=on)

Set 0 to disable the digital beep interface for HD-audio by default.
Set 1 to always enable the digital beep interface for HD-audio by
default.

Note that the mode ‘2’ is no longer an option in newer Kernels.

So, if your installation uses the Intel HDA driver and you want your computer’s sound card to be able to emit beeps instead of a PC Speaker (which your computer may or may not have), set these two accordingly in the Kernel configuration:

user $ grep CONFIG_SND_HDA_INPUT_BEEP /usr/src/linux/.config
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1

The functional design of these Kernel options is not clear, but Kernel bug report no. 13651 appears to indicate that the design intention is for CONFIG_SND_HDA_INPUT_BEEP and CONFIG_SND_HDA_INPUT_BEEP_MODE to be used in addition to either CONFIG_INPUT_PCSPKR or CONFIG_SND_PCSP, not instead of them. In other words, if your computer has a PC Speaker but you want beeps to be routed via its Intel HDA sound card instead then I believe you are expected to use either of the following two sets of options:

Option 1
CONFIG_HAVE_PCSPKR_PLATFORM=Y
CONFIG_PCSPKR_PLATFORM=Y
CONFIG_INPUT_PCSPKR=Y (or =M)
CONFIG_SND_HDA_INPUT_BEEP=Y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1

Option 2
CONFIG_HAVE_PCSPKR_PLATFORM=Y
CONFIG_PCSPKR_PLATFORM=Y
CONFIG_SND_PCSP=Y (or =M)
CONFIG_SND_HDA_INPUT_BEEP=Y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1

On the other hand, if your computer has a PC Speaker and your installation uses the Intel HDA driver for a sound card but you do want your computer to emit beeps from the PC Speaker, I think you would set the two options as follows in the Kernel configuration:

CONFIG_SND_HDA_INPUT_BEEP=N
CONFIG_SND_HDA_INPUT_BEEP_MODE=0

If you read the comment by ALSA developer Takashi Iwai quoted in Kernel bug report no. 13651 you’ll see that the functionality is not at all straightforward. For example, on some computers, especially laptops (which normally do not have a PC Speaker), the beep may be emitted via the sound card irrespective of whether or not you set CONFIG_SND_HDA_INPUT_BEEP.

X Windows

A beep can be emitted in X Windows, and I have seen this beep referred to as the ‘X Windows server bell’ or the ‘X Windows keyboard bell’.

Given that X Windows can emit a beep via the sound card when neither the pcspkr module nor the snd-pcsp module is loaded and CONFIG_SND_HDA_INPUT_BEEP=N and CONFIG_SND_HDA_INPUT_BEEP_MODE=0, I assume X Windows emits beeps directly to the default sound card irrespective of the settings of those Kernel options. I could be wrong, but I have not found any explanation on the Web about the underlying mechanism; the X.Org Web site FAQ ‘How can I configure the Xserver bell (xkbbell) to use the sound subsystem of my computer? (ALSA, OSS, etc.)‘ simply states:

Answer (hopefully) goes here.. 🙂

*shrug*.

Below is a summary of the commands to disable, enable and configure the beep in X Windows.

To disable beeps in X Windows:

user $ xset b off

To enable beeps in X Windows:

user $ xset b on

To change the volume, pitch and duration of the beeps:

user $ xset b <volume> <pitch> <duration>

For example, to set the beep volume to 25% without changing the pitch and duration:

user $ xset b 25

To return to the default settings:

user $ xset b

To view the current settings:

user $ xset q | grep bell

which displays the following (default) values in my case:

bell percent:  50        bell pitch:    400        bell duration:    100

To set the beep automatically each time X Windows starts, add the following line before the last one in the ~/.xinitrc file if you don’t use a Desktop Manager, otherwise use the Desktop Environment’s system settings GUI to run it at login:

xset b 20 400 20 &

PulseAudio

To confuse matters further, note that PulseAudio intercepts X11 beeps (see: PulseAudio Documentation – User Documentation – Modules – X Window system – module-x11-bell). Therefore, if your installation uses PulseAudio and you want the ability to emit event beeps in X Windows, you also need to configure PulseAudio so it does not ignore the beeps. This can either be done from the command line:

user $ pactl upload-sample /usr/share/sounds/freedesktop/stereo/bell.oga x11-bell
user $ pactl load-module module-x11-bell sample=x11-bell display=$DISPLAY

or you can edit /etc/pulse/default.pa and make sure the following lines are included in that file (they may already exist but are commented out):

load-sample-lazy x11-bell /usr/share/sounds/freedesktop/stereo/bell.oga
load-module module-x11-bell sample=x11-bell

On the other hand, if PulseAudio is installed and you want it to ignore event beeps in X Windows, delete or comment out the above-mentioned two lines in /etc/pulse/default.pa. You can achieve the same effect from the command line:

user $ pactl unload-module module-x11-bell

Configuring userspace to emit a ‘digital beep’

Installation of PulseAudio will have created the directory /usr/share/sounds/freedesktop/ and sub-directories containing various Ogg Vorbis audio files, including the ‘digital beep’ file bell.oga. If your installation does not have PulseAudio installed, you can obtain the same file /usr/share/sounds/freedesktop/stereo/bell.oga by installing the package x11-themes/sound-theme-freedesktop instead. You can configure your installation to use this file to emit a ‘digital beep’ in X Windows (but not in a VT) by using the XKB (X Windows keyboard extension) event daemon as explained in a post on the superuser Web site. That post relates to Ubuntu, but the basic principle applies whatever the Linux distribution.

Now, in my case I am using KDE Plasma 5 in Gentoo Linux, and I cannot hear any beep/bell in Konsole and Yakuake. I came across KDE bug report no. 177861 that has been outstanding since 2008, which indicated that KDE’s terminal applications will not emit beeps even if you do have a PC Speaker and your Kernel has been correctly configured to use it, or even if you have configured your installation to use a ‘digital beep’. You may have better luck with a different Desktop Environment but in KDE you will have to use a non-KDE X Windows terminal application if you want to hear beeps produced by shell scripts.

Update (October 9, 2016): Regarding KDE’s terminal applications emitting beeps, I am currently using KDE Plasma 5.7.5 and have been able to configure Konsole and Yakuake to emit a ‘digital beep’ as follows:

  • In Konsole, click on ‘Settings’ > ‘Configure Notifications…’, select ‘Bell in Visible Session’ and ensure ‘Play a sound’ is ticked and a file is specified there (I specify /usr/share/sounds/freedesktop/stereo/bell.oga). If you wish, do the same for ‘Bell in Non-Visible Session’.
  • For Yakuake, press F12 to display the Yakuake window, click on the ‘Open Menu’ icon, select ‘Configure Notifications…’, select ‘Bell in Visible Session’ and ensure ‘Play a sound’ is ticked and a file is specified there (I specify /usr/share/sounds/freedesktop/stereo/bell.oga). If you wish, do the same for ‘Bell in Non-Visible Session’.

Below I explain how I implemented a ‘digital beep’ in KDE Plasma 5.

First I installed the XKB event daemon:

root # emerge xkbevd

The package vorbis-tools was already installed, otherwise I would have installed that too in order to install an audio player for Ogg Vorbis audio files:

root # emerge vorbis-tools

PulseAudio was also already installed, and hence an appropriate audio file for a beep already existed. Had I not previously installed PulseAudio I would have installed the following package to get an appropriate Ogg Vorbis audio file:

root # emerge sound-theme-freedesktop

I created the file /home/fitzcarraldo/.config/autostart/xkbevd.desktop containing the following:

[Desktop Entry]
Comment[en_GB]=Software terminal bell
Comment=Software terminal bell
Exec=xkbevd -bg
GenericName[en_GB]=XKB Event Daemon
GenericName=XKB Event Daemon
Icon=system-run
MimeType=
Name[en_GB]=XKB Event Daemon
Name=XKB Event Daemon
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=fitzcarraldo	

and I changed its permissions:

user $ chmod 755 /home/fitzcarraldo/.config/autostart/xkbevd.desktop

I created the file /home/fitzcarraldo/.xkb/xkbevd.cf containing the following:

soundDirectory="/usr/share/sounds/"
soundCmd="ogg123 -q"

Bell() "freedesktop/stereo/bell.oga"

If the file /usr/share/sounds/freedesktop/stereo/bell.oga does not exist in your installation then you can copy any suitable audio file of your choice into the directory /usr/share/sounds/ or use one of the existing audio files in that directory, and specify its filename in xkbevd.cf. For example:

soundDirectory="/usr/share/sounds/"
soundCmd="aplay -q"

Bell() "beep.wav"

Notice that the choice of audio player is up to you. In the first example of xkbevd.cf I specified the ogg123 player, whereas in the second example I specified the aplay player.

The aforementioned bug in KDE Konsole and Yakuake prevented me from testing the use of the XKB event daemon, so I installed a non-KDE X Windows terminal application to see if the ‘digital beep’ would work in that:

root # emerge xterm

The command echo -e '\a' generates a beep in xterm. So the ‘digital beep’ approach does work, albeit use of the XKB event daemon means you are limited to using it in X Windows. To reiterate, as the XKB event daemon is for X Windows, no ‘digital beep’ is generated if you enter a beep command outside of X Windows (e.g. in a VT).

By the way, I’m currently using Gentoo Stable Branch and hence Version 5.6.5 of KDE Plasma, and there is another KDE bug to complicate matters further: ‘System Settings’ > ‘Autostart’ > ‘Add Program…’ does not save all the entries I make via the GUI to the .desktop file, and does not set the file permissions correctly either. I don’t know if that is an upstream bug or a bug in the Gentoo implementation of Plasma 5.6.5. Anyway, that is why I manually created xkbevd.desktop and manually set the permissions, rather than using System Settings.

Instead of launching the XKB event daemon by using a .desktop file in ~/.config/autostart/, if you don’t use a Desktop Manager you could launch it by adding the command in the file ~/.xinitrc.

Summary

All the following factors govern whether or not your computer will issue a beep for the BEL character:

  • the specific hardware and firmware in your computer;
  • CONFIG_HAVE_PCSPKR_PLATFORM;
  • CONFIG_PCSPKR_PLATFORM;
  • CONFIG_INPUT_PCSPKR;
  • CONFIG_SND_PCSP;
  • CONFIG_SND_HDA_INPUT_BEEP;
  • CONFIG_SND_HDA_INPUT_BEEP_MODE;
  • X Windows settings;
  • PulseAudio configuration (if installed);
  • a bug in KDE’s terminal applications (if installed).

A. If you are hearing event beeps but don’t want them:

  • Preferably, set CONFIG_HAVE_PCSPKR_PLATFORM and CONFIG_PCSPKR_PLATFORM both to ‘N’.
  • Either set both CONFIG_INPUT_PCSPKR and CONFIG_SND_PCSP to ‘N’ in your Kernel, or, if either driver exists as a module (pcspkr and snd-pcsp, respectively), blacklist it.
  • Make sure CONFIG_SND_HDA_INPUT_BEEP is set to ‘N’.
  • Make sure the X Windows bell is turned off.
  • If you also have PulseAudio installed, make sure the PulseAudio module module-x11-bell is not loaded (also check /etc/pulse/default.pa to see if it has been enabled by default).

B. If you are not hearing event beeps but you do want to hear them:

1. If you are sure your computer has a PC Speaker:

  • Make sure CONFIG_HAVE_PCSPKR_PLATFORM and CONFIG_PCSPKR_PLATFORM are set to ‘Y’.
  • Either set CONFIG_INPUT_PCSPKR to ‘M’ and CONFIG_SND_PCSP to ‘N’ in your Kernel, or, if the module snd-pcsp already exists, blacklist it.
  • Make sure the module pcspkr exists and is not blacklisted.
  • Make sure the module pcspkr is loaded after the module snd-hda-intel.
  • Make sure CONFIG_SND_HDA_INPUT_BEEP is set to ‘N’.
  • Make sure the X Windows bell is turned on and the volume is turned up.
  • If you have PulseAudio installed, make sure the PulseAudio module module-x11-bell is loaded (check /etc/pulse/default.pa to ensure it includes the applicable lines, or issue the two commands listed earlier).
  • If you use KDE, use a non-KDE terminal application until KDE bug report no. 177861 is fixed.
  • If, after doing all the above, you still do not hear a beep in X Windows, follow the procedure in the section above titled Configuring userspace to emit a ‘digital beep’.

Above I have recommended using pcspkr. However, an advantage of using snd-pcsp instead is that it adds a virtual sound card with a channel named ‘Beep’ and you should be able to mute that channel via ALSA Mixer as you wish. Therefore, if you do opt to use the module snd-pcsp instead of pcspkr then make sure you specify the module option (or Kernel Quirk if you built the driver into the Kernel) described in the Kernel Help text quoted earlier, so that pcsp does not become the default sound card instead of the Intel HDA sound card.

2. If your computer does not have a PC Speaker:

  • Preferably, set CONFIG_HAVE_PCSPKR_PLATFORM and CONFIG_PCSPKR_PLATFORM both to ‘N’. *
  • If you leave CONFIG_HAVE_PCSPKR_PLATFORM and CONFIG_PCSPKR_PLATFORM both set to ‘Y’, either set CONFIG_INPUT_PCSPKR and CONFIG_SND_PCSP both to ‘N’, or, if either module already exists, blacklist it. *
  • Make sure CONFIG_SND_HDA_INPUT_BEEP is set to ‘Y’ and CONFIG_SND_HDA_INPUT_BEEP_MODE is set to ‘1’ (I’m not sure this step is required for all computers).
  • Make sure the X Windows bell is turned on and its volume is turned up.
  • If you have PulseAudio installed, make sure the PulseAudio module module-x11-bell is loaded.
  • Use the XKB Event Daemon method to play an audio file (‘digital beep’) when the BEL character is detected in X Windows.
  • If you use KDE, use a non-KDE terminal application until KDE bug report no. 177861 is fixed.
    Update (October 9, 2016): Regarding KDE’s terminal applications emitting beeps, I am currently using KDE Plasma 5.7.5 and have been able to configure Konsole and Yakuake to emit a ‘digital beep’ — see my update in the section titled Configuring userspace to emit a ‘digital beep’.

    * If your computer’s hardware and firmware have been designed to emulate a PC Speaker via a sound card, you may find that you can use the pcspkr (or snd-pcsp) driver to generate beeps in a VT. As the saying goes, your mileage may vary.

    And Finally

    If you know precisely how all these Kernel options are supposed to interact, do comment. Or if you know the relationship, if any, between the X Windows beep (a.k.a. ‘bell’) and these Kernel options, please also comment.

    Update (September 29, 2016): See my latest post Another look at beeps in Linux for the results of some experiments with these Kernel options on my laptop, giving more insight into how to configure them and how they work.

Gentoo Linux installations without initramfs: Updating Intel CPU microcode revisited

In a previous post I described how I updated the CPU microcode on my Clevo W230SS laptop running Gentoo Linux (Stable Branch). Today I decided to check if a newer version of microcode had been released since then and apply it.

First I checked the current state of my installation…

The CPU microcode version in use was the version I had installed last year:

root # grep microcode /proc/cpuinfo
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c
microcode       : 0x1c

The existing kernel image was still configured as necessary:

root # grep CONFIG_BLK_DEV_INITRD /usr/src/linux/.config
CONFIG_BLK_DEV_INITRD=y
root # grep CONFIG_MICROCODE /usr/src/linux/.config
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
root # CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_EARLY=y
root # CONFIG_MICROCODE_AMD_EARLY is not set
CONFIG_MICROCODE_EARLY=y
root # grep CONFIG_INITRAMFS_SOURCE /usr/src/linux/.config
CONFIG_INITRAMFS_SOURCE=""

The relevant packages I installed last year were sys-apps/microcode-ctl-1.28-r1, sys-apps/microcode-data-20150121-r1 and sys-apps/iucode_tool-1.3. Since then I have updated the installation regularly, and I now found microcode-ctl-1.28-r1 and iucode_tool-1.5 installed but the package microcode-data had been replaced by the new package sys-firmware/intel-microcode-20160607:

root # eix microcode
[I] sys-apps/microcode-ctl
     Available versions:  1.23 (~)1.27 (~)1.28 (~)1.28-r1 {selinux}
     Installed versions:  1.28-r1(15:06:33 26/08/15)(-selinux)
     Homepage:            https://fedorahosted.org/microcode_ctl/
     Description:         Intel processor microcode update utility

[I] sys-firmware/intel-microcode
     Available versions:  20140430 (~)20140624 (~)20140913 20150121 (~)20150121-r1 (~)20151106 (~)20160607 {initramfs monolithic +split-ucode}
     Installed versions:  20160607(23:02:24 25/06/16)(initramfs split-ucode -monolithic)
     Homepage:            http://inertiawar.com/microcode/ https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=26083
     Description:         Intel IA32/IA64 microcode update data

Found 2 matches
root # eix iucode_tool
[I] sys-apps/iucode_tool
     Available versions:  (~)1.3 (~)1.5
     Installed versions:  1.5(15:57:21 13/12/15)
     Homepage:            https://gitlab.com/iucode-tool/
     Description:         tool to manipulate Intel X86 and X86-64 processor microcode update collections

I checked the relevant contents of package.use and package.accept_keywords and found that Portage had updated automatically the files to reflect the replacement of package sys-apps/microcode-data by the package sys-firmware/intel-microcode (Portage is an excellent package manager!):

root # cat /etc/portage/package.use/microcode-data
# move sys-apps/microcode-data sys-firmware/intel-microcode
sys-firmware/intel-microcode initramfs
root # cat /etc/portage/package.accept_keywords/microcode-data
# move sys-apps/microcode-data sys-firmware/intel-microcode
sys-firmware/intel-microcode ~amd64
sys-apps/iucode_tool ~amd64

The file /lib/firmware/microcode.cpio and the contents of /lib/firmware/intel-ucode/ had indeed changed since I applied the last CPU microcode update:

root # ls -la /lib/firmware/microcode.cpio
-rw-r--r-- 1 root root 946176 Jun 25 23:02 /lib/firmware/microcode.cpio
root # ls -la /lib/firmware/intel-ucode/
total 1052
drwxr-xr-x  2 root root  4096 Jun 25 23:02 .
drwxr-xr-x 75 root root 16384 Jun 25 23:02 ..
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-03-02
-rw-r--r--  1 root root  6144 Jun 25 23:02 06-05-00
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-05-01
-rw-r--r--  1 root root  6144 Jun 25 23:02 06-05-02
-rw-r--r--  1 root root  8192 Jun 25 23:02 06-05-03
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-06-00
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-06-05
-rw-r--r--  1 root root  6144 Jun 25 23:02 06-06-0a
-rw-r--r--  1 root root  6144 Jun 25 23:02 06-06-0d
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-07-01
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-07-02
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-07-03
-rw-r--r--  1 root root 10240 Jun 25 23:02 06-08-01
-rw-r--r--  1 root root  4096 Jun 25 23:02 06-08-03
-rw-r--r--  1 root root 10240 Jun 25 23:02 06-08-06
-rw-r--r--  1 root root  6144 Jun 25 23:02 06-08-0a
-rw-r--r--  1 root root  6144 Jun 25 23:02 06-09-05
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-0a-00
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-0a-01
-rw-r--r--  1 root root  4096 Jun 25 23:02 06-0b-01
-rw-r--r--  1 root root  4096 Jun 25 23:02 06-0b-04
-rw-r--r--  1 root root  2048 Jun 25 23:02 06-0d-06
-rw-r--r--  1 root root  4096 Jun 25 23:02 06-0e-08
-rw-r--r--  1 root root  8192 Jun 25 23:02 06-0e-0c
-rw-r--r--  1 root root  8192 Jun 25 23:02 06-0f-02
-rw-r--r--  1 root root 12288 Jun 25 23:02 06-0f-06
-rw-r--r--  1 root root  8192 Jun 25 23:02 06-0f-07
-rw-r--r--  1 root root  4096 Jun 25 23:02 06-0f-0a
-rw-r--r--  1 root root 28672 Jun 25 23:02 06-0f-0b
-rw-r--r--  1 root root 12288 Jun 25 23:02 06-0f-0d
-rw-r--r--  1 root root 12288 Jun 25 23:02 06-16-01
-rw-r--r--  1 root root 20480 Jun 25 23:02 06-17-06
-rw-r--r--  1 root root  4096 Jun 25 23:02 06-17-07
-rw-r--r--  1 root root 24576 Jun 25 23:02 06-17-0a
-rw-r--r--  1 root root 14336 Jun 25 23:02 06-1a-04
-rw-r--r--  1 root root 10240 Jun 25 23:02 06-1a-05
-rw-r--r--  1 root root 15360 Jun 25 23:02 06-1c-02
-rw-r--r--  1 root root 20480 Jun 25 23:02 06-1c-0a
-rw-r--r--  1 root root  4096 Jun 25 23:02 06-1d-01
-rw-r--r--  1 root root  6144 Jun 25 23:02 06-1e-04
-rw-r--r--  1 root root  7168 Jun 25 23:02 06-1e-05
-rw-r--r--  1 root root  8192 Jun 25 23:02 06-25-02
-rw-r--r--  1 root root  3072 Jun 25 23:02 06-25-05
-rw-r--r--  1 root root 10240 Jun 25 23:02 06-26-01
-rw-r--r--  1 root root 10240 Jun 25 23:02 06-2a-07
-rw-r--r--  1 root root 16384 Jun 25 23:02 06-2d-06
-rw-r--r--  1 root root 17408 Jun 25 23:02 06-2d-07
-rw-r--r--  1 root root 13312 Jun 25 23:02 06-2f-02
-rw-r--r--  1 root root 12288 Jun 25 23:02 06-3a-09
-rw-r--r--  1 root root 22528 Jun 25 23:02 06-3c-03
-rw-r--r--  1 root root 17408 Jun 25 23:02 06-3d-04
-rw-r--r--  1 root root 13312 Jun 25 23:02 06-3e-04
-rw-r--r--  1 root root 11264 Jun 25 23:02 06-3e-06
-rw-r--r--  1 root root 15360 Jun 25 23:02 06-3e-07
-rw-r--r--  1 root root 32768 Jun 25 23:02 06-3f-02
-rw-r--r--  1 root root 15360 Jun 25 23:02 06-3f-04
-rw-r--r--  1 root root 20480 Jun 25 23:02 06-45-01
-rw-r--r--  1 root root 24576 Jun 25 23:02 06-46-01
-rw-r--r--  1 root root 11264 Jun 25 23:02 06-47-01
-rw-r--r--  1 root root 96256 Jun 25 23:02 06-4e-03
-rw-r--r--  1 root root 25600 Jun 25 23:02 06-4f-01
-rw-r--r--  1 root root 28672 Jun 25 23:02 06-56-02
-rw-r--r--  1 root root 96256 Jun 25 23:02 06-5e-03
-rw-r--r--  1 root root  4096 Jun 25 23:02 0f-00-07
-rw-r--r--  1 root root  6144 Jun 25 23:02 0f-00-0a
-rw-r--r--  1 root root  2048 Jun 25 23:02 0f-01-02
-rw-r--r--  1 root root  6144 Jun 25 23:02 0f-02-04
-rw-r--r--  1 root root  8192 Jun 25 23:02 0f-02-05
-rw-r--r--  1 root root  2048 Jun 25 23:02 0f-02-06
-rw-r--r--  1 root root  6144 Jun 25 23:02 0f-02-07
-rw-r--r--  1 root root  6144 Jun 25 23:02 0f-02-09
-rw-r--r--  1 root root  2048 Jun 25 23:02 0f-03-02
-rw-r--r--  1 root root  2048 Jun 25 23:02 0f-03-03
-rw-r--r--  1 root root  7168 Jun 25 23:02 0f-03-04
-rw-r--r--  1 root root 10240 Jun 25 23:02 0f-04-01
-rw-r--r--  1 root root  2048 Jun 25 23:02 0f-04-03
-rw-r--r--  1 root root  3072 Jun 25 23:02 0f-04-04
-rw-r--r--  1 root root  3072 Jun 25 23:02 0f-04-07
-rw-r--r--  1 root root  9216 Jun 25 23:02 0f-04-08
-rw-r--r--  1 root root  2048 Jun 25 23:02 0f-04-09
-rw-r--r--  1 root root  4096 Jun 25 23:02 0f-04-0a
-rw-r--r--  1 root root  3072 Jun 25 23:02 0f-06-02
-rw-r--r--  1 root root  6144 Jun 25 23:02 0f-06-04
-rw-r--r--  1 root root  2048 Jun 25 23:02 0f-06-05
-rw-r--r--  1 root root  2048 Jun 25 23:02 0f-06-08

So I was in a position to apply the latest CPU microcode…

I mounted the /boot partition:

root # mount /dev/sda1 /boot
root # ls -1 /boot
System.map-3.18.11-gentoo
config-3.18.11-gentoo
grub
lost+found
microcode.cpio
vmlinuz-3.18.11-gentoo

Then I copied the new version of the file microcode.cpio to the /boot partition:

root # cp /lib/firmware/microcode.cpio /boot/

I made sure /boot/grub/grub.cfg still contained the extra line ‘initrd /microcode.cpio‘ I had added in the past:

root # grep -B 15 -A 1 initrd /boot/grub/grub.cfg

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {
        load_video
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  f6ffc085-66fe-4bbe-b080-cec355749f85
        else
          search --no-floppy --fs-uuid --set=root f6ffc085-66fe-4bbe-b080-cec355749f85
        fi
        echo    'Loading Linux 3.18.11-gentoo ...'
        linux   /vmlinuz-3.18.11-gentoo root=/dev/sda5 ro  drm_kms_helper.edid_firmware=edid/1920x1080_Clevo_W230SS.bin i915.modeset=1 rcutree.rcu_idle_gp_delay=1 acpi_enforce_resources=lax
        initrd /microcode.cpio
}
submenu 'Advanced options for Gentoo GNU/Linux' $menuentry_id_option 'gnulinux-advanced-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {
        menuentry 'Gentoo GNU/Linux, with Linux 3.18.11-gentoo' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.18.11-gentoo-advanced-525a90f1-8ad2-44a3-ade3-20f18a0a9595' {
                load_video
                insmod gzio
                insmod part_msdos
                insmod ext2
                set root='hd0,msdos1'
                if [ x$feature_platform_search_hint = xy ]; then
                  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  f6ffc085-66fe-4bbe-b080-cec355749f85
                else
                  search --no-floppy --fs-uuid --set=root f6ffc085-66fe-4bbe-b080-cec355749f85
                fi
                echo    'Loading Linux 3.18.11-gentoo ...'
                linux   /vmlinuz-3.18.11-gentoo root=/dev/sda5 ro  drm_kms_helper.edid_firmware=edid/1920x1080_Clevo_W230SS.bin i915.modeset=1 rcutree.rcu_idle_gp_delay=1 acpi_enforce_resources=lax
                initrd /microcode.cpio
        }

Then I rebooted and checked to make sure the new version of CPU microcode is being applied:

root # grep microcode /proc/cpuinfo
microcode       : 0x20
microcode       : 0x20
microcode       : 0x20
microcode       : 0x20
microcode       : 0x20
microcode       : 0x20
microcode       : 0x20
microcode       : 0x20
root # dmesg | grep microcode
[    0.000000] CPU0 microcode updated early to revision 0x20, date = 2016-03-16
[    0.049437] CPU1 microcode updated early to revision 0x20, date = 2016-03-16
[    0.064540] CPU2 microcode updated early to revision 0x20, date = 2016-03-16
[    0.079569] CPU3 microcode updated early to revision 0x20, date = 2016-03-16
[    0.265322] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x20
[    0.265425] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x20
[    0.265524] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x20
[    0.265620] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x20
[    0.265717] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x20
[    0.265815] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x20
[    0.265913] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x20
[    0.266011] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x20
[    0.266127] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Notice the microcode version has changed from 0x1c to 0x20. Mission accomplished. 🙂

Eliminating the loud hum from powered speakers connected to my laptop

My external powered speakers emit a loud, annoying hum if I plug them into the headphones socket of my Clevo W230SS laptop. The hum stops if I unplug the laptop’s mains charger, so the problem is due to an earth loop (a.k.a. ‘ground loop’). The charger’s recessed socket for connecting its mains lead has three prongs (IEC 60320 C6), i.e. the charger is not double-insulated. The recessed socket on a double-insulated mains charger would only have two prongs (IEC 60320 C8), and the label on a double-insulated charger in the UK usually has an icon consisting of two concentric squares. I suspect the audio circuitry in the Clevo W230SS is not very well designed, as there is virtually no hum from the same powered speakers if I plug them into the headphones socket of my Compal NBLB2 laptop while its mains charger, which has the same IEC 60320 C5/C6 coupler design as the Clevo laptop’s charger, is connected.

Now, I could have purchased a ground loop isolator, a passive device which is basically a couple of transformers (one per stereo channel), to interpose between the headphones socket on my laptop and the external powered speakers.

The YouTube video Solving Laptop Noise and Ground Loop Audio Interference contains a demonstration of what happens when you use a ground loop isolator on the headphones output of a laptop, and what happens when you use a double-insulated mains charger (two-prong coupler, rather than three-prong).

However, rather than buy a ground loop isolator I decided to try an active device, and purchased the XQ-10 portable headphones amplifier manufactured by Chinese company xDuoo. The XQ-10 is compact, fitting in the palm of my hand and weighing only 30 grammes. It has an aluminium-alloy case, and looks and feels well-made. Two cables are supplied: a USB cable to connect the XQ-10 to a phone charger or laptop in order to charge the LiPo battery in the XQ-10 (about 2 hours to charge, and about 20 hours of use on battery power), and a short 3.5 mm jack cable (male jack at both ends) to connect the XQ-10 to your laptop or phone.

xDuoo XQ-10

If the XQ-10’s USB charging cable is not connected (see the photograph above) then the loud hum from my external powered speakers still occurs. But with both cables connected (see the photograph below), the XQ-10 does the job perfectly: there is no hum or hiss, even when I turn the speakers’ volume knob to maximum.

xDuoo XQ-10

Although I do not need to use a headphones amplifier with the laptop when I use headphones or earphones — the volume is fine and there is no hum from headphones/earphones — I should mention that audio quality from my headphones and earphones connected to the XQ-10 is excellent (both with and without the USB charging cable connected, which is not surprising given that no earth loop exists when headphones/earphones are connected).

By the way, shop around if you do decide to buy the XQ-10, because its price on-line varies a lot. I paid GBP 17.95 for mine, and that included p&p.

Text too small in X Windows when using nvidia-drivers

In an earlier post titled ‘Switching between Intel and NVIDIA graphics processors on a laptop with NVIDIA Optimus hardware running Gentoo Linux‘ I described how I am able to switch between the closed-source NVIDIA video driver and the open-source Intel video driver on a Clevo W230SS laptop with NVIDIA Optimus hardware. This works nicely, but one thing had been niggling me for over a year: the size of the fonts in the Desktop Environment were much smaller when using the NVIDIA driver than when using the Intel driver. I could of course increase the font size via KDE’s ‘System Settings’ > ‘Font’ when using the NVIDIA driver, but then I would have to reduce the font size the same way when using the Intel driver. So I resolved to find a better way, and it turned out all I needed to do was add one line to the Monitor section in xorg.conf to specify the DPI (Dots Per Inch) for the X Screen when using the NVIDIA driver:

Section "Monitor"
    Identifier     "Monitor0"
    Option         "DPMS"
    Option         "DPI" "96 x 96"
EndSection

You can read more about this in the NVIDIA Accelerated Linux Graphics Driver README and Installation Guide, Appendix B. X Config Options.

As described in my earlier post, I run a script to copy a file I named xorg.conf.nvidia to xorg.conf when I want to use the NVIDIA driver, and another script to copy a file I named xorg.conf.intel to xorg.conf when I want to use the Intel driver. So all I needed to do was add the line Option "DPI" "96 x 96" to the Monitor section in the file xorg.conf.nvidia and run my script to switch to the NVIDIA driver. Problem finally solved.

Getting KDE Plasma 5 to work with the NVIDIA closed-source driver in Gentoo Linux

Up until a few days ago I had avoided migrating from KDE 4 to KDE Plasma 5, Frameworks 5 and Applications 5 — I’ll refer to the latter three package categories collectively as ‘KDE:5’ — on my main laptop, a Clevo W230SS with NVIDIA Optimus hardware and Gentoo Linux Stable Branch installed. My reluctance to migrate to KDE:5 was because of various problems I experience in KDE:5 on my Compal NBLB2 laptop, which has Gentoo Testing Branch installed (currently Plasma 5.7.1, which you would expect to be less buggy than Plasma 5.5.5 in the Gentoo Stable Branch).

Recently the maintainers of Gentoo’s KDE ebuilds removed some of the KDE 4 ebuilds and made some of the other ebuilds dependent on KDE:5. It became more complicated and convoluted to keep KDE 4 going, so I reluctantly threw in the towel and migrated to KDE:5 on my main laptop. I wish I could have kept KDE 4 on that machine, as KDE 4 worked extremely well (and looked great too).

My first problem after migrating was the infamous black screen in X Windows at start-up. Trying the various suggestions in the Gentoo Wiki did not help and, for the first time since I’ve owned the Clevo laptop, I was glad it has NVIDIA Optimus hardware as I was able to change from using nvidia-drivers to using xf86-video-intel, which got me to a usable Desktop after I switched desktop managers from SDDM (see the system log file error messages below) to LightDM.

Jul 17 04:32:37 clevow230ss sddm-helper[3245]: PAM unable to dlopen(/lib64/security/pam_systemd.so): /lib64/security/pam_systemd.so: cannot open shared object file: No such file or directory
Jul 17 04:32:37 clevow230ss sddm-helper[3245]: PAM adding faulty module: /lib64/security/pam_systemd.so

Although I had merged x11-misc/sddm with USE="-systemd" because my installation uses OpenRC, the above error messages made me suspect that something is wrong with the sddm-0.13.0-r3 ebuild, which is why I switched to LightDM.

However, using solely the Intel driver is not a long-term solution for me because DraftSight CAD software is slower with the Intel driver, so I was keen to get Plasma 5 working with the closed-source NVIDIA driver (I do not want to use Bumblebee).

I managed to get LightDM and Plasma 5 working with nvidia-drivers by doing the following:

  1. Merge x11-misc/lightdm.
  2. Re-merge kde-plasma/plasma-meta with USE="-sddm".
  3. Remove the x11-misc/sddm package and kde-plasma/sddm-kcm package by using the command ‘emerge --ask --depclean‘.
  4. Edit the file /etc/lightdm/lightdm.conf to add the line ‘greeter-session=lightdm-kde-greeter‘ as specified in Gentoo Wiki article LightDM.
  5. Edit the file /etc/lightdm/lightdm.conf to add the line ‘display-setup-script=/etc/X11/Sessions/plasma‘ (any file name would do).
  6. Create the above-mentioned Bash script /etc/X11/Sessions/plasma containing the following:
#!/bin/bash
GPU=`eselect opengl list | grep \* | awk '{ print $2 }'`
if [ "$GPU" = "nvidia" ]; then
    xrandr --setprovideroutputsource modesetting NVIDIA-0
    xrandr --auto
fi

I can now switch between the NVIDIA closed-source driver and the Intel open-source driver using the method described in an earlier post: Switching between Intel and NVIDIA graphics processors on a laptop with NVIDIA Optimus hardware running Gentoo Linux.

No sound from headphones after resume from suspension / No sound from headphones after re-plug

It is not difficult to find posts on the Web regarding certain models of laptop that no longer produce sound from headphones after resuming from suspension, or no longer produce sound from their speakers or from headphones if you unplug and reconnect the headphones. My Clevo W230SS laptop suffered from these problems and more: sometimes the external microphone socket would no longer work either. I had to reboot the laptop in order to get audio working properly again.

The cause of these problems varies according to the specific hardware and software, and here I will describe a couple of fixes I implemented in Gentoo Linux for my Clevo W230SS laptop. Bear in mind that what works for one model of laptop may not necessarily work for a different model even if the symptoms are the same.

PROBLEM 1: No sound from headphones after resume from suspension

After my laptop resumed from suspension, headphones would no longer work until I rebooted the laptop. Sometimes an external microphone would also stop working until I rebooted. In 2014, Ubuntu user Kiril filed a bug report regarding this problem with the Clevo W230SS: [W230SS, VIA VT1802, Green Headphone Out, Front] No sound after suspend/resume. Actually, his original title for the bug report was: ‘[W230SS, VIA VT1802, Green Headphone Out, Front] No sound after fresh boot’. I didn’t have that problem: the headphone socket of my Clevo W230SS did produce sound after a ‘fresh boot’. Regarding Kiril‘s initial problem, ALSA developer Raymond Yau made several comments, including the following:

driver should not use same audio output for device 0 and device 2

independent headphone should be disabled on notebook by default

for desktop line out and headphone connected to different audio output nodes 0x03 and 0x04

this allow you to play different audio to line out and headphone

but this feature usually should be disabled for notebook

you need to file an upstream bug report to fix this bug in the indep_hp_possible function which should return false when there is no internal mic since some notebook have line out, headphone and Mic jack to support 5.1 or only enabled when headphone at extra front and line out at ext rear

the workaround is use hint to disable the indep_hp=0

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/alsa/HD-Audio.txt

Now, Kiril was using Ubuntu 14.04 and ALSA 1.0.27, whereas I’m using Gentoo and ALSA 1.0.29. Furthermore, apart from the two installations using different kernel versions, in Gentoo you configure and build the kernel yourself. So there is quite some difference between the two installations, which might explain why I do not have his original problem of no sound from headphones after a fresh boot. Where we did coincide, though, was that there was no sound from headphones following resumption from suspension.

First attempt at fixing the problem

Even though Independent HP does not stop headphones working after I boot my laptop, I decided to try to remove Independent HP anyway, to see if it would fix the suspend/resume problem with headphones in my case.

The Clevo W230SS has two sound cards:

root # lspci | grep Audio
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)

The HDMI audio card is Card 0, and the analogue HD Audio card is Card 1. ALSAMixer shows an Independent HP (headphone) channel for Card 1:

user $ alsamixer -c 1

The kernel documentation for the HD Audio driver explains how to fix the problem using what is called a driver ‘hint’. There is a link to the documentation in the above-mentioned bug report, and you can also find the documentation in the file /usr/src/<kernel_release>/Documentation/sound/alsa/HD-Audio.txt on your laptop if you have installed the kernel source code. As explained in the documentation, you can remove Independent HP either via the command line:

root # echo "indep_hp = no" > /sys/class/sound/hwC1D0/hints
root # echo 1 > /sys/class/sound/hwC1D0/reconfig

or by using so-called ‘Early Patching’:

Early Patching
~~~~~~~~~~~~~~
When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a
firmware file for modifying the HD-audio setup before initializing the
codec.  This can work basically like the reconfiguration via sysfs in
the above, but it does it before the first codec configuration.

Note that the term ‘patching’ here has nothing to do with patching the driver’s source code; it refers to patching the ALSA driver’s configuration of the VIA chip’s CODEC on the Intel sound card.

The format of this particular patch file containing a ‘hint’ would be as follows:

[codec]
<vendor_id> <subsystem_id> <address_of_the_CODEC>

[hint]
indep_hp = no

The values for vendor_id and subsystem_id can be found as follows:

root # cat /sys/class/sound/hwC1D0/vendor_id
0x11068446
root # cat /sys/class/sound/hwC1D0/subsystem_id
0x15582300

(As the driver is used with Card 1, remember to look in directory hwC1D0 rather than hwC0D0.)

The required value for address_of_the_CODEC is zero in this particular case. Therefore the file /lib/firmware/clevo-hda-patch (you can choose any file name you want) should have the following contents:

[codec]
0x11068446 0x15582300 0

[hint]
indep_hp = no

If you built the HA Audio driver as a module, you would need to add the following line to the file /etc/modprobe.d/alsa.conf in order to apply the patch:

options snd-hda-intel patch=,clevo-hda-patch

Notice the comma after the equals sign. This is required because the patch applies to the second card (Card 1) rather than to the first card (Card 0).

However, I had built the HD Audio driver into the kernel rather than as a module:

root # grep HDA /usr/src/linux/.config | grep -v "is not set"
CONFIG_SND_HDA=y
CONFIG_SND_HDA_INTEL=y
CONFIG_SND_HDA_PREALLOC_SIZE=2048
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1
CONFIG_SND_HDA_INPUT_JACK=y
CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_I915=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0

Therefore adding the option to /etc/modprobe.d/alsa.conf would have no effect, as the HD Audio driver is not a module. In this case I could have appended the following parameter to the kernel boot line in the file /boot/grub/grub.cfg instead:

snd-hda-intel.patch=,clevo-hda-patch

The above kernel boot parameter could be appended to the kernel boot line either directly by editing the file grub.cfg, or indirectly by adding it to the list of boot parameters in the variable GRUB_CMDLINE_LINUX_DEFAULT="" in the file /etc/default/grub and then using the command ‘grub2-mkconfig -o /boot/grub/grub.cfg‘ as root user to regenerate the grub.cfg file. Remember to mount /boot first if it is on a different partition.

Now, I tried applying the patch using the appropriate method in each case: HD Audio driver built into the kernel, and HD Audio driver built as a module (it didn’t take me long to modify the kernel configuration and rebuild the kernel). In both cases the following messages were included in the output of the dmesg command:

[ 0.430218] snd_hda_intel 0000:00:1b.0: Applying patch firmware 'clevo-hda-patch'
[ 0.430356] snd_hda_intel 0000:00:1b.0: Direct firmware load for clevo-hda-patch failed with error -2
[ 0.430359] snd_hda_intel 0000:00:1b.0: Cannot load firmware, aborting

I’m not sure if the reason for the failure to load the patch is the same in both cases, but certainly the reason in the case of the module is that PulseAudio is already running and using the driver by the time the OS attempts to apply the patch. In the case of the kernel boot parameter, my guess is that the patch would need to be included in an initramfs in order to be able to apply it before PulseAudio starts.

The same situation occurs if you try to apply the ‘hint’ manually from the command line after start-up:

root # echo "indep_hp = no" > /sys/class/sound/hwC1D0/hints
root # echo 1 > /sys/class/sound/hwC1D0/reconfig
bash: echo: write error: Device or resource busy

The above error message occurs because PulseAudio is running and using the driver. To apply the hint and refresh the driver in this case, the solution is to stop PulseAudio beforehand:

user $ echo "autospawn = no" >> ~/.config/pulse/client.conf
user $ pulseaudio --kill
user $ su
root # echo "indep_hp = no" > /sys/class/sound/hwC1D0/hints
root # echo 1 > /sys/class/sound/hwC1D0/reconfig
root # exit
user $ pulseaudio --start

Now, having to do the above manually every time you boot your machine is impractical. To automate the procedure I did the following…

Make sure the automatic (re)spawning of PulseAudio is disabled in the file ~/.config/pulse/client.conf (you can create the file if it does not exist):

autospawn = no

Create a Bash script in the directory /etc/local.d/ for the OS to launch automatically at boot, and in that script issue the above two commands first and then start pulseaudio. I named the script ‘99-clevo-hda-fix.start‘ and made its contents the following:

#!/bin/bash
# Fix for Intel HDA problem with Clevo W230SS
# See https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1313904
# N.B. Assumes your ~/.config/pulse/client.conf contains
# 'autospawn = no' so that PulseAudio is not launched automatically.
#
# Specify the hint
echo "indep_hp = no" > /sys/class/sound/hwC1D0/hints
#
# Reinitialise the HD Audio driver so it parses the CODEC tree again
echo 1 > /sys/class/sound/hwC1D0/reconfig
#
# Start PulseAudio for my user account
su -c "pulseaudio --start" -s /bin/sh fitzcarraldo

Don’t forget to make the script executable:

root # chmod +x /etc/local.d/99-clevo-hda-fix.start

This method of applying the hint to the HD Audio driver should work irrespectively of whether the driver is a module or built-in. It’s a bit more of a hack compared to the Early Patching approach, but it does the job in my case. After logging in to the Desktop Environment, you can check if the hint has been applied by looking at the contents of /sys/class/sound/hwC1D0/hints:

root # cat /sys/class/sound/hwC1D0/hints
indep_hp = no

However, this alone does not mean the CODEC was reconfigured after the hint was applied, so you need to check if Independent HP still exists. The ALSAMixer output on my laptop now looked like the following after I implemented the above method (notice that Independent HP no longer exists):

user $ alsamixer -c 1

So, what was the result? Well, audio continued to work after I removed Independent HP, but there was still no sound from headphones after resuming from suspension. And neither was there for Kiril, so he changed the title of his bug report to that effect. Fortunately, another user, unrud, commented later in the bug report that he had written init-headphone, a Python script to fix the problem. So I decided to hack his Ubuntu package to get init-headphone working in my Gentoo Linux installation. Here is how I did it…

Second (successful!) attempt at fixing the problem

1. Download init-headphone-ubuntu-0.11.zip from https://github.com/Unrud/init-headphone-ubuntu/releases

2. Extract the contents to the directory ~/init-headphone-ubuntu-0.11/

3. Copy to pm-utils’ hook directory the script that launches init-headphone upon resuming or thawing:

root # cp /home/fitzcarraldo/init-headphone-ubuntu-0.11/etc/linux-pm-utils/init-headphone /etc/pm/sleep.d/03-init-headphone # (use whatever number you want)

4. Copy the init-headphone script itself to the system binaries directory:

root # cp /home/fitzcarraldo/init-headphone-ubuntu-0.11/src/init-headphone /usr/local/sbin/

5. The init-headphone script requires the i2c_dev and i2c_i801 modules:

REQUIRED_MODULES = ["i2c_dev", "i2c_i801"]

However, I prefer to build them into the kernel rather than as modules, so I checked to make sure they are already built into the kernel:

root # grep CONFIG_I2C /usr/src/linux/.config | grep -v "is not set"
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MUX=y
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_I801=y

Then I commented out the lines in /usr/local/sbin/init-headphone that check if the two modules are loaded:

root # diff /home/fitzcarraldo/init-headphone-ubuntu-0.11/src/init-headphone /usr/local/sbin/init-headphone
174,181c174,181
< def check_modules():
< try:
< for module in REQUIRED_MODULES:
< logging.info("Trying to add module to the kernel: %s", module)
< if subprocess.call(["modprobe", "--quiet", module]) != 0:
< logging.warning("Module is not loaded: %s", module)
< except OSError:
#def check_modules():
> # try:
> # for module in REQUIRED_MODULES:
> # logging.info("Trying to add module to the kernel: %s", module)
> # if subprocess.call(["modprobe", "--quiet", module]) != 0:
> # logging.warning("Module is not loaded: %s", module)
> # except OSError:
> # logging.warning("modprobe not found")
206c206
# check_modules()

6. I created a script /etc/local.d/99-clevo-hda-fix.start to launch init-headphone automatically at boot:

#!/bin/bash
# Fix for Intel HDA problem with Clevo W230ss
# See https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1313904
exec /usr/local/sbin/init-headphone

root # chmod +x /etc/local.d/99-clevo-hda-fix.start

7. Add the kernel boot parameter ‘acpi_enforce_resources=lax‘ to the end of the kernel boot line(s) in /boot/grub/grub.cfg (don’t forget to mount /boot first if it is on another partition). You can either edit /boot/grub/grub.cfg directly, or indirectly by adding the parameter to the list of existing parameters in GRUB_CMDLINE_LINUX_DEFAULT (if any) as shown below and issuing the command ‘grub2-mkconfig -o /boot/grub/grub.cfg‘ as root user (again, don’t forget to mount /boot first if it is on another partition):

GRUB_CMDLINE_LINUX_DEFAULT="acpi_enforce_resources=lax"

8. Create a script file /etc/local.d/99-clevo-hda-fix.start to launch the init-headphone automatically at boot:

#!/bin/bash
# Fix for Intel HDA problem with Clevo W230SS
# See https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1313904
exec /usr/local/sbin/init-headphone

9. As my user account does not have a path configured to the system binaries directory, I created a symlink to it from the directory /usr/local/bin/:

root # ln -s /usr/local/sbin/init-headphone /usr/local/bin/init-headphone

10. As I no longer needed to stop PulseAudio running at boot, I deleted the file /home/fitzcarraldo/.config/pulse/client.conf I had created earlier (or you could just change ‘autospawn = no‘ to ‘autospawn = yes‘).

You can also use init-headphone from the command line:

user $ sudo init-headphone --help

e.g.

user $ sudo init-headphone unmute

This looks like it has finally solved the problem; now headphones still work after my laptop resumes from suspension. I still don’t need to pass the ‘hint’ to the HD Audio driver, so Independent HP continues to appear in ALSAMixer and apparently does not cause any problems.

A big ‘Thank you’ from me to Unrud for creating init-headphone.

PROBLEM 2: No sound from headphones after re-plug

The other problem I experienced with the Clevo W230SS was that, if I unplugged working headphones, audio switched to the laptop’s speakers as expected, but, if I then plugged-in the headphones again, no more sound came from the headphones. If I again unplugged the headphones, sound would again come from the speakers. If I did all this whilst ALSAMixer was running, then:

  1. if I unplugged the headphones, as expected the ALSAMixer volume level indicator for the speaker would rise from zero and the volume level indicator for the headphones would drop to zero;
  2. if I plugged in the headphones, as expected the ALSAMixer volume level indicator for the speaker would drop to zero and the volume level indicator for the headphones would rise from zero.

Now, it is possible that this problem was due to the same thing that caused the loss of audio to headphones when the laptop resumed from suspension. Anyway, before I came across init-headphone I found the following in the Arch Linux Wiki article on PulseAudio:

Switch on connect

This is a module used to switch the output sound to the newly connected device. For example, if you plug in a USB headset, the output will be switched to that. If you unplug it, the output will be set back to the last device. This used to be quite buggy but got a lot of attention in PulseAudio 8.0 and should work quite well now.

If you just want to test the module then you can load it at runtime by calling:

root # pactl load-module module-switch-on-connect

If you want to make the change persistent you will have to add it to your local pulseaudio settings or to /etc/pulse/default.pa (system wide effect). In either case, add this line:

load-module module-switch-on-connect

So, as the file /etc/pulse/default.pa in my installation did not have that line, I added it:

# Added by fitzcarraldo
# https://wiki.archlinux.org/index.php/PulseAudio
# The headphone socket no longer worked if I
# removed and re-inserted the jack plug.
load-module module-switch-on-connect

This seemed to help, but I am not certain module-switch-on-connect is really having an effect when I plug and unplug headphones, and I have not bothered to disable it to see what happens now that init-headphone is in use (I’m just happy that audio is all working now, whatever the reason!). ALSA’s Auto-Mute Mode* appears to perform the same role as module-switch-on-connect: When I unplug the headphones with Auto-Mute Mode enabled in ALSAMixer, there is a noticeable delay before sound starts to come from the laptop’s speakers, whereas there is no such delay when I unplug the headphones with Auto-Mute Mode disabled via ALSAMixer, so presumably module-switch-on-connect is doing its job.

* The documentation file /usr/src/<kernel_release>/Documentation/sound/alsa/HD-Audio-Controls.txt explains what Auto-Mute Mode does.

Anyhow, one or both of the two software modifications (init-headphone and module-switch-on-connect) seem to have cured the problem of no sound from headphones after they are disconnected then reconnected to the laptop.

Stopping my laptop spontaneously resuming immediately after Suspend to RAM

If I selected ‘Suspend to RAM’ via the Desktop Environment in the Gentoo Linux installation on my Clevo W230SS laptop, the laptop did suspend but then immediately resumed automatically. The same thing happened if I suspended the laptop using either of the following commands from the command line:

root # pm-suspend

user $ qdbus org.kde.Solid.PowerManagement /org/freedesktop/PowerManagement Suspend

This behaviour was annoying, as it meant I had to shut down the laptop completely when I was not at my desk for a long time, rather than just being able to suspend the laptop.

Problem 1: USB devices

I usually have several USB devices connected to my laptop when I am at home or in the office, and I began to suspect that these USB connections were somehow causing Linux to resume as soon as it had suspended. Searching the Web turned up a Q&A page that seemed to confirm my suspicion: Why does my laptop resume immediately after suspend? I installed the utility acpitool mentioned on that Web page and used it with the ‘-w‘ option to check which wakeup-capable USB devices were currently enabled in my installation:

root # acpitool -w
   Device       S-state   Status   Sysfs node
  ---------------------------------------
  1. RP01         S4    *disabled  pci:0000:00:1c.0
  2. PXSX         S4    *disabled
  3. RP02         S4    *disabled
  4. PXSX         S4    *disabled
  5. RP03         S4    *disabled  pci:0000:00:1c.2
  6. PXSX         S4    *disabled  pci:0000:03:00.0
  7. RP04         S4    *disabled  pci:0000:00:1c.3
  8. PXSX         S4    *disabled  pci:0000:04:00.0
  9.            *disabled  platform:rtsx_pci_sdmmc.0
  10.           *disabled  platform:rtsx_pci_ms.0
  11. RLAN        S4    *disabled
  12. RP05        S4    *disabled
  13. PXSX        S4    *disabled
  14. RP06        S4    *disabled
  15. PXSX        S4    *disabled
  16. RP07        S4    *disabled
  17. PXSX        S4    *disabled
  18. RP08        S4    *disabled
  19. PXSX        S4    *disabled
  20. GLAN        S4    *disabled
  21. EHC1        S3    *enabled   pci:0000:00:1d.0
  22. EHC2        S3    *enabled   pci:0000:00:1a.0
  23. XHC         S3    *disabled  pci:0000:00:14.0
  24. HDEF        S4    *disabled  pci:0000:00:1b.0
  25. PEG0        S4    *disabled  pci:0000:00:01.0
  26. PEGP        S4    *disabled  pci:0000:01:00.0
  27. PEGA        S4    *disabled
  28. PWRB        S3    *enabled   platform:PNP0C0C:0
^C
root #

(I had to use Ctrl-C to get back to the command prompt.)

I then used the command ‘acpitool -W <device number>‘ on each of the three enabled devices (21, 22 and 28 above) in order to find out which of them needed to be disabled in order for my laptop to remain suspended when I suspended it. I found that I only needed to disable devices EHC1 (pci:0000:00:1d.0) and EHC2 (pci:0000:00:1a.0) to be able to suspend the laptop successfully:

root # acpitool -W 21 | grep 21
  Changed status for wakeup device #21 (EHC1)
  21. EHC1        S3    *disabled  pci:0000:00:1d.0
^C
root # acpitool -W 22 | grep 22
  Changed status for wakeup device #22 (EHC2)
  22. EHC2        S3    *disabled  pci:0000:00:1a.0
^C
root # pm-suspend

In this laptop these two devices are two internal USB root hubs:

user $ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
        |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
            |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 4: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 4: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
        |__ Port 3: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
        |__ Port 4: Dev 5, If 0, Class=Video, Driver=uvcvideo, 480M
        |__ Port 4: Dev 5, If 1, Class=Video, Driver=uvcvideo, 480M

The next challenge was to find out how to disable and re-enable the two devices automatically when I suspend and resume the installation. Further searching of the Web turned up another Q&A page which pointed me in the right direction: How to run a script when suspending/resuming?. It turns out that you need to put a script of the following form in the directory /etc/pm/sleep.d/:

#!/bin/bash

case "$1" in
    suspend)
        # executed on suspend
        ;;
    resume) 
        # executed on resume
        ;;
    *)
        ;;
esac

If you want the script to run when hibernating and thawing, the tests would be for ‘hibernate‘ and ‘thaw‘ instead of ‘suspend‘ and ‘resume‘.

The thread [SOLVED] Computer immediately resumes after suspend in the KDE Forums almost gave me the solution I needed. I created a file /etc/pm/sleep.d/01-toggle-usb-hubs containing the following:

#!/bin/sh
#
username=fitzcarraldo
userhome=/home/$username
export XAUTHORITY="$userhome/.Xauthority"
export DISPLAY=":0"
#
case "$1" in
    suspend|hibernate)
        # Unbind ehci-pci for the device 0000:00:1a.0
        echo -n "0000:00:1a.0" | tee /sys/bus/pci/drivers/ehci-pci/unbind
        # Unbind ehci-pci for the device 0000:00:1d.0
        echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/unbind
    ;;
    resume|thaw)
        # Bind ehci-pci for the device 0000:00:1a.0
        echo -n "0000:00:1a.0" | tee /sys/bus/pci/drivers/ehci-pci/bind
        # Bind ehci-pci for the device 0000:00:1d.0
        echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/bind
    ;;
    *)
        exit $NA
    ;;
esac

I obtained the device details from the output of the ‘acpitools -w‘ command listed earlier and by looking in the directory /sys/bus/pci/drivers/ehci-pci:

root # ls /sys/bus/pci/drivers/ehci-pci
0000:00:1a.0  0000:00:1d.0  bind  new_id  remove_id  uevent  unbind

Notice that the script tests for either ‘suspend‘ or ‘hibernate‘ to disable the two devices, and tests for either ‘resume‘ or ‘thaw‘ to enable the two devices.

I made the script executable:

root # chmod +x /etc/pm/sleep.d/01-toggle-usb-hubs


Problem 2: Blank X Windows display due to NVIDIA closed-source driver bug

However, a problem remained: My laptop has an NVIDIA GPU and, when resuming from suspension, the X Windows display (Virtual Terminal 7) was a blank screen with only the mouse pointer visible. Now, it so happens that I also experience this behaviour if I switch from Virtual Terminal 7 to e.g. Virtual Terminal 1 (Ctrl-Alt-F1) and then switch back to Virtual Terminal 7 (Ctrl-Alt-F7). Apparently this is due to a bug in the closed-source NVIDIA driver (I am currently using Gentoo package x11-drivers/nvidia-drivers-358.16-r1). However, if I first disable compositing before switching to another virtual terminal, the X Windows display on Virtual Terminal 7 is still visible when I switch back to Virtual Terminal 7. It turns out there is a known bug in the NVIDIA closed-source driver, as explained in the following KDE bug report and thread in the NVIDIA CUDA ZONE Forums:

KDE Bugtracking System Bug No. 344326 – Black or corrupted screen on resume from suspend

NVIDIA CUDA ZONE Forums – Black screen on resume from suspend with 325.15 and KWin 4.11 with enabled compositing

As the suggested work-around is to disable compositing before suspending to RAM, I created a script /etc/pm/sleep.d/02-toggle-compositing containing the following:

#!/bin/sh
#
username=fitzcarraldo
userhome=/home/$username
export XAUTHORITY="$userhome/.Xauthority"
export DISPLAY=":0"
#
case "$1" in
    suspend|hibernate)
        su $username -c "qdbus org.kde.kwin /KWin toggleCompositing" &
    ;;
    resume|thaw)
        su $username -c "qdbus org.kde.kwin /KWin toggleCompositing" &
    ;;
    *)
        exit $NA
    ;;
esac

As I have KDE 4 on this laptop, I made the script use the command ‘qdbus org.kde.kwin /KWin toggleCompositing‘ to disable/enable compositing, so replace that command with the appropriate command if you are not using KDE 4.

I made the script executable:

root # chmod +x /etc/pm/sleep.d/02-toggle-compositing

Now both the scripts in the directory /etc/pm/sleep.d/ run when I suspend or resume the laptop, and everything works as expected. Mission accomplished! 🙂