Автор Тема: Live-загрузка и установка с переносного жесткого диска с NTFS  (Прочитано 108628 раз)

Оффлайн Mr.Madguy

  • Участник
  • *
  • Сообщений: 249
Что то у меня ничего не получается с APTCONF.

Генерирую конфиги на ходу вот таким скриптом:
#Это просто пример - на самом деле все сложнее

echo 'Dir::Etc::SourceParts "/var/empty";' > ./apt.conf
echo 'Dir::Etc::parts "/var/empty";' >> ./apt.conf
echo 'Dir::Etc::main "/dev/null";' >> ./apt.conf
echo 'Dir::Etc::SourceList "/tmp/live/mkimage-profiles/source.list";' >> ./apt.conf
echo 'Dir::State::lists "/tmp/live/mkimage-profiles/lists/";' >> ./apt.conf
echo 'Dir::Cache "/tmp/live/mkimage-profiles/cache/";' >> ./apt.conf

echo "rpm [p$build_vers] http://mirror.yandex.ru/altlinux p$build_vers/branch/i586 classic" > ./source.list
echo "rpm [p$build_vers] http://mirror.yandex.ru/altlinux p$build_vers/branch/noarch classic" >> ./source.list

Потом запускаю сборку вот так:
make IMAGEDIR=$dest_dir ARCH=$config_distr APTCONF=\tmp\live\mkimage-profiles\apt.conf alt-p$build_vers-$build_distr.iso

Если запускаю для той же разрядности, что и установленная система - все работает. Если запускаю для 32-х бит - вылетает ошибка, что не может скачать пакет. Куда копать? Что не так?
« Последнее редактирование: 26.09.2019 16:27:14 от Mr.Madguy »

Оффлайн klark973

  • Участник
  • *
  • Сообщений: 662
  • Неспящий саппорт
http://mirror.yandex.ru/altlinux
Не локальная сборка в m-p была поломана, баг висит. Все используют локальное зеркало для этих целей.

APTCONF=\tmp\live\mkimage-profiles\apt.conf
А это что за конструкция с экранированием? Чай тут не винда)

Спойлер
$ cd ~/.hasher/

$ cat config
def_target="x86_64"
workdir="/tmp/.private/klark"
packager="`rpm --eval %packager`"
apt_config="/home/klark/.hasher/apt-sisyphus-x86_64.conf"
def_repo="/home/klark/hasher-repo"
known_mountpoints=/proc,/dev/pts
mount=/proc,/dev/pts
lazy_cleanup=1

$ cat apt-sisyphus-x86_64.conf
APT::Cache-Limit 100663296;
Dir::Etc::Main "/dev/null";
Dir::Etc::Parts "/var/empty";
Dir::Etc::SourceParts "/var/empty";
Dir::Etc::Preferences "/dev/null";
Dir::Etc::PreferencesParts "/var/empty";
Dir::Etc::SourceList "/home/klark/.hasher/apt-sisyphus-x86_64.list";

$ cat apt-sisyphus-x86_64.list
rpm file:/ALT/Sisyphus x86_64 classic
rpm file:/ALT/Sisyphus noarch classic

$ cat apt-p8-i586.conf
Dir::Etc::Main "/dev/null";
Dir::Etc::Parts "/var/empty";
Dir::Etc::SourceParts "/var/empty";
Dir::Etc::Preferences "/dev/null";
Dir::Etc::PreferencesParts "/var/empty";
Dir::Etc::SourceList "/home/klark/.hasher/apt-p8-i586.list";

$ cat apt-p8-i586.list
rpm file:/ALT/p8 i586 classic
rpm file:/ALT/p8 noarch classic
To moan or to solve -- that is the question!

Оффлайн Mr.Madguy

  • Участник
  • *
  • Сообщений: 249
APTCONF=\tmp\live\mkimage-profiles\apt.conf
А это что за конструкция с экранированием? Чай тут не винда)
А вот это я не заметил. Сейчас у меня нет с собой этого скрипта. Завтра проверю, это я при копировании сюда что то намутил или там действительно слэши не в ту сторону и в этом и кроется косяк.

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 5 182
  • antohami@
