Не грузится linux fstab

Обновлено: 04.07.2024

Из-за различных неполадок или неожиданного отключения компьютера файловая система может быть повреждена. При обычном выключении все файловые системы монтируются только для чтения, а все не сохраненные данные записываются на диск.

Но если питание выключается неожиданно, часть данных теряется, и могут быть потерянны важные данные, что приведет к повреждению самой файловой системы. В этой статье мы рассмотрим как восстановить файловую систему fsck, для нескольких популярных файловых систем, а также поговорим о том, как происходит восстановление ext4.

Немного теории

Как вы знаете файловая система содержит всю информацию обо всех хранимых на компьютере файлах. Это сами данные файлов и метаданные, которые управляют расположением и атрибутами файлов в файловой системе. Как я уже говорил, данные не сразу записываются на жесткий диск, а некоторое время находятся в оперативной памяти и при неожиданном выключении, за определенного стечения обстоятельств файловая система может быть повреждена.

Современные файловые системы делятся на два типа - журналируемые и нежурналируемые. Журналиуемые файловые системы записывают в лог все действия, которые собираются выполнить, а после выполнения стирают эти записи. Это позволяет очень быстро понять была ли файловая система повреждена. Но не сильно помогает при восстановлении. Чтобы восстановить файловую систему linux необходимо проверить каждый блок файловой системы и найти поврежденные сектора.

Для этих целей используется утилита fsck. По сути, это оболочка для других утилит, ориентированных на работу только с той или иной файловой системой, например, для fat одна утилита, а для ext4 совсем другая.

В большинстве систем для корневого раздела проверка fsck запускается автоматически, но это не касается других разделов, а также не сработает если вы отключили проверку.

Основы работы с fsck

В этой статье мы рассмотрим ручную работу с fsck. Возможно, вам понадобиться LiveCD носитель, чтобы запустить из него утилиту, если корневой раздел поврежден. Если же нет, то система сможет загрузиться в режим восстановления и вы будете использовать утилиту оттуда. Также вы можете запустить fsck в уже загруженной системе. Только для работы нужны права суперпользователя, поэтому выполняйте ее через sudo.

А теперь давайте рассмотрим сам синтаксис утилиты:

$ fsck [опции] [опции_файловой_системы] [раздел_диска]

Основные опции указывают способ поведения утилиты, оболочки fsck. Раздел диска - это файл устройства раздела в каталоге /dev, например, /dev/sda1 или /dev/sda2. Опции файловой системы специфичны для каждой отдельной утилиты проверки.

А теперь давайте рассмотрим самые полезные опции fsck:

-l - не выполнять другой экземпляр fsck для этого жесткого диска, пока текущий не завершит работу. Для SSD параметр игнорируется;
-t - задать типы файловых систем, которые нужно проверить. Необязательно указывать устройство, можно проверить несколько разделов одной командой, просто указав нужный тип файловой системы. Это может быть сама файловая система, например, ext4 или ее опции в формате opts=ro. Утилита просматривает все файловые системы, подключенные в fstab. Если задать еще и раздел то к нему будет применена проверка именно указанного типа, без автоопределения;
-A - проверить все файловые системы из /etc/fstab. Вот тут применяются параметры проверки файловых систем, указанные в /etc/fstab, в том числе и приоритетность. В первую очередь проверяется корень. Обычно используется при старте системы;
-C - показать прогресс проверки файловой системы;
-M - не проверять, если файловая система смонтирована;
-N - ничего не выполнять, показать, что проверка завершена успешно;
-R - не проверять корневую файловую систему;
-T - не показывать информацию об утилите;
-V - максимально подробный вывод.

Это были глобальные опции утилиты. А теперь рассмотрим опции для работы с файловой системой, их меньше, но они будут более интересны:

Теперь мы все разобрали и вы готовы выполнять восстановление файловой системы linux. Перейдем к делу.

Как восстановить файловую систему в fsck

Допустим, вы уже загрузились в LiveCD систему или режим восстановления. Ну, одним словом, готовы к восстановлению ext4 или любой другой поврежденной ФС. Утилита уже установлена по умолчанию во всех дистрибутивах, так что устанавливать ничего не нужно.

Восстановление файловой системы

Если ваша файловая система находится на разделе с адресом /dev/sda1 выполните:

sudo fsck -y /dev/sda1

Опцию y указывать необязательно, но если этого не сделать утилита просто завалит вас вопросами, на которые нужно отвечать да.

