Система Dracut Centos 7 не загружается
Обновлено: 04.07.2024
RHEL 7.4 не загружается после успешного обновления с любым ядром выше 3.10.0-514.21.1.el7.x86_64.
Система не находит корневой раздел, установленный на lvm2.
Загрузочное сообщение:
dracut-initqueue[279] Предупреждение: не удалось загрузить
dracut-initqueue[279] Предупреждение; /dev/картограф/rhel_. -root не выходит
Ответы
Конечно, он не может найти требуемое корневое устройство '/dev/mapper/rhel-root', как ожидалось, и, следовательно, терпит неудачу, поэтому вы можете проверить блочные устройства и разделы, доступные из оболочки dracut. Запустите команду «parted /dev/sda -s p», чтобы узнать сведения о разделе (при условии, что корневая файловая система установлена на первом диске, который установлен по умолчанию).
Кроме того, активируйте группу томов и найдите имеющиеся логические тома. Запустите команду «lvm vgscan», а затем «lvm vgchange -ay» из оболочки dracut, чтобы проверить это. Запустите «blkid», который в идеале должен показать ваш корень, поменять файловую систему на соответствующие блочные устройства.
Предполагая, что ваше старое ядро не повреждено, попробуйте загрузиться в старое ядро и проверьте, создан ли соответствующий файл образа vmlinuz для нового ядра в /boot . Вы можете попробовать восстановить исходный образ и проверить. Кроме того, проверьте наличие свободного места в файловой системе /tmp или в корневой папке, если она не смонтирована отдельно.
Здравствуйте, Садашива, после "lvm vgscan" и "lvm vgchange -ay" в dracut-shell есть группа томов для корневого раздела, lvdisplay показывает, что логический том для root присутствует, но статус LV "Недоступен" для корневого раздела и раздела подкачки. Я не понимаю, почему. blkid показывает lvm-раздел на /dev/sdg2 как тип LVM2_member. Пересоздание initrd для нового ядра не помогает. Сообщение об ошибке такое же.
В корневой файловой системе имеется 40 ГБ свободного места, а /tmp не является эксклюзивной точкой монтирования.
Людгер Кёлер, вам удалось это исправить?
Вы можете активировать lvm с помощью "lvchange -ay /dev/vgname/lvname".
Ознакомьтесь с шагами, перечисленными в этой базе знаний https://access.redhat.com/solutions/1282013. Вам потребуется выполнить шаги в разделе «ПРОСМОТР И ВОССТАНОВЛЕНИЕ КОНФИГУРАЦИИ GRUB». Давайте узнаем, что будет после этого. Всего наилучшего!
К сожалению, это не помогает. lvm.conf filter = [ "a/.*/" ]
Вывод dracut-shell "lvm pvscan" и "lvm vgscan" показывает наличие root VG. «lvm lvscan» показывает неактивный root LV lvm vgchange -ay показывает «0 логических томов в группе томов для root теперь активен
Я мог предположить, что система может без проблем загрузиться обратно в предыдущее ядро. Если да, не могли бы вы загрузиться со старой рабочей конфигурацией ядра и проверить наличие необходимых файлов в /boot для нового ядра, доступного там, например, vmlinuz.x, intramfs.x, проверить файл /boot/grub2/grub.cfg на наличие ошибок в строке, начинающейся с linux16 для более нового ядра.
Я некоторое время наблюдал за этим обсуждением и предположил, что проблема, скорее всего, может возникнуть из-за того, что вы обновили систему с RHEL 7.3 до RHEL 7.4 . потому что вы упомянули, что все ядра после версии 3.10.0-514.21.1.el7.x86_64 не загружаются.
Ядро 3.10.0-514 использовалось в RHEL 7.3, а в RHEL 7.4 включено ядро 3.10.0-693. Обновление операционной системы часто приводит к различным (более или менее крупным) проблемам, поэтому я рекомендовал выполнить чистую установку системы после выхода финальной версии. Возможно, вы захотите последовать этому совету, я думаю, что проблема должна быть решена позже.
Кристиан, иногда даже я думаю, что чистая установка предпочтительнее, но в большинстве случаев это неосуществимый вариант. Я не видел особых проблем в этом процессе (незначительные обновления выпуска), за исключением этого случая, всякий раз при обновлении до RHEL7.4. Конечно, при рассмотрении полного обновления (например, при обновлении с RHEL7.3 до RHEL7.4) необходимо учитывать множество факторов, совместимость приложений, насколько легко вернуть роль в случае сбоя обновления, сколько времени мы приступайте к работе над всеми этими действиями/устранением неполадок и т. д. однако, если вы посмотрите на эту ситуацию, которую мы здесь обсуждаем, это просто то, что загрузочные конфигурации, файлы, модули не синхронизированы или не собраны должным образом после обновления ядра.
Не уверен, что это постоянная проблема с обновлением RHEL7.4, а также нет ясности, знает ли об этом Red Hat и обращался ли кто-либо к Red Hat по этому поводу.
Людгер Кёлер, вы можете обратиться в Red Hat, если у вас есть действующая подписка на поддержку.
Я не думаю, что это "особая проблема обновления RHEL 7.4" . такие вещи случаются - я просто хотел сказать, что чистая установка, безусловно, позволяет избежать таких проблем и что Ludger может потратить меньше времени на переустановку системы, чем на исправление конфигураций и модулей, которые вы правильно упомянули. :)
Спасибо за все ответы, я не думаю, что это проблема для RHEL7.4. Проблема также существует для RHEL7.3 с ядром > vmlinuz-3.10.0-514.21.1.el7.x86_64, поэтому ядро вмлинуз-3.10.0-514.26.1.el7.x86_64 и vmlinuz-3.10.0-514.26.2.el7.x86_64 тоже не работают. Доступны файлы в /boot для всех ядер (vmlinuz.x, intramfs.x), а /boot/grub2/grub.cfg содержит правильные строки для каждого ядра. Создание нового initrd также не работает. Да, у нас есть действующая подписка на поддержку, и мы можем подать заявку в Redhat.
Добро пожаловать, Людгер,
Тогда сначала попытайтесь исправить это вместе с командой технической поддержки, и если они не могут сделать это в разумные сроки, просто выполните чистую установку. Кстати, вы можете использовать файловую систему ext4 вместо lvm.
Извините, Кристиан, использовать ext4 вместо lvm? . Вы хотите сказать "используйте ext4 вместо xfs"? Я не думаю, что здесь это необходимо.
О, извините, Садашива, кажется, я недостаточно хорошо выразил то, что хотел сказать. Я имел в виду разбиение, установку системы на «старый добрый» надежный раздел ext4 (выбрав «ручную настройку» в установщике Anaconda) вместо установки на логические тома, то есть в «режиме LVM». :)
Хорошо, поднимите вопрос и держите нас в курсе. Делиться знаниями — это лучшее, что мы можем дать сообществу :)
Был ли запрос по этой проблеме в службе поддержки Red Hat? Надеюсь, вы не возражаете обновить эту дискуссионную ветку о событиях.
Можно ли загрузиться со старым ядром?
Если да, что означает вывод команд df -h /boot и df -h / ?
ИМХО, возможно, файловая система /boot или файловая система / слишком малы, поэтому каждое обновление ядра не выполняется.
Загрузочная файловая система может быть кандидатом.
Другим вариантом может быть отсутствие в файлах initrd модулей lvm. Чтобы исправить это, я советую вам, как это уже сделал Sadashiva Murthy M, открыть обращение в службу поддержки и загрузить sosreport.
Ян Геррит Кутстра
Хорошая идея, Ян Геррит, но по умолчанию в /etc/yum.conf установлено значение installonly_limit=3 , поэтому когда Людгер не изменил его на гораздо большее число . эти три ядра не должны занимать слишком много места — или я ошибаюсь? :)
загрузочная файловая система составляет 1 ГБ, используется 400 МБ, достаточно места в каждом файле initrd, в котором присутствует модуль lvm
Я встречал установки, в /boot которых было всего 256 МБ, потому что кикстарты все еще основывались на установках Red Hat 6.1 или Red Hat 9 (до RHEL), а установка раздела/lvm никогда не обновлялась.
Игнорировать очевидное — плохая практика, мой опыт.
Вы правы, Ян Геррит, предположив, что "худший случай" лучше, чем "нормальный или лучший случай" . кстати - я никогда не видел преимущества в создании отдельного раздела /boot. и в случае поломки я просто запускаю clonezilla . :)
"Преимущество" заключается в том, что у вас меньше ограничений на тип файловой системы "корневой" файловой системы.
Исторически это было ограничение, связанное с тем, что загрузчики не могли обнаружить физические тома lvm на этапе загрузки 0. Поэтому вам требовались этапы загрузки 1 и 2 в файловой системе, которая находится на разделе диска, а не на логическом томе.
Спасибо за эту информацию, Ян Геррит, я также хочу воспользоваться возможностью, чтобы поблагодарить вас в целом за вашу полезную поддержку и ваш полезный вклад здесь. Мы действительно можем многому научиться у вас и вашего опыта, Ян Геррит! :)
Спасибо, Кристиан, за 20 лет в бизнесе можно чему-то научиться и набраться опыта. Просто изучение новых трюков становится сложнее. Так что экзамен RHCE 7 — это преступление. У меня больше нет повседневного опыта с тех пор, как меня повысили до дизайнера решений.
Поэтому я создал демонстрационную среду/среду разработки примерно 17 лет назад, когда я еще был системным администратором Unix/Linux и аспирантом прикладной математики.
Поэтому, если я вижу обсуждение, которое занимает много времени или касается темы, которую я знаю, я воспроизведу проблему и, если необходимо, сам открою запрос в службу поддержки. Это преимущество работы с Red Hat Partner более десяти лет. В некоторых ситуациях я прошу своих контактов в Red Hat изучить обсуждение, и они также просят коллег посмотреть.
Поэтому я рад, что могу учить и помогать новичкам и видеть, как они быстро учатся.
Посмотрите на себя, сколько вкладов вы вносите в форум: отлично.
Спасибо за добрые слова, Ян Геррит. Кажется, у нас одинаковый подход. Я изо всех сил стараюсь помочь (новым) пользователям решить их проблемы, а значит, вернуть что-то сообществу Red Hat. Я очень рад, что вы цените мой вклад. :)
Вы упомянули, что в каждом файле initrd есть модуль lvm. Вы извлекли содержимое файлов initrd?
Если да, то проверили ли вы также фильтр в /etc/lvm.conf внутри initrd?
В прошлом мои коллеги и я столкнулись с тем, что старый MAKEINITRD на RHEL 5 или RHEL 6 не всегда создавал тот же файл /etc/lvm/lvm.conf, что и в корневой файловой системе, где файл, созданный anaconda во время установка прошла "идеально".
Я думаю, почему бы Red Hat не создать инструмент/командный интерфейс, который может выполнять некоторые из этих проверок работоспособности после установки нового ядра, чтобы подтвердить, добавлены ли требуемые модули (сравнивая новый образ initrd с текущим используется один), необходимые параметры должным образом добавлены в файл grub, или даже добавить их в сам процесс установки ядра было бы хорошо. Это избавило бы от многих таких проблем, или, по крайней мере, люди будут знать, что новое ядро успешно установлено со всеми модулями / конфигурацией или нет, чтобы они не рискнули перезагрузиться и пройти через все проблемы, тратя время впустую, что очень важно, что предприятие не хочет потерять (имея в виду перезагрузку в старое ядро). Я настоятельно рекомендую Red Hat разработать инструмент для этого, иначе нам придется вручную проверять все это (файлы конфигурации, файл grub, ограничения по размеру, проверку образа initrd и т. д.).
Недавно пытался загрузить свой сервер, но получаю следующую ошибку. Кажется, что initramfs не может генерировать, и я попытался загрузиться в режиме восстановления и обнаружил, что файл fstab пуст. Обновил файл, но безрезультатно. Я приложил изображение, так как не могу скопировать строки.
2 ответа 2
Добро пожаловать в Unix&Linux StackExchange!
Ошибка исходит от initramfs , и основная проблема, по-видимому, описана
Другими словами, используя драйверы хранилища, доступные в initramfs, невозможно найти корневую файловую систему, указанную этим UUID.
Включает ли загрузочное меню GRUB старые версии ядра? Если это так, что произойдет, если вы попытаетесь загрузиться со старым ядром?
Если загрузка со старым ядром не работает, вы можете загрузить систему в режиме восстановления с помощью установочного носителя CentOS или использовать другой действующий носитель Linux для загрузки системы для исследования. Если команда blkid не может найти UUID, указанный в сообщении об ошибке, ни на одном из дисков, это может быть вызвано несколькими причинами:
Отсутствует водитель? Некоторые современные серверы используют «BIOS RAID», для которого требуется специальный драйвер от поставщика оборудования. Возможно, вам придется предпринять дополнительные шаги для загрузки этого драйвера в среде восстановления/LiveOS. Ошибка может быть вызвана обновлением ядра на сервере, но не установкой соответствующего обновления драйвера от поставщика.
Ошибка конфигурации GRUB/initramfs? Корневая файловая система может быть указана с параметрами загрузки ядра, и ошибка в редактировании конфигурации GRUB могла привести к тому, что она ссылалась на неправильную файловую систему. Вам нужно будет определить правильный UUID для корневой файловой системы и исправить конфигурацию. Исправления фактического файла конфигурации GRUB /boot/grub/grub.cfg или /boot/efi/EFI/centos/grub.cfg будет недостаточно; вам также необходимо исправить файл, который используется в процессе автоматической перенастройки GRUB при установке обновлений ядра. Этот файл должен быть /etc/default/grub .
Корневая файловая система повреждена или перезаписана? Вы сказали, что пытались загрузиться в режиме восстановления, но обнаружили, что файл /etc/fstab пуст — как именно вы это сделали? Если бы это была аварийная оболочка Dracut, она работала бы в среде initramfs и могла бы иметь пустой файл /etc/fstab.
Но если вы действительно загрузились с отдельного носителя и успешно смонтировали устройство, которое должно было содержать корневую файловую систему, и обнаружили пустой файл /etc/fstab, это означает, что с этой файловой системой могло произойти что-то очень плохое. В таком случае, надеюсь, у вас есть хорошие резервные копии.
Допустим, вы обновили макет программного рейда — создали, удалили или изменили свой программный рейд и перезагрузили систему, а ваш сервер не запускается нормально. После загрузки вашей удаленной видеоконсоли (KVM) вы видите отчеты о процессе загрузки для отсутствующего устройства, и вы находитесь под консолью (консоль dracut). Ваша система находится в «Аварийном режиме».
СКРИНШОТ 1) Процесс загрузки сообщает о нескольких предупреждающих сообщениях о тайм-ауте dracut-initqueue, так как диск не найден.
Предупреждение: тайм-аут dracut-initqueue — запуск сценариев тайм-аута
Эта статья похожа на Centos 7 Server, который зависает при загрузке после удаления программного рейда (устройство mdadm).
Проверьте, все ли ваши программные рейд-устройства включены в:
- /etc/default/grub, который используется при настройке конфигурации загрузки.
- /boot/grub/grub.cfg — файл конфигурации grub.
Что произошло в нашем случае
мы включили конфигурацию в /etc/default/grub, но никогда не генерировали новую конфигурацию grub2 перед перезагрузкой, поэтому наш сервер перешел в аварийный режим, из которого вы можете выйти, просто набрав «exit» и чтобы продолжить загрузку системы в обычном режиме.
Итак, чтобы было ясно, если вы удаляете RAID или заменяете его новым с новым идентификатором, вы должны обновить /etc/default/grub, а затем сгенерировать конфигурацию grub /boot/grub/grub.cfg.< /p>
Вот журнал того, как мы столкнулись с проблемой и как мы ее исправили.
Проблема
Как вы можете видеть, в нашей конфигурации по умолчанию последнее устройство программного рейда имеет идентификатор d950abd0:22d3443d:07148bae:344b362a, но в активной конфигурации grub2 используется старый идентификатор 2fdc509e:8dd05ed3. :c2350cb4:ea5a620d и поэтому мы попали в аварийный режим, grub2 не может найти этот диск, потому что он был удален.
Чтобы решить проблему
Создайте конфигурацию grub2 и убедитесь, что две конфигурации по умолчанию и активная совпадают.
Как упоминалось выше, мы уже обновили «/etc/default/grub» и включили новый UUID RAID в параметр ядра rd.md.uuid, но не создали файл /boot/grub2/grub.cfg. с новой конфигурацией. Поэтому, если вы еще этого не сделали, вы должны сделать это перед использованием grub2-mkconfig. Довольно легко увидеть UUID RAID с помощью инструмента mdadm. Сначала выведите список устройств mdstat, чтобы найти их имена. Допустим, «md0» — новый (старый уже удален, он все еще находится в конфигурации) и используем mdadm с одним из дисков, входящих в состав RAID «md0», чтобы увидеть UUID. Замените старый rd.md.uuid=[UUID_OLD] в «/etc/default/grub» на rd.md.uuid=43ceac15:c4a1be05:690eef43:2d364140. И теперь вы можете использовать grub2-mkconfig, как описано выше, для создания новой конфигурации grub2.
СКРИНШОТ 2) Если загрузка не удалась, процесс загрузки оставит вас в аварийной оболочке.
Выйти и продолжить загрузку очень просто — просто введите «exit» и нажмите Enter. Вы можете просмотреть журналы systemd с помощью journalctl — эти журналы относятся к текущему процессу загрузки и находятся в памяти.
Запуск аварийной оболочки Dracut и выход из нее
СКРИНШОТ 3) Выйдите из Emergency Shell с помощью команды «Выход», и процесс загрузки продолжится, если это возможно.
В нашем случае нераспознанный диск был нашим новым хранилищем и не имел значения для процесса загрузки. Если бы неправильно настроенный идентификатор относился к корневому разделу, процесс загрузки можно было бы продолжить. Процесс загрузки достаточно шустрый и вы можете увидеть две строчки после команды «выход»: «Не все диски найдены». и «Возможно, вы захотите восстановить свои initramfs». — в нашем случае не initramfs, а конфигурация grub2!
Выйдите из Emergency Shell и продолжите нормальную загрузку
СКРИНШОТ 4) Обычная загрузка продолжается после Emergency Shell, если нераспознанный диск не так важен (например, как корневой раздел).
Обычная загрузка после Emergency Shell
3 мысли о «CentOS 7 dracut-initqueue timeout и не удалось загрузить — предупреждение /dev/disk/by-id/md-uuid- не существует»
простое решение заключается в том, что при отключении от Интернета на самом деле обновите файл grub из репозитория Linux, если вы работаете на виртуальной машине. После этого, если эта проблема возникнет, перейдите к вышеупомянутому решению,
Спасибо. Ваше объяснение очень ясно. Но, возможно, я использую EFI в качестве загрузочного раздела, я использую этот способ для решения своей проблемы.
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Оставить ответ Отменить ответ
Найти нас
Адрес
101010010100 Main Street
Earth, EA 101010101010100
Часы (в TimeBank)
1000000:00:0:00:00 по времени…
Об этом сайте
Высококвалифицированные гоминины населяли планету Земля давным-давно! И этим гомининам нужно поделиться некоторыми знаниями здесь.
Чтобы решить эту проблему, может потребоваться одно или оба из следующих действий, а затем восстановление исходного виртуального диска:
- Исправьте фильтр LVM в файле /etc/lvm/lvm.conf, чтобы он принимал устройства, связанные с корневой файловой системой.
- Убедитесь, что ссылки на корневые пути VG и LV в конфигурации GRUB верны.
- Убедитесь, что пакет LVM установлен и модуль lvm присутствует в файле образа initramfs.
Следующие шаги предлагают один из подходов к поиску и устранению неполадок с использованием оболочки dracut:
Войдите в оболочку dracut
Оболочка dracut заменит панику ядра после ошибки на начальном виртуальном диске, позволяя вам устранять неполадки и, возможно, решать проблему оттуда. Чтобы войти в оболочку dracut вместо паники, прервите процесс загрузки GRUB, отредактируйте командную строку ядра следующим образом, а затем продолжите процесс загрузки:
Продолжить загрузку с этим изменением. После предупреждения о dracut вы должны увидеть что-то вроде этого:
Просмотр и восстановление фильтра LVM в файле /etc/lvm/lvm.conf
<р>1. В оболочке dracut, описанной в первом разделе, выполните в командной строке следующие команды:Если в выходных данных отображаются корневая группа томов и тома LV, перейдите к следующему разделу, посвященному восстановлению конфигурации GRUB. Если они отсутствуют, перейдите к следующему шагу.
<р>2. Удалите файл конфигурации LVM на работающем в данный момент начальном виртуальном диске. Обратите внимание, что это не сохраняется и не влияет на корневую файловую систему. Это всего лишь изменение того, что в настоящее время загружено в ОЗУ для виртуального диска. Это заставит LVM использовать фильтр «принять все» по умолчанию при сканировании устройств: <р>3. Повторно просканируйте устройства с удаленным фильтром LVM и убедитесь, что корневая группа VG найдена: <р>4. Если корневая виртуальная группа найдена, пропустите этот шаг. Если корневая группа томов не найдена, проверьте вывод blkid, чтобы убедиться, что физическое блочное устройство найдено. Если сами устройства не отображаются, проверьте физические подключения к устройству. Если устройство отображается, проверьте, не произошло ли повреждение устройства, из-за чего данные LVM стали нечитаемыми. При необходимости обратитесь в службу поддержки Red Hat за помощью: <р>6. Восстановите первоначальный образ виртуального диска после внесения изменений в /etc/lvm/lvm.conf перед перезагрузкой системы:Как восстановить исходный образ виртуального диска в Red Hat Enterprise Linux <р>7. Попробуйте перезагрузить систему в обычном режиме. Если та же ошибка возникает снова, даже с исправленным фильтром, см. следующий раздел, посвященный настройке GRUB.
Просмотр и восстановление конфигурации GRUB
<р>1. В оболочке dracut, описанной в первом разделе, запустите команды «lvm pvs» и «lvm lvs» в командной строке. Запишите выходные данные, особенно имена устройств, VG и LV. Ниже показан пример вывода с помощью команд: <р>2. Перезагрузите систему и снова прервите загрузчик GRUB. Оттуда при необходимости исправьте строку ядра, чтобы убедиться, что имена LV и VG совпадают с показанным выводом. Затем продолжите загрузку в обычном режиме.ПРИМЕЧАНИЕ. Если после внесения этих изменений система по-прежнему не загружается нормально, перейдите к загрузке в аварийной среде для дальнейшего устранения неполадок.
<р>3. После загрузки отредактируйте конфигурацию GRUB, чтобы сделать изменения в командной строке ядра постоянными. <р>4. Перезагрузитесь еще раз, чтобы убедиться, что изменения GRUB были успешными.Основная причина
Одна из причин появления этого сообщения заключается в том, что фильтр LVM, заданный с помощью параметра filter в файле /etc/lvm/lvm.conf , имеет слишком строгие ограничения. В результате, когда первоначальный виртуальный диск сканирует устройства, он отклоняет устройство, содержащее корневую файловую систему. Затем, когда виртуальный диск продолжает поиск метаданных LVM и корневой файловой системы, он не обнаруживается на остальных устройствах.
Еще одна причина появления этого сообщения заключается в том, что конфигурация LVM на диске несовместима с конфигурацией исходного виртуального диска или GRUB. Примером этого может быть переименование корневого VG или LV без обновления GRUB или перестроения виртуального диска.
Этапы диагностики
Чтобы определить, может ли быть проблема с фильтром LVM, выполните дополнительные действия для расследования из оболочки dracut:
<р>1. Прервите процесс загрузки GRUB и отредактируйте командную строку ядра следующим образом:Удалите это (если есть): rhgb quiet
Добавьте это: rdshell
rdshell перейдет в оболочку dracut, если есть проблемы с начальным виртуальным диском. <р>2. Используйте базовые команды pvs и lvs из LVM, чтобы проверить, что нашли текущие фильтры LVM:
Если фильтр LVM является ограничительным и пропускает устройство с корневой файловой системой, в выводе этой команды не будет корневой VG и LV.
<р>3. Проверьте фильтр LVM, связанный с начальным виртуальным диском (ПРИМЕЧАНИЕ: это файл внутри виртуального диска, а не в корневой файловой системе). Первая показанная команда позволит вам просмотреть весь файл /etc/lvm/lvm.conf; вторая команда покажет только строки с "фильтром" в них. <р>4. Найдите корневую виртуальную группу с помощью сканирования PV и перекрывающего фильтра LVM, который принимает все устройства. Вывод может показывать некоторые ошибки или предупреждения, но при сканировании он должен найти корневую виртуальную группу. В левом столбце должен быть указан путь к устройству в столбце PV и корневая группа томов в столбце VG.Ниже показана команда и пример корневой VG в выходных данных:Это решение является частью программы ускоренной публикации Red Hat, предоставляющей огромную библиотеку решений, созданных инженерами Red Hat для поддержки наших клиентов. Чтобы дать вам необходимые знания, как только они станут доступны, эти статьи могут быть представлены в необработанном и неотредактированном виде.
Читайте также: