1 (2020-03-07 19:15:56 отредактировано ingvaro)

MagOSM-Multi Linux
MagOSM - Mageia  -     https://disk.yandex.ru/client/disk/MagOSM-Multi/Mageia

MagOSM-Multi Linux это многофункциональный GNU/Linux .
Может запускать  MagOS(Rosa), Mageia,Ubuntu
Linux/$DISTR - папка запуска дистров
Где DISTR= Mageia или DISTR= MagOS или DISTR= Ubuntu
Предусмотрен DISTR= TEST  Отсюда можно запустить что то еще.
/Linux/Zmod  -  общий магос-модуль
Нумерация модулей  -  цифровая, причем UIRD  учитывает только первые две цифры

+ открыть спойлер

Например, если написать в сроке ядра загрузчика :
uird.noload=72,75 
То модули 72 и 75 не загрузятся
uird.noload=16      -   отключение, при старте,  модуля 16-nvidia.xzm  (драйвера для nvidia)

Совместим с MagOS Linux - http://magos-linux.ru/
Тема иконок - Papirus

+ открыть спойлер

Взял из Убунту. После темы иконок уж слишком строгой   Breeze даже очень ничего. На критику этой темы иконок могу только ответить ..... это векторная графика

Моя сборка отличается  от штатной использованием для инициализации системы   UIRD https://github.com/neobht/uird
Автор -  neobht    Или на русском - https://www.opennet.ru/opennews/art.shtml?num=48315
Т к модульную систему еще надо собрать из модулей  и настроить с заданными параметрами а лишь потом управление запуском передается системе

+ открыть спойлер

Скачать :
Требуется наличие пакетов kmod,  lib64kmod-devel
1) В root-терминале  запустить :
      git clone --recursive https://github.com/neobht/uird.git
      Чтоб обновить
      git pull
2) Зайти в скачанную папку с UIRD
    Дальше выполнять инструкции из README.md

3) PFS - https://github.com/pfs-utils/pfs-utils-cli/tree/v4


В данной реализации Mageia собрана на пакетной базе Магеи 7 x86-64.
Не установлены MagOS-Server и некоторые приложения из Росы, которых нет в Магее. Установлены дополнительные приложения, нужные в Магее
По принципу действия MagOS-Linux является Live-системой с гибкой настройкой и возможностью сохранения изменений, что позволяет использовать MagOS и как Live систему, и как обычный дистрибутив. При этом можно получить все то же самое, что и в обычном дистрибутиве + невероятную гибкость за счет модулей и возможности загружать систему практически откуда угодно (жесткие диски, флеш накопители, сетевая загрузка по NFS, HTTP, DVD ). А сжатая файловая система делает дистрибутив компактным и увеличивает скорость работы.

Установка на  флэшку или диск:

+ открыть спойлер

Файловую систему рекомендую BtrFS
Конечно можно использовать и другие - Ext3, Ext4 ....   Но тестирование проводилось только на BtrFS
Ну и несколько раз запускал для контроля на FAT32.   Работать на FAT32 можно, но это в крайнем случае.

Описание установки и опцийhttps://github.com/magos-linux/magos-linux/wiki/
Подготовка образа :
1)  Если сборка в формате NAME.tar.gz, то просто распаковать на заранее отформатированную флэшку или раздел диска.
2) Если сборка в формате NAME.img, то
   - примонтировать образ
     Например - acetoneiso
     К тому же у меня в сборке в Dolphin, для правой кнопки мыши, есть интерактивное меню работы с ~.iso и ]~.img образами

Традиционный bios (таблица разделов msdos) :

   - Переписать папки из образа в корень раздела жесткого диска или USB накопителя.
     Папка boot должна быть обязательно на загрузочном разделе (флешка, диск C, линуксовый загрузочный раздел).

EFI-загрузка (таблица разделов gpt)
Про форматирование флэшки с таблицей разделов gpt в инете написано много и подробно
Есть и статьи и обзоры и добавить мне к этому нечего. Скажу только что флэшку для gpt, с использованием grub 2, придется разбивать на три раздела.  Иначе никак.
Я уже давно готовлю флэшку с таблицей разделов gpt отдельной утилитой - MakeFlash
В моей сборке находится в  /Linux/VAR/MakeFlash.zip
- распаковать в любом удобном месте. Можно прямо на флэшке
- запустить в root терминале папки MakeFlash

./start.sh

- в /Linux/VAR/MakeFlash/start.conf  можно перенастроить утилиту
- по дефолту - gpt разметка с разбивкой флэшки на три раздела для Linux
- Скрипт интерактивный. Надо не спешить, читать и быть очень вниметельным
  Имя флэшки или диска в окне запроса  надо писать вручную  и если ошибиться с имененм диска, то он будет затерт.

+ открыть спойлер

MakeFlash - утилита для подготовки форматирования флэшки
По дефолту запуск gparted, надо удалить все разделы с флэшки

Если флэшка чистая, то можно указать диск .  Например
DEVA="/dev/sda"

Параметры по дефолту
В итерактивном режиме можно можно поменять метку флэшки и имя диска
Внимание !!!  Если ошибется в имени диска и назнчить не тот диска, то он будет стерт.
#Выбрать метку флэшки :
LABELFL="MagOSM"
# Чистка флэшки
CLEARING="yes"

# Выбор таблицы разделов
#WK="msdos"
WK="gpt"

Выбор форматирования для режима мультизагрузочной флэшки.
Это раздел для запуска Windows и раздел для запуска Linux

#FRMT=efi-flash   # форматирование обычного диска  или флэшки
#FRMT=efi-eMMC  #форматирование диска eMMC в efi-нетбуке

Если раздел для запуска Windows не нужен
FRMT=efi-flash-lx  #форматирование всего раздела диска или флэшки для запуска Linux
GBFL="XXgb"

# Выбрать емкость флэшки :
GBFL="8gb"
#GBFL="16gb"
#GBFL="32gb"

# Выбрать версии EFI
EFIDIR="refind-0.11.4"
#EFIDIR="EFIL"

Установка загрузчика:

1) Установить загрузчик из папки /boot/magosmbootinst.sh 
   
Настройка загрузки в ] /boot/magosm/bootinst.conf   Пояснения в boot/magosm3.ReadMe
   Для установки загрузчика  запустить в терминале ] /boot/magosm3/bootinst.sh
  При этом все загрузчики из папки boot удаляются. По дефолту записывается и устанавливается grub2.
  Но можно установить и syslinux

Системные данные
Администратор - root (Пароль — toor)
Пользователь - live (Пароль - magos)
Halt - Выключение системы с сохранением системных изменений в модуль
Reboot - Перезагрузка системы без сохранения системных изменений в модуль
SysXdrake=no - видеооборудование определяет MagOS
SysXdrake=yes - видеооборудование определяет систем


Пользователь   - Можно создать любого пользователя.
По умолчанию создаются :
root    пароль - toor
live    пароль -  magos
Рабочий стол  - KDE, LXQt
Локализация :

+ открыть спойлер

Задается в меню загрузчика
     lang=en           -   английская локализация
     lang=en+ru      -   основная локализация английская, с добавленной возможностью использования русской
     lang=ru             -    русская локализация
    Если совсем исключить  опцию lang из меню загрузчика ,  то локализацию сформирует finish-install от Магеи, запускаемый при загрузке системы

Подписи рабочего стола
admin - uird.load=/base/,/modules/,rootcopy - Работа с системой
home - uird.load=/base/,/modules/,rootcopy,/modulhome/ - Работа с системой + /modulhome/
magos - Режимы Machines и Changes

Разрешение монитора :

+ открыть спойлер

К сожалению разрешение монитора в моей сборке надо устанавливать вручную. В стр каждого меню :

set gfxpayload='1280x1024'

