# Booting from a specific HDD with UEFI

## dbishop

I am trying to get one of my Gentoo systems to boot from a very specific SATA disk (GPT and UEFI), when the type and number of other disks can vary (SAS, SATA, some raid, others not). For the most part it works.  But there are some corner cases I am dealing with that result in total failure.  here is a rundown of some pertinent details:

1) The machine has both SATA and SAS interfaces (in this case the SAS is an LSI HBA, SATA are the usual SATA3 controller combos).

2) The boot disk is SATA3 (GPT) 

3) There are other disks, some SATA, some SAS-based, BUT these are NOT permanently mounted and what is present at boot varies quite a lot. <-- This is the issue

The system will boot correctly (in minutes, that is, as opposed to hours) if there are no other SATA or SAS disks plugged in.  However, if these other disks are plugged in, the system gets lost in hours-long fsck's -- these file systems range from 4TB to 16TB, some raid, some not, and there are a number of file system varians in play too -- reiserfs, ext2, ext4 with 16K blocks, ntfs just to name a few.

To make matters worse, this particular system is headless, and access is only via ssh, so once it begins fsck'ing there is no choice but to hard-boot the machine ensuring the other disks areother disks unplugged. (The SAS disks are in an external JBOD box so I just power it down, and the other SATA disks are in hot-swap trays, so I pop them out for boot, then plug everything back in and power on the JBOD box post boot.  Sometimes I forget -- or can't because it's remote.

I have set the dump/p[ass to 0 0 in fstab, but I have been reading that tune2fs might be able to do the trick, but it seems that it won't work if the devices move around (as the do with these disk systems, they get hotplugged and moved across systems all the time).

Is tune2fs the solution? Will it work even if the disks are not always there or get hotplugged, or their /dev/ node changes with each boot?

I am grateful for any help.

----------

## NeddySeagoon

dbishop,

There are several issues here and its not clear which one is the root of your problem.

There is the HDD detection order before the kernel is loaded and the HDD detection order by the kernel.

There is not much to do about first one.  You can make a small raid1 /boot partition on all the drives, then any drive can provide the boot files

You also need to install the boot loader on them all.

After the kernel is loaded, you can pass root=UUID=<filesystem_UUID> which needs an initrd, or you can use root=PARTUUID=<root_partition_UUID> which the kernel can handle unaided.

----------

## dbishop

Hah -- don't know if you recall, but this is the same exact machine you helped me with before -- I ended up giving it network interfaces neddy1 and neddy2. You're doubly invested now  :Smile: 

UEFI and GPT have pretty much gotten the correct boot disk to get identified well enough.  Now the problem is that if there are other disks -- particularly large ones -- they tend to want to get fsck'd.  This can take *hours*.

It is a very dynamic situation. The only disk guaranteed to be there at boot is the boot disk.  All others are optional. So There may be one or two or three SATA data disks there, there may be one or two SAS data disks or RAIDs.

How can I reliably make sure that fsck is only ever run on the boot disk?

----------

## NeddySeagoon

dbishop,

For the extX family of fs read 

```
man tune2fs
```

and ask yourself if you really really want to do this.

The simple answer is that you can't.

----------

## dbishop

We are discussing data-only disks -- they are not system disks at all.  It's fine that the main boot disk gets checked (but all the partitions are reiserfs and I have never has any real problems with reiserfs over literally hundreds of disks and thousands of partitions. But fsck-away on those. Quick. Painless. Fine.

I don't care if the data disks get fsck'd, that's not the point, I just want it to happen after the system gets booted. These disks aren't even automounted. 

The funny thing is that when they are added to the system post-boot, fsck's are never run.  Same system, same disks. 

I'll read the man page just to see what can be done.

As always, thanks for your help.

----------

## dbishop

Adding to the irony of all this is the fact that the file systems that I want to bypass checking use a 16K block size. I don't even think fsck works with it. check this out:

```
temmanuel ~ # dumpe2fs -h /dev/md127

dumpe2fs 1.42.12 (29-Aug-2014)

Filesystem volume name:   3R_EXT4_1

Last mounted on:          /mnt/XC_RAID1

Filesystem UUID:          8b7c58a0-9116-4ce6-a799-5eccd669daf5

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Filesystem flags:         unsigned_directory_hash 

Default mount options:    (none)

Filesystem state:         not clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              234258816

Block count:              234423040

Reserved block count:     0

Free blocks:              106259639

Free inodes:              234258195

First block:              0

Block size:               16384

Fragment size:            16384

Reserved GDT blocks:      122

Blocks per group:         65528

Fragments per group:      65528

Inodes per group:         65472

Inode blocks per group:   1023

RAID stride:              8192

RAID stripe width:        131072

Flex block group size:    16

Filesystem created:       Wed Mar 11 10:41:47 2015

Last mount time:          Wed Dec 31 19:00:19 1969

Last write time:          Mon May  4 03:30:06 2015

Mount count:              53

Maximum mount count:      24

Last checked:             Wed Mar 11 10:41:47 2015

Check interval:           15552000 (6 months)

Next check after:         Mon Sep  7 10:41:47 2015

Lifetime writes:          1963 GB

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               256

Required extra isize:     28

Desired extra isize:      28

Default directory hash:   half_md4

Directory Hash Seed:      c25a474f-de43-b920-e3bb-4c894bb8fbf2
```

Notice the line: Filesystem state:         not clean

When I run fsck, I get this:

```
temmanuel ~ # fsck /dev/md127

fsck from util-linux 2.25.2

temmanuel ~ #
```

(I mount this file system using fuse)

----------

## krinn

Read this: https://forums.gentoo.org/viewtopic-t-1007788.html

1/ find and plug your sata boot disk on the lowest (first) sata port, and just never replace it so this port will always kept your boot disk

2/ of course set the sata controller driver as buildin your kernel

3/ any other controllers -> set them as module (so any disks plug on them can only take a drive name next to the ones attach to the controller that is buildin the kernel ; a disk on it could never get sda name)

4/ mount your disk in your fstab using label, partuid or anything that can ident the disk to mount ie: 

```
/dev/disk/by-label/belegBOOT      /boot      ext2      noauto,noatime   1 2
```

5/ Prevent them from mounting by setting 1 in your fstab 5rd field (ie: same as the boot example upper)

6/ Prevent fsck on the ones you want handle yourself by setting 0 to 6rd field: ie 

```
/dev/disk/by-label/belegSWAP      none      swap      sw      0 0

```

You will endup with:

- fstab will never mount the disk that are 1 (5rd field), however manually asking to mount them will works (and without pain, you don't need to figure out its name, just "mount /boot" and you're done)

- fstab will only mount disk that are 0 (5rd field), but only if the disk label match, and this even your disks name is change, no matter if belegROOT is sdc or sdd... ie: 

```
/dev/disk/by-label/belegSWAP      none      swap      sw      0 0
```

 In this case, the swap will always be mount even if the disk holding the swap is sdc or sdf... as long as you care to not label two disk with the same label of course  :Wink: 

- only 6rd field set to 1 disks will be fsck (remember to do it yourself sometimes)

- use ext4 on your disks datas, i'm not ready to drop ext3 for my system disk and still testing ext4 reliability, but until prove i will kept using the ext3 that is simply rock stable and kick ass prone to failure (with a not bad recovery in case of trouble) ; but as i have some ext4 disks, i could tell you that, at least, it is impressive the speedup of fsck on them, i would say more than 10x (vs ext3), but it could be even more i didn't look at the speedup real increase, a big partition is just taking seconds to check. Build a big test partition, make it ext4 and fsck it, you'll be amazed.

----------

