LINUX.ORG.RU

Компьютер, на котором линукс не может...

 , ,


0

3

…загрузиться даже в минимальной конфигурации.

Самый обычный NUC-подобный одноплатник на базе N4000, встроенный диск, по-видимому, – eMMC. Винда 10 ставится с пол-пинка, никаких F6-драйверов подсовывать не приходится.

Перепробовал из спортивного интереса с десяток дисрибутивов, ни один даже до командной строки не загрузился. GRUB с флешки стартует нормально, но после выбора варианта загрузки сначала идет долгий выхлоп с такими сообщениями:

[10.843768] mmc1: Reset 0x4 never completed.
[10.844991] mmc1: sdhci: =========== SDHCI REGISTER DUMP ===========
[10.844238] mmc1: sdhci: Sys addr: 0xffffffff | Version:  0x0000ffff
[10.844471] mmc1: sdhci: Blk size: 0x0000ffff | Blk cnt:  0x0000ffff
[10.844798] mmc1: sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff
[10.844943] mmc1: sdhci: Present:  0xffffffff | Host ctl: 0x000000ff
[10.845178] mmc1: sdhci: Power:    0x000000ff | Blk gap:  0x000000ff
[10.742115] mmc1: sdhci: Wake-up:  0x000000ff | Clock:    0x0000ffff
[10.742115] mmc1: sdhci: Timeout:  0x000000ff | Int stat: 0xffffffff
[10.742115] mmc1: sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff
[10.742115] mmc1: sdhci: ACmd stat:0x0000ffff | Slot int: 0x0000ffff
[10.742115] mmc1: sdhci: Caps:     0xffffffff | Caps_1:   0xffffffff
[10.742351] mmc1: sdhci: Cmd:      0x0000ffff | Max curr: 0xffffffff
[10.742587] mmc1: sdhci: Resp[0]:  0xffffffff | Resp[1]:  0xffffffff
[10.742824] mmc1: sdhci: Resp[2]:  0xffffffff | Resp[3]:  0xffffffff
[10.743869] mmc1: sdhci: Host ctl2:0x0000ffff
[10.743293] mmc1: sdhci: ADMA Err: 0xffffffff | ADMA Ptr: 0xffffffffffffffff
[10.944991] mmc1: sdhci: ===========================================
[10.958175] mmc0: Controller never released inhibit bit(s).
[10.944991] mmc0: sdhci: =========== SDHCI REGISTER DUMP ===========
[10.944238] mmc0: sdhci: Sys addr: 0xffffffff | Version:  0x0000ffff
[10.944471] mmc0: sdhci: Blk size: 0x0000ffff | Blk cnt:  0x0000ffff
[10.944798] mmc0: sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff
[10.944943] mmc0: sdhci: Present:  0xffffffff | Host ctl: 0x000000ff
[10.945178] mmc0: sdhci: Power:    0x000000ff | Blk gap:  0x000000ff
[11.042115] mmc0: sdhci: Wake-up:  0x000000ff | Clock:    0x0000ffff
[11.042115] mmc0: sdhci: Timeout:  0x000000ff | Int stat: 0xffffffff
[11.042115] mmc0: sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff
[11.042115] mmc0: sdhci: ACmd stat:0x0000ffff | Slot int: 0x0000ffff
[11.042115] mmc0: sdhci: Caps:     0xffffffff | Caps_1:   0xffffffff
[11.042351] mmc0: sdhci: Cmd:      0x0000ffff | Max curr: 0xffffffff
[11.042587] mmc0: sdhci: Resp[0]:  0xffffffff | Resp[1]:  0xffffffff
[11.042824] mmc0: sdhci: Resp[2]:  0xffffffff | Resp[3]:  0xffffffff
[11.043869] mmc0: sdhci: Host ctl2:0x0000ffff
[11.043293] mmc0: sdhci: ADMA Err: 0xffffffff | ADMA Ptr: 0xffffffffffffffff
[11.044991] mmc0: sdhci: ===========================================

100500 раз чередуются дампы SDHCI-регистров, связанные с mmc0 и mmc1.

