При обновлении F23=>F24 поломался /etc/fstab

Покажи /etc/fstab и blkid, что ли.

/dev/sda1: LABEL="Windows" UUID="2F8701A643595A0A" TYPE="ntfs" PARTUUID="401376fd-01"
/dev/sda2: LABEL="/boot" UUID="12d10dae-123f-4ac6-9abb-dbba5c9e4d4a" TYPE="ext4" PARTUUID="401376fd-02"
/dev/sda5: UUID="3a98f645-9081-4e90-8352-a2aa4703710c" TYPE="crypto_LUKS" PARTUUID="401376fd-05"
/dev/sda6: UUID="e494ff2b-4b5e-4b01-9ddf-f34d58cb2038" TYPE="crypto_LUKS" PARTUUID="401376fd-06"
/dev/sdb1: UUID="b952532e-4d03-41f4-b5df-8ef1e14c2e7a" TYPE="crypto_LUKS" PARTUUID="6fc16c0d-01"
/dev/sdc1: LABEL="Container3TB" UUID="8a8f70ca-66d2-4a8b-8fed-45d237e8f7f0" TYPE="ext4" PARTUUID="9948f4a2-16e2-4203-83cd-30a4d32ef809"
/dev/sdd1: UUID="72488DFE7E161743" TYPE="ntfs" PARTUUID="000e58a6-01"
/dev/sdd2: LABEL="FlashBackUp" UUID="01BC74E02FF9D4F0" TYPE="ntfs" PARTUUID="000e58a6-02"
/dev/sdd3: UUID="0EA1CFF532CF84CB" TYPE="ntfs" PARTUUID="000e58a6-03"
/dev/mapper/luks-e494ff2b-4b5e-4b01-9ddf-f34d58cb2038: LABEL="/" UUID="de88bf21-59fb-482e-bde7-30297a32fdf6" TYPE="ext4"
/dev/mapper/luks-3a98f645-9081-4e90-8352-a2aa4703710c: LABEL="swap" UUID="59ccad36-c0ee-44e3-9060-4697cb3f0d18" TYPE="swap"
/dev/mapper/luks-b952532e-4d03-41f4-b5df-8ef1e14c2e7a: LABEL="/home" UUID="2f0c3222-a4b7-41d9-bdc3-e2ae802fa74c" TYPE="ext4"

#
# /etc/fstab
# Created by anaconda on Tue Apr  5 13:26:50 2016
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/luks-e494ff2b-4b5e-4b01-9ddf-f34d58cb2038 /                       ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=12d10dae-123f-4ac6-9abb-dbba5c9e4d4a /boot                   ext4    defaults        1 2
/dev/mapper/luks-b952532e-4d03-41f4-b5df-8ef1e14c2e7a /home                   ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/luks-3a98f645-9081-4e90-8352-a2aa4703710c swap                    swap    defaults,x-systemd.device-timeout=0 0 0

Добавление строчки

UUID=8a8f70ca-66d2-4a8b-8fed-45d237e8f7f0 /run/media/username/Container3TB ext4 defaults 0 0

А в логах-то что? Подозреваю, что точка монтирования тупо не существует.

