Linux перенос программ на другой компьютер
Мой ноутбук с Ubuntu настроен со всеми программами и темами на мой выбор, могу ли я перенести это программное обеспечение на другой компьютер, на котором работает Ubuntu, и установить их там через USB-накопитель.
3 ответа
Перенос настроек конкретного приложения также очень прост. Новое программное обеспечение обычно хранит свои настройки в ~ / .config / application_name /, его данные в ~ / .local / share / application_name / и кэш в ~ / .cache / application_name. К сожалению, еще не все приложения следуют этому соглашению. Старое соглашение заключалось в том, чтобы хранить его непосредственно в вашем домашнем каталоге, например ~ / .appname.
Я знаю ручной способ сделать это, так что вот оно:
- Скопируйте содержимое /var/cache/apt/archives в папку на вашем USB-накопителе. В качестве альтернативы вы можете создать хранилище образов дисков, используя AptOnCD .
- В файловом менеджере (Nautilus) в вашем домашнем каталоге отобразите скрытые папки (для этого временно используется сочетание клавиш Ctrl+H ). Папки, начинающиеся с точки, являются скрытыми папками и содержат ваши пользовательские настройки для приложений, которые вы используете. Найдите папки приложений, для которых вы хотите выполнить резервное копирование (например, .thunderbird или .wine ), и скопируйте все из них (желательно) в другую папку на вашем USB-накопителе.
- Теперь на компьютере, который вы хотите настроить так же, как и на первом компьютере, скопируйте все эти файлы Deb с вашего USB-диска в /var/cache/apt/archives (вам нужно сделать это как root), если вы хотите их установить из Synaptic (в Synaptic это немного приятнее, потому что, если Synaptic найдет более новую версию этого пакета, он загрузит ее из Интернета). В качестве альтернативы вы можете перейти к этой папке в терминале (в терминале вы можете сделать cd /media/usbdrive/debfiles/ , а затем запустить sudo dpkg -i *.deb , чтобы установить все эти файлы deb. Вы можете впоследствии перейти в Synaptic, чтобы убедиться, что у вас нет отсутствующие пакеты для установки.
- Наконец, скопируйте эти папки, начиная с точки, в новый домашний каталог. Если там уже была папка, вы можете сначала удалить ее (убедитесь, что приложение закрыто). Например, в то время как Thunderbird не работает, удалите .thunderbird в вашем домашнем каталоге и скопируйте .thunderbird с вашего USB-накопителя.
Это обеспечит вам быструю установку (хорошо вы сэкономите на времени загрузки ) всего программного обеспечения, которое вы используете, и быстрый импорт пользовательских настроек этих приложений. Наслаждайтесь.
Пока вы копируете файлы на новый компьютер, убедитесь, что на новом компьютере установлена та же версия , что и предыдущая (куда вы копируете все файлы).
Если не существует той же версии Ubuntu, то система может быть сбой. Так что будьте осторожны, прежде чем сделать это.
Добрый день. Скомпилировал программу в qt creator с использованием либ opencv.
Скопировал на другой компьютер папку релиза, выдает ошибку в отстувии библиотек, скопировал в эту папку необходимые либы, всё равно ошибка, скопировал в /usr/local/lib та же хрень.
Так же делал sudo ldconfig - v.
Привык что в винде при переносе можно все dll просто в папку с exe закинуть и всё работает, а здесь какая-то засада.
Не буду же я компилить opencv на каждой машине где прогу запустят?
- Вопрос задан более трёх лет назад
- 1603 просмотра
Простой 3 комментария
Что было в винде, то осталось в винде. В линухе другой подход. Здесь не будут автоматом грузиться левые либы.
1. Проверьте, что в /etc/ld.so.conf.d есть файлик (имя любое), содержащий строку:
/usr/local/lib
Если не было, создайте и уже потом ldconfig. Проверить, что нужные либы система увидела, можно через ldconfig -p
2. Если используется opencv, то на целевой машине должен стоять OpenCV - а Вы думаете, менеджеры пакетов, которые автоматически разрешают и ставят зависимости - просто так придумали, от скуки?
3. Вы еще и автоматически детектить его должны через configure и ошибку выдавать вменяемую, что OpenCV не обнаружен - это если программа будет только в сырцах распространяться. А если пакетами - то ее поставит соответствующий пакетный менеджер, для чего ему должны быть конечно выданы указания :)
. Что было в винде, то осталось в винде. В линухе другой подход. Здесь не будут автоматом грузиться левые либы.
planc, Это проблемы ребят :) Не, может быть в бубунте что-то особенное сделано, я просто не работал в ней никогда. Но приходилось неоднократно таскать наработки между центосами и FreeBSD (не между ними конечно же, а между несколькими центосами и несколькими FreeBSD). Так вот там оказалось проще освоить местные пакетные менеджеры и паковать наработки в пакеты, при установке которых yum или pkg_add сам поставит депенды.
Привет. Установил XUbuntu на домашний комп, настроил, установил программы, теперь хочу установить XUbuntu на рабочем компе, вот только тратить время на установку программ и настройку не хочется. Как можно перенести данные на другой комп? Гугл выдает различные варианты, в линуксе новичок, только осваиваю. Подскажите как правильно все сделать. Заранее спасибо.
Простой 3 комментария
sim3x, да, из репозитория (grub-customizer, terminal gnome, deluge, редактор dconf, java, Git, Sublime text, PuCharm (скачал с офф. сайта)) + настройки к ним.
разметка диска проводилась /, swap, home
Ram, мой совет - ну мучаться и поставить все заново
Выгребать конфиги ,а потом их синхронизировать - не сильно веселое занятие
Единственное, что легко синхронизируется dotfiles - настройки баша/zsh
а можно подробней, какие папки копировать?
я так понимаю что сначала устанавливаю чистую систему, а дальше как?
Ram, сказано не "скопируй", а склонируй диск.
Это значит сделай точную копию содержимого диска на другое устройство.
Делается специальными утилитами, например clonezilla, dd (для гуру)
как уже верно заметили не скопировать а склонировать
вместе с системой
линукс в отличии от винды это вполне допускает
проще всего имхо с помощью norton ghost с загрузочного диска или флешки(я лично пользуюсь флешкой с adminpe)
но можно и другими программами в том числе и прямо из линукса
еще такая мысля возникла, есть ли что на подобие git для всей системы линукс, например установил какую либо программу, изменил настройки в системе, сделал коммит, пуш, а на другом компе синхронизировал и готово. Просто так получается что работаю дома, на работе и еще ноутбук есть, хочется вкл комп и через пару минут продолжить работу.
готового нет
в программах клонирования в частности acronis true image
есть возможность делать копию не всего диска а изменений с момента предыдущего копирования
теоретически это можно использовать для синхронизации двух компьютеров
на практике это слишком неудобно (и долго(порядка 20-40 минут))
опять таки теоретически можно написать программу для синхронизации но это мало кому нужно поэтому никто пока не заморачивался
Те же рецепты, что для вопроса: перенести Linux на другой диск. Вариантов решений - масса (например, всё скопировать (если точнее, почти всё) с помощью rsync. Но это требует более или менее хорошего знания системы. Если его нет - результат может получиться не тем, что хотелось бы.
Настройки-то перенести несложно (делать ессно от рута):
Полученный архив перенести на новую инсталляцию и . нет, ни в коем случае не распаковать в /etc! А держать у себя в домашке в качестве хранилища уже готовых настроек, да и бэкап лишним не будет.
Программы переносить не стоит. Бубунта пакетный дистриб, в нем все программы тупо ставятся из пакетов - достаточно просто посмотреть, что было установлено и поставить то же самое. И вот после установки того же самого - можно перебрасывать уже настроенные конфиги. Кстати, это требует некоторого знания системы и программ - тупое копирование незнам-чего может привести к совершенно обратному результату.
Перенос UNIX-приложений под Linux удивительно легок. Linux и его GNU Си библиотека разработана для приложений, переносимых по замыслу; это означает что многие программы компилируются просто через make. Речь идет обо всех программах, не обращающихся к каким-то туманным возможностям частно й реализации, или сильно завязанных на недокументированном или неопределенном поведении, или, скажем, особенном системном вызове.
Linux часто не согласуется со стандартом IEEE Std 1003.1-1988 (POSIX.1), но это никак не сертифицировано. Linux позаимствовал много хорошего от SVID и BSD ветвей UNIX, но опять же не подражал им во всех возможных случаях. Проще говоря, Linux разработан чтобы быть совместимым с другими реализациями UNIX, сделать прикладные программы легко переносимыми, и в ряде случаев продвинут благодаря отобранным лучшим идеям из этих реализаций.
Например, аргумент timeout , посылаемый системному вызову select , на самом деле уменьшается Linux во время опроса. Другие реализации не изменяют это значение вовсе, и программа, скомпилированная под Linux может сломаться. Руководства SunOS и BSD говорят, что модифицируемость указателя timeout дело "будущих реализаций". К сожалению, многие приложения до сих пор предполагают, что timeout неприкосновенен.
Цель этой главы: сделать обзор основных вещей, связанных с переносом приложений в Linux, освещая различия между Linux, POSIX.1, SVID и BSD в следующих областях: обработка сигналов, ввод/вывод с терминала, управление процессами и сбор информации и переносимая условная компиляция.
С годами определение и семантика сигналов изменялись и совершенствовались различными реализациями UNIX. В настоящее время существует 2 класса сигналов: ненадежные (unreliable) и надежные (reliable) . Ненадежные сигналы это те, для которых вызванный однажды обработчик сигнала не остается. Такие "сигналы-выстрелы" должны перезапускать обработчик внутри самого обработчика, если есть желание сохранить сигнал действующим. Из-за этого возможна ситуация гонок, в которой сигнал может прийти до перезапуска обработчика, и тогда он будет потерян, или прийти вовремя, и тогда сработает в соответствии с заданным поведением (например, убьет процесс). Такие сигналы ненадежны, поскольку отлов сигнала и переинсталяция обработчика не являются атомарными операциями.
В семантике ненадежных процессов системные вызовы не повторяются автоматически будучи прерванными поступившим сигналом. Поэтому для обеспечения отработки всех системных вызовов программа должна проверять значение errno после каждого из них и повторять вызовы, если это значение равно EINTR .
По тем же причинам семантика ненадежных сигналов не предоставляет легкого пути реализации атомарных пауз для усыпления процесса до получения сигнала. Ненадежное поведение постоянно перезапускающегося обработчика может привести к неготовности спящего в нужный момент принять сигнал.
Напротив, семантика надежных сигналов оставляет обработчик проинсталированным и ситуация гонок при перезапуске избегается. В то же время определенные сигналы могут быть запущены заново, а атомарная операция паузы доступна через функцию POSIX sigsuspend .
SVR4-реализация сигналов заключается в функциях signal, sigset, sighold, sigrelse, sigignore и sigpause . Функция signal эквивалентна классическим сигналам UNIX V7, она предоставляет только ненадежные сигналы. Остальные функции автоматически перезапускают обработчик. Перезапуск системных вызовов не предусмотрен.
BSD предлагает функции signal, sigvec, sigblock, sigsetmask и sigpause . Все сигналы надежны, а все системные вызовы перезапускаемы Программист имеет возможность это отключить.
В POSIX.1 предоставляются функции sigaction, sigprocmask, sigpending и sigsuspend . Заметьте отсутствие функции signal : она оказалась излишней. Указанные функции работают с надежными сигналами, но перезапуск системных вызовов не определен совсем. Если sigaction используется в BSD или SVR4, то перезапуск системных вызовов по умолчанию отключен. Но он может включаться поднятием флага SA_RESTART .
В итоге, лучший путь работы с сигналами это sigaction , которая позволит точно определить поведение обработчиков сигналов. Однако signal до сих пор используется во многих приложениях и, как мы видели, имеет различную семантику в BSD и SVR4.
- SA_NOCLDSTOP : Не посылайте SIGCHLD во время остановки процесса-потомка.
- SA_RESTART : Осуществляет перезапуск определенных системных вызовов во время прерывания обработчиком сигналов.
- SA_NOMASK : Обнуление маски сигнала (которое блокирует сигналы во время работы обработчика сигналов).
- SA_ONESHOT : Очищает обработчик сигналов после исполнения. Заметьте, что SVR4 использует SA_RESETHAND для тех же целей.
- SA_INTERRUPT : Определен под Linux, но не используется. Под SunOS системные вызовы автоматически перезапускались, а этот флаг отменял такое поведение.
- SA_STACK : В настоящее время не работает; предназначен для стеков сигналов.
Заметьте, что POSIX.1 определяет только SA_NOCLDSTOP , а существуют различные другие опции, определенные SVR4, но невозможные под Linux. Во время переноса прикладных программ, которые используют sigaction , вам, возможно, придется обновлять значения sa_flags , чтобы добиться желаемого поведения.
Функция signal в Linux эквивалентна применению sigaction с опциями SA_ONESHOT и SA_NOMASK , что соответствует классической ненадежной семантике сигналов подобно SVR4.
Если вы хотите использовать signal с семантикой BSD, то для Вас большинство Linux-систем предоставляет совместимую с BSD библиотеку, которую можно прилинковать. Для подключения этой библиотеки вы можете добавить опции для командной строки компиляции. Перенося приложения, использующие signal , присмотритесь к тому, какие предположения делает ваша программа относительно обработчиков сигналов, и исправьте код (или компилируйте с соответствующими установками), чтобы добиться правильного поведения.
- SIGEMT не поддерживается; он соответствует аппаратному сбою под SVR4 и BSD.
- SIGINFO не поддерживается; он используется для информационных запросов к клавиатуре под SVR4.
- SIGSYS не поддерживается; он относится к некорректному системному вызову в SVR4 и BSD. В сочетании с libbsd этот сигнал переопределяется в SIGUNUSED .
- SIGABRT и SIGIOT одинаковые.
- SIGIO , SIGPOLL и SIGURG одинаковые.
- SIGBUS определен как SIGUNUSED . Технически в среде Linux нет никаких "ошибок шины".
Так же, как для сигналов, управление вводом/выводом имеет 3 различных реализации: под SVR4, BSD и POSIX.1.
SVR4 работает со структурой termio и различными вызовами ioctl (такими, как TCSETA, TCGETA и т.д.) для получения и установки параметров терминала. Эта структура выглядит так:
В BSD вызовы ioctl типа TIOCGETP, TIOCSETP и т.д. работают со структурой sgtty .
В POSIX используется структура termios вместе с различными функциями POSIX.1, такими как tcsetattr и tcgetattr . Структура termios соответствует структуре termio в SVR4, но типы переименованы (например, tcflag_t вместо unsigned short ), и для размера массива c_cc употребляется NCCS .
Если ваша программа использует реализацию BSD sgtty , вы можете прилинковать libbsd , как описывалось выше. Это обеспечит перекройку ioctl , означающую пересмотр запросов ввода/вывода на терминал в термины структуры termios POSIX, поддерживаемые ядром. При компиляции такой программы, если символы вроде TIOCGETP не определены, вам придется прилинковать libbsd .
Такие программы, как ps, top и free , должны иметь способ получения информации от ядра о процессах и ресурсах системы. Аналогично, отладчикам и другим подобным средствам требуется управлять и инспектировать работающий процесс. Такие возможности предоставляет ряд интерфейсов различных версий UNIX, и практически все они либо машинно-зависимы, либо привязаны к конкретной реализации ядра, поэтому не существует универсально доступного интерфейса для такого взаимодействия ядра и процесса.
Для прямого доступа к структурам ядра многие системы используют устройство /dev/kmem и подпрограммы kvm_open, kvm_nlist и kvm_read . Программа открывает /dev/kmem , читает символьную таблицу ядра, определяет при помощи этой таблицы расположение данных в работающем ядре и читает соответствующие адреса адресного пространства ядра используя названные подпрограммы. Поскольку это требует согласования между программой пользователя и ядром, размера и формата структур данных, подобные программы перестраиваются для каждой новой версии ядра, типа процессора и т.д.
Системный вызов ptrace используется в 4.3BSD и SVID для управления процессом и считывания из него информации. Классически он используется отладчиками для, скажем, trap-исполнения процесса (с условными точками останова) или исследования его состояния. Под SVR4 ptrace заменен файловой системой /proc , которая появляется как директория, содержащая единственную точку входа в файл для каждого работающего процесса, называемую ID процесса. Пользовательская программа может открыть файл интересующего ее процесса и совершить над ним различные вызовы ioctl для управления выполнением процесса или получения информации о процессе от ядра. Аналогично, программа может читать или записывать данные напрямую в адресное пространство процесса через файловый дескриптор в файловую систему /proc .
Под Linux для управления процессом поддерживается системный вызов ptrace , работающий так же, как 4.3BSD. Для получения информации о процессе или системе Linux также предоставляет файловую систему /proc , но с совершенно другой семантикой. Под Linux /proc состоит из ряда файлов с общесистемной информацией, такой как использование памяти, средняя загруженность, статистика загружаемых модулей и сетевая статистика. Эти файлы общедоступны для read и write ; их содержимое можно разбирать, используя scanf . Файловая система /proc под Linux также предоставляет точку входа в директорию для каждого работающего процесса, называемую ID процесса. Она содержит файловые точки входа для информации типа командной линии, связей с текущей директорией и исполняемым файлом, открытых файловых дескрипторов и т.д. Ядро предоставляет всю эту информацию в ответ на запрос read . Такая реализация не противопоставляется файловой системе /proc , находящейся в Plan 9, и имеет некоторые ее недостатки. Например, для ps , чтобы просмотреть таблицу с информацией о всех работающих процессах, нужно пересечь многие директории, открыть и прочитать многие файлы. Для сравнения: подпрограммы kvm в других UNIX-системах считывают структуры ядра напрямую, потратив лишь несколько системных вызовов.
Очевидно, все реализации настолько различны, что перенос приложений, их использующих, может стать серьезной задачей. Следует особо отметить, что файловая система /proc в SVR4 намного грубее, чем в Linux, и их нельзя использовать в одно и том же контексте. На самом деле каждая программа, которая использует kvm или файловую систему /proc SVR4, просто непереносима, и такие фрагменты кода должны быть переписаны.
- Запросы PTRACE_PEEKUSER и PTRACE_POKEUSER под BSD названы соответственно PTRACE_PEEKUSR и PTRACE_POKEUSR в Linux.
- Регистры процесса могут быть установлены с использованием запроса PTRACE_POKEUSR со смещениями, находящимися в /usr/include/linux/ptrace.h .
- Запросы SunOS PTRACE_не поддерживаются, как не поддерживаются ни PTRACE_SETACBKPT , ни PTRACE_SETWRBKPT , ни PTRACE_CLRBKPT , ни PTRACE_DUMPCORE . Отсутствие этих запросов влияет лишь на малое количество существующих программ.
Linux не имеет подпрограмм kvm для чтения адресного пространства ядра из пользовательской программы, но в нем есть средства, такие как kmem_ps , в действительности являющиеся версией подобных подпрограмм. Вообще говоря, они непереносимы, и каждый код, использующий kvm , вероятнее всего, зависит от определенных обозначений или от типов данных ядра, поэтому такой код следует признать машинно-зависимым.
- __STRICT_ANSI__ : только для ANSI C
- _POSIX_SOURCE : для POSIX.1
- _POSIX_C_SOURCE : если определено как 1, то используется POSIX.1, если 2, то POSIX.2
- _BSD_SOURCE : ANSI, POSIX и BSD
- _SVID_SOURCE : ANSI, POSIX и System V
- _GNU_SOURCE : ANSI, POSIX, BSD, SVID и GNU расширения. Это значение по умолчанию, если ничего из вышеперечисленного не определено.
Если вы определили _BSD_SOURSE , то для библиотеки определится _FAVOR_BSD . Тогда некоторые вещи POSIX и SVR4 будут вести себя, как в BSD. Например, если определено _FAVOR_BSD, setgmp и longgmp будут сохранять и запоминать маску сигнала, а getpgrp будет допускать аргумент PID. Напомним, что вы должны собирать программу с libbsd , чтобы добиться BSD-поведения.
- __GNUC__ (major GNU C version, e.g., 2)
- __GNUC_MINOR__ (minor GNU C version, e.g., 5)
- unix
- i386
- linux
- __unix__
- __i386__
- __linux__
- __unix
- __i386
- __linux
Эта глава охватывает многое, связанное с переносом, кроме, правда, отсутствия некоторых системных вызовов, названных в главе о системных вызовах, и потоков (знатоки говорят, что загружаемый потоковый модуль должен быть на ftp.uni-stuttgart.de в pub/systems/linux/isdn). (Добавлено Свеном Голдтом /Sven Goldt/.)
Хочу поделиться собственным опытом переноса системы на другой компьютер, целиком и полностью отличающийся аппаратной конфигурацией.
На самом деле, вариантов перенести систему много. Каждый имеет свой подход. Я же опишу способ, который больше всего подходит для новичков.
Что имеем
Итак, вот конфигурация моего исходного компа, с установленно ОС:
Материнка: Intel S3200shv
Процессор: Intel Core 2 Duo E8400
Память: 8Гб
Raid 1 ёмкостью 300 Гб
ОС: Fedora 12 i686
Будем для краткости называть его «донором».
Конфигурация компа назначния:
Материнка: Intel Desktop Board D845EBG2
Процессор: Celeron 2ГГц
Память: 512Мб
HDD 160 Гб
Это будет «пациент».
В кратком виде алгоритм будет таким:
1. Создать разделы у «донора», как Вы хотите.
2. Установить на комп назначения такую же систему, как на исходном компе.
3. Подключить к исходному компу HDD компа назначения
4. Скопировать файлы из разделов «донора» в разделы «пациента».
Многие вместо второго шага правят разделы вручную. Я предлагаю установку, поэтому этот способ как мне кажется, проще и универсальнее. Чтобы Вы не мучились с переустановкой загрузчика и правкой /etc/fstab.
Шаг первый
Я размечал свой HDD с помощью загрузочного диска pmagic. Удобно и наглядно.
Разделы я создавал «один-в-один» как и на исходном компе, только меньше размером, т.к. HDD «пациента» меньше.
Шаг второй
Установка Fedora на подготовленный HDD прошла быстро и без проблем. Правда, сначала не мог запустить её в графическом режиме, т.к. стояла планка только в 256 Мб. Пришлось заменить на 512 и процесс пошёл.
Шаг третий
Для начала советую провести у «донора» небольшую подготовку. Это установить kudzu:
yum install kudzu
На всякий случай с помощью dd создать бэкап исходной системы. Мало ли, вдруг что-то напутаете при копировании файлов из-за невнимательности?
Далее, выключаем оба компа, подключаем к «донору» винчестер HDD, на который мы только что установили такую же систему. Загружаемся с LiveCD.
Шаг четвёртый
Заходим в консоль, под рутом создаём 2 директории: /mnt/donor/ и /mnt/pacient/. Внутри каждой директории я создал поддиректории, и туда смонтировал разделы HDD «донора» в /mnt/donor/, а разделы HDD «пациента» в /mnt/pacient/.
Теперь можно начать копировать файлы. Но прежде, очень важное замечание! Есть некоторые исключения, которые не нужно копировать от «донора»! Создадим где-нибудь файл exclude_list, содержащий эти исключения:
/etc/fstab
/boot/grub/grub.conf
/proc
/sys
/dev
/mnt
/media
А теперь копируем файлы с пом. команды:
rsync -xrlptgoEv --progress --exclude-from=/путь/до/exclude_list /путь/откуда/копируем/ /путь/куда/копируем/
Аналогично выполняем вышеприведённую команду для всех смонтированных разделов. Только обязательно в конце "/путь/откуда/копируем/" указывайте слеш.
Перезагружаемся.
У меня после перезагрузки система стартовала без проблем. В логах ни на что не ругалась. Единственное, что пришлось сделать, это подредактировать файл /etc/sysconfig/network-scripts/ifcfg-eth0, т.к. скопировался MAC-адрес с компа «донора». Ну и автозагрузка программ исправил с помощью ntsysv.
Было бы классно, если бы с виндой можно было проделать такой же фокус.
Читайте также: