Установка AltLinux startterkit на комп с встроенной интеловской графикой

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

Попробую так: https://files.catbox.moe/f5vnr7.log Хотя и знаю что не все такие файлообменники не у всех открываются и заранее не угадать у кого какой сработает.

Скачал успешно. Что увидел – у меня иксы полностью на дефолтном конфиге, кроме конфигурации клавиатуры. Попробуй убрать всё, что есть в /etcX11/xorg.conf{,.d/*.conf} и стартануть.

убрать всё, что есть в /etcX11/xorg.conf{,.d/*.conf} и стартануть.

Нет там ничего.

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

Внезапно обнаружил что установленное инсталлятором ядро собрано без PAE и поэтому не видит память дальше 4 гигабайтов. Не ожидал что кто-то такое ядро соберет. Привык что в Дебиане ядро с PAE обычно ставится. Похоже предстоит пересборка ядра ибо в списке доступных пакетов готовое собранное с PAE я не нашел. А видеопамять вполне может отображаться дальше четвертого гигабайта.

Ого, даже в Slackware, который считается консервативным дистрибутивом, от nopae ядра по умолчанию Патрик отказался ещë в 2012, в 14.0, офигеть.

Ничего, конфиг от установленного ядра есть, поменять одну опцию и пересобрать можно.

Проверь две вещи:

1) запуск командой «startx xterm» (если тут тоже будет чёрный экран то переключись на консоль и проверь в ps что xterm действительно запущен)

2) посмотреть, есть ли на Xorg-е (/usr/bin/X, наверно, но это не точно, посмотри что там бинарник а не скрипт и сравни с тем что ps axuww или top показывает когда иксы запущены, ты ж теперь можешь переключаться) suid-root и если его там нет - поставить.

А видеопамять вполне может отображаться дальше четвертого гигабайта.

VESA - не может. Про остальные не знаю, но думаю оно сможет настроиться так чтобы работало, если всё норм.

Проблема XY.

...ругаться будут и говорить...

Да и хрен с ними, пусть говорят. Не было печали.

офигеть

Боюсь, что там не только ядро собрано на отвали. Официальная линия партии это 64 бита, systemd, гном/кде. Всё остальное на наш страх и риск. Я не удивлюсь, если стартеркит с icewm никто не проверял лет 15. Лучше бы заходить с чего-то более мейнстримного.

Я не удивлюсь, если стартеркит с icewm никто не проверял лет 15.

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

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

Я для тебя, дурака, даже ссылку прикреплю. Если фантазии - то не мои, а ТС.

Установка AltLinux startterkit на комп с встроенной интеловской графикой (комментарий)

Above 4G Decoding - древняя такая опция в BIOS, да. Щас оно уже в дефолте обычно включено, что без PAE будет вызывать проблемы.

Есть же пользователи, могут пожаловаться если что.

Можно, но я с этого начал — i586 больше не собирают, поэтому даже если разработчики что-то исправят, в дистрибутив это уже не попадёт.

Официальная линия партии это 64 бита, systemd, гном/кде.

В Альт Образование пока ещё есть вариант с xfce.

если разработчики что-то исправят, в дистрибутив это уже не попадёт.

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

Если там xinit не положили, то можно ожидать любых приколов.

Не «не положили», а «сам по зависимостям не поставился». Что вобщем-то допустимо для не самых мейнстримных вариантов дистрибутива. Тем более что я по совету выше ставился с диска JeOS по совету выше, когда вариант с icewm не заработал. Что - JeOS тоже что ли никто не пользуется и глюк с неработающими иксами не видел? Причем глюку как минимум год.

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

Подо что изначально был написан этот софт? Судя по описанию я вообще могу предположить, что писалось оно ещё под Wnidows XP или ранее.

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

Путь вполне рабочий, кстати. Я такие штуки гонял в ВМ с ХР практически без бубна.

То есть ты признаёшься, что, как я и указал, пересказываешь чужие фантазии? И ничего умнее не придумал, кроме как согласие с моим сообщением сопроводить обзыванием меня дураком?

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

Достаточно четко донёс позицию? Я сейчас намеренно не обращаю твое некомпетентное внимание на то, что софт написанный особым образом для 32 бит просто не будет собираться на 64-битной системе без дополнительных телодвижений, а ТС заявляет, что ему именно такой софт и надо собирать. И тут приходишь ты, такой весь красивый в белом и начинаешь кидаться говном. Просто проигнорируй мое существование, если я тебе где-то на хвост наступил и жить тебе станет легче.

пересказывая слова ТС

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

запуск командой «startx xterm»

Спасибо, совет помог! В варианте nomodeset в командной строке ядра и driver «vesa» в конфиге иксов всё заработало. Заодно оказалось что в Альте иксы вообще не умеют показывать «сеточку с крестиком» на пустом экране (как в Дебиане) поэтому дебиановские советы по отладке и не помогли. Уже настроил запуск icewm, всё показывает. Разве что дебиановский файлик .Xresources в домашнем каталоге не подхватывается - видимо в Альте он как-то по-другому должен называться, но с этим вечером разберусь. У меня там настройки для xterm прописаны, а то тут у него по умолчанию фон белый и шрифт мелкий - наверно специально чтобы зрение портить.

Ну а с загружаемым по умолчанию модулем i915 и драйвером modesetting по-прежнему выключается экран так что даже после переключения в текстовую консоль не работает. Вобщем-то меня и vesa вполне устраивает, так что можно считать что проблема решена.

Тебя даже ТС поправил, что я прав. Ты бы шёл бы мимо, если не понимаешь, или научился задавать вопросы правильно, а?

Ты немного неправ.

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

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

Поэтому твой оппонент прав, а ты передергиваешь.

Скажи, пожалуйста, какой у тебя опыт работы с ембеддед-разработкой?

Как ты себе это представляешь на этапе инсталлятора? )) После установки — да, но ты предлагал поправить дистрибутив.

я прав

Ну давай, расскажи свой (а не watchcat382) опыт, когда у тебя программа на скомпилировалась из-за 64-битного int-а - что это была за программа (или хотя бы сфера её применения), на каком железе ты её компилировал (какой-нить mips64?), в каком году это было?

Ну давай, расскажи свой (а не watchcat382) опыт, когда у тебя программа на скомпилировалась из-за 64-битного int-а - что это была за программа (или хотя бы сфера её применения), на каком железе ты её компилировал (какой-нить mips64?), в каком году это было?

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

Бггг. Давай я тебе лучше кусок кода покажу:

#include <stdio.h>

int main() {
    int32_t value = 4294967296;
    printf("%d\n", value);
    return 0;
}

А теперь подумай, где именно там взлетает int 64. И нет, де факто тип int в x86_64 ещё 32 бит. Но, поди ж ты, не у любого компилятора. Но вот откуда тут взялось вдруг переполнение? Почему конкретно этот кусок кода не соберется в x86_64 с gcc?

А если мы, не дай божи, начнем это собирать на какой-нить экзотической архитектуре - мы ещё огребем проблему с тем, что байт != 8 бит.

malloc(pointersCount * 4)

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

Приложения поддерживаются. Ставишь 64-разрядный дистр и в него 32-разрядные приложения.

Если у него шаг в сторону - смерть контроллера, то лучше перестраховаться с i586.

Такое в ALT Linux'е не работает.
в системе не оказалось... нужных шрифтов, которые Chromium упорно искал в цикле и из-за этого тормозил

Странный вывод. Если зависимость не прописана, то она не тянется, но при чём тут обобщение «Такое в ALT Linux'е не работает»? Работает там, где надо.

Что - JeOS тоже что ли никто не пользуется и глюк с неработающими иксами не видел? Причем глюку как минимум год.

Я относительно регулярно ставлю JeOS, причём вот прямо веcной часто было, этот вот ставил: alt-p11-jeos-sysv-20250912-x86_64.iso. Глюка с графикой Intel не видел, и с относительно старой, и с относительно новой.

И нет, де факто тип int в x86_64 ещё 32 бит

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

Начались отмазки про какие-то «другие компиляторы», и про экзотические архитектуры без 8-битных байтов. К исходной теме (установка i386-линукса вместо amd64) это всё, разумеется, никакого отношения не имеет. И к твоему опыту - тоже.

Кусок кода твой никакого отношения к i386 vs amd64 не имеет, а не соберётся он из-за пропущеного include stdint.

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

Кстати вполне вариант.

Речь же шла про метазависимости. Типа, ставлю FVWM, а надеюсь, что притянутся и Tcl с Lua (на которых могут быть скрипты для него).

В ряде дистрибутивов они могут быть широко прописаны. В ALT Linux - нет.

Ну а с загружаемым по умолчанию модулем i915 и драйвером modesetting по-прежнему выключается экран так что даже после переключения в текстовую консоль не работает. Вобщем-то меня и vesa вполне устраивает, так что можно считать что проблема решена.

А что показывает «lspci | grep VGA»? Для интереса.

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

Кусок кода твой никакого отношения к i386 vs amd64 не имеет, а не соберётся он из-за пропущеного include stdint.

Дааа, кекспертиза во всей красе.

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

Вы не могли бы перестать терять контекст?

Вы не могли бы перестать терять контекст?

Вроде не теряю.

Погоди-погоди, а результат работы компилятора зависит от того, на какой архитектуре работает сам компилятор?

Пять лет назад ещё была актуальна 8-я платформа, в которой не было apt-get autoremove, поэтому там с зависимостями было всё непросто. Сейчас полегче.

Конечно. Потому, что в нашем мире оказывается, что компилятор собирает под ту систему, на которой он запущен. Но, на самом деле, все немного сложнее. Если ты запустишь 32-битный GCC то он и на 64 бит системе соберет тебе как надо, но тоже не всё и не вся, нюансов хватает. А вот гвозди вылезают, например, из-за разной длины указателей. Если без дополнительных телодвижений - вот сразу тебе основная проблема, от которой можно отстрелить ноги:

ILP32 (int, long и указатели — по 4 байта) — часто используется в 32-битных Unix-системах.
LP32 (int — 2 байта, long и указатели — по 4 байта) — в Win16 API.
LP64 (int — 4 байта, long и указатели — 8 байт) — типично для 64-битных Unix-систем (Linux, macOS).
LLP64 (int и long — по 4 байта, указатель — 8 байт) — используется в 64-битных системах Windows (Win32 API).

То есть ты пишешь long и в одной системе он 8 байт, в другой - 4 байта. Хотя компилятор и там и там - GCC и даже той же версии. Поэтому если не делать доп. телодвижений - можно здорово удивиться.

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

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

ОК, спасибо, понял.

Вы меня неправильно поняли. Как раз именно с инсталлятором проблема решаема - xdriver=vesa в командной строке ядра и инсталлятор работает. А вот потом, чтобы запустить уже установленную систему, пришлось как видите попрыгать потому что xdriver=vesa уже не помогает. Надо ядру говорить nomodeset и написать xorg.conf(которого по умолчанию вообще нет) с указанием driver «vesa».

когда у тебя программа на скомпилировалась из-за 64-битного int-а

Типичные грабли - это даже не конкретно int, а представление структур в памяти. Потому что типично создает структура (сишная), берется на нее указатель и туда делается чтение из файла. Аналогично и запись. И если с разным выравниванием можно успешно бороться с помощью pragma pack, то с различием размеров типов данных входящих в структуру бороться сложнее. Собственно, никто и не борется если пишет программу для себя и собирается запускать ее на своем компе Вторые грабли - это спецификации форматов у sprintf если требуется заполнить буфер в памяти какими-то текстовыми значениями. Они тоже зависят от разрядности (или надо форматную строку сильно обмазывать макросами). А самое неприятное в том, что программа как раз вполне может скомпилироваться. Вот только работать будет неправильно. Соответственно, если даже в виндах люди подбирают версию виндов под софт чтобы он заработал (софт для автодиагностики как пример) то почему это нельзя делать в линуксе? Написала программа под 32-битную систему - под ней и запускаю.