Не локальная сборка в m-p была поломана, баг висит. Все используют локальное зеркало для этих целей.

Что-то я не в курсе. Собираю без локального зеркала у себя на буке.

Оффлайн Mr.Madguy

  • Участник
  • *
  • Сообщений: 249
Все заработало. Спасибо. Просто надоело уже вручную все конфигурировать каждый раз. Тем более, что для пересборки Debian я написал скрипт, который все автоматизирует. А то там сборка дистрибутива намного медленнее и жрет больше памяти. Хочется просто ткнуть скрипт и пойти по своим делам.

Если кому интересно, вот мой скрипт. До конца еще не протестил. Может еще где какие косяки есть. Сейчас займусь этим. Если что то неправильно или неоптимально сделано, то сильно не бейте. Это мой второй bash-скрипт в жизни. Первый был на сборку всех дистрибутивов Debian.

Первый скрипт нужно запустить под рутом из папки (не из корня!) с виндового раздела и после этого релогнуться. Тут следует поменять по своему желанию название терминала и размер свопа.

#!/bin/sh

swap_size=8
ramdisk_size=24

mate-terminal -e htop &

if ! [ -f ../swapfile ]
then
    dd if=/dev/zero of=../swapfile bs=$(( ($swap_size+$ramdisk_size)*1024 )) count=1048576
    mkswap ../swapfile
fi

swapon ../swapfile

sed "s/nosuid\t/size=${ramdisk_size}g\t/g" /etc/fstab > ./temp.cfg

cp -f ./temp.cfg /etc/fstab

rm ./temp.cfg

mount -o remount /tmp

apt-get update

apt-get install -y mkimage mkimage-preinstall hasher gear

hasher-useradd altlinux

echo "allowed_mountpoints=/proc" >> /etc/hasher-priv/system

Второй скрипт запускается от обычного пользователя. Тут можно поменять dest_type на network и в src_dir указать путь к этой шаре, а в src_pwd пароль к ней. А так же можно поменять список дистрибутивов, который нужен. Я знаю, что в p9 32bit нет gnome3 и kde5. Может когда появятся.

#!/bin/sh

dists="p8 p9"
arches="i586 i686 amd64"
flavours="lxde lxqt xfce gnome mate cinnamon kde"

base_dir=$PWD
src_dir=//192.168.0.1/linux
src_pwd=
dest_type=directory

mate-terminal -e htop &

case $dest_type in
directory)
dest_dir=$base_dir/../export
if ! [ -d $dest_dir ]
then
mkdir $dest_dir
fi
;;
network)
dest_dir=/mnt
sudo mount -t cifs $src_dir $dest_dir -o rw,uid=500,gid=500,username=User,password=$src_pwd
;;
esac

cd /tmp/

mkdir live

cd live

for build_vers in $dists
do
case $build_vers in
p9)
git clone git://git.altlinux.org/people/mike/packages/mkimage-profiles.git
;;
*)
git clone -b $build_vers git://git.altlinux.org/people/mike/packages/mkimage-profiles.git
;;
esac

cd mkimage-profiles

echo "ntfs.ko" >> ./sub.in/stage1/modules

sed 's/$(IMAGE_NAME)$(IMAGE_VERSION)-$(STATUS)$(DATE)-$(ARCH).$(IMAGE_TYPE)/$(config_file_name)/g' ./image.in/Makefile > ./temp.cfg

cp -f ./temp.cfg ./image.in/Makefile

rm ./temp.cfg

sed 's/std-def/$(config_arch)/g;s/un-def/$(config_arch_undef)/g' ./conf.d/regular.mk > ./temp.cfg

cp -f ./temp.cfg ./conf.d/regular.mk

rm ./temp.cfg

echo 'Dir::Etc::SourceParts "/var/empty";' > ./apt.conf
echo 'Dir::Etc::parts "/var/empty";' >> ./apt.conf
echo 'Dir::Etc::main "/dev/null";' >> ./apt.conf
echo 'Dir::Etc::SourceList "/tmp/live/mkimage-profiles/source.list";' >> ./apt.conf

for build_arch in $arches
do
case $build_arch in
i586)
config_distr=i586
config_arch=std-def
config_arch_undef=un-def
echo "rpm [$build_vers] http://mirror.yandex.ru/altlinux $build_vers/branch/i586 classic" > ./source.list
echo "rpm [$build_vers] http://mirror.yandex.ru/altlinux $build_vers/branch/noarch classic" >> ./source.list
;;
i686)
config_distr=i586
config_arch=std-pae
config_arch_undef=std-pae
echo "rpm [$build_vers] http://mirror.yandex.ru/altlinux $build_vers/branch/i586 classic" > ./source.list
echo "rpm [$build_vers] http://mirror.yandex.ru/altlinux $build_vers/branch/noarch classic" >> ./source.list
;;
amd64)
config_distr=x86_64
config_arch=std-def
config_arch_undef=un-def
echo "rpm [$build_vers] http://mirror.yandex.ru/altlinux $build_vers/branch/x86_64 classic" > ./source.list
echo "rpm [$build_vers] http://mirror.yandex.ru/altlinux $build_vers/branch/x86_64-i586 classic" >> ./source.list
echo "rpm [$build_vers] http://mirror.yandex.ru/altlinux $build_vers/branch/noarch classic" >> ./source.list
;;
esac
for build_distr in $flavours
do
case $build_distr in
gnome)
distr_name=gnome3
;;
kde)
distr_name=kde5
;;
*)
distr_name=$build_distr
;;
esac
config_file_name=alt-$build_vers-$build_arch-$build_distr.iso
if [ -f $dest_dir/$config_file_name ]
then       
continue   
fi
make config_arch=$config_arch config_arch_undef=$config_arch_undef config_file_name=$config_file_name IMAGEDIR=$dest_dir ARCH=$config_distr APTCONF=/tmp/live/mkimage-profiles/apt.conf alt-$build_vers-$distr_name.iso
make clean
done
done

cd ..

rm -rf mkimage-profiles
done

cd ..

rm -rf live

Для полного счастья не хватает еще пары вещей:
1) Сразу переместить файлы live, vmlinuz и full.cz в нужную мне папку, чтобы потом с этим не парится.
2) Как то разобраться с ramdisk_size, а то задолбало его копировать. Может вообще не стоит его указывать и все и так будет работать?
3) Добавить поддержку ntfs-3g в stage1. Нативная поддержка NTFS что то немного притормаживает.
« Последнее редактирование: 30.09.2019 09:30:54 от Mr.Madguy »

Оффлайн klark973

  • Участник
  • *
  • Сообщений: 662
  • Неспящий саппорт
Что-то я не в курсе. Собираю без локального зеркала у себя на буке.
Во как! Помню, было поломано. Но проявлялось как-то странно, не во всех случаях.

Как то разобраться с ramdisk_size, а то задолбало его копировать. Может вообще не стоит его указывать и все и так будет работать?
Надо вычислять по формуле. Если не ошибаюсь, это размер сквоша в килобайтах, возможно, округлённый в большую сторону. Если точнее, сквош туда должен влезть целиком.

Добавить поддержку ntfs-3g в stage1. Нативная поддержка NTFS что то немного притормаживает.
Теперь-то уж вы точно знаете, как это делать через m-p. Но придётся не только докладывать модуль вместе /bin/ntfs-3g и всем, что требуется для работы fuse, но ещё и пропагатор таки пропатчить. Использовать в данном сценарии оба модуля, вероятно, не стоит.
To moan or to solve -- that is the question!

Оффлайн Mr.Madguy

  • Участник
  • *
  • Сообщений: 249
Надо вычислять по формуле. Если не ошибаюсь, это размер сквоша в килобайтах, возможно, округлённый в большую сторону. Если точнее, сквош туда должен влезть целиком.
Да это понятно. Вопрос в том, что я должен его переносить в свои конфиги syslinux. А это муторно. Хотелось бы как то автоматизировать, но это будет сложно сделать. И вроде мне где то в документации попадалась фраза, что если его просто не указывать, то как раз и возьмется размер squashfs. Или что то в этом роде. Теперь не могу ее найти.
Теперь-то уж вы точно знаете, как это делать через m-p. Но придётся не только докладывать модуль вместе /bin/ntfs-3g и всем, что требуется для работы fuse, но ещё и пропагатор таки пропатчить. Использовать в данном сценарии оба модуля, вероятно, не стоит.
Да я знаю. Надо только разобраться, что нужно пихать в stage1. На ум пока приходят только fuse.ko и /bin/ntfs-3g. Есть еще libntfs-3g.so, но я не уверен, нужен ли он. Может еще как то надо зарегистрировать ntfs-3g в системе. В общем наверное нужно поковырять скрипты установки fuse и ntfs-3g. В принципе тут вопрос только в том, будет ли оно работать через mount -t ntfs-3g, вызванный через C, или придется вызывать /bin/ntfs-3g. И может и покатит использовать оба модуля. Поставить ntfs-3g перед ntfs. По идее должно работать как и с другими файловыми системами. Не грузится - пробуем следующую. Так и дойдем до ntfs, если ntfs-3g не сработает.

П.С. Обновил скрипты, чтобы конфигурация была более удобной - вынес все нужные переменные в начало.

П.П.С. Хмммм.
« Последнее редактирование: 30.09.2019 10:46:03 от Mr.Madguy »

Оффлайн Mr.Madguy

  • Участник
  • *
  • Сообщений: 249
Как это ни странно, Gnome p9 32bit заработал. KDE собирается, но не запускается. В тот момент, когда появляется курсор, он постоянно сменяется с просто черного на серый и обратно, плюс все время возвращается в центр экрана. Как будто оболочка пытается запустится, но все время падает.

Оффлайн gvy

  • alt linux team
  • ***
  • Сообщений: 1 010
    • Альт на Эльбрусе
Так у меня 16Гб, но возможно в 32-х битном режиме не все доступно.
Ну это мягко говоря... где больше гига памяти -- лучше сразу применять 64-битные системы, если верить Торвальдсу.
--
Michael Shigorin | ALT Linux Team | ANNA-News | Сделано у нас | altlinux.org/эльбрус

Оффлайн gvy

  • alt linux team
  • ***
  • Сообщений: 1 010
    • Альт на Эльбрусе
Не локальная сборка в m-p была поломана, баг висит. Все используют локальное зеркало для этих целей.
Единственное место, где m-p есть дело до sources.list -- это `git grep "requested arch"`.  Всё остальное интересует apt (который дёргает hsh, который дёргает mkimage).
--
Michael Shigorin | ALT Linux Team | ANNA-News | Сделано у нас | altlinux.org/эльбрус

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 5 182
  • antohami@
где больше гига памяти -- лучше сразу применять 64-битные системы, если верить Торвальдсу.

Не, только если больше 2 ГБ :-) Вот 4 ГБ для 64 бит уже нормально (Raspberry 4, Jetson Nano).

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Так у меня 16Гб, но возможно в 32-х битном режиме не все доступно.
Ну это мягко говоря... где больше гига памяти -- лучше сразу применять 64-битные системы, если верить Торвальдсу.

:-) Михаил, это про это?
And dammit, in this age and date when almost everybody has a gigabyte of RAM in any new machine, anybody who still thinks that “not that many people need 64-bits” is simply not aware of what he’s speaking of.

Теория Торвальдса разбивается об жестокую реальность практики:
p8-sysv-xfce-i586 проходил все тесты реальной эксплуатацией на NX6110. При уже тогда существовавшем Lenovo G50-80.
При заполнении физической памяти и своп, по I/O система уйдёт в такой жестокий даун, что вывести её оттуда, можно будет только через poweroff 4 sec. И пытаться покилить процесс в такой ситуации почти нереально.
Поэтому:
Для системы на p8/branch 32 bit с нересурсоёмким DE, для минимального комфорта, 2 Gb физической памяти. Что однако не исключает периодический контроль расхода физической памяти. Такова реальность.
Теоретически, систему на p8 можно удержать в пределах 1Gb физической памяти. Но почти всегда, это потеря функционала, хорошее знание и контроль ресурсоёмкости приложений. Постоянный контроль расхода памяти или использование earlyoom. Однако непонимание принципов работы earlyoom, может привести к потере несохранённых данных.

