Самопроизвольно меняются местами разделы

У тебя они как в fstab записаны, как /dev/sdXn ? Если да, то это нормально, имена дисков получаются в опрядке инициализации. Настрой монтирование по UUID ФС.

Тема не раскрыта

• что есть метка диска в контексте темы?
• Параметры монтирования прописаны в fstab извините, не развидел в теме

Подскажите - где искать косяк?

начать отсюда параметры монтирования в fstab, а там куда вывезет ;)

Блин, у тебя что, гонка сигналов? Не может быть. Хотя… монтируй по ууидам, так надежней.

Кроме традиционных файлов /dev/sd* (которые могут давать такой эффект, они назначаются в порядке обнаружения) есть ещё папочки /dev/disk/by-*, где все те же самые диски перечислены по разным идентификаторам. Выбирай любой, прописывай в /etc/fstab вместо /dev/sd* и путаница исчезнет.

UUID это самый непонятный из вариантов. Тогда уж по by-id, там зашита шина, видимо серийник и номер раздела. Но я предпочитаю by-label (хотя метки у разделов могут оказаться одинаковыми, зато наглядно и понятно).

Начиная с какой-то версии ядра в линуксе сломали стабильность номеров /dev/sd* устройств, сделав их практически бесполезными если у тебя больше одного диска. Знаю, что в ядре 3.2 оно точно работало нормально, а в ядре 5.10 (как раз debian 11) уже точно сломано. В ядре 4.9 кажется тоже работало норм, но это уже не точно.

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

