История изменений
Исправление intelfx, (текущая версия) :
А если после mv пересоздать корректные симлинки? Или сломается что-то ещё?
Судя по файлу правил (60-persistent-storage.rules), эти правила исполняются не только при ACTION==add, но и при ACTION==change. Т. е. гипотетически посередине работы системы симлинки могут внезапно так пересоздаться. Может ли такое быть на самом деле (в каких конкретно условиях возникают change-события на блочных устройствах) — я не знаю.
(Не говоря уже о том, что ты задолбаешься в точности копировать логику из udev в самописный скрипт.)
И к тому же если симлинки создаёт udev, то если сделать mv перед его стартом, то ведь он создаст корректные симлинки?
Можно проверить, но сомневаюсь. Имена устройств он наверняка получает через нетлинк от ядра, а не сканированием /dev.
(Опять же, не говоря о том, что SATA-контроллер и жёсткий диск совершенно не обязаны проинициализироваться строго до запуска udev. Это как бы причина, по которой udev вообще существует.)
Исправление intelfx, :
А если после mv пересоздать корректные симлинки? Или сломается что-то ещё?
Судя по файлу правил (60-persistent-storage.rules), эти правила исполняются не только при ACTION==add, но и при ACTION==change. Т. е. гипотетически посередине работы системы симлинки могут внезапно так пересоздаться. Может ли такое быть на самом деле (в каких конкретно условиях возникают change-события на блочных устройствах) — я не знаю.
(Не говоря уже о том, что ты задолбаешься в точности копировать логику из udev в самописный скрипт.)
И к тому же если симлинки создаёт udev, то если сделать mv перед его стартом, то ведь он создаст корректные симлинки?
Можно проверить, но сомневаюсь. Имена устройств он наверняка получает через нетлинк от ядра, а не сканированием /dev.
(Опять же, не говоря о том, что контроллер жёсткого диска совершенно не обязан проинициализироваться строго до запуска udev. Это как бы причина, по которой udev вообще существует.)
Исправление intelfx, :
А если после mv пересоздать корректные симлинки? Или сломается что-то ещё?
Судя по файлу правил (60-persistent-storage.rules), эти правила исполняются не только при ACTION==add, но и при ACTION==change. Т. е. гипотетически посередине работы системы симлинки могут внезапно так пересоздаться. Может ли такое быть на самом деле (в каких конкретно условиях возникают change-события на блочных устройствах) — я не знаю.
(Не говоря уже о том, что ты задолбаешься в точности копировать логику из udev в самописный скрипт.)
И к тому же если симлинки создаёт udev, то если сделать mv перед его стартом, то ведь он создаст корректные симлинки?
Можно проверить, но сомневаюсь. Имена устройств он наверняка получает через нетлинк от ядра, а не сканированием /dev.
Исходная версия intelfx, :
А если после mv пересоздать корректные симлинки? Или сломается что-то ещё?
Судя по файлу правил, он исполняется не только при ACTION==add, но и при ACTION==change. Т. е. гипотетически посередине работы системы симлинки могут внезапно так пересоздаться. Может ли такое быть на самом деле (в каких конкретно условиях возникают change-события на блочных устройствах) — я не знаю.
(Не говоря уже о том, что ты задолбаешься в точности копировать логику из udev в самописный скрипт.)
И к тому же если симлинки создаёт udev, то если сделать mv перед его стартом, то ведь он создаст корректные симлинки?
Можно проверить, но сомневаюсь. Имена устройств он наверняка получает через нетлинк от ядра, а не сканированием /dev.