На ядре 5.1.3-desktop-4.mga7 загрузчик uird сконфигурировался ок !
Сборка UIRD в магее
Правильно понимаю, что все нормально и чинить ни чего ненужно?
Ядро 5.1.3-desktop-5.mga7
Да ! На свежей сборке и последнем uird все заработало, но все же сделал правки 
В file:///usr/share/uird/dracut/dracut.sh :
- стр 754
[[ $tmpdir ]] || tmpdir=/var
Это переместил папку сборки в tmpdir=/var (было /var/tmp)
2) Т к dracut находится у меня в /usr/share/uird/dracut
То в /usr/share/uird/dracut/dracut.sh заменил пути
/usr/lib/dracut на /usr/share/uird/dracut
Вообще то пути правильнее задать в команде ./configure
Но не знаю какие опции задать.
Хотя на сбойных ядрах это не помогло, но правки вполне логичные
Проблема есть
При загрузке с UIRD в AUFS Магеи 7.1 пакет shadow-utils-4.6-1.mga7.x86_64.rpm не устанавливается
Но если загрузить в LiveDVD от Магеи то устанавливается
Т е к Магее не обратиться
Причем если загрузить от UIRD LiveDVD от Магеи пакет shadow-utils-4.6-1.mga7.x86_64.rpm не устанавливается
С пакетом прежней версии shadow-utils-4.4-1.2.mga6.x86_64.rpm все ок
Проверка :
Удаляю пакет shadow-utils
/ # rpm --nodeps -e shadow-utils
Пробую установить его
/ # rpm -ivh shadow-utils-4.6-1.mga7.x86_64.rpm
Verifying… ################################# [100%]
Подготовка… ################################# [100%]
Обновление / установка…
1:shadow-utils-2:4.6-1.mga7 ################################# [100%]
ошибка: распаковка архива не удалась на файле /usr/bin/newgidmap;5d4946f0: cpio: cap_set_file не удалось - Нет такого файла или каталога
ошибка: shadow-utils-2:4.6-1.mga7.x86_64: установить не удалось
Отличия пакетов (из shadow-utils.spec)
shadow-utils-4.4-1.2.mga6.x86_64.rpm
%files -f shadow.lang
%doc doc/HOWTO NEWS
%doc doc/WISHLIST doc/README.platforms
%attr(0640,root,shadow) %config(noreplace) %{_sysconfdir}/login.defs
%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/default/useradd
%{_bindir}/sg
%attr(2711,root,shadow) %{_bindir}/chage
%attr(4711,root,root) %{_bindir}/gpasswd
%attr(4711,root,root) %{_bindir}/newgidmap
%attr(4711,root,root) %{_bindir}/newgrp
%attr(4711,root,root) %{_bindir}/newuidmap
shadow-utils-4.6-1.mga7.x86_64.rpm
%files -f shadow.lang
%doc doc/HOWTO NEWS
%doc doc/WISHLIST doc/README.platforms
%attr(0640,root,shadow) %config(noreplace) %{_sysconfdir}/login.defs
%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/default/useradd
%{_bindir}/sg
%attr(2711,root,shadow) %{_bindir}/chage
%attr(4711,root,root) %{_bindir}/gpasswd
%attr(0711,root,root) %caps(cap_setgid=ep) %{_bindir}/newgidmap
%attr(4711,root,root) %{_bindir}/newgrp
%attr(0711,root,root) %caps(cap_setuid=ep) %{_bindir}/newuidmap
Или отличия для newgidmap
%attr(4711,root,root) %{_bindir}/newgidmap
%attr(0711,root,root) %caps(cap_setgid=ep) %{_bindir}/newgidmap
Т е отличаются %caps(cap_setgid=ep) это :
use caps instead of setuid on newuidmap/newgidmap
Что бы это значило ?
Не знаю даже. Там, кстати, еще права разные в %attr
Это в переводе
используйте заглавные буквы вместо setuid на newuidmap / newgidmap
И вроде ошибка никак не связана с заглавными буквами
Если бы права доступа были виновны, то и сообщение было бы другое
Сам newgidmap то же что на старой версии
Пока делаю системный модуль на Магее а все остальное дособирываю.
Чистая пакетная сборка не собирается
Конечно можно либо использовать старый shadow-utils или его перекомпилировать
Наверное. Цифра 4 впереди это SUID, выполнять с правами владельца.
Таблица разделов на флэшке у меня уже давно gpt и сегодня сделал флэшку в msdos(bios) разметке.
Но ничего не изменилось и баг остался.
Пробовал для верности на LiveDVD от Магеи запустить сборку дистра но не получилось.
Видимо пакетов не хватает
Кроме того еще не устанавливается пакеты perl, gnome-keyring а может и еще найдется.
Повторюсь, что данную проблему я обхожу. Использую сис-модуль на базе штатной установки Магеи в минимальной конфигурации где данные пакеты уже установлены.
Вроде как aufs виновата
В федоре смотрел shadow-utils и он аналогичный с Магеей
В Росе обновят shadow-utils и в МагОС эта же проблема будет.
Пересобрал я shadow-utils-4.6-1.mga7.x86_64.rpm
Командой
rpmrebuild -e shadow-utils
При этом удалив из спека %caps(cap_setgid=ep)
%attr(0711,root,root) %{_bindir}/newgidmap
%attr(4711,root,root) %{_bindir}/newgrp
%attr(0711,root,root) %{_bindir}/newuidmap
Все !
Пакетная сборка пошла !!!
Но все равно остался вопрос. Что такое %caps(cap_setgid=ep)
И почему shadow-utils устанавливается в LiveDVD от Магеи
И почему пакет не устанавливается в aufs, на которой собирается MagOS
rpmdrake2xzm - https://cloud.mail.ru/public/3kv7/2UkX7bbra
Запустил на Магее
Изменения
- Стр 67
for a in
ls -dr $mod_path/??-*; do
Это берется rpm-база с последнего модуля
Иначе с первого
-
Теперь /var/lib/rpm/Packages будут запоминаться в модуле записи
Для этого перенес со своего chrootdisk clear_rpm - стр 39 -
Прежний вариант rpmdrake2xzm не записывал модуль на LXQt
Глючит mdialog
В магее отсутствует xuserrun
Закоментировал со стр 38 в mdialog
start mdialog with xuserrun
if [ “$(id -un)” = “root” ] ;then
xuserrun $0 “$@” ; exit
fi
В итоге kdialog на плазме работает а zenity на LXQt нет
Заменил mdialog на cXdialog в стр 107
Теперь везде все работает
- Ввел переменную
Это куда будет писаться модуль
SELECT=/memory/layer-base/0
Меня этот адрес устраивает. В моей сборке есть возможность без особых усилий запускать 4 различные сборки и как раз при различных запусках модуль будет писаться куда надо
А имена папок MagOS и MagOS-Data в корне флэшки в моей сборке пришлось изменить
на Linux и LX-Data
Т к нельзя было запустить вашу сборку из MagOS/MagOS
Уже протестировал. Обновил Магею и МагОС из rpmdrake2xzm
- Заменил gactivate на activate
[ $? = 0 ] && activate “$mod_name”
gactivate на plasma работает на LXQt нет (нет сообщения о выполнении операции)
Вроде все. Возможно что по мелочи
А так rpmdrake2xzm понравилась тем что если не установить пакета то модуля и не создается
И запускается от обычного пользователя. Мой chrootdisk только от root
Теперь это надеюсь просто аналог штатного rpmdrake2xzm, но только с возможностью создания модуля
PS
Не понял зачем создается
mod_file="$URPMITMP/rpmdrake2xzm.img"
В своем chrootdisk я обхожусь без pmdrake2xzm.img
Но вроде не мешает
Это скрипт найденный на гитхабе и слегка модифицированный. Должен быть в 88-magos.xzm
Не помню, надо смортреть. может просто ограничивает размер папки для установки пакетов размером образа.
Наверное Вам лучше разобраться с mdialog и xuserrun. В наших скриптах много где используется. Помимо запуска zenity или kdialog зависимо от среды mdialog решает и еще одну проблему. Сообщения от рута в kdialog отправленные udev или например cron не будут работать, а с mdilaog - работают.
xuserrun заработал но модуль в LXQt в zenity не создается
пишет
chmod: невозможно получить доступ к ‘PREFIX=NONKDE PREFIX=NONKDE 1 /memory/data/mounts/0/Linux/Mageia/optional/555.xzm’: Нет такого файла
Т е лишняя инфа в zenity при установке имени файла
Вроде то же самое и в Росе при запуске вашей сборки
И kdialog нормально работает на LXQt есть сообщение о выполнении операции gactivate
Задал строчкой
mod_name=$(kdialog --getsavefilename $file_save/$xzm_name.$MODULEFORMAT)
zenity похоже в Магее или старый (вроде мало опций) или наоборот самый новый
Осталось mdialog заставить в LXQt запускать kdialog
Здесь с путем все ок. Допустим
mod_name=/memory/layer-base/0/optional/66-XX.xzm
У zenity
mod_name=PREFIX=NONKDE PREFIX=NONKDE 1 /memory/data/mounts/0/Linux/Mageia/optional/555.xzm
Да, можно так починить.
rpmdrake2xzm
Обновленный вариант - https://cloud.mail.ru/public/2kvi/5zsmpQWHh
- Починил zenity на LXQt стр 109 - Это оказалось проще
mod_name=$(echo $mod_name | sed s/[.]$MODULEFORMAT$// | awk ‘{ print $2 }’)
Запуск rpmdrake2xzm только от user. Запуск от root оказалось запрещен в mdialog
В Магее работает. Даже как то скучно.
В МагОС обновился и после перезагрузки не смог открыть rpm-базу в rpmdrake
Но в своем chrootdisk (запуск от root) я МагОС обновил и открыл в rpmdrake rpm-базу
Вероятно запуск rpmdrake2xzm в Росе надо делать от root
Но учитывая что в Магее rpmdrake2xzm от user работает то больше уж ничего делать не буду
Непонятно что делать
- Запуск в chrootdisk rpmdrake в МагОС получился - /usr/bin/rpmdrake
Но в rpmdrake2xzm есть другой запуск - rpmdrake - /usr/sbin/rpmdrake
В rpmdrake2xzm и тот и другой работают
В chrootdisk запустилдся только - /usr/bin/rpmdrake
То же непонятки. Как в системе может быть два варианта запуска приложения ?
Да запросто. Например из sbin запускается сразу, а из usr/bin перезапускает тот что в sbin только с kdesu/beesu. Просто предположение
Если закоментировать xuserrun то mdialog будет запускать kdialog и zenity при входе в систему как root
Похоже что xuserrun как раз и запрещает работу при входе в систему как root
Учитывая что сборку дистра и все настройки системы я делаю при входе в систему как root
То для меня это ограничение. Долгое время использовал только вход от root.
Если я закоментирую то будут ли какие нибудь неприятности ?
Если это лучше не делать то тогда просто перейду на kdialog
Может просто xuserrun не работает. Попробуйте под рутом xuserrun whoami
Работает
mageia ~ # xuserrun whoami
root
mageia ~ #
Видимо виноват mdialog
f [ “$(id -un)” = “root” ] ;then
xuserrun $0 “$@” ; exit
fi
Закоментировать эту блокировку и все работает под root
не работает, xuserrun whoami должно вернуть имя текущего юзера пользователя иксов. Вы ж не под рутом иксы запускаете.