This media is not supported in your browser
VIEW IN TELEGRAM
Когда решил быстро поправить 👨🔬
Linux / Линукс🥸
/etc/fstab
без mount -a
для проверки, а потом забыл про noauto
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Это закомментированный код в ядре, который никто не решается удалить, потому что оно как-то влияет 🤔
Linux / Линукс🥸
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Дух Open Source.
Берешь то, что есть, прикручиваешь что-то свое, получается... что-то🕊
Linux / Линукс🥸
Берешь то, что есть, прикручиваешь что-то свое, получается... что-то
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Как объяснить новичку разницу между 🤔
Linux / Линукс🥸
/bin, /sbin, /usr/bin и /usr/sbin
(и зачем это всё) Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда ты только что установил Arch, всё настроил, и теперь не знаешь, чем заняться, пока не выйдет новое ядро 👨🔬
Linux / Линукс🥸
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from IT-Мемасы от Эникея
Кажется, кто-то установил kde-plasma-desktop на сервер реальности и забыл настроить виджеты.
Linux / Линукс🥸
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Linux / Линукс 👨🔬
Please open Telegram to view this post
VIEW IN TELEGRAM
Обсуждение будущего Open Source. И, судя по составу, оно будет интегрировано с Active Directory и мониториться через Performance Monitor 😮
Linux / Линукс🥸
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда ты одновременно компилируешь ядро, настраиваешь dwm, пишешь скрипт на Perl и холиваришь про systemd.
Linux / Линукс🥸
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from IT-Мемасы от Эникея
Коллега поделился по-настоящему странной проблемой, с которой столкнулся после обновления нескольких виртуальных машин Ubuntu Server. Эта история – отличный пример того, какими непредсказуемыми могут быть трудовые будни, и как важно иногда просто сравнить конфиги.
Началось все с рутинной задачи: обновления старых Ubuntu серверов. Два из них, работавшие на версии 18.04, потребовали двух последовательных циклов
Самое мистическое в этой ситуации было то, что если загрузиться в консоль восстановления, а затем выбрать опцию "продолжить обычную загрузку", система волшебным образом стартовала и работала как ни в чем не бывало. Две из двадцати виртуальных машин демонстрировали идентичное поведение, что добавляло загадочности. Админ перепробовал многое: проверил конфигурации, вручную обновил тип виртуальной машины, пересобрал initramfs, обновил GRUB – но ничего не помогало, кроме этого странного обходного пути через rescue-консоль. Подозрение падало на конфигурацию самой ВМ, так как даже live-образ Ubuntu 22.04 на этих машинах загружался с трудом.
В ходе поисков решения были отброшены различные гипотезы: нехватка места на
Разгадка пришла, когда автор сделал то, что, по его собственному признанию, "нужно было сделать еще прошлой ночью": он сравнил (
Как именно конфигурация виртуальной видеокарты могла повлиять на доступ к диску при загрузке – остается небольшой загадкой, но это яркий пример того, что при крупных обновлениях операционных систем могут меняться поддержка или поведение различных моделей виртуального оборудования. Старые конфигурации виртуальных машин не всегда переносятся без сюрпризов.
Linux / Линукс🥸
Началось все с рутинной задачи: обновления старых Ubuntu серверов. Два из них, работавшие на версии 18.04, потребовали двух последовательных циклов
do-release-upgrade
. Однако после второго апгрейда, до версии 22.04, обе эти виртуальные машины наотрез отказались нормально загружаться, просто зависая на старте. Логи намекали на проблемы с монтированием корневого раздела /dev/vda1
.Самое мистическое в этой ситуации было то, что если загрузиться в консоль восстановления, а затем выбрать опцию "продолжить обычную загрузку", система волшебным образом стартовала и работала как ни в чем не бывало. Две из двадцати виртуальных машин демонстрировали идентичное поведение, что добавляло загадочности. Админ перепробовал многое: проверил конфигурации, вручную обновил тип виртуальной машины, пересобрал initramfs, обновил GRUB – но ничего не помогало, кроме этого странного обходного пути через rescue-консоль. Подозрение падало на конфигурацию самой ВМ, так как даже live-образ Ubuntu 22.04 на этих машинах загружался с трудом.
В ходе поисков решения были отброшены различные гипотезы: нехватка места на
/boot
, проблемы с fstab
или udev
(хотя и пробовались разные варианты монтирования), ошибки файловой системы. Kernel panic при обычной загрузке указывал на невозможность найти корневой раздел, который, тем не менее, прекрасно находился при старте через rescue-режим.Разгадка пришла, когда автор сделал то, что, по его собственному признанию, "нужно было сделать еще прошлой ночью": он сравнил (
diff
) XML-файл конфигурации проблемной виртуальной машины (/etc/libvirt/qemu/server.xml
) с аналогичным файлом работающей ВМ. И вот оно! В секции <video>
у проблемных машин был указан тип модели vmvga
. Простое изменение `vmvga` на `qxl` немедленно решило проблему! Виртуальные машины стали загружаться штатно.Как именно конфигурация виртуальной видеокарты могла повлиять на доступ к диску при загрузке – остается небольшой загадкой, но это яркий пример того, что при крупных обновлениях операционных систем могут меняться поддержка или поведение различных моделей виртуального оборудования. Старые конфигурации виртуальных машин не всегда переносятся без сюрпризов.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM