Форум проекта Matuntu
Поддержка => Создание загрузочного носителя и установка системы => Тема начата: ivm от 05 Июня 2016, 15:19:40
-
Заинтриговала меня возможность установить Matuntu на несколько разделов на нераспределённое пространство SSD размером 32 ГБ с таблицей разделов MBR.
Установку на SSD (аналогично на HDD) опишу как можно подробнее.
- На чистом диске создал два раздела в EXT4: сначала для корневого (/) размером 10240 MiB, а затем на оставшемся для домашнего (/home)
Применение настроек создания каждого раздела происходит нажатием кнопки с зелёной стрелкой отдельно для каждого раздела - Теперь назначим разделам точки монтирования: / и /home
PS. Я не сторонник разделять корневую систему на разделы, потому что данное действие выделит квоту величиной в указанный размер раздела, после исчерпания которой начнутся проблемы. Можно, конечно, из-под живой сессии изменять размер раздела. Нов едином корневом разделе это происходит без лишних действий. Так зачем создавать себе проблемы? - После подтверждения назначения всех разделов кнопкой с зелёной стрелкой ставим отметку (чекбокс) Перенести файлы данных и конфигурации пользователя
- В нижней строке указываем место установки загрузчика Grub - /dev/sd?
- Вот теперь пришло время нажать кнопку Далее для установки системы на диск...
PS. Надеюсь, понятно показал, как при помощи Systemback установить систему на несколько разделов с разделением по точкам монтирования.
Единственное предупреждение: установка системы на неисправное оборудование практически всегда заканчивается плачевно.
-
Всё больше тайн раскрывается с применением замечательного инструмента :)
Спасибо, Игорь, за подробное описание своих действий.
-
Метка SB@ - для чего ето?
-
Метка SB@ - для чего ето?
Это фирменная метка System Back, которая появляется в процессе установки системы автоматически.
Для лучшей ориентации в созданных разделах можно изменить метку при помощи Gparted.
-
Как раз вчера ставил и настраивал Матунту Х32-М114, и вручную переносил /home на другой раздел диска.
Суть в том, что Systemback мне настойчиво предлагала раздел /home отформатировать. Снимаю галочку, перещелкиваюсь на строку, помеченную как /, потом снова перещелкиваюсь на /home - галочка снова стоит. А у меня там же /home от 14.04, который пока что надо сохранить, на всякий случай.
Поэтому сделал так:
1.Из-под 16.04 создал на отдельном разделе /home папку, совпадающую с логином. Создавал от root, потом переключил права на себя
2. скопировал все файлы из действующего на тот момент /home во вновь созданную папку.
3. Потом перегрузился в 14.04, из fstab 14.04 скопировал строку монтирования /home в fstab 16.04
4. Перегрузился обратно в 16.04. Вылез из /home/<username> кнопкой "вверх" и увидел "рядом" папку пользователя, который в 14.04 создан.
-
Рискованное это мероприятие - переносить все настройки потому, что различия в системах 14.04 и 16.04 значительные. Можно было просто перекинуть настройки отдельных приложений. У меня таким образом настройки трансмиссии перекочёвывают из системы в систему ещё с нулевых ;)
-
Не-а, не все настройки из 14.04.
При установке системы с помощью Systemback /home создается на том же разделе, что и /
А я привык, что у меня /home на отдельном разделе живет.
Вот и переносил /home 16.04 на отдельный раздел.
А настройки я переношу именно для отдельных программ, по мере их установки. Вчера вот настройки krusader перенес, сегодня перенесу настройки transmission, в основном - список закачек :)
-
ivm
Спасибо за подробную расшифровку но есть один вопрос
Смысл в галочке - перенос всех параметров. Перенос откуда? Из исходной версии?
Если ее не ставить - я понимаю что после установки получаю чистую систему как при более ранних версиях Matuntu
Я права?
ludoed
Не знаю как вы ставите. Я использую иногда несколько систем при этом все хомяки монтируются на один раздел. Что в основной что в тестовой, что в....
Единственно но - в основной системе один юзер, в тестовой другой
Некоторое время назад я перепробовала несколько вариантов Matuntu на основе 16.04. Папка юзера создается во время установки. Проблем не возникает.
-
Rondo Andante, если хотите, чтобы система подхватила пользовательские настройки, которые Вы наблюдаете в живой сессии, галочку лучше поставить.
Как понимаю, способ сохранения в определённом каталоге пользовательских настроек, как это делалось ранее в 12.04 и 14.04 в Remastersys, здесь, в Systemback, не работает.
-
Смысл в галочке - перенос всех параметров. Перенос откуда? Из исходной версии?
Наследование пользователем, созданным при инсталляции, конфигов и данных пользователя Live-сессии, у меня это некая гражданка cintu, у Татьяны, кажется, vita.
Я использую иногда несколько систем при этом все хомяки монтируются на один раздел.
Сапсэм-сапсэм нэдавна, лет сто назад (а конкретней, лет 15 тому) я тоже так делал. Потом обнаружил, что в результате в $HOME получается каша. Иногда реально вредная: в одном дистре KDE 3.5.X, в другом - 4.X, и конфиги у них на самом деле разные, и друг другу мешаются. А если учесть, что кроме разных линксов у меня ещё BSD одна-другая часто жила...
Это даже конфига login shell касается: $HOME/.zshrc для чистых убунтоидов один, для Mint'одиов чуть другой, для, скажем, openSUSE - ещё другее, а для DragonFly - вообще $HOME/.tcshrc :)
Поэтому постепенно пришёл к тому, что $HOME - всегда на том же разделе, что и корень, и в нём нет ничего кроме dot-файлов. А все рабочие данные - в /home/data на отдельном разделе (желательно вообще на отдельном носителе). Который монтируется в любую систему.
А dot-конфиги для отдельных приложений - так и переношу,. как написали ivm и ludoed - только для тех, для которых это действительно нужно, типа того же transmission или, что для меня очень важно, geany.
Кстати, копирую их я в банальный tar-архив, для сохранения всей атрибутики, типа UID'а и mtime (последнее бывает очень важно). И прям так в MC открываю архив и тибрю оттуда нужные конфиги. А не нужные - не тибрю :)
-
способ сохранения в определённом каталоге пользовательских настроек, как это делалось ранее в 12.04 и 14.04 в Remastersys, здесь, в Systemback, не работает.
Да, Systemback на /etc/skel плевать хотел. Настройки (при наличии "птицы") наследуются из /home/$LIVEUSER.
-
Единственно но - в основной системе один юзер, в тестовой другой
Кстати, действительно важно вот что: юзер определяется системой не по имени, а по UID'у. А во всех убунтоидах юзер, чей аккаунт создаётся при установке, имеет по умолчанию UID 1000. То есть получается, что у Вас в /home оказывается несколько подкаталогов, принадлежащих юзеру, пусть с разным login'ом, но с одним и тем же UID. Поверьте, это потенциальный источник проблем, и странно, что Вы с ними ещё не столкнулись.
-
alv, не сталкивалась. Мне до вас мягко скажем далеко.
Всю важную инфу сразу сношу на другие разделы, которые при развлечениях с установками иногда даже не монтируются.
(Все пути в офисных пакетах и тп сразу переписываю)
Несколько раз было что ставила с тем же именем юзера новую систему - все настройки вплоть до картинки на декстопе подхватывались.
По поводу работы с разными направлениями ( типа OpenSUSE И Buntu) - либо задается новый юзер либо - что чаще все конфиги прикладных программ (типа Skype, Icq, transmission) сохранятся а хомяк пускаю под формат.
В Догонку
Надо признать что размещение хомяка и корня вместе не считала правильным решением, хотя возможно именно так решится проблема которая кажется скоро потребует своего решени.
-
в /home оказывается несколько подкаталогов, принадлежащих юзеру, пусть с разным login'ом, но с одним и тем же UID. Поверьте, это потенциальный источник проблем, и странно, что Вы с ними ещё не столкнулись.
Было бы интересно услышать хотя бы намек на причины подобных проблем, или описание процесса, приведшего к переходу потенциального источника проблем в источник проблем реальных. Спасибо.
-
Как выяснилось (http://alv.me/installyatsiya-cintu-dopolnenie/), можно использовать диск без таблицы разделов и создавать средствами Systemback. Здорово!
-
Как выяснилось (http://alv.me/installyatsiya-cintu-dopolnenie/), можно использовать диск без таблицы разделов и создавать средствами Systemback. Здорово!
Это Snowman спасибо: кажется, он первый догадался, что !Delete! - вовсе не delete, а наоборот - create.
-
Было бы интересно услышать хотя бы намек на причины подобных проблем, или описание процесса, приведшего к переходу потенциального источника проблем в источник проблем реальных. Спасибо.
Ну очень простая ситуация, о которой я уже говорил: есть User1 с UID 1000, и есть User2 с UID 1000. Конфиги, скажем, login shell'а у них разные, а шелл один и тот же. Чей конфиг будет считываться при авторизации любого из них? Вот и я не знаю, есть подозрение, что рэндомно.
А уж с чуть более сложными вещами, типа KDE, да ещё если версии чуть разные, проблемы просто гарантированы.
-
есть User1 с UID 1000, и есть User2 с UID 1000. Конфиги, скажем, login shell'а у них разные, а шелл один и тот же. Чей конфиг будет считываться при авторизации любого из них?
Они из разных дистрибутивов, в /etc/passwd каждого только один из, домашний каталог у каждого свой.
Конфиг будет читаться из домашнего каталога пользователя, указанного в /etc/passwd и записанного в переменную окружения HOME.
UID для определения каталога участвует только при поиске в /etc/passwd, а они, повторюсь, разные.
Нет повода для путаницы.
User1:x:1000:1000:,,,:/home/User1:/bin/bash
User2:x:1000:1000:,,,:/home/User2:/bin/bash