Восстановление поврежденного суперблока

Обычно эта команда справляется со всеми повреждениями на ура. Но если вы сделали что-то серьезное и повредили суперблок, то тут fsck может не помочь. Суперблок - это начало файловой системы. Без него ничего работать не будет.

Но не спешите прощаться с вашими данными, все еще можно восстановить. С помощью такой команды смотрим куда были записаны резервные суперблоки:

sudo mkfs -t ext4 -n /dev/sda1

На самом деле эта команда создает новую файловую систему. Вместо ext4 подставьте ту файловую систему, в которую был отформатирован раздел, размер блока тоже должен совпадать иначе ничего не сработает. С опцией -n никаких изменений на диск не вноситься, а только выводится информация, в том числе о суперблоках.

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

sudo fsck -b 98304 /dev/sda1

После этого, скорее всего, вам удастся восстановить вашу файловую систему. Но рассмотрим еще пару примеров.

Проверка чистой файловой системы

Проверим файловую систему, даже если она чистая:

sudo fsck -fy /dev/sda1

Битые сектора

Или еще мы можем найти битые сектора и больше в них ничего не писать:

sudo fsck -c /dev/sda1

Установка файловой системы

Вы можете указать какую файловую систему нужно проверять на разделе, например:

sudo fsck -t ext4 /dev/sdb1

Проверка всех файловых систем

С помощью флага -A вы можете проверить все файловые системы, подключенные к компьютеру:

Но такая команда сработает только в режиме восстановления, если корневой раздел и другие разделы уже примонтированы она выдаст ошибку. Но вы можете исключить корневой раздел из проверки добавив R:

Или исключить все примонтированные файловые системы:

Также вы можете проверить не все файловые системы, а только ext4, для этого используйте такую комбинацию опций:

sudo fsck -A -t ext4 -y

Или можно также фильтровать по опциям монтирования в /etc/fstab, например, проверим файловые системы, которые монтируются только для чтения:

sudo fsck -A -t opts=ro

Проверка примонтированных файловых систем

Раньше я говорил что нельзя. Но если другого выхода нет, то можно, правда не рекомендуется. Для этого нужно сначала перемонтировать файловую систему в режим только для чтения. Например:

sudo mount -o remount,ro /dev/sdb1

А теперь проверка файловой системы fsck в принудительном режиме:

sudo fsck -fy /dev/sdb1

Просмотр информации

Если вы не хотите ничего исправлять, а только посмотреть информацию, используйте опцию -n:

sudo fsck -n /dev/sdb1

Выводы

Вот и все, теперь вы знаете как выполняется восстановление файловой системы ext4 или любой другой, поддерживаемой в linux fsck. Если у вас остались вопросы, спрашивайте в комментариях!

На десерт сегодня видео на английском про различия файловых систем ext4 и xfs, как обычно, есть титры:

Это мой второй день в Linux. У меня проблемы с подключением USB-накопителя. Это показывает эту ошибку:

Как я могу избавиться от этой ошибки?

Это не правильно. Вы должны смонтировать ваше устройство в точке монтирования. например: mount /dev/sdb1 /media/usb . Просто помните, что это /media/usb/ нужно сделать перед монтажом для USB лучше его монтировать внутри /media/ папки. Более того, /mnt/ не сделано вами. это встроенная папка в убунту Вы сделали это media в своем домашнем каталоге, пока мы говорим о корневом каталоге (/). Сначала запустите его, а sudo mkdir /media/usb затем sudo mount /dev/sda1 /media/usb

Почему?

Вы, вероятно, забыли сказать, mount где монтировать диск.

Linux использует файлы устройств ( /dev/sda , /dev/sdb1 и т. Д.). В отличие от дисков Windows ( C: , D: и т. Д.), Вы не можете получить к ним прямой доступ ( cd /dev/sdb1 неизбежно произойдет сбой, сообщив, что это не каталог, а файл). Если вы хотите открыть диск с помощью mount , вам необходимо указать точку монтирования . Точка монтирования - это, по сути, каталог, в котором будет открыт ваш USB-накопитель и где вы сможете получить доступ к своим файлам.

Решение

Создайте каталог, который вы будете использовать в качестве точки монтирования для вашего диска:

Смонтируйте ваш диск с помощью этой команды:

Примечание. Если вы не знаете файл устройства вашего накопителя, вы можете запустить sudo fdisk -l или lsblk определить, какой из разделов вы ищете.