[username@localhost ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        7.9G     0  7.9G   0% /dev
tmpfs           7.9G   94M  7.8G   2% /dev/shm
tmpfs           7.9G  1.9M  7.9G   1% /run
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/dm-0       120G   15G   99G  14% /
tmpfs           7.9G  404K  7.9G   1% /tmp
/dev/sda2       870M  167M  643M  21% /boot
/dev/dm-2       355G  154G  184G  46% /home
tmpfs           1.6G   16K  1.6G   1% /run/user/42
tmpfs           1.6G   48K  1.6G   1% /run/user/1000
/dev/sdc1       2.7T  1.7T  875G  67% /run/media/username/Container3TB

точка монтирования существует? Логи какие нужны? Journalctl?

Ты логи загрузки посмотришь, или дальше будем выхлопы команд в загруженной системе смотреть?

/run в tmpfs живёт обычно и не факт, что «media/username/Container3TB» существует на момент монтирования локальных файловых систем.

Доводишь систему до незагружабельного до конца состояния и смотришь dmesg и journlactl.

Погоди, ты считаешь, что папка /run/media/username/Container3TB не существует, поэтому том некуда монтировать? Я тебя удивлю, но /run/media тоже не существует, но монтирование происходит именно в эту папку (пускай и временную). И раньше так было, и раньше всё отлично работало. Я, конечно, попробую вариант создания этих директорий, но это явно то, чего раньше в системе не было... Сейчас логи гляну.

Сделай /mnt/cnt3tb и монтируй туда.

И раньше так было, и раньше всё отлично работало.

Удивительно.

Вот это сообщение я получаю после очередного редактирования fstab.
Это содержание dmesg после перезагрузки с отредактированным fstab.
Вот содержание journalctl -xb.

Строка 2101 по третьей ссылке.

Jun 30 16:18:45 localhost.localdomain systemd[1]: run-media-pushistiq-Container3TB.mount: Failed to check directory /run/media/pushistiq/Container3TB: No such file or directory

Строка 2120

Jun 30 16:18:45 localhost.localdomain mount[1005]: mount: mount point /run/media/pushistiq/Container3TB does not exist

Создал папку /run/media/pushistiq/Container3TB
Результат тот же — Emergency Mode. Содержание journalctl -xb. Интересно то, что я создал эту папку, а теперь её нет. Создавал под правами рут, естественно. Магия от Fedora)). Я такое впервые вижу!)))

Ещё раз попробовал создать. Всё то же самое. Папка автоматом удаляется после перезагрузки и в journalctl появляется запись о несуществующей папке. Жесть.

А вот этот фокус удался. Спасибо!
Удивительно, что с 2010 года, у меня всегда это было папкой /run/media/... — и никогда проблем с этим не было — и я никогда её не создавал, она всегда автоматически появлялась при автомонтировании через fstab. А такую фишку с автоматическим удалением созданных папок после перезагрузки я впервые вижу! Видать, основательно поковыряли федору, начиная с 24 релиза).

Мозгом-то пользоваться совсем отвык?

1. Если раздел в fstab не критичен для загрузки, поставь ему в параметры nofail. Система продолжит загрузку, даже если раздел не примонтируется.
2. Директория /run на твоём корне пустая. В процессе загрузки туда монтируется tmpfs. Можешь убедиться в этом, посмотрев на выхлоп mount.
3. Директория /run/media/username создаётся при логине пользователя. До этого момента её не существует.
4. Как уже посоветовали выше, создай диру в /mnt или в /media, монтируй раздел туда и не парь мозги.

С разморозкой. Всё уже сделали. И да, 3-ий пункт — мимо. Не создаётся она.

/run живёт в tmpfs как выше написали. Монтируется туда раньше твоей ошибки, но на момент монтирования твоего диска там скорее всего только pid-файлы и немного логов journald. После загрузки посмотри время создания /run/media/username и посмотри по логам, какому примерно этапу загрузки оно соответствует. Скорее всего много позже времени монтирования твоего диска. Если диск подключен постоянно, то замути для него точку монтирования постоянную, чтобы на диске была. Можно еще костылик из udevil замутить, чтобы при логине в систему оно диск монтировало, например.

# dracut --regenerate-all --force

Дело в том, что папки /run/media/username не существует после перезагрузки. До перезагрузки я могу её создать. После перезагрузки не остаётся моей созданной под правами root папки, и сама система её не создаёт.
Хотя раньше она создавалась сама, если указать её в fstab. Более того, при монтировании любого тома, раздела, эта папка создаётся системой автоматически. И так же удаляется, при размонтировании тома/раздела. Видимо, поменяли в федоре в 24-ом релизе алгоритм безопасности для этой папки (я про папку /run). А папку /mnt традиционно оставили для монтирования всего, что захочет пользователь, поэтому фокус с fstab удался)). Там какая-то заморочка с pid, раз даже права root не помогают оставить эту папку после перезагрузки. То есть, в течение текущей сессии ты можешь создать любую папку там под рутом, и система может временно создать для флеши и проч.носителей папочку для этих устройств, но после перезагрузки они удаляются в принудительном порядке.

Почитай про tmpfs.

Понятно. Значит, папка /run вообще не существует, как таковая, на жёстком диске. Теперь всё встаёт на свои места, кроме... почему же раньше всё выходило?))))