Хотя сейчас посмотрел, там названия привязаны к названиям моделей дисков, либо к их серийникам. Нормального варианта с привязкой к слоту (номеру разъёма на материнке) походу всё-таки нет теперь :(

Они никогда не были стабильными. Ну, разве что во времена шины ide, когда диски подключались в строгом порядке и первый не мог стать вторым. Во времена ядра 2.6 sata-диски уже в принципе могли взять и поменяться.

Ставь FreeBSD.

Можно дать уникальные метки тома, так чтобы точно не совпало.

Знаю, что в ядре 3.2 оно точно работало нормально, а в ядре 5.10

В генте 5.14 всё работало.

Потому что сломали не ядро, а системд. Я недавно создавал такую тему. Харды меняются местами из-за параллельной инициализации. Найти бы, как это отключить (переход на маргинальные иниты не предлагать).

fstab поддерживает метки нативно:

LABEL=<label> or UUID=<uuid> may be given instead of a device name. This is the recommended method, as device names are often a
coincidence of hardware detection order, and can change when other disks are added or removed. For example, 'LABEL=Boot' or
'UUID=3e6be9de-8139-11d1-9106-a43f08d823a6'. (Use a filesystem-specific tool like e2label(8), xfs_admin(8), or fatlabel(8) to set
LABELs on filesystems).

It’s also possible to use PARTUUID= and PARTLABEL=. These partitions identifiers are supported for example for GUID Partition Table
(GPT).

Почему у меня тогда ни разу не менялись?

У меня на этом компе с несколькими дисками нет системд и не было никогда.

Рад за вас.

Потому, что. Какой вопрос такой и ответ. То, чего ты не видел, не факт, что этого нет. Тебе просто повезло.

Если в системе стоят жёсткие диски, то всё зависит от того прошивка какого диска запустится первой и сообщит контроллеру о наличии накопителя на порту.

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

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

Суслика видишь? Нет. А он есть.

Это не в системд дело, а в ядре Linux. Оно назначает имена дискам в последовательности их инициализации.

Я в курсе. Просто utanho заявил что это из-за системд, я ему и ответил.

Прошивки жёстких дисков записаны на нулевой дорожке.

Что за глупости? Прошивка записана в каком-то из чипов на плате контроллера в виде флеш-памяти.

Потому, что. Какой вопрос такой и ответ. То, чего ты не видел, не факт, что этого нет. Тебе просто повезло.

Да прям так повезло: всё годами работало стабильно, стоило обновиться как сразу через раз стали меняться (вплоть до того что первый же ребут после апдейта ядра не запустился из-за того что перепутал sdb1 и sda1, я тогда ещё подумал что апдейт видимо что-то запорол).

Что за глупости? Прошивка записана в каком-то из чипов на плате контроллера в виде флеш-памяти.

Ну сходи почитай в гугл, что такое сервисный раздел жёсткого диска.

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

Сходи почитай.

Суслика видишь? Нет. А он есть.

Да прям так повезло: всё годами работало стабильно

Я с такой проблемой сталкивался лично. Ещё на Gentoo примерно 2.6.28 и 3.2 и далее.

вплоть до того что первый же ребут после апдейта ядра не запустился из-за того что перепутал sdb1 и sda1

Файловую систему /dev наполняет ядро. Ну за некоторым исключением.

С обновлением прилетело не только systemd, но ещё и новое ядро. А следовательно новый драйвер контроллера жёстких дисков. Попробуй загрузиться со старым ядром. Только обнови в начале initramfs для него.

из-за того что перепутал sdb1 и sda1

А нафейхуа ты используешь эти имена, я уже года с 2008 примерно использую либо метки файловых систем, либо PARTUUID раздела, либо UUID файловой системы, либо LVM.

Это называется ССЗБ.

служебная информация

Не путай названия, это не прошивка. Прошивка это то что в чипе.

Я с такой проблемой сталкивался лично. Ещё на Gentoo примерно 2.6.28 и 3.2 и далее.

А вот utanho говорит что Gentoo 5.14 наоборот не подвержен. Значит, возможно, это не изменения в коде самого ядра, а в каких-то дефолтных его настройках, зависящих от дистра.

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

Никакого systemd мне не прилетало, у меня его нет, ещё раз говорю. И то что дело в ядре я с самого начала написал.

я уже года с 2008 примерно использую либо метки файловых систем, либо PARTUUID раздела, либо UUID файловой системы, либо LVM.

А я, с тех пор как в debian кажется 6 установщик стал наполнять fstab этими uuid-ами вместо нормальных названий устройств - каждый раз вручную правлю их на читаемые названия /dev/sdaX. Что собственно везде и работает т.к. обычно физический диск один.

А нафейхуа ты используешь эти имена,

Затем, что бы при замене диска можно было новый диск разметить, скопировать на него все файлы, сделать grub-install (или как там его) и всё сразу норм. И было бы норм если б не умники, додумавшиеся не следить за номерами устройств.

Я и ставлю (на серверах, и кстати никаких путаниц с номерами устройств разумеется там никогда не было). А для десктопа пока не изучил его. Может быть он и не хуже линукса будет и всё из коробки заработает (учитывая что всякие блоатварные плохосовместимые ДЕ я не использую), но времени разбираться не особо.

Не путай названия, это не прошивка. Прошивка это то что в чипе.

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

А вот utanho говорит что Gentoo 5.14 наоборот не подвержен.

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

Затем, что бы при замене диска можно было новый диск разметить, скопировать на него все файлы, сделать grub-install

Достаточно после копирования файлов и установки загрузчика, перегенерации его конфига, т.к. в самом grub в конфиге используются идентификаторы разделов, поставить метку файловой системе и все.

Достаточно

Может быть, но я привык видеть разделы по номеру sata-интерфейса + номеру раздела. То что в линуксе это сломали лишь ещё раз подтверждает общее низкое качество его разработки.

Прочитай описание того, почему это происходит. Это не сломали, это так и было. Не было лишь на ide накопителях, потому что каналы мастер, слейв были изначально именования hda, hdb, если два ide разъёма ещё hdc и hdd.

Во freebsd ядро именует диски всегда по каналам контроллера в случае же Линукс на sata, scsi и именования диска a, b, c, d … на каком он канале, всё зависит от того в каком порядке он проинициализирован и определен контроллером.

Вангую, материнская плата и биос стабильно передают ОС табличку с устройствами или типа того.
По той же причине возникла новая схема наименования сетевых интерфейсов (enpX…Y) вместо eth0.

Не было лишь на ide накопителях

Было и на IDE. Уже писал несколко раз, в том числе и utanho. Напишу еще раз.

Был у меня ноутбук, 2004 года, HDD ide. БИОС, слова УЕФИ тогда еще не существовало.

При подключении более одного диска они менялись почти каждую перезагрузку. Диски любые: ide, usb-ide, usb-sata, flash.

Лично у меня - потому что у меня был только 1 диск. А вот юсб-флешки всегда были «угадай куда прилетит», и я иногда монтировал их при старте как корень.

Божественно:-) Оказалось именно то, что надо. Прописал в fstab монтирование по лабелам и теперь диски подключаются именно в той последовательности, как прописаны в fstab, и подключаются каждый на своё место.