Теперь, если вы запустите ls /mnt/mydrive , он должен перечислить файлы вашего диска.

Когда вы закончите, не забудьте отключить USB-накопитель, прежде чем извлекать его из компьютера:

Дополнительная информация

/etc/fstab это файл, в котором вы можете связать раздел с точкой монтирования, что позволяет вам запускать mount <device> вместо mount <device> <mountpoint> . Вот почему вы получаете эту запутанную ошибку.

fstab имеет много других применений, таких как монтирование раздела во время загрузки и т. д. Больше информации о fstab на вики-сайте Arch Linux

Чтобы узнать имя вашего устройства используйте sudo fdisk . Ваше устройство может быть распознано по его размеру, и, вероятно, выглядит /dev/sdx , где x может быть любая буква от a до z. (Обычно ваш первый внутренний жесткий диск назначается)

Чтобы смонтировать USB-накопитель sudo mount <Your Device Name> <Mount Position> , например:

Чтобы получить доступ к тому, что вы только что установили, используйте положение, в котором вы установили. В приведенном выше примере я использовал /mnt , поэтому я бы набрал:

sudo mkdir / mnt / spider mount sudo -t ntfs-3g -o удалить_hiberfile / dev / sda2 / mnt / spider

Не забудьте заменить имя диска с / dev / sda2 на ваше. Вы можете найти имя ваших дисков с помощью команды sudo fdisk -l.

Подключение к виртуальной машине Azure Linux (VM) невозможно с помощью подключения Secure Shell (SSH). При запуске функции диагностики загрузки на портале Azureвы увидите записи журналов, похожие на следующие примеры:

Примеры

Ниже приводится пример возможных ошибок.

Пример 1. Диск устанавливается идентификатором SCSI вместо универсального уникального идентификатора (UUID)

Пример 2. Незакрепление устройства отсутствует в CentOS

Пример 3. VM не может запускаться из-за неправильной структуры fstab или из-за того, что диск больше не присоединен

Пример 4. В последовательной записи журнала показан неправильный UUID

Эта проблема может возникнуть, если синтаксис таблицы файлов (fstab) некорректен или если необходимый диск данных, который соизмерен с записью в файле "/etc/fstab", не присоединен к VM.

Решение

Чтобы устранить эту проблему, запустите виртуальный компьютер в режиме аварийной ситуации с помощью последовательной консоли для виртуальных машин Azure. Затем используйте средство для восстановления файловой системы. Если серийная консоль не включена в вашем компьютере, перейдите в раздел Ремонт автономного доступа к VM.

Использование серийной консоли

Использование режима одного пользователя

Использование последовательной консоли для одного режима пользователя в режиме одного пользователя

После загрузки vm в режим одного пользователя. Чтобы открыть файл fstab, используйте любимый текстовый редактор.

Просмотрите перечисленные файловые системы. Каждая строка в файле fstab указывает на файловую систему, которая устанавливается при старте VM. Дополнительные сведения о синтаксисе файла fstab запустите команду fstab man. Чтобы устранить сбой запуска, просмотрите каждую строку, чтобы убедиться, что она правильна как в структуре, так и в содержимом.

Измените или прокомментировать любые неправильные или ненужные строки в файле fstab, чтобы обеспечить правильное начало VM.

Сохраните изменения в файле fstab.

Перезагрузка vm с помощью нижеупомяг.

Вы также можете использовать команду "ctrl+x", которая также перезагружает vm.

Если комментарии или исправления записей были успешными, система должна достичь запроса bash на портале. Проверьте, можно ли подключиться к VM.

Использование корневого пароля

Для входов в систему в серийной консоли нельзя использовать ключ SSH.

Найми ошибку, которая указывает на то, что диск не был установлен. В следующем примере система пыталась прикрепить диск, который больше не присутствовал:

Подключение в VM с помощью корневого пароля (VMs на основе красной шляпы).

Чтобы открыть файл fstab, используйте любимый текстовый редактор. После установки диска запустите следующую команду для Nano:

Сохраните изменения в файле fstab.

Перезапустите виртуальную машину.

Если комментарии или исправления записей были успешными, система должна достичь запроса bash на портале. Проверьте, можно ли подключиться к VM.

Проверьте точки крепления при проверке изменений fstab при запуске крепления — команды. Если ошибок нет, точки установки должны быть хорошими.

Восстановление автономного доступа к VM