В конце сообщение:

mmc0: Failed to initialize a non-removable card
Unable to find a medium containing a live file system

Я категорически не понимаю, почему он не может продолжить загрузку с флешки из-за того, что не смог проинициализировать eMMC. Хотя, с другой стороны, а что с там делать без главного накопителя, даже если бы он загрузился?

Что пробовал:

  • Другую флешку (хотя с этой ставил и винды и линукса уже сотню раз)
  • Другой порт (есть как USB2, так и USB3, но результат совершенно одинаков)
  • Переключаться в Legacy Boot
  • MBR-режим в rufus
  • DD-режим в rufus
  • tuxboot вместо rufus
  • Колдовал над iommu и intel_iommu в параметрах ядра в GRUB

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

Что еще можно сделать? Или полномочия линукса на этом – всё?


Насколько понимаю ты берёшь некоторые готовые дистрибутивы?

Что у тебя указано в параметре root=?

По сути тебе нужно запустить полноценную LiveUSB систему с флешки или запустить ядро и initramfs и провалиться в bash (sh) внутри initramfs и посмотреть какие устройства видит ядро.

Может в initramfs не хватает нужных модулей.

Если ты правильно передаёшь параметр root, то ядро должно как минимум запустить полноценную LiveUSB систему с флешки, если в составе ядра или в initramfs есть модуль USB контроллера и драйвер файловой системы, на которой лежит squashfs образ или драйвер ext4, если на флешке сразу раздел с ext4.

anonymous
()

Для начала прошивку бы обновить и желательно не бету ставить. Потом идешь пробуешь Manjaro, Artix и Void в лайв и порезанном режиме. Писать только в dd режиме - хрен его знает что там иначе. Просто линукс со сбоями сбоит, а винда едет дальше скажем обрабатывая поток ошибок от мыши. И на венде все пучком в то время как на линуксе указатель прыгает в разные стороны экрана по сто раз в секунду. Поэтому надо обновить прошивку - может дело в ней. У меня например разные версии биоса разными проблемами обладают и в одной версии вафля глючит, в другом hwclock при загрузке не выставляется и система не может загрузиться. То есть глюки где-то чаще всего это корявые руки сборщика прошивки.

anonymous
()
Ответ на: комментарий от vtVitus

Попробуй apci=off передать в параметры ядра.

Загрузилось! Но все равно без диска. В логе такое:

mmc0: mmc_secect_hs400 failed, error -84
mmc0: error -84 whilst initializing MMC card
mmc0: Failed to initialize a non-removable card

Причем не один раз, а четыре.

Но все равно ничего внятного не гуглится кроме какого-то патча от 2016 года.

quwy
() автор топика
Ответ на: комментарий от anonymous

Для начала прошивку бы обновить и желательно не бету ставить

Девайс кетайский, прошивку неясно где брать и стремно шить. Но поищу, спасибо.

quwy
() автор топика
Ответ на: комментарий от u5er

Ещё можно попробовать другую версию ядра и/или собрать своё ядро.

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

quwy
() автор топика
Ответ на: комментарий от anonymous

Что у тебя указано в параметре root=?

Сейчас на флешке бубунта последняя, в ней такого параметра вообще нет. В других, когда, ковырял параметры загрузки, что-то видел, не помню точно. Но не зависит в итоге.

По сути тебе нужно запустить полноценную LiveUSB систему с флешки или запустить ядро и initramfs и провалиться в bash (sh) внутри initramfs и посмотреть какие устройства видит ядро.

Неплохо бы, но максимум, что предлагается после остановки безумия ошибок, – ввести параметры для загрузки по сети.

ядро должно как минимум запустить полноценную LiveUSB систему с флешки, если в составе ядра или в initramfs есть модуль USB контроллера и драйвер файловой системы, на которой лежит squashfs образ или драйвер ext4, если на флешке сразу раздел с ext4.

Ну вот выключил ACPI и загрузилось, но сильно легче от этого не стало. Флешку он теперь видит, eMMC – нет.

quwy
() автор топика

На Atom SoC линукс в принципе через то место работает, Windows-only железки, фиг ли.

По сабжу, может в iGPU проблема?

p.s. n-серия целеронов/пентиумов - переименованные атомы.

whbex ★★
()
Последнее исправление: whbex (всего исправлений: 1)
Ответ на: комментарий от anonymous

молятся на какой-то свой rufus

Кто здесь молится? Мне на него вообще пофигу, это просто инструмент для записи флешки. А вам к доктору бы.

quwy
() автор топика
Ответ на: комментарий от whbex

На Atom SoC линукс в принципе через то место работает

У меня есть еще две похожих железки, тоже махровый Китай, на настоящих Celeron-ах, но на них все взлетело без сучка. Так что дело не в SoC-ах как таковых.

По сабжу, может в iGPU проблема?

Как он может мешать загрузке с флешки?

quwy
() автор топика
Последнее исправление: quwy (всего исправлений: 1)
Ответ на: комментарий от vtVitus

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

quwy
() автор топика
Ответ на: комментарий от quwy

Скоростью/отзывчивостью

так ты какую то первую попавшуюся взял, на надо было брать ту которая побыстрее, я взял такую workspace dtvs 32gb, но ей 100 лет в обед - сейчас есть гораздо быстрее.

anonymous
()
Ответ на: комментарий от anonymous

Установить можнг было только с ядром 4.15

Спасибо за инфу. Проверил 4.15 – работает: грузится и видит диск.

Но решил не останавливаться, пошел выше, и выяснилось, что реально поломали уже в шестой версии.

5.18.5-1 – OK.
6.0.6-2 – FAIL.

Такая фигня, в общем. Вот кому-то радость при апдейте привалит…

quwy
() автор топика
Последнее исправление: quwy (всего исправлений: 1)
Ответ на: комментарий от quwy

5.18.5-1 – OK. Спасибо за информацию. Я просле того как поменял ирбис на ленову,этой темой не интересовался. Но к сведению принял, что есть жизнь после 4.15

anonymous
()
Ответ на: комментарий от quwy

Сейчас на флешке бубунта последняя, в ней такого параметра вообще нет.

Ты что, с дуба рухнул? ))) Есть так или иначе или его можно задать - это основной параметр, через который указывается ядру где искать корень.

Могли конечно в init скриптах в initramfs зашить или жёстко при компиляции ядра задать в параметрах, но он так или иначе есть.

Ну погуглил бы хотя бы. )))

Неплохо бы, но максимум, что предлагается после остановки безумия ошибок, – ввести параметры для загрузки по сети.

Ну значит распаковывай initramfs и смотри как там всё утроено, читай документацию по LiveUSB от Ubuntu, ну и справка по параметам ядра тебе в помощь.

Ну вот выключил ACPI и загрузилось, но сильно легче от этого не стало. Флешку он теперь видит, eMMC – нет.

Это нормально, параметры noacpi / noapic могут привести к тому, что часть устройств не будут проинициализированы.

kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

Ну погуглил бы хотя бы. )))

Нафига, если я могу нажать ‘e’ в грубе, и увидеть это:

/casper/vmlinuz  --- quiet splash

Всьо.

Если добавить сюда же «acpi=off» и нажать F10, то загружается без eMMC. А значит это и есть актуальная строка параметров.

или жёстко при компиляции ядра задать в параметрах, но он так или иначе есть

Если он захардкожен в ядро, то как я могу увидедь его, не загружаясь в это ядро? Грепом искать прямо в бинарнике?

quwy
() автор топика
Ответ на: комментарий от quwy
set timeout=30

loadfont unicode

set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

menuentry "Try or Install Ubuntu" {
	set gfxpayload=keep
	linux	/casper/vmlinuz  --- quiet splash
	initrd	/casper/initrd
}
menuentry "Ubuntu (safe graphics)" {
	set gfxpayload=keep
	linux	/casper/vmlinuz nomodeset  --- quiet splash
	initrd	/casper/initrd
}
grub_platform
if [ "$grub_platform" = "efi" ]; then
menuentry 'Boot from next volume' {
	exit 1
}
menuentry 'UEFI Firmware Settings' {
	fwsetup
}
else
menuentry 'Test memory' {
	linux16 /boot/memtest86+x64.bin
}
fi


Посмотрел, в конфиге grub действительно не задается.

Значит определяется в initramfs, скриптом что нужно смонтировать, либо зашито при компиляции ядра.

Ubuntu в целом применяя свои SNAP пакеты уже не совсем классический Linux и посмотрев его LiveCD я вижу, что они подход со SNAP пакетами во всю применяют.

К тому же классическая модель LiveCD систем состоит из:

  • загрузчик;
  • ядро;
  • initramfs и скрипты в нём для поиска файловой системы, где находится squashfs образ с системой;
  • один squashfs образ с системой.

В LiveCD ubuntu 24.04 есть несколько squashfs образов, minimal, minimal-enhansed-secureboot, minimal.standart.live.squashfs в директории casper на носителе.

Ну видимо вся механика поиска CD / DVD привода, а точнее файловой системы с этими squashfs образами и их монтирования находится в скриптах initramfs.

Более того, я не все просмотрел, но думаю большей частью все там даже нет /etc/fstab, либо я его просмотрел, либо он всё же создаётся, либо просто работает systemd, чтобы он всё смонтировал /etc/fstab не нужен. Более того, в системах с systemd механика монтирования файловых систем происходит не через файл /etc/fstab. Systemd после монтирования корневой файловой системы читается /etc/fstab и создаёт на его основе systemd unit’ы для монтирования файловых систем и запускает их. К тому же запускает асинхронно, а не в той очерёдности, что прописано в /etc/fstab. Отсюда вывод, что для корректного монтирования в /etc/fstab теперь нужно прописывать параметры, указывающие systemd зависимости и очерёдность монтирования (выполнения *.mount unit’ов), всё становится удобнее в плане возможностей использования, но сложнее в плане настройки.

Параметры ядра могут быть заданы при его компиляции в параметре CONFIG_CMDLINE: https://cateee.net/lkddb/web-lkddb/CMDLINE.html

В squashfs файле casper/minimal.standard.live.squashfs есть директория /boot и конфиг ядра, в нём нет этого параметра.

Отсюда ещё один вывод: всё делается скриптами init в initramfs, которые ищут и монтируют squashfs и далее всё делает systemd.

Нафига, если я могу нажать ‘e’ в грубе, и увидеть это:

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

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

А ты отвечаешь, да что вы такое говорите никакой бензин не нужен - я всегда просто садился за руль и ехал, никуда ничего не заливая.

Если ты посмотришь grub твоего установленного Linux и любого другого, то увидишь там параметр root, в котором задаётся какую файловую систему ему смонтировать, через имя устройства, например /dev/sda1, через идентификатор раздела, через метку файловой системы (LABEL), через уникальный идентификатор файловой системы (UUID), но всё равно задаётся.

В случае устройства LiveCD Ubuntu и обычный дистрибутив может загружаться тоже по другому, например можно собирать initramfs и в нём зашивать эти идентификаторы, чтобы скрипты или systemd внутри него нашли и смонтировали корень.

Но в 99% процентов случаев параметр root задаётся в загрузчике и он явно указан.

Поэтому когда тебе пишут на форуме - сходит посмотри вот эти базовые знания, чтобы не выглядеть бледно и не показывать, чтобы вообще не понимаешь как происходит процесс запуска Linux, открой гугл и вбей просто то, что тебе посоветовали посмотреть.

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

И я тебе написал где смотреть и примерно как:

Могли конечно в init скриптах в initramfs зашить или жёстко при компиляции ядра задать в параметрах, но он так или иначе есть.

Ну значит распаковывай initramfs и смотри как там всё утроено, читай документацию по LiveUSB от Ubuntu, ну и справка по параметрам ядра тебе в помощь.

https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html

        root=           [KNL] Root filesystem
                        See name_to_dev_t comment in init/do_mounts.c.

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

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

Грепом искать прямо в бинарнике?

Можно и так, но лучше найти конфиг, где он находится я тебе указал, уточняю ещё раз, он находится в squshfs файле и ты его можешь увидеть, либо смонтировав squashfs, либо загрузиться с LiveCD / LiveUSB там, где она загружается и посмотреть в директории /boot запущенной Live системы.

То, что у тебя не происходит загрузка - варианта два:

  • сбой в acpi приводит к некорректной работе MMC памяти;
  • или не корректно работает драйвер USB контроллера, т.к. ты грузишься с флешки.

Если добавить сюда же «acpi=off» и нажать F10, то загружается без eMMC. А значит это и есть актуальная строка параметров.

То, что ты передав параметр acpi=off запускаешь систему и из-за этого параметра устройство карт ридера вообще не видно ядру не значит, что это актуальная строка параметров.

У тебя может так же из-за параметра acpi=off не работать другое оборудование.

Как минимум сам ACPI работать не будет, а это значит не будет обработано ядром нажатие на кнопку включения хотя бы, что под кратковременному одинарному нажатия запустилась процедура выключения.

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

Поэтому ни о какой актуальной строке и речи не идёт. Почитай тогда ещё что такое ACPI и зачем нужно.

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

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

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

За подробностями, что это за параметр - читай ссылку выше с описанием параметров ядра.

как только определишь перебором или анализом логов какой модуль нужно заблокировать - добавляй параметр и блокируй.

Говорить более подробно не буду, не очень хочется что-то ещё пояснять тебе, т.к. ты не хочешь учиться, а сразу говоришь, что я тебе говорю чушь, ты же в Linux разбираешься как бог.

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

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

Удачи.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 6)
Ответ на: комментарий от kostik87

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

Тут вопрос не технический, а скорее философский. Если параметр не передается в ядро при старте, значит его нет. То, что у ядра есть дефайн со значением по-умолчанию, мало что меняет, ибо параметра в строке параметров все равно нет, и с этим не поспоришь.

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

quwy
() автор топика
Ответ на: комментарий от quwy

Я не знаю какой ты ембеддер.

Но вот эта фраза:

Если ты правильно передаёшь параметр root, то ядро должно как минимум запустить полноценную LiveUSB систему с флешки, если в составе ядра или в initramfs есть модуль USB контроллера и драйвер файловой системы, на которой лежит squashfs образ или драйвер ext4, если на флешке сразу раздел с ext4.

Означает: попробуй передать руками параметр root явно указывая ядру где искать корень.

Я понимаю, что русский язык сложный и возможно двоякое толкование. Возможно я не очень хорошо написал. Тем более выше я спросил что указано в root и у тебя действительно ничего не было указано.

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

Другое дело с initramfs от Live системы тоже могло не взлететь.

Но в этом случае наш уважаемый эмбеддер должен был попробовать поковырять initramfs, а он это должен уметь делать или использовать initramfs из обычной системы. Если ты не знаешь как распаковывать Initramfs, то в моих комментариях давностью в несколько лет указаны команды.

Искать я их не будут, напишу примерно по памяти, распаковка:

zat initramfs | cpio -i -d -H newc

А запаковка, примерно:

cd initramfs_dir
find ./ | cpio ... | gzip > ../new_initramfs.gz

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

Видимо знаешь, но применять полностью не можешь. Потому как слишком прямолинейно прочёл мой комментарий и не подумал ничего другого.

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

Если параметр не передается в ядро при старте, значит его нет.

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

То, что у ядра есть дефайн со значением по-умолчанию, мало что меняет, ибо параметра в строке параметров все равно нет, и с этим не поспоришь.

Ну так его и нет в параметрах ядра в загрузчике потому как он может быть определён в CONFIG_CMDLINE или может быть не нужен благодаря работе init сценариев в initramfs.

Но параметр явно переданный через загрузчик будет иметь приоритет.

Просто совет, чтобы ты как эмбеддер стал лучше.

Я тут ковырял WirenBoard, джаст фор фан. Знакомый хотел, чтобы там заработал wireguard. WB был 6-й версии, ещё вроде был на 10-ом Debian построенный.