Конечно хорошо бы интерактивный выбор, как в опции vga=ask
Но для grub 2 опция vga  является устаревшей. И надо пользоваться опцией gfxpayload. А для этой опции  возможности задействовать интерактивный выбор разрешения я не нашел
Но зато  я дополнил  скрипт   /usr/lib/magos/rc.post.d/11-xorg  конфигурированием  Modeline для выбранного разрешения.
И то разрешение, кот установлено в  опции gfxpayload становится вроде как  системным
Это очень удобно. Скорректировал меню, запустил систему и ничего делать больше не надо.
Если  скопировать в /Linux/MagOS/base  содержимое    MagOS/base/*   из последней сборки MagOS linux - http://magos-linux.ru/
Меню Clean-MagOS  запустит MagOS linux в авторском варианте и можно увидеть разницу
Мой домашний монитор в MagOS linux определяется как 1024x768 (это при 1920x1080)
Работать на  таком разрешении при  оптимальном 1920x1080  -  это разновидность мазохизма.
Этот случай и послужил толчком  конфигурирования  Modeline для выбранного разрешения в меню grub 2

Вот  мой   /etc/X11/xorg.conf.d/00-modes.conf
Для выбранного разрешения для моего нетбука :

set gfxpayload='1600x900'
+ открыть спойлер

Section "Monitor"
    Identifier "monitor1"
# 1600x900 59.95 Hz (CVT 1.44M9) hsync: 55.99 kHz; pclk: 118.25 MHz
Modeline "1600x900_60.00"  118.25  1600 1696 1856 2112  900 903 908 934 -hsync -vsync
EndSection   
Section "Screen"
    Identifier "screen1"
    Device "device1"
    Monitor "monitor1"
    SubSection "monitor1"
     Modes "1600x900"
    EndSubSection
EndSection

Эта доработка прекрасно работает и в Ubuntu

Режимы запуска UIRD

+ открыть спойлер

Machines - Сохранение в папку machines/dynamic каждого дистра. Причем каждая машина запоминается отдельно
Режим Machines можно рекомендовать для записи изменений на флэшку

+ открыть спойлер

Для работы конечно Machines  проблематичный.
Я как то отлаживал скрипт и делал это на 4 компах. С Машинез мне пришлось бы 4 раза начинать все сначала.
Но как вариант для тестирования оборудования он как раз к месту.
Т е не работает комп . Зашел с флэшечной системы протестировал исправил.
Допустим через месяц опять что то. Опять зашел с флэшки. Тут к месту результаты прошлого тестирования

Changes - Сохранение в папку My-Data/changes. Режим Changes рекомендуется для установки на жесткий диск или usb-диск

+ открыть спойлер

Преполагается что Changes будет использоваться только для Магеи, поэтому и папка одна
Небходимо наличие в корне флэшки или на разделе диска /May-Data/changes
Сохранение в модуль в Changes заблокировано, т к все сохраняется прямо в папке /My-Data/changes
Если папка /May-Data/changes в системе будет одна то UIRD найдет ее при запуске
Если папка /May-Data/changes в системе будет не одна и сформирована на разных разделах диска,
то UIRD будет искать /May-Data/changes до рервого совпадения

Linux/My-Data.tar.gz - архив My-Data для распаковки"

Загрузчик grub2 :

+ открыть спойлер

Live - Запуск с сохранением системных изменений для пользователя. С автовходом в рабочий стол live
Machines - Основной режим запуска с сохранением в xzm-модуль в папку MagOS/machines/dynamic
Changes - Очень подходит для установки сборки на раздел диска. Можно не сохранять сис-изменения в xzm-модуль. При запуске на флэшке может "тянуть". Все зависит от быстродействия флэшки
Admin - Основной режим запуска с сохранением в xzm-модуль в системную папку $DISTR/base. С автовходом в рабочий стол root
Предназначен для установки обновлений и др системных изменений в Linux/$DISTR/base

Syslinux    -  Взят из MagOS-Linux

Режим FIRSTBOOT

+ открыть спойлер

В MagOS.ini каждого дистра есть есть :
FIRSTBOOT=40-firstboot.xzm    -  для дистров  Mageia, Ubuntu, Test
FIRSTBOOT=90-firstboot.xzm   -  для MagOS(Rosa)

При первом запуске  того или иного дистра есть возможность настроить систему по своему вкусу и со своими предпочтениями.
Решил что  не надо решать все за пользователя  что и как и где ему запускать. Это бесполезно.
Это как в MagOS Linux мне непонятно наличие на панели калькулятора. Сколько запускал столько и думал а зачем он ?
Ну а может он кому то и нужен .
Но введенный режим настройки системы FIRSTBOOT все поправил.
Запускаешь, устанавливаешь сколько угодно пользователей, настраиваешь рабочие столы, до настраиваешь систему  выключаешься и все !
Ты уже владелец своей собственной сборки.
И это станет частью системы и при выключении запишется в в Linux/$DISTR/base

Для Магеи FIRSTBOOT я уже сделал. Если кому то это не нравится, то надо удалить /Linux/Mageia/base/40-firstboot.xzm
Перезагрузиться и настроить систему со своими предпочтениями и выключить систему
Появится новый  40-firstboot.xzm и уже с вашими настройками, которые станут частью системы

AutoDesktop

+ открыть спойлер

Находится в /usr/lib/magos/rc.desktop/AutoDesktop
Сам скрипт в /usr/lib/magos/scripts/autodesktop
Это новый сервис и в МагОС такого нет
Во время входа в   систему подгружает на  рабочий  стол значки приложений и меняет некоторые параметры запуска по дефолту
Допустим для плазмы выключает эфекты рабочего стола
При первом запуске пользователя сервис выолнит
echo "$DE=yes" >> $HOME/.autodesktop
При втором запуске пользователя сервис выполнит
echo "$DE=yes" >> $HOME/.autodesktop
mv $HOME/.autodesktop $HOME/.autodesktop.aut
После второго запуска и появлении в $HOME  текстового файла .autodesktop.aut  сервис будет выключен и управлять рабочим столом будет уже системам
Конечно если удалить $HOME/.autodesktop.aut  то настройка рабочего стола из AutoDesktop повторится.
Сотрутся все значки на рабочем столе и скорректирует некоторые параметры запуска


Еще немого :

+ открыть спойлер

4) А что на рабочем столе ?
Для удобства редактирования, на рабочем столе разместил ссылки , нужные для работы.
4.1)    Анализ системных изменений

+ открыть спойлер

Очень полезная утилита. - http://www.magos-linux.ru/index.php?opt … =55#p16985
Позволяет отслеживать системные изменения за заданный промежуток времени
Работает только в UIRD . Для начала работы надо кликнуть ссылку на рабочем столе
Сначала формируется контрольная точка системы.
Потом обычная работа или настройка чего либо
И в завершение формирование каталога "new"   и каталога "changed"

Хочу отметить отличия моего syschanges (Анализ системных изменений)  от MagOS.
Сам код не трогал, но поменял режим работы :
Запуск в root-терминале :
1)  sys-changes  (или sys-changes --auto ) - Запуск полного цикла создания контрольной точки и формирования
   каталога "new"   и каталога "changed"
       new          - новые появившееся файлы
       changed  - измененные файлы

2)  sys-changes --start   Формирование только  контрольной точки
3)  sys-changes --finish   Формирование только каталога "new"   и каталога "changed"
     Причем syschanges --finish  с заданной  контрольной точкой ( syschanges --start  ) можно запускать сколько угодно. Мне это показалось удобно. Т к в процессе анализа системных изменений выявляются измененные файлы, но что изменено в этих файлах может дать только новое изменение каких-либо настроек и повторный запуск syschanges --finish
Но к сожалению это только в root-терминале.

4.2)  Управление MagOS

+ открыть спойлер

Конфиг управления системой - /memory/etc/MagOS, формируемый при загрузке системы из Linux/$DISTR/MagOS.ini
Для управления формирования модуля сохранения есть строчка:
 
   SAVETOMODULE=yes  Разрешает формирование модуля сохранения системных изменений при отключении системы
   Замена на :
   SAVETOMODULE=no   Запретит формирование модуля сохранения системных изменений при отключении системы
Режим работы модуля сохранения системных изменений при отключении системы задается в  Linux/$DISTR/MagOS.ini
  Но активация изменений  режимов будет после перезагрузки.
  При этом они попадут в /memory/etc/MagOS (/etc/sysconfig/MagOS)

Если драйвер видеокарты не запускается :

Можно попробовать в строке меню запуска ядра записать опции

    xdriver=vesa   -   установка vesa подходит во многих случаях
    xdriver=fbdev   -   установка fbdev подходит во многих случаях

Зачем все это ?

+ открыть спойлер

Почему я  занялся этим?
Мне нужны :
- Тестирование оборудования.
  Здесь Магея на высоте. Многие сетевые карты у нас на работе списывылись, так как драйверов под новую винду не находилось.
  Запускаю на компе флэшечную Магею. Смотрю как она определила сетевую карту. Ищю  драйвер. Захожу в Windows
  Устанавливаю и все работает.
    Так как Linux ищет драйвера по чипу. Windows по фирме производителя.
  А многое  -  китайская подделка известных фирм. И поддержки у них конечно нет. Сделали, продали и забыли
   Именно поэтому я поставил себе задачу использования именно  магеевских инструментов установки системы и настройки
  Т е системный диск сделан штатаным магеевским инсталятором

-  Нужен отладчик программ, где можно было бы безопасно экспериментировать.
  К своему стыду, резервирование системы в Магее я как то не освоил. Не особо требуется в Linux архивирование
  Перезапустил и все восстановилось.  (думаю  в  ~70%   всех отказов)
   Если не лезть в систему, то все работает. А если залез и что то сделала не так, то это все.
  Она обиделась.
А помогает резервирование в этом.  А если что то сделал не так и система вообще зависла и не запускается.
Как из терминала  запустить  резервирование . Все вопросы и вопросы.
Думаю никакой самый крупный специалист не сможет предсказать, что придет в голову новичку.
     И модульная Магея  оказалась выходом из тупика. 
Согласитесь  идея стоит того, что бы потратить некоторую часть жизни на отладку.
Нет   каких то прочих заумных вещей.  Просто перезагрузился   без сохранения изменений или удалил сбойный модуль и все !!!

Работа как в обычно в Магее

+ открыть спойлер

Т е запускается drakconf (Центр правления Магеиа) и все устанавливается там.
Установка программ -  drakrpm
подключить репозит.  - drakrpm-editmedia
обновления                  - drakrpm-update

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

Спасибо сказали: Vagulo1

2 (2019-09-30 17:47:22 отредактировано ingvaro)

Сохранение  системных изменений при отключении системы

1) Home - предназначены именно для пользователя

- Machines  -  Изменения создаются для каждого компьютера в  MagOS/machines/dynamic в модуль xzm
  Удобный режим. Но модуль сохранения только  увеличивается и увеличивается время на запись модуля

- Changes  -  По дефолту системные изменеия сохраняются в LX-Data/changes
        Очень хорош при установке сборки на диск. При работе на флэшке может "тянуть". Все зависит от быстродействия флэшки.
        Сохранение изменений не требуется и  желательно запретить его
       опция 

SAVETOMODULE=no  в    /memory/etc/MagOS

Подробнее - https://github.com/magos-linux/magos-li … 1%8B%D1%85

2)  Admin -  Это  "Чистый режим " как в MagOS , но с возможностью сохранения изменений
      Предназначен для установки обновлений и редактирования системного MagOS/base

Работа проста ;

1)  Формироание  настроенного  /root.
-  Войти в систему как root.  Настроить систему  как удобно или обновится.
-  Отредактировать  сохраняемое SAVE_BASE в   /memory/etc/MagOS ( по дефолту   55_save-base.xzm )
- Выключится

2)    Формироание  настроенного $HOME

-  Войти в систему как live  Настроить систему  как удобно.
-  Отредактировать, если нужно,   сохраняемое SAVE_HOME в   /memory/etc/MagOS ( по дефолту   SAVE_HOME=65_save-home.xzm )
- Выключится

Только надо помнить. Все ваши действия будут запомнены.    Может что то совсем необязательно  их запоминать.

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

Полезная инфа
Обзор и установка Linux Mageia 7 на компьютер с UEFI - https://info-comp.ru/install-mageia-7-uefi

3 (2017-07-29 20:19:54 отредактировано ingvaro)

Сетевые интерфейсы

Сетевые интерфейсы -  это проблемма.
Мне нравится в работе NetworkManager. Особенно он удобен при работе с модемом. Поэтому он у меня основной.
NetApplet никуда не удален. Просто не запускается при старте.
Тем более, что NetworkManager беспокойств не доставляет. Есть данная сеть -  запускает. Нет - то нет.

4

ingvaro⇓ пишет:

Для разблокировки записи надо удалить строчку из home-filtr :
etc/sysconfig/network-scripts

ingvaro, протестирую в выходные ещё, но я уже кое-что знаю про системы типа Mageia-Live(MagOS), а большинство новичков нет, для них лезть куда-то в конфиги это как в тёмный лес ночью без фонарика идти.
Например AlexL свои дистры затачивает под школьников - установил и поехал без всяких доработок, это потом они научатся в систему лазить и затачивать под себя. И режимы Home/Clean должны быть обязательно такими, какими я уже писал(изменения сохраняются/не сохраняются)

5 (2017-07-27 23:13:52 отредактировано ingvaro)

Ну я конечно не  AlexL. Уровень у меня поскромнее. Не программист системщик.

6 (2018-06-12 09:42:49 отредактировано ingvaro)

машинно-зависимые файлы

Т е это файлы, для данного компа.

Это /var/log  /var/lib   /etc/sysconfig/network-scripts
Некоторые другие файлы из /etk



Теперь самое интересное !!!

Если запустить  Mageia-Live (MagOS) в Grub2  без  ~/MagOS/modules/59-aufs_filtr.xzm
В строке ядра задаем   uird.noload=59
Получится полный аналг реальной системы, но модульный, но этот вариант запуска  лчше  использовать при установке на диск

7 (2017-07-28 15:22:18 отредактировано ingvaro)

Если начать с чего начали, то ручнаое редактирование в  файлах

/etc/sysconfig/MagOS
~/MagOS-Data/MagOS.ini

Это как у  AlexL

8

ingvaro⇓ пишет:

Ну я конечно не  AlexL. Уровень у меня поскромнее. Не программист системщик.

Зато стараешься сделать для людей и не занимаешься самолюбованием, может быть из молодых кто-то ещё заинтересуется этой темой.
Предложение, в меню сделать раздел - Инструменты: GParted, Flash-Imagewriter... вобщем набор утилит в одном месте для специфических работ, раздел мониторинг системы - чтобы не искать их по меню в разных местах

9

Интересная мысль !
Тогда будет  .Настройки  / .Инструменты

Только можно поподробнее со списком.
С меню конечно надо разбираться.

10 (2015-09-04 08:42:47 отредактировано ingvaro)

algri14⇓ пишет:

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

-  мониторинг системы   -  Уже есть раздел.  Это  Утилиты/ Наблюдение
    Просто может что то не там появляется. Это может быть  Надо соощить в теме и я переставлю.
    Может переименовать Наблюдение в Мониторинг  ?
-    GParted    -  В настойки/ оборудование. Вроде на месте.  Как никак настройка оборудования.
- Flash-Imagewriter.  Вот она не на месте.
   Смотрим  file:///usr/share/applications/flash-imagewriter.desktop  :
    Categories=System;
   Так по категориям она на месте, но по сути она просто iso- образ копирует на флэшку.

Тут думаю надо сделать в "Настойки"  подменю  "Флэш". Для всех работ с флэшкой

11 (2015-09-13 19:47:57 отредактировано ingvaro)

Режим SAVETOMODULE (сохранение сис-изменений в память)

Работает в КДЕ и  LXDE. Это, для меня, приятная неожиданность. Раньше в  LXDE не работал.
Но в  LXDE пока не рабатает контекстное меню мыши  для маговских утилит(оно для КДЕ). Что конечно неудобно.

12

ingvaro⇓ пишет:

Может переименовать Наблюдение в Мониторинг  ?

Да, так лучше. ingvaro, подожди немного, я ещё потестирую, это не так быстро делается, пока всё рассмотришь, сравнишь.
Сборка от AlexL хороша для школьников, много образовательного софта, образ весит 5,9Гб. А вот твою хотелось бы видеть в качестве инструмента для работы с системой и с уже предустановленными пакетами, а какими? - надо подумать

13 (2015-09-13 02:52:16 отредактировано betcher)

Приветствую, господа.
Ingvaro, прочитал ветку. Есть вопросы и предложения.
1. По сохранению базы rpm. Не буду поновой объяснять почему в магос сделано именно так. Просто предлагаю добавить к urpm2lzm и rpmdrake2lzm ключик, который заставит их сохранять базу. Допускаю, что это может быть полезным в определенных обстоятельствах. Так у нас будут единые скрипты.
2. Что не так с rpmdrake2lzm?
3. Что за секретный менеджер модулей у AlexL? Хоть скриншот глянуть smile
4. Что не допилено в нашем  модменеджере. Если есть вопросы по адаптации, спрашивайте. Лучше у нас, сюда редко захожу.
5. Почему rootcopy монтируется? По задумке копироваться должен. А вообще uird позволяет любой каталог и монтировать и копировать.
6. По м9 идея интересная. Может пригодится. Если склероз не изменяет в магос эти .wh файлы работают только если лежат в верхнем слое aufs. У вас не так?  Ну то есть мне пришлось бы их класть например в rootcopy.
7. Не понимаю проблем с машинно-зависимыми файлами.  Не используйте save2module для создания общих модулей и все. Это режим для конкретной машины, также как changes=xzm. Urpm2lzm создает универсальные модули, без "мусора". Грабли тоже возможны, но значительно реже.
8. Нужно стремиться к общим скриптам везде где возможно. Тогда наши нововведения будут доступны у Вас сразу и наоборот. Михаил, к примеру систему обновлений сделал по лету. Или syschanges тот же. Надо и наших гуру попинать, по поводу полного  перехода на uird smile
Пока вроде все. Больше всего интересует менеджер модулей от magicOS. Что за зверь такой?

14

6. В uird по умолчанию .wh во всех модулях. Специально это включал.
3. Нет там ничего smile все у нас взято. Просто названо через форк, вот люди и выделяют это как что-то от AlexL. smile

15 (2015-09-14 06:09:52 отредактировано ingvaro)

betcher⇓ пишет:

Просто предлагаю добавить к urpm2lzm и rpmdrake2lzm ключик, который заставит их сохранять базу

А что это за ключик ?
Просмотрел http://www.magos-linux.ru/dwiki/doku.php
Но ничего там не нашел

betcher⇓ пишет:

Что не так с rpmdrake2lzm?

Не совсем корректно работает с rpm-базой (для МагОС это не актально) - https://forum.mageia.org.ru/viewtopic.p … 081#p11081
Он работает как бы в unionfs. Т е  file:///etc/urpmi/urpmi.cfg он берет в первом модуле
МагОС  работает на aufs и drakrpm в системе берет его в последнем модуле
В MagOS+Mageia 4.1-alfa   я добил, но ....
МагОС от нее отказался. В последнем magos-linux-master.zip его уже нет ( по крайней мере я его там не нашел )
Когда освоил save2module, то  rpmdrake2lzm стал не нужен

betcher⇓ пишет:

Что за секретный менеджер модулей у AlexL? Хоть скриншот глянуть

Менеджер модулей у AlexL конечно не конкрент вашему. Он более аскетичен.

Когда он был совместим с МагОС я его использовал.
А сейчас свежей версии я не запускал.

betcher⇓ пишет:

Что не допилено в нашем  модменеджере. Если есть вопросы по адаптации, спрашивайте

В вашем модменеджере , при запуске его в Магее я, например ,  не могу пользоваться инсталятором
Так как он скачивает обновления с сайта МагОС, а для Магеи они не подходят.
В менеджер модулей у AlexL  можно запустить rpmdrake2lzm  или   ~/MagOS-Data/MagOS.ini

betcher⇓ пишет:

Почему rootcopy монтируется? По задумке копироваться должен

Он все нормально копируется, но если кликнть на флэшку  (где находится МагОС), то  там будет, почему то ,  содержание папки rootcopy.  Кто пользется  rootcopy. это хорошо. Ком он не нужен, то это, вероятно, раздражает.

betcher⇓ пишет:

По м9 идея интересная. Может пригодится. Если склероз не изменяет в магос эти .wh файлы работают только если лежат в верхнем слое aufs. У вас не так?  Ну то есть мне пришлось бы их класть например в rootcopy.

Если  в корне системы (вероятно это верхний слой aufs) найти файл, который надо удалить.
Удалить его.
То  в /memory/changes появится .wh.имя_файла
Именно этот .wh.имя_файла  если поместить его в rootcopy удалит из системы ненужный файл
Вначале пытался вручную создавать. Но они не работали


betcher⇓ пишет:

Не понимаю проблем с машинно-зависимыми файлами.  Не используйте save2module для создания общих модулей и все. Это режим для конкретной машины

Проблем с машинно-зависимыми файлами нет. Если m9 не будет, то в /var/log записи будут сохраняться
Для системы это не актуально.
Но save2module у меня сохраняет все. Если есть  m9  то должен быть чистый запуск
Если нет  m9, то это  запуск для конкретной машины

И  m9  появился как побочный  продукт создания системного модуля.
Сначала я редактировал саму флэшку (где установлена Магея), но этот вариант неудачен
Потом решил смонтировать флэшку и редактировать уже смонтированный образ
скрипт монтирования :

+ открыть спойлер

#!/bin/bash
#   http://habrahabr.ru/post/98742/

AUT=/run/media/root/Arhiv-mga5/Mag-OS/Mga5f         # папка монтирования
SRC=/run/media/root/Mga5                                              # флэшка

if [ -d $SRC-rw ]; then
      mkdir $AUT
      else
      mkdir $AUT $AUT-rw
      fi
mount -t aufs -o br:$AUT-rw=rw:$SRC=ro none  $AUT

$AUT-rw=rw  -   это и есть будущий m9
Там надо удалить лишнее
Только из системы этот модуль делать проблематично. Т к файл надо удалить из корня системы и не всякий файл система позволит удалить

betcher⇓ пишет:

Нужно стремиться к общим скриптам везде где возможно. Тогда наши нововведения будут доступны у Вас сразу и наоборот. Михаил, к примеру систему обновлений сделал по лету. Или syschanges тот же. Надо и наших гуру попинать, по поводу полного  перехода на uird

Сам МагОС , на мой взгляд,  можно разделить на две части :

-  Скрипты управления модулями   /usr/lib/magos/scripts
-  Скрипты настройки системы.

  Скрипты настройки системы могут быть разные.
  Скрипты управления модулями, это как бы основа МагОС. И она будет одинакова на всех системы
И  syschanges у меня то же работает

16

ingvaro⇓ пишет:

А что это за ключик ?
Просмотрел http://www.magos-linux.ru/dwiki/doku.php
Но ничего там не нашел

Естественно нет. Я и предлагаю переписать скрипты так, чтоб работали и по Вашему и по нашему алгоритму.

ingvaro⇓ пишет:

Не совсем корректно работает с rpm-базой (для МагОС это не актально) - https://forum.mageia.org.ru/viewtopic. … 081#p11081
Он работает как бы в unionfs. Т е  file:///etc/urpmi/urpmi.cfg он берет в первом модуле

Тут смотреть конечно надо. Может как и с urpm2lzm добавить ключик для работы c unionfs.

ingvaro⇓ пишет:

Менеджер модулей у AlexL конечно не конкрент вашему. Он более аскетичен.

Из Ваших скудных описаний сильно подозреваю, что это таки тоже мой менеджер модулей. Самый первый вариант который был в магос. Смущает только фраза про отсутствие исходников. Он написан на tcl/tk, а это такой же скриптовый язык как питон. Исходников не может не быть. Так что если нравится можно и его поправить под вашу сборку. Но новый поправить проще у него хоть конфиг есть smile

ingvaro⇓ пишет:

В менеджер модулей у AlexL  можно запустить rpmdrake2lzm  или   ~/MagOS-Data/MagOS.ini

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

ingvaro⇓ пишет:

В вашем модменеджере , при запуске его в Магее я, например ,  не могу пользоваться инсталятором

Инсталлятор не скачивает обновлений с сайта.  Он устанавливает тот магос, что загружен. Boot и MagOS-Data  берутся из архивов, так вот если этих архивов нет то тогда инсталлятор будет их качать. Все естественно лечится. Возможно достаточно будет добавить в архив со сборкой boot.tar.bz2 и MagOS-Data.tar.bz2

ingvaro⇓ пишет:

Он все нормально копируется, но если кликнть на флэшку  (где находится МагОС), то  там будет, почему то ,  содержание папки rootcopy.  Кто пользется  rootcopy. это хорошо. Ком он не нужен, то это, вероятно, раздражает

Страная штука smile


ingvaro⇓ пишет:

Сам МагОС , на мой взгляд,  можно разделить на две части :

-  Скрипты управления модулями   /usr/lib/magos/scripts
-  Скрипты настройки системы.

Да возможно стоит разделить.
Тогда скорее так:
-  magos-patches (часть которая привязана к uird и только)
-  magos-ext          (часть привязанная к конкретной реализации MagOS-Rosa)
Но при таком раскладе rpmdrak2lzm, urpm2lzm, modmnger, хоткеи, скрипты для файловых менеджеро и проч. попадут во вторую группу. Их нельзя сделать универсально.
Надо думать smile

17 (2017-07-29 18:35:42 отредактировано ingvaro)

betcher⇓ пишет:

Я и предлагаю переписать скрипты так, чтоб работали и по Вашему и по нашему алгоритму.

В мире нет ничего положительного и отрицательного.  Вот как пояснял ситуацию с rpm - базой neobit

+ открыть спойлер

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


Трудно не согласиться. У меня действительно, при сохранении rpm - базы,   в ~/MagOS/base  даже лучше не переставлять модули.
Просто я привык к rpm-базе. И кто то должен делать  обновления. В MagOS там все таки коллектив и, похоже обязанности разделены.
В Магее как то я один и похоже, что идея модульного дистрибутива, на этом форуме,  особо никого не интересует.
И как делать модуль с обновлениями без rpm-базы?  А если объем обновлений 500 Мб ?

18 (2015-09-14 08:53:55 отредактировано ingvaro)

betcher⇓ пишет:

Я и предлагаю переписать скрипты так, чтоб работали и по Вашему и по нашему алгоритму.

Я предлагал, на маговском сайте  вариант rpmdrake2lzm с сохранением rpm-базы в отдельный модуль. http://www.magos-linux.ru/index.php?opt … =55#p15482
Но идея не прижилась.
Но основная проблема при сохранении rpm-базы, что все скрипты создающие  модули надо как то синхронизировать
Т е надо сначала принять алгоритм работы с rpm-базой, а потом уже все скрипты переписать., что бы все писали в одно место и не было ручной правки.
Т к когда кто то в первый раз запустит Магос, то он, скорее всего, ничего о модулях знать не будет и как и куда писать то же
У меня например мой save2module :

-  в ~/MagOS/base запись модуля,  с изменениями системы,   с rpm-базой, т к там уже есть сис-модуль.. Это обновления и установка программ
-  в  ~/MagOS/modules   все другие изменения системы

Сейчас хочу сделать, что бы rpm-база удалялась из создаваемых модулей и записывалась в последнем модуле  ~/MagOS/base
Как я понимаю, это самую чуточку подправить обычный МагОС.
Тогда модули будут похожи на магеевские и rpm-база под рукой

19 (2015-09-14 08:57:25 отредактировано ingvaro)

betcher⇓ пишет:

Да возможно стоит разделить.
Тогда скорее так:
-  magos-patches (часть которая привязана к uird и только)
-  magos-ext          (часть привязанная к конкретной реализации MagOS-Rosa)
Но при таком раскладе rpmdrak2lzm, urpm2lzm, modmnger, хоткеи, скрипты для файловых менеджеро и проч. попадут во вторую группу. Их нельзя сделать универсально.
Надо думать

Тут напрашивается такое разделение при запуске

1) Обычнай  пользователь  .   Это посмотреть видео,фильм  и поиграть в интернет-игры и здесь save2module незаменим. Перезагрузился и все
2) Администратор.  Это полный Магос со всеми возможностями. Т е когда пользователь освоился на первом уровне и захотел узнать систему поглубже.
    Не захотел ?  Ну это его право выбора
3)  Сервер.    Планирую, у себя, модуль MDS (Mandriva Directory server). Ну а в МагОС есть свой сервер.

Как  разделить это надо думать.
Пока у меня в Администратор есть запуск rootcopy, а в Обычнай  пользователь нет
Запустил без rootcopy  и получился MagicOS

20

ingvaro⇓ пишет:

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

Да, я помню. Но делать нужно не ломая. Если бы Вы предложили такой вариант:
rpmdrak2lzm  (все работает как привычно пользователям магос)
rpmdrak2lzm --rpmdbset (работает так как хотите Вы)
Думаю такой вариант возражений бы не имел. Именно это я и предлагаю сделать сейчас.

По поводу сохранения базы рпм могу еще вариант предложить. Немного в сторону ото всех этих сэйвтумодулей.
Может помните тему на нашем сайте по поводу сохранения /var/tmp, где kde хранит свои кэши.  Так вот самым удобным для меня вариантом оказалось писать этот каталог сразу в папку на диск. Делается это следующим образом. Создаете модуль в котором лежит ссылка /var/tmp, которая указывает на каталог /memory/data/from/1/vartmp. И все. Может получится сделать по аналогии. Это не рецепт, это тема для размышлений smile

21 (2015-09-14 16:28:59 отредактировано ingvaro)

Я у себя уже сделал подобный эксперимент. Папка /boot теперь  ссылка на /memory/data/from/0/boot
Это позволило сократить операции с boot
Установил новое ядро и  файлы прекрасно записались в  /memory/data/from/0/boot
Удалил  старый 3.19.8-desktop586 (через savetomodule) и удалился  vmlinuz-3.19.8-desktop586-3.mga5 и пр.
Ничего не надо никуда переносить.
Действительно можно и с /var/lib/rpm так же поступить

22 (2017-07-29 18:36:31 отредактировано ingvaro)

rpmdrakexzm


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

    mount -t aufs -o shwh,br:$mount_br wiz_fly $root_br

где shwh позволяет при монтировании учитывать .wh.имя_файла ,  которые и удаляют файл
Теперь,при удалении пакета будет сформирован  .wh.имя_файла . И данных файлов в системе не будет
В aufs ничего не удаляется.
Если удалить  .wh.имя_файла из модуля, то файл  имя_файла появится снова

стр 101

Исключил удаление  рпм-базы
При работе rpmdrake2xzm вместо файлов рпм-базы формируются скрытые файлы
.wh.__db.000   .wh.__db.001   .wh.__db.002   .wh.__db.003  они удаляют старую базу и новая рпм-база  формируется при инициализации системы.
Если этих скрытых файлов нет, то рпм-база формируется при первом запуске drakrpm. Или вернее при первом обращении к  рпм-базе.
Разница очевидна.

Если  рпм-база не нужна то восстановить строку в исходном виде ::
    rm -rf $mod_br/tmp $mod_br/var/lib/urpmi $mod_br/var/lib/rpm $mod_br/var/cache/urpmi $mod_br/.wh*

При работе в Магос и Магикос возможны  проблеммы с  rpmdrake2lzm
Т е у меня он заработал, когда системный модуль находится под номером 00-xxx
Проблемма , что file:///etc/urpmi/urpmi.cfg в  rpmdrakexzm считывается из первого файла, а  системный rpmdrake из последнего.
Правда проверял я это еще до использования UIRD
Может на МагОС сейчас все работает.

23

kvv-vp⇓ пишет:

Прочитал весь топик... Запутался.

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

kvv-vp⇓ пишет:

На вашей сборке что-то подобное росовской freeze можно сотворить?

freeze, как я понял, это резервирование системы http://forum.rosalab.ru/viewtopic.php?f … eze#p51309

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

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

Основная идея модульного дистрибутива - это сборка системы не из пакетов, а из модулей.  В МагОС , например, периодически выпускаются обновления  и обновленные сборки.
Моя сборка (https://forum.mageia.org.ru/viewtopic.p … 958#p15958) отличается от МагОС  сохранением рпм-базы (/var/lib/rpm) при создании модуля с изменениями системы
Т к рпм-база в модуля с изменениями может различаться и на других компах созданный модуль может не запуститься.
Основная задача моей сборки  -  это отлдчик программ, для Магеи
Сохранив рпм-базу я потерял в модульности, но зато приобрел качество тестирования различных программ и приложений на Магее. Допустим есть проблемное приложение и теперь без опаски можно экспериментировать
И работа на ней теперь ничем не отличается от обычной Магеи
И , поэтому, в моей сборке обновления можно уже получать с реопозитариев Магеи

Ели что то опять запутанно написал, то не теряйтесь. Пишите

Спасибо сказали: algri141

24 (2017-07-29 18:37:22 отредактировано ingvaro)

сис-модль  у меня свой.
- устанавливаю Магею на флэшку
- загружаюсь с флэшки
- устанавливаю обновления, нужные  пакеты. Все в привычной магеевской среде
- выхожу из флэшечной Магеи
- запускаю другую Магею
- по принципу Mageia 5 LiveDVD KDE редактирую машинно-зависимые файлы
- пакую в формат xzm
Я пытался использовать сис-модуль от Mageia 5 LiveDVD KDE, но там надо делать правки и я не знаю все ли я сделал правильно.

В принципе в Mageia 5 LiveDVD надо удалить всего то /etc/fstab, но это согласитесь принципиальный файл
А свой сис-модль - это надежнее. Да и сделать его несложно

Выделяя основное то у меня :

- свой вариант магеевского  сис-модуля
- маговские скрипты упраления модулями (/usr/lib/magos/scripts )
- режим savetomodul

Вот и вся сборка.

25

ingvaro, не надо мне про модульность. Я вот это хочу понять:

ingvaro⇓ пишет:

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

Задача: 1.подключить репозит., 2.обновиться, 3.установить opera и поработать в ней, 4. вернутся в конец т.2 не удаляя opera. Как?