LINUX.ORG.RU

Переезд gentoo на другой компьютер

 ,


0

1

Собственно, вопрос описан в теме. Как предполагается действовать для (рассматривается всё в рамках переезда с одних x86_64 на другие):

  • смена железа при рабтоающем старом. Я так понимаю, чтобы не было конфликтов, нужно для начала перекомпилировать мир с общими настройками оптимизиации, потом воткнуть жёсткий в новую систему, загрузиться и перекомпилировать с новыми настройками оптимизациями. Ну или вариант переписать всё на новый винт и установить загрузчик.
  • смена железа при неработающем старом. Т.е. перекомпилировать не получится. Как вариант, наверное, можно использовать эмуляцию для перекомпила. Дальше всё как в первом варианте.

Правильно ли всё я понимаю? Есть ли какие-то типовые решения?

Ни разу не сталкивался с таким, чтоб старая гента на более новом железе не работала, даже когда переезжал с интела на амд. Просто менял флаги в make.conf, никакой мир не пересобирал, со временем само пересоберётся. Ну, может, какой-нибудь ffmpeg теоретически может сломаться, ну дык не загнёшься без него первое время.

anonymous ()

Включить в ядре поддержку контроллера диска, и пересобрать его (ядро, естественно), может быть достаточным.

Какие процессоры то?

alfix ()

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


Сталкивался при клонировании с AMD на INTEL.
Развернул stage-3 и запилил старые конфиги.

Inside-Squirrel ()

Мне как-то раз пришлось переехать с нового проца на старый, причём гента была собрана с -march=native. Загрузился со стороннего носителя, распаковал stage3 поверх собранной системы, пересобрал весь мир. Всё заработало.

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

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

Если ядро поддерживает новое железо

На первый раз можно и с каким-нибудь сторонним ядром загрузиться. Интересовали именно программы, коих до фига, собранные со своими флагами.

turtle_bazon ★★★ ()

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

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

распаковал stage3 поверх собранной системы

А оно там чисто бинарники? Никакие конфиги не перетирает?

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

Чёрт, а я и не помню. Вполне возможно, что я подменил только /bin, /lib, /usr/bin и /usr/lib, а не весь stage3 распаковывал. Это надо смотреть, что в stage3 лежит. Собственно, подменять нужно только то, что компилировалось на твоём железе, конфиги и маны трогать не стоит.

devsdc ★★ ()

С какого процессора на какой переезжаешь? Если на более старый, тогда да, некоторые программы могут не запуститься, а так максимум чуть медленнее будут работать без оптимизации под новый проц

Harald ★★★★★ ()

Короче, не нужно всё по два раза перекомпилировать, иначе какой смысл, проще заново с нуля тогда поставить

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

некоторые программы могут не запуститься

Это не беда. Можно и на новом перекомпилировать. Главное, чтобы принципиально заработала компиляция.

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

Ну блеа, а почему она не должна заработать-то? GCC вдруг SSE инструкции стал использовать для компиляции?

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

Главная фича x86 архитектуры - обратная совместимость, которую тащат со времён 8086, соответственно программа из 80-х годов может запускаться на i7 без перекомпиляции, иначе бы x86 давно уже закопали

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

Главная фича x86 архитектуры - обратная совместимость

А наоборот? :) И ещё интересует совместимость Intel vs AMD между собой.

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

Главная проблема x86 архитектуры - обратная совместимость, которую тащат со времён 8086

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

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

всё верно, но тред не об этом, в данном случае это фича

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

без перекомпиляции

Не gentoo-way же :) После переноса все равно придется перекомпилировать, чтобы подогнать под текущую архитектуру. А что касается x86-64, оно, вроде-как, унифицировано и АМДшные и интелевские чипы должны быть совместимыми. Но это зависит, в основном, от расширений архитектуры, которые быле указаны компилятору, поскольку у одних вендоров одни костыли (3DNow! например), у других - другие.

Unicode4all ★★★★ ()

Зависит от того что было в CFLAGS. У меня gentoo на флешке, -march=prescott, грузится на любом многоядерном проце.

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

У меня при перекате с Intel на AMD при -march=native была куча ругани в dmesg, сделал emerge -e @world и всё пофиксилось.

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

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

Всё зависит от CFLAGS и в частности параметра march.

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

Да и любой линукс так перенести можно как бы, это не проблема, разве нет?

Ну в gentoo же ключи, компиляция, подгон под железо. С этим вопросы. А так да:

скопировать систему, вставить загрузчик, ребут.

turtle_bazon ★★★ ()

Бэкапь и правь конфиги, перекомпиливай всё, переноси, если не взлетело — распаковывай stage3 поверх, ресторь конфиги (портажеконфиги точно подменит), пересобирай всё, собирай едро под "новое" железо, ребутайся. У меня при переезде на новый проц всё взлетело без пересборки, потому оптимизацию я запиливал позже.

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

GCC вдруг SSE инструкции стал использовать для компиляции?

Да, GCC использует SSE, если в CFLAGS указать что-нибудь вроде такого:
-msse2 -msse3 -msse4a -ftree-vectorize

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

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

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

kaffeine@gid0pc ~ $ analyze-x86 /usr/bin/gcc-4.8.3
instructions:
cpuid: 14 nop: 642 call: 0 count: 102751
i686: 372
mmx: 717
sse: 410
sse2: 145
sse3: 5
sse4.2: 2

kaffeine ()

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

Оптимизации — зло. Делай как можно меньше оптимизаций. В этом случае можно будет на мощном компьютере собирать бинарные пакеты для слабых, а потом элементарно все обновлять. Самый классный вариант.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.