Разработчики WB криво собрали ядро и в систему вроде бы даже можно всё поставить. Даже скачав исходники ядра дособрать для дистрибутивного ядра модуль wireguard, не пересобирая всё ядро, и всё должно бы работать. Но нет, они ещё выключили в ядре алгоритм шифрования, который нужен wireguard. А тут без сборки ядра с нужной опцией уже не обойтись.

Так что в итоге всё равно пришлось для WB6 кросскомпилировать ядро и собирать DEB пакеты, включив алгоритм шифрования и модуль wireguard.

Можешь почитать форум wirenboard, там есть моя тема, где я описал процедуру сборки ядра, выложил пакеты и даже в собранных мной ядрах включил монолитно модуль USB контроллера.

И описал какими командами для uboot можно изменить настройку загрузчика для запуска WB с ядром и корневой файловой системой на USB флешке. Только в случае WB6 флешка нужна небольшого размера, 32Гб не виделась загрузчиком.

Может если uboot обновить - увиделась бы.

Тут я уже не стал разбираться. Основная цель была получить ядро с рабочим wireguard.

И далее разработчики WB выпустили штатное обновление пакета с ядром, в котором включили все нужные опции для работы wireguard.

В другой теме там же описал процедуру разборки загрузочного образа системы с помощью binwalk.

Так что, уважаемый эмбеддер - учитесь, думайте, становитесь лучшим эмбеддером )))

Удачи.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 5)
Ответ на: комментарий от kostik87

Я не понимаю вашу позицию. Зачем эти простыни текста с язвительным подтекстом? Прорва свободного времени, или навящивая жажда самоутверждения?

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

А еще я реально устал от этого вашего линукса с его придурочной внутренней архитектурой, и так и не избавившихся от юношеского максимализма идеологами.

Прекращайте, это никому не нужно.

quwy
() автор топика
Ответ на: комментарий от quwy

Я не понимаю вашу позицию. Зачем эти простыни текста с язвительным подтекстом?

Моя позиция, что человек задаёт вопрос и не хочет разбираться.

А потом, когда ему даёшь пояснения, что и почему - он пишет: «Я ЭМБЕДДЕР И ВСЁ ЗНАЮ.»

Когда так человек пишет - я привожу ему пример. Что да, эмбеддер, но то, что он сказал - показывает его непонимание в том вопросе, о котором он говорит.

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

Лично мне всё равно. Но я помню как преподаватель в вузе сказал мне такую вещь: «Вы не хотите учиться и хотите оценку? Давайте, могу поставить 3, могу 4, могу хоть 5. Но у вас знаний не будет и от этого я как специалист буду ценнее на рынке.»

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

Как ты понимаешь факап не только со стороны разработчиков ядра, но и может быть со стороны разработчиков железа.

Да, в основном ACPI таблицы и прошивка устройств в целом для x86 платформы оттачивается под более массовую ОС, т.е. Windows и может нарушать даже принятые стандарты.

А разработчики ядра могли напротив в новой версии более точно следовать спецификациям стандартов.

И у них может не быть, а с вероятностью 95% точно нет, твоего железа. И баг так и останется багом.

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

А всё потому, что ты не стал разбираться и не отправил баг репорт.

Но если тебе не надо - не делай.

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

А еще я реально устал от этого вашего линукса с его придурочной внутренней архитектурой

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

Прекращайте, это никому не нужно.

Тебе не нужно. Ты не понимаешь посыла.

Ок.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от quwy

А еще я реально устал от этого вашего линукса с его придурочной внутренней архитектурой

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

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Я бы тоже не стал писать баг. Проще самому лезть и чинить. В последний раз, когда я столкнулся, то мне пришлось чинить всё самому. Автор коммита, который ломает драйвер, проигнорировал моё письмо на почту, а баг до сих пор висит https://bugzilla.kernel.org/show_bug.cgi?id=212335 Вопрос: какой смысл репортить баги, если их никто не чинит?

u5er ★★
()