Прикрепить системный диск VM в качестве диска данных к восстановлению VM (любой работающий Linux VM). Для этого можно использовать команды CLI или автоматизировать настройку VM восстановления с помощью команд восстановления VM.

После установки системного диска в качестве диска данных на VM восстановления, перед внесением изменений выполните следующие действия по исправлению файла fstab.

Подключение в VM с помощью корневого пароля (VMs на основе красной шляпы).

Чтобы открыть файл fstab, используйте любимый текстовый редактор. После установки диска запустите следующую команду для Nano. Убедитесь, что вы работаете над FSTAB-файлом, расположенным на установленом диске, а не fstab-файлом, который находится в VM-службе спасения.

Сохраните изменения в файле fstab.

Перезапустите виртуальную машину или восстановите исходный VM.

Отсоединяйте и отсоединяйте исходный виртуальный жесткий диск, а затем создайте виртуальный виртуальный диск с исходного системного диска. Для этого можно использовать команды CLI или команды восстановления VM, если вы использовали их для создания VM восстановления.

После создания VM снова и подключения к ней с помощью SSH примите следующие действия:

Системы Linux загружаются очень быстро, поэтому большая часть данных, выводимых во время загрузки, быстро прокручивается и мы не успеваем прочитать текст. Тем не менее, во время загрузки, могут возникнуть различные ошибки, вплоть до того, что вы столкнетесь с проблемой не загружается Linux.

Ошибка может возникнуть в любом месте загрузки и любом компоненте системы инициализации. Обычно, systemd выводит подробную информацию об ошибках загрузки Linux на экран, но не всегда можно успеть их все прочитать. В этой статье мы рассмотрим что делать если не загружается Linux после установки, а также как посмотреть логи загрузки в этой операционной системе.

Почему Linux не загружается?

Причин проблем с загрузкой Linux может быть большое количество, в этой статье мы рассмотрим самые частые из них, которые можно достаточно просто решить. Сначала кратко пройдемся по самим причинам:

Linux после обновления не загружается, вы обновляли дистрибутив и что-то пошло не так, и теперь вы не можете попасть в вашу рабочую оболочку;
Linux перестал загружаться в результате повреждения файловой системы;
Linux не может примонтировать один из важных разделов диска из-за неверных настроек fstab;
Система не загружается из-за несовместимости графического драйвера и ядра;
Диск переполнен и системе попросту негде создать временные файлы.

Все это может возникать не так редко, если вы очень любите экспериментировать с системой и при этом не очень аккуратны. Мы не будем рассматривать проблемы с загрузкой из за Grub. Я буду надеяться, что там у вас все в порядке. Самое главное, что нужно сделать при проблемах с загрузкой - это посмотреть внимательно логи последней загрузки. Только так вы сможете понять в чем причина проблем и не гадать. Как это сделать? Есть несколько способов, вы можете использовать LiveCD или загрузиться в режим восстановления.

Проверка журналов загрузки

Итак, вы загрузились с LiveUSB системы и подключили разделы с основной системой или же вошли в режим восстановления с помощью загрузчика Grub. Для этого есть специальная опция в большинстве дистрибутивов. Она загружает однопользовательский режим Systemd с поддержкой сети и минимальными возможностями. С помощью него вы можете вернуть систему к нормальной работе.

Для работы в этом режиме нужно ввести пароль суперпользователя.

Если такого пункта нет можно загрузить режим восстановления Bash. Для этого нужно нажать клавишу "E" на пункте меню Grub и дописать в строку параметров ядра "init=/bin/bash":

С этим параметром ядро запустит интерпретатор Bash вместо того, чтобы загружать систему инициализации. Самый первый способ посмотреть логи в systemd - это использовать утилиту journalctl. Система нам сама подсказывает какую команду нужно запустить, чтобы посмотреть логи:

В режиме восстановления можно посмотреть содержимое лога ядра с помощью dmesg, в LiveUSB это бесполезно:

Все дальнейшие действия по восстановлению загрузки Linux нужно выполнять опираясь на информацию, полученную из лог файлов, только так вы сможете решить проблему.

Что делать если Linux не грузится?

1. Проблема с местом на диске

Предположим, что вы обновляли систему и она перестала загружаться после этого. Тогда можно предположить два варианта, либо загрузка обновлений переполнила корневой раздел и теперь системе некуда писать файлы, либо обновление прошло не очень успешно и важные пакеты повреждены. Сначала посмотрим свободное место на диске:

Если доступно 0% места, то вы знаете в чем проблема. Чтобы ее решить просто удалите ненужные файлы из папок /var/log, /var/cache/ и так далее. Для того чтобы вы смогли редактировать и удалять файлы, корневую систему, возможно, придется перемонтировать для чтения и записи:

mount -o remount,rw /

2. Целостность пакетов и системы

dpkg --configure -a

Также можно выполнить:

Но это сработает только в chroot окружении LiveUSB системы, поскольку в режиме восстановления интернета нет. Вы можете попытаться настроить проводной интернет с помощью команды:

3. Проблема с /etc/fstab

Следующая причина проблем с загрузкой может быть неверная запись в /etc/fstab для одного из разделов, если лог сообщает что-то в роде "Dependency failed for /dev/disk/by-uuid/f4d5ddc4-584c-11e7-8a55-970a85f49bc5" то это означает, что система не может примонтировать один из разделов в /etc/fstab.

Если это будет корневой раздел, система не загрузится. Systemd может выдавать много ошибок, но важно найти первую. Все остальные могут оказаться только ее следствием.

Поэтому если есть такая ошибка в логе проверьте файл /etc/fstab. Правильно ли там указан адрес корневого раздела? Если не уверены, лучше заменить на привычную запись Linux без UUID.

4. Повреждение файловой системы

Обычно файловая система проверяется автоматически, но это обычно. Если вы отключили эту функцию, а потом произошло неожиданное отключение компьютера, файловая система будет повреждена, а восстановить ее будет некому. Поэтому при ошибках монтирования еще можно попытаться проверить файловые системы на ошибки:

Здесь нужно указать адрес файла нужного раздела в файловой системе.

5. Проблема видеодрайвера

Если вы обновляли систему или устанавливали проприетарный драйвер, а потом в логах загрузки увидели ошибку запуска драйвера, то проблема в нем. Такое происходит потому что проприетарные драйвера не всегда совместимы с самыми новыми версиями ядер. Для решения проблемы достаточно удалить драйвер из системы в режиме восстановления. Например, для Nvidia:

apt purge nvidia*

Для видеокарт AMD команда будет выглядеть так:

apt purge fglrx*

С новым драйвером AMDGPU проблем быть не должно, так как он имеет открытый исходный код и встроен в ядро.

Во всяком случае, после удаления драйвера черный экран Linux должен перестать появляться.

6. Другое

Если у вас все же проблемы с загрузчиком Grub, вы можете использовать инструмент BootRepair для восстановления или просмотрите статью как восстановить Grub2 вручную. Также, возможно, вас заинтересует статья: ускорение загрузки Linux.

Выводы

В этой статье мы рассмотрели что делать когда не загружается Linux. Как видите, может возникнуть достаточно различных проблем. Но преимущество Linux в том, что вы можете решить все это благодаря прямому доступу к файловой системе. Также, если домашняя папка вынесена в отдельный раздел, то если ничего не сработает - можно переустановить систему с минимальными потерями. Надеюсь, эта информация была полезной.

Нет похожих записей

Оцените статью:

(17 оценок, среднее: 4,94 из 5)

Об авторе

10 комментариев

Спасибо Сережа! С уважением А И

Линупс уже давно потерял свою привлекательность. Ещё 6-8 лет назад он был ничего. Отлично пахал на стареньких машинах, можно было и файлопомойку организовать и торрентокачалку, почта там, микросервер, etc. И все работало как winxp на 64-128 Мб оперативки за глаза (есессно не везде), да и вцелом какая-то лёгкость была. Но были и "детские проблемы" ввиде плохой организованности в работе с медиа, кривости драйверов, отсутствию нормальной поддержки образов нового поколения, софт опять же скудный и жалкий был. А сейчас жрет искаропки до 1 Гб, гигабайта, Карл! При этом детские проблемы не излечились, Южноафриканский Линукс стал каким то диким, в остальном какое то все глупое, рассчитанное на поиграться по типу арча, дженты и иже с ними, что там? Рюшечки, шрифтики, тайловые de, а как насчет автомонтирования без костылей? То то же. Те же детские проблемы. И не удивительно, что система падает, но как принято говорить, это не баг, это фича и rolling release, а во всех проблемах винить криворуких и хромых пользователей и ветку testing. Очень жаль, что все стало таким плачевным.