:-) Мне это образно представилось как: волны теории штормящего моря, разбивающиеся об скалы практики.

Эволюция (??:-)) тест-эксплуатации p8-sysv-xfce на HP Compaq NX6110:
Pentium M 740 / 2x512Mb RAM => Pentium M 770 / 2x1Gb RAM
Причиной эволюции, стали частые высокие нагрузки по I/O.
Тест-эксплуатация sysv-xfce на HP Compaq NX6110 прекращена в связи с проблемами пайки BGA чипсета 82915GM.
« Последнее редактирование: 19.12.2019 11:52:44 от Speccyfighter »

Оффлайн Mr.Madguy

  • Участник
  • *
  • Сообщений: 249
Ну это мягко говоря... где больше гига памяти -- лучше сразу применять 64-битные системы, если верить Торвальдсу.
64-х битные системы жрут больше памяти. Ну не в два раза, т.к. в большинстве своем данные все равно остаются 32-х битными. Но некоторые вещи, типа указателей, становятся в два раза шире. А потому раза в 1,5 больше 64-х битные системы жрут. Так же очень важно, дискретная ли в компьютере видушка или встроенная. Встроенная может жрать до 256Мб. А потому тогда надо, чтобы сама система влазила мегабайт в 400-500. А такие требования у нас как давно были? Во времена XP? Сейчас это уже нереалистичные требования. Так например у меня есть компьютер, которому и на 32-х битной системе мало 2Гб. Работает конечно, но откровенно тормозит. Комфортно только с 4Гб. А 64-х битные системы со встроенной видушкой кстати начинают со временем тормозить даже на 4Гб, так что им и этого мало, что уж говорить о 2 или тем более 1.

64 бита круче только из за некоторых оптимизаций и дополнительных ускоренных команд. А так нужно следовать принципу целесообразности. Операционка должна соответствовать железу.

Я лично считаю, что решение похоронить 32 бита было, скажем так, чисто политическим. Как в свое время программистов задолбала возня с сегментами на 16-ти битах, так и сейчас никто просто уже не хочет иметь дела с некоторыми ограничениями 32-х бит, самым серьезным из которых является ограничение на размер виртуального адресного пространства. Проблему можно обойти, но смысл морочиться?
« Последнее редактирование: 21.12.2019 15:02:42 от Mr.Madguy »

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
нужно следовать принципу целесообразности.

Хорошо сказано.
Абсолютно согласен.

Моё ИМХО:

Нужно учесть, что про 1Gb RAM на x86_64, Торвальдс сказал в 2011-ом году.
И также нужно учесть рост потребления памяти системой от бранча к бранчу.

Изменение потребления памяти xfce-sysv собранных на разных бранчах:
(X-сессия, холодный старт; замер через tty)
altlive-xfce-t7-i586 (сборка enp; 201310; Intel 82915GM)          77Mb
alt-p8-sysv-xfce-i586 (Intel HD Graphics 5500)                   123Mb
alt-p9-xfce-sysv-x86_64 (Intel HD Graphics 5500)                 255Mb
« Последнее редактирование: 21.12.2019 18:04:55 от Speccyfighter »

Оффлайн Mr.Madguy

  • Участник
  • *
  • Сообщений: 249
Тут бесполезно спорить, т.к. истина зависит от некоторых условий. Если программам не требуется адресное пространство больше 2-3 Гб, то лучше ставить 32бита, чтобы расходовать память более оптимально. Лучше конечно PAE, которое, насколько я знаю, поддерживает до 64Гб (4x16). В таком случае лишнее адресное пространство не будет кушатся на IO. И в прошлом данные условия прекрасно удовлетворялись. Просто сейчас случилось то же, что и с 16-ю битами в свое время. Зачем парится? Зачем оптимизировать? Если можно просто сделать более простой алгоритм, который однако будет отжирать больше 3Гб адресного пространства. Например зачем парится с загрузкой данных в память по требованию, если можно просто отобразить все огромным мега-файлом на 100Гб, а там уж операционка пусть сама разбирается, что грузить, а что нет.
« Последнее редактирование: 23.12.2019 09:01:04 от Mr.Madguy »