Немного поясню: у меня комп качает по скриптам разную инфу и раскладывает её по разделам. Сам проверяет актуальность, сам удаляет старую инфу и закачивает свежую… И все скрипты завязаны на пути /dev/sd*… Поэтому для меня критично, чтобы все харды были там, где им назначено… А хардов под хранение, у меня 16… Так что, большое вам спасибо за помощь :-)

Вопрос решён. Тему можно закрывать. Всем спасибо за помощь. Я узнал много нового для себя :-)

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

Генту-сурсес, патчи не накладываю. Проблема присутствует во весь рост. При том, что у меня сда = ссд, сдб = хдд.

По идее, сдд должен всегда быть вперде, потому что ничего не раскручивается.

Как я уже писал, проблема имеет место как минимум в дебиане и опенсусе. В федоре все нормально, диски не путаются.

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

Ошибаешься, уже давно нумерация динамическая.

Про usb речи не было, они понятно куда попало попадают.

либо LVM

Вот +100500. Особенно для multimedia/pressa. Годы идут, информация копиться, диски портятся… А тут закончилось дисковое пространство, выключил комп, диск вставил, включил и на горячую настроил. Хочешь забэкапить/зазеркалить всё есть и без простоев. Если надо, то и SSD кэш за пару минут настраивается. Ну и по теме, имена разделов человеческие.

Если их не перетыкать, то у них точно так же есть номер шины и номер порта. Но там просто ситуация гонки более жёсткая и хз от чего зависит кто первым очнётся.

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

И чёрт с ним с fstab-ом, там-то можно прописать ID, LABEL и прочее. А вот LVM, например, тоже использует для физических томов нотацию sd?, и приходится каждый долбаный раз выяснять, на каком же всё-таки устройстве находится сегодня какой-нибудь конкретный PV. Равно как и море, скажем, виджетов для десктопа, которые эти ваши by-id либо вообще не понимают, либо они в виджет тупо не влезут, потому что длиной в 80 символов, в отличие от короткого sd?. Короче, очередное спасибо ядреным улучшаторам.

В LVM точно такая же проблема, если физических дисков несколько. Вот решил ты переместить LV с одного устройства на другое — нее, просто так нельзя, сначала убей время на то, чтобы выяснить, который из 4 приводов у тебя сегодня /dev/sda.

И что? Для usb никогда не было цели держать их статичными, воткнул в рандомный порт, вытащил, через день воткнул в другой и совершенно ни к чему их запоминать. А вот то что внутри компа оно воткнуто 1 раз и на годы, меняться самопроизвольно не должно.

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

LVM собирает разделы по UUID. Что ты там каждый раз выясняешь, и зачем?

А я, с тех пор как в debian кажется 6 установщик стал наполнять fstab этими uuid-ами вместо нормальных названий устройств - каждый раз вручную правлю их на читаемые названия /dev/sdaX.

А можно было всего лишь передать параметр partman/mount_style=traditional при установке.

Куда передать?

Очевидно, установщику через параметры ядра.

То есть мне надо ковыряться в iso-образе и редактировать в нём параметры ядра вместо того чтобы просто запустить его? Напомню, grub-а там нет.

То есть мне надо ковыряться в iso-образе и редактировать в нём параметры ядра вместо того чтобы просто запустить его? Напомню, grub-а там нет.

https://ibb.co/H75BCxc

Документация — для слабаков!

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

Так как я использую системд, то проверить поведение системы с другими инитами немного затруднительно.

Однако ж, в Федоре36 диски не пляшут.

Тему с системд я не с потолка взял. На каком-то буржуйском форуме наткнулся. Что-то там в недрах изменилось и даже вроде было указано, куда копать.

Для дисков тоже такой цели не было. Разве что биос помнил какой из них считать первым загрузочным. Но это на уровне биоса и загрузчика. а ядру вообще паралельно.

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

то только потому, что она когда-то получилась сама собой.

Вот. Но гарантий никто даже тогда не давал, и иногда они могли перетасоваться (иногда!). А сейчас, с полной виртуализацией всего, прослойками и распаралеливанием - странно что не регулярно, как флешки.

PV как назывались /dev/sd?, так и называются, при всех этих ваших UUID. Сразу видно лоровского «игзперда», который pvs никогда в жизни не запускал.

А ты каждый раз LVM собираешь по именам устройств, эксперт?

Вопросов больше не имею.