А, ты с чем сравниваешь? Если с семейством windows, то linux на порядок лучше. Уродство Гейтса слетает чаще и проблем больше, и еще к тому же за каждую мелочь денег просит, про вирусы вообще отдельный разговор. Не нравится южно-африканский используй какой нравится, сборок полно. Ну, а если хочешь под себя, берёшь ядро и делай правильный Linux с твоей точки зрения.

Дружок-пирожок, как там в 2017-м со взглядами из 2007-го?

У меня десятка три года стоит на одном компе, четыре на втором, рядом с убунтой. Где у меня было больше проблем? Невероятно, наверное для тебя, но в убунту

спосибо. Был бы еще хорош обзор, если линукс "завис".

Линупс не виснет! (с) Штульман

это конечно чудесные советы, но чтобы ими воспользоваться, нужно всё-таки, чтобы Линукс загрузился

Уважаемый Админ, прошу помощи.
Каюсь в своей криворукости заранее, дайте совет в каком направлении копать.
В общем суть проблемы, Linux Lite 3.8 ubuntu 16.04, заведена в домен средствами PBIS open (likewise-open), но пользователи доменные в терминале не работали с автозаполнением команд и при перемещении стрелками по клавиатуре терминал вместо запомненных команд выдавал символы нажатых клавиш.
Поставил пакеты apt-get install krb5-user, samba, winbind, libnss-winbind, libpam-winbind, терминал ругнулся что likewise несовместим с winbind, продолжить? Жамкнул - Да, заменил файлы, после перезагрузки убунта в режиме восстановления грузится (emergency mode) только по root.
Удалял эти пакеты, которые поставил, удалял их зависимости apt-get autoremove, не помогает, не знаю куда копать, рядом винда стоит по соседству, комп рабочий.
При загрузке стала пробегать строка
Spectre V2: Spectre mitigation:LFENCE not serializing, switching to generic retpoline

Можно как-то восстановить убунту или сносить и по новой ставить?
И еще - какой раздел лучше выбирать при установке, основной или логический или в принципе разницы никакой нет?

В меню загрузчика, в пункте дополнительные опции можно войти в режим восстановления. Здесь можно попытаться выполнить обновление системы, чтобы пакетный менеджер установил всё чего ему не хватает. Не знаю на что влияет домен, но могу предположить, что там монтировались какие-либо диски. Если система не может их смонтировать - это будет мешать загрузке. А вообще, чтобы что-то сказать надо видеть лог загрузки. Для этого надо в загрузчике (там можно редактировать пункт меню, если нажать F10) заменить опцию загрузки ядра quiet на verbose.

2021 год на дворе. Как выражаются опытные линукзятники, я решил уйти со своей гавно-лицензионной Windows 10 на которой проблем не знал вообще никогда и ни с чем, на мною уважаемый Debian Cinnamon. Скачал образ, залил на флешку, начал устанавливать. Устанавливал на SSD Kingston 250гб. Разбил диски, установил. Дебиан не загрузился. Как в пункте 1 посвился целый список, все было ОК, но потом было одно Failed. Я устанавливал вручную, подумал что накосячил. Снова установка. На этот раз выбрал опцию, чтобы при разбивке диска Дебиан сам все сделал. Он разбил. Я установил. Failed. Спасибо Дебиан.
Сейчас по всем правилам мне должны рассказать, что у меня руки кривые, железо кривое, видеокарта кривая, я кривой, и еще раз я кривой. Но тогда вопрос к вам - почему тот же Mint Mate поставился до этого на это же железо норм, а Великий Debian Cinnamon не смог? Минт я кстати снова поменял на Винду из-за ошибок, которые не лечатся годами:
1) невозможно поменять время на нужное;
2) Мате не поддерживает монитор 4к, а когда нашел как поддержать, то и тут всплыли дохренища багов с отображением.
3) Тот же YouTube выглядит как будто под слоем неведомой пыли со странным отображением цветов и контраста, хотя на Винде с этим проблем не было ни разу.
4) Звук шо то был тише, чем на Винде. Даже на Максимуме.
А мне обидно. Мне нравится Дебиан, и я хотел "Корицу". Но она меня не хочет. Уверен, если поставлю тот же Минт Корица, проблем не будет. Соглашусь с одним из комментариев выше - Линукс скатился. Раньше подавал признаки процветания, то сегодня возможно только окружение "Гном" и дистрибутивы "Манжаро" где-то дотягивают, хотя бы на 50% до возвожностей Виндовс 10.

Читайте также: