Не запускается linux с ssd

РЕШЕНО: Не грузится Kubuntu копированный Clonezillo`й с SSD на NVME

Доброго времени суток уважаемому Сообществу. Суть проблемы изложена в сабже. Kubuntu 18.04 была копирована с помощью Clonezilla с SSD на NVME в режиме клонирования диска. Затем исходный SSD был отключен. BIOS увидел новую систему, определил NVME как загрузочный, GRUB показал варианты загрузки. А дальше, после выбора первого варианта в меню GRUB`а — чёрный экран. Никаких сообщений об ошибке или т.п. Просто не происходит загрузка системы. Светодиод активности — тоже молчит. В интернетах покопался, но везде вариант Clonezilla указывается как абсолютно беспроблемный. Кстати, так и было до сих пор. Переношу рабочую, настроенную систему уже не первый раз и всегда всё было просто… А с таким сталкиваюсь впервые. Подскажите где искать проблему. Заранее благодарен. З.Ы. Вопрос решил простой переустановкой системы на свежую версию. С переносом прежней системы — колупался почти до рассвета. Главная проблема — ни один LiveCD не хотел монтировать nvme. Ошибки выдавались самые разнообразные, вплоть до bad option, bad file system и badblock… Поскольку раздел /home сидит на отдельном SSD, после установки свежей системы никаких проблем не возникло. Большое спасибо всем за советы. Узнал для себя много нового. Отдельное спасибо Программисту из Екатеринбурга 🙂 Респектище тебе чувак. Буду в твоих краях — поставлю тебе пивас, или что сам выпить пожелаешь 🙂

А загрузчик переустановить, нет? Поправить /etc/fstab ?

На ноутбуке, кстати, BIOS-CSM или UEFI режим загрузки?

Стационарный комп. Включена UEFI. SSD работал с ней же, поэтому не стал ничего трогать при клонировании. Про переустановку загрузчика и правку /etx/fstab — с чего лучше начать?

Проверь, что в /etc/fstab совпадает UUID разделов.

Через chroot перегененируй конфиг grub.

В случае uefi нужно будет ещё поправить файл конфига рядом с efi образом grub на efi system partition, в котором указывается откуда подгружать основной конфиг.

И возможно, нужно перкгенерировать initramfs, чтобы в нем были драйверы (модули) для доступа к nvme диску.

Сверка uuid и правка /etc/rstab;

Перегенерации grub.cfg и правка конфига груб, в котором указывается откуда грузить основной конфиг.

Переустановка efi образа grub и прописывание его в efivars, либо переименовывание его в bootx64.efi.

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

Если не сможешь самостоятельно, скопируй сюда содержимое fstab и выхлоп sudo fdisk -l . Для начала можешь просто sudo update-grub попробовать, может прокатить (с efi не прокатит, инструкция ниже).

Сложно это для меня 🙁 Скажите, а есть ли смысл в «переезде» с sATA SSD на NVME?

Вот инструкция по восстановлению grub, смотри секцию «Восстановление используя chroot». Не ссы, ничего сложного.

Спасибо за советы и поддержку 🙂 Ушёл пробовать. Мне, чтобы nvme воткнуть — полкомпа разобрать надо. О результатах отпишусь.

Ты скопировал, не смог загрузиться, вытащил, загрузился с SATA-носителя, написал сюда, а сейчас хочешь по второму кругу?

Немного не так… Сейчас я подключил рабочий SSD, с которого копировал систему, и загрузился с него. Не отключая NVME.

Теперь сперва проверю содержимое fstab

/ was on /dev/sda3 during installation

UUID=bc214833-d0f3-4849-b7e0-bff3b79f0e82 / btrfs defaults,subvol=@ 0 1

/boot/efi was on /dev/sda1 during installation

UUID=0378-1E80 /boot/efi vfat umask=0077 0 1

/home was on /dev/sdb1 during installation

UUID=bed99606-a0a7-4fcc-81f5-93123dd6dcef /home btrfs defaults,subvol=@home 0 2

swap was on /dev/sda2 during installation

UUID=705936c6-fe57-442e-8f1f-12d0764d80f7 none swap sw 0 0 /dev/sdc1 /media/data btrfs defaults 1 2 /dev/sdd1 /media/multimedia btrfs defaults 1 2

Кстати — вообще божественно получилось: разделы swap и efi подтянулись с nvme, а загрузка произошла с ssd. Я так полагаю, что нужно в fstab таки прописать uuid раздела root на nvme — и будет мне счастье?

Ты же таблицу разделов склонировал? По логике уиды должны быть одинаковые. Это легко проверить с помощью fdisk .

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

Таблица разделов — клонирована. UUID — разные. fstab вообще показывает, что у меня swap и efi на одном устройстве, а root — на другом. Хотя изначально они все втроём на одном сидят. Значит GRUB просто находит root на том устройстве, где ему указано искать в BIOS, а остальные разделы подтаскивает с того устройства, которое установлено в приоритетный для загрузки слот NVME. Следовательно, нужно GRUB`у указать, что ВСЕ разделы нужно искать на одном устройстве. Вообще, как я полагаю, проблема возникла именно из-за того, что устройство, на которое клонирована система, подключено к другому разъёму.

Старый носитель я отключаю при операциях с новым. Обновление конфига GRUB`а — делать по-инструкции выше?

Выхлоп fdisk -l

Диск /dev/nvme0n1: 238,5 GiB, 256060514304 байт, 500118192 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 512 байт Размер I/O (минимальный/оптимальный): 512 байт / 512 байт Тип метки диска: gpt
Идентификатор диска: DBC2AB35-1E0E-447D-803F-8F0143B5ACF5

Устр-во начало Конец Секторы Размер Тип
/dev/nvme0n1p1 2048 999423 997376 487M EFI
/dev/nvme0n1p2 999424 17000447 16001024 7,6G Linux своп
/dev/nvme0n1p3 17000448 234440703 217440256 103,7G Файловая система Linux

Диск /dev/sda: 111,8 GiB, 120034123776 байт, 234441648 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 512 байт Размер I/O (минимальный/оптимальный): 512 байт / 512 байт Тип метки диска: gpt Идентификатор диска: DBC2AB35-1E0E-447D-803F-8F0143B5ACF5

Устр-во начало Конец Секторы Размер Тип /dev/sda1 2048 999423 997376 487M EFI /dev/sda2 999424 17000447 16001024 7,6G Linux своп /dev/sda3 17000448 234440703 217440256 103,7G Файловая система Linux

Диск /dev/sdb: 447,1 GiB, 480103981056 байт, 937703088 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 512 байт Размер I/O (минимальный/оптимальный): 512 байт / 512 байт Тип метки диска: gpt Идентификатор диска: 2BCA24AC-DB24-4996-8AF2-718D96D300CE

Устр-во начало Конец Секторы Размер Тип /dev/sdb1 2048 937701375 937699328 447,1G Файловая система Linux

Диск /dev/sdd: 3,7 TiB, 4000787030016 байт, 7814037168 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 4096 байт Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт Тип метки диска: gpt Идентификатор диска: 16325560-A4C7-4FF1-8319-FE61335E1BAD

Устр-во начало Конец Секторы Размер Тип /dev/sdd1 2048 7814037134 7814035087 3,7T Файловая система Linux

Диск /dev/sdc: 3,7 TiB, 4000787030016 байт, 7814037168 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 4096 байт Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт Тип метки диска: gpt Идентификатор диска: 4671995E-9596-4867-8F57-7252758DE349

Устр-во начало Конец Секторы Размер Тип /dev/sdc1 2048 7814037134 7814035087 3,7T Файловая система Linux

Вот глупый вопрос: а как из загрузочного меню GRUB a попасть в командную строку? При нажатии кнопки «c» появляется командная строка самого GRUB a, в которой не работают обычные команды. Или я что-то не так делаю?

Не, не, это не так работает. Загрузчик знает только про ядро, а ядро уже само монтирует всё нужное как указано в fstab.

Ну так у меня в FSTAB почему-то именно так и прописано. Думаю — надо переписать по-нормальному.

Только вот с командной строкой грабовской — не понятно.

Выполни: sudo blkid /dev/nvme0n1p* и сравни с теми, что прописаны в fstab и с теми, что у тебя на старом диске (та же команда + соответвующее устройство).

Всё так. Если нужна ядерная консоль, нужно выбрать соответствующий пункт из предложенных, он может по-разному называться. Но когда линукс не грузит, ты так и так в ней должен оказаться.

загрузка у меня просто стопорится на показе логотипа Kubuntu. Когда надоедает ждать (минут через 5 тишины) я просто жму сочетание волшебных кнопок и комп ребутится.

Выхлоп

sudo blkid /dev/nvme0n1 /dev/nvme0n1: PTUUID=«dbc2ab35-1e0e-447d-803f-8f0143b5acf5» PTTYPE=«gpt» sudo blkid /dev/sda /dev/sda: PTUUID=«dbc2ab35-1e0e-447d-803f-8f0143b5acf5» PTTYPE=«gpt»

Получается, что у меня в fstab прописан одинаковый UUID для SSD и для NVME. Получается, теперь нужно в FSTAB, расположенном на NVME, прописать UUID в строке, где перечислены разделы efi, root, swap, и по-идее, загрузка должна начаться?

Всё как изначально и предлагали. Нужно замостить live-образ на флешку, загрузиться с неё, вытащив SATA-носитель и обновить grub, можно тупо следуя инструкции по восстановлению, там есть все нужные шаги и апдейт в конце.

Образ взять от Kubuntu 18.04? Инструкция — на которую ссыль выше? Раздел в инструкции — chroot? Там написано, что нужно примонтировать важные разделы — у меня эти разделы называются также?

У меня загрузочный диск в GPT, а не MBR — это не страшно?

А иначе бы и без choot восстановилось, всё ок.

— если я правильно распасил твой выхлоп, то так. Ты бы лучше его в «`» заворачивал.

mad_austronaut ★★★★ (21.08.20 22:37:23) Купил KingSpec NVMe 2242 256GB @ 04.07.19

И как оно, шевелится?

kuguar, не туда тебя понесло.

/home was on /dev/sdb1 during installation

UUID=bed99606-a0a7-4fcc-81f5-93123dd6dcef /home btrfs defaults,subvol=@home 0 2

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

Продал его на авито, не подошел, так как в Lenovo X250 диск M.2 работает как SATA.

Купил у того же продавца на али аналогичный диск, но не NVMe, а SATA. Не такой шустрый, но тоже нормальный (SMART).

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

Источник

Самый актуальный гайд по установке Linux на SSD-накопители в 2021 году

Привет, Хабр! Долгие годы по сети гуляют байки о тайных умениях спецподготовки твердотельных накопителей к установке Linux-дистрибутивов. Пользователей-новичков это отпугивает — перейти на OpenSource типа Ubuntu. А давно не следящих за новинками железа — оттягивает прокачать скорость работы. В этом посте мы отбросим все мифы и неактуальные советы, прочно засевшие в топе поисковых запросов. А заодно подскажем ряд простых и эффективных советов по установке Linux на SSD-накопители. Поехали!

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

С большой долей вероятности, поисковая выдача отправит вас прямиком во времена доллара по 30 рублей и новейших процессоров Intel Core под Socket H2. Эх, ностальгия!

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

Насколько готовы современные дистрибутивы Linux к установке на SSD?

Не пытайтесь изобрести колесо. Современные дистрибутивы Linux хорошо оптимизированы под установку на твердотельные накопители и автоматически выставляют оптимальные параметры журналирования и ежедневного обновления TRIM, а также деликатно относятся к записи кэша на диск. Начиная с Ubuntu версии 14.04 твердотельные диски корректно определялись еще на этапе установки, оставляя пользователю лишь иллюзию выбора неправильной файловой системы вместо рекомендуемой Ext4. Все остальное вторично, а 99% проверяющих через консоль активность TRIM на SATA-дисках, неизменно обнаруживали корректные значения вместо нулей.

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

Как подготовить SSD-накопитель к установке Linux-системы?

На сегодняшний день можно смело урезать советы по подготовке твердотельного диска для Linux до советов по выбору подходящего носителя по типу и емкости. Вместо поиска альтернатив файловой системе Ext4 (стандарт де-факто) лучше потратить время на изучение отличий между NAND-чипами с QLC, TLC и другими видами компоновки ячеек. Подробнее о выборе накопителей по признаку QLC и их теоретических недостатках мы подробно рассказывали в этом посте. Если вкратце, SSD-накопители с QLC-ячейками дешевле, а TLC применяются во флагманских решениях, обеспечивая лучшую наработку на отказ и более высокую скорость передачи данных. Продукция Kingston построена на базе передовых 3D TLC и 3D NAND ячеек памяти, лишенных недостатков 4-битных QLC.

Но раскрыть потенциал памяти на ячейках 3D TLC и 3D NAND можно лишь с применением SSD-накопителей формата M.2, подключаемых напрямую к шине PCI-E x4. В линейке накопителей Kingston вы можете выбрать наиболее производительные M.2-накопители линейки KC2500 с предельной скоростью чтения/записи 3500/2500 МБ/с уже для моделей c емкостью от 500 ГБ. Ячейки выполнены по 96-слойной технологии 3D TLC, а производительность контроллера Silicon Motion 2262EN давно стала неким стандартом.

В сегменте M.2-накопителей с ячейками 3D NAND одним из самых популярных решений Kingston являются SSD из линейки A2000. Модели на 500 и 1000 ГБ демонстрируют скорость чтения/записи на отметке 2200/2000 МБ в секунду, а младшая — 2000/1100 МБ/с.

Если же планируете подключать диск по SATA, гнаться за скоростями выше 560 МБайт/с не имеет смысла — упретесь в лимит по шине. Выгоду следует искать в емкости доступного пространства. В линейках Kingston A400 и KC600 доступны твердотельные SATA-диски вместимостью до 2 ТБ. Отличия бюджетной линейки A400 от старшей кроется в использовании ячеек памяти TLC вместо 3D TLC, что напрямую влияет на цену и показатель наработки по числу записываемых байтов информации.

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

Ориентироваться на разницу значений по наработке до отказа у твердотельных SATA-накопителей не столь важно. Как минимум, важнее заложить в бюджет обновления дискового массива качественное питание компьютера, начиная с блока питания и заканчивая сетевым фильтром и бесперебойником. Твердотельные накопители в целом довольно слаботочные решения по сравнению с жесткими дисками, и некачественное питание может свести к нулю всю выгоду от показателя в 1 миллион часов по MTBF.

О журналировании и бэкапе при выборе файловой системы

Возвращаемся к проблеме вреда от чрезмерной заботы по сохранности SSD-накопителей. Бывает, что пользователи отказываются от журналирования вовсе, или вставляют HDD-костыли для снижения паразитных операций перезаписи ячеек. Вообще, применение жестких дисков в паре с твердотельным накопителем можно советовать лишь для хранения крупных мультимедийных файлов (типа кино и музыки), ведь перенос системного кэша и логов на жесткий диск моментально сведет к нулю всю прибавку скорости SSD.

Другое дело — бэкап и все резервные копии. В отличие от сомнительной пользы RAID-массивов из твердотельных накопителей вне промышленных систем хранения данных, резервное копирование информации и образов системы напрямую влияет на сохранность ваших данных. Подстраховка жестким дискам в подобных случаях уместна, но только в случаях, когда IOPS не превышает ваш лимит по стоимости.

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

Как настроить разделы и сколько оставить неразмеченной?

В вопросах эффективности разделения SSD-накопителей на массив логических разделов мы не рекомендуем пытаться искать связи с продлением срока службы носителя. Заложив изначально 25-30% хранилища свободными от данных, вы внесете максимальный вклад в срок безотказной и верной службы диска, а потому вольны свободно размечать до 4-х разделов в рамках Ext4. Другой вопрос, что современные высокоскоростные носители данных можно подключить как USB-C флешку и перекинуть туда некоторые разделы системы.

Создавать несколько логических разделов имеет смысл лишь для разнесения каталогов системы с различным характером применения. Например, системные и бинарные каталоги имеет смысл разделить от логов, как и резервные базы. А вот потребности /run лучше покрыть запасом по доступной оперативной памяти. Это наилучшим образом скажется на снижении IOPS на диск в течении длительного периода эксплуатации.

Как следует настраивать актуальные сборки на базе Linux под SSD?

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

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

Выходит, что никаких отличий по настройке, при установке Linux системы на SSD и жесткий диск, нет вовсе. Можете смело доверить заботу о твердотельном накопителе системе, позаботившись запасом доступной оперативной памяти под нагрузкой. 32 ГБ гарантированно покроют этот вопрос у 99% пользователей, а проверить текущие значения потребления можно простой командой free.

Как измерить скорость работы SSD в Linux?

Если десять лет назад еще можно было встретить упоминания Phoronix test suite, на сегодняшний день стандартом бенчмарков в бытовых, рабочих и серверных машинах является утилита Fio. В умелых руках с ее помощью можно оперативно измерить окупаемость масштабирования СХД по стоимости IOPS, но в бытовых целях вас наверняка интересуют те же значения, что выдает на Windows утилита CrystalDiskMark, не так ли?

Ее аналог доступен на просторах Github под именем KDiskMark. У программы есть графический интерфейс, сводящий проверку скорости накопителей и любых дисков до пары кликов мышкой. За оболочкой скрывается вышеупомянутая Fio, итоговые значения которой наиболее точны в сравнении измерений диска на других ОС.

Вердикт: смело монтируйте Linux на SSD без заморочек

Более подробный анализ значений работы SSD-дисков требует более обстоятельного подхода и широко освещен Хабровчанами. Базовую информацию, разметку и проверку дисковых разделов можно выполнить с помощью утилиты Disks, предустановленной в Ubuntu и многих других Linux-дистрибутивах. А 99% всех рекомендаций и твиков давно утратили свою актуальность. Сегодня вы можете наслаждаться быстрой работой Linux-систем на твердотельных накопителях Kingston без дополнительных танцев с бубнами, просто выбрав установку по умолчанию.

Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.

Источник