Sfs linux ��� ���

squashfs — извлечение файла без монтирования

С некоторого момента появилась потребность извлекать файлы из файла образа squashfs, не пребегая к монтированию (оч. лень писать в терминале sudo mount, а потом еще и пароль набирать).
Судя по ману к unsquashfs опция -е должна была мне помочь, однако команда вида:
unsquashfs -e filesystem.sfs file.txt
где file.txt — извлекаемый файл находящийся в корне ФС, а filesystem.sfs — файл-образ squashfs. Выдали результат:
Could not open file.txt, because No such file or directory
Как эту проблему решить? Все ли я правильно понял, читая man?

-l — и посмотреть путь к файлу, и «-e» ставить _перед_ оным (а не образом фс)

попробовал следующие варианты:
unsquashfs filesystem.sfs -e squashfs-root/file.txt
unsquashfs filesystem.sfs -e /file.txt
unsquashfs filesystem.sfs -e file.txt
все три команды создали директорию squashfs-root и ни одного файла не было извлечено.
Может это баг unsquashfs?

Путь точно верный? Проверял на образе убунты:

// unsquashfs version 4.2 (2011/02/28)

$ unsquashfs -l templates.sfs
Parallel unsquashfs: Using 6 processors
3 inodes (110 blocks) to write

squashfs-root
squashfs-root/add_sting
squashfs-root/change_char

$ unsquashfs templates.sfs -e add_string
Parallel unsquashfs: Using 6 processors
0 inodes (0 blocks) to write

created 0 files
created 1 directories
created 0 symlinks
created 0 devices
created 0 fifos

Однако при распаковке mint’овского файла-образа все сработало отлично
$ unsquashfs /mnt/casper/filesystem.squashfs -e bin/bash
Parallel unsquashfs: Using 6 processors
1 inodes (7 blocks) to write

[===================================================================/] 7/7 100%
created 1 files
created 2 directories
created 0 symlinks
created 0 devices
created 0 fifos

Источник

Пакеты и модули: PET, SFS, PFS

В операционных системах Puppy и PuppyRus используется несколько типов пакетов и модулей (аддонов).

Пакеты типа PET (файлы с расширением .pet).

Это самый распространенный тип пакетов в Puppy и PuppyRus, поддерживается практически всеми версиями дистрибутива.
В дистрибутивах проекта Puppy Linux (в т.ч. локализованных) PET является основным типом пакетов. Устаревшие дистрибутивы PuppyRus также собирались из PET-пакетов.
В современных версиях PuppyRus (начиная c версии 12.12) используется другой тип пакетов — PFS. Поддержка PET сохранена для обратной совместимости.

Модули (аддоны) SquashFS (файлы с расширеним .sfs).

SquashFS — это файл, содержащий внутри полноценную сжатую файловую систему (только для чтения).

В дистрибутивах Puppy такие файлы используются для двух целей:

Преимущества использования модулей SFS перед пакетами PET — в возможности горячего подключения и отключения их непосредственно в корневую файловую систему.
Работает это так: При подключении SFS-модуля файлы, содержащиеся в нём, «возникают» в корневой файловой системе в соответствующих каталогах (при этом файлы на самом деле не копируются, а читаются операционной системой непосредственно из SFS-модуля). При отключении SFS-модуля эти файлы исчезают из файловой системы.

Пакеты типа PFS (файлы с расширением .pfs).

PFS (Package sFS) — это новый тип пакетов, разработанный командой проекта PuppyRus в 2012 году.
Пакеты типа PFS соединяют в себе преимущества пакетов PET (хранение информации о пакете внутри) и модулей SFS (возможность подключения).
Другая особенность пакетов PFS — использование контейнеров. Файл с расширением .pfs является контейнером, который может содержать внутри один или несколько пакетов PFS. Контейнеры легко перепаковать (добавить или удалить необходимые пакеты, объединить или разделить контейнеры).
Контейнеры PFS можно подключать в корневую файловую систему (так же как SFS-модули).
PFS-пакеты также могут быть установлены в систему (так же как PET, или любые другие пакеты). При установке можно выбрать необходимые пакеты из контейнера, а подключать/отключать можно только весь контейнер сразу.

В операционной системе PuppyRus PFS является стандартным форматом пакетов. Основные компоненты системы также хранятся в одном или нескольких файлах .pfs (контейнерах), которые автоматически подключаются при загрузке системы.
В дистрибутивах Puppy Linux пакеты PFS либо пока не поддерживаются, либо поддерживаются в тестовом режиме.

Источник

SFSLinux

Сокращения в тексте

Основные характеристики

Скачать

Идеология

История:

Зарождение идеи произошло при ознакомлении с live-boot (Dеbian) и load_sfs (www.PuppuRus.org). 2011 год

3 источника и 3 составные части

Варианты применения

Направление развития SFSL

(…или хотя бы улучшение подготовленности пользователя в процессе создания и популяризация linux )

Ищу единомышленников!

Похожие дистрибутивы

puppy
deb	grml, knoppix, pureos
arch	ctkarch
slack	porteus
mandriva	magos

Установка, загрузка

Запуск в VirtualBox

Обязательно в свойствах: Система-Процессор— Включить PAE/NX

Установка на hdd, usbflash

Если не уверены в себе — устанавливайте загрузчик на usbflash. Файлы при этом могут располагаться на любом другом носители. SFSL в этом случае никак не повлияет на другие установленные у Вас на hdd ОС

Неквалифицированно установленный на hdd загрузчик может привести к тому, что другие ОС перестанут загружаться. И это не является проблемой SFSL

Как из SFSl сделать FULL

Теряется весь смысл задумки. Лучше поставить с обычный Debian. Но если вы 1 пользователь на стационарном пк и не склонны к экспериментам:

Варианты загрузки (mode в параметрах ядра)

Задается при загрузке в параметрах ядра (см. /menu.lst)

Persistent mode

/download на /media/sda2

Использование раздела диска в качестве live-rw ( с live-home аналогично)

Live mode

Live toram mode

Модули .s*fs

В качестве GUI для работы с .sfs можно использовать sfs-get или mnt_sfs вместе с любым файловым менеджером

Подключение и отключение

или sfsmnt [-u] [-r] модуль.sfs. Подробности: sfsmnt –help Отключение : sfsumnt [-u] [-r] модуль.sfs.

Изготовление

Самый простой рецепт создания своего модуля:

Вообще такой модуль хорошо бы

Рецепт 1 (сложный)

Ниже есть 2 попроще, но модуль даст большего размера

Рецепт 2. Для тех кому рецепт 1 сложен.

Модули .squashfs

Обновление, модификация SFSL, patch (исправления)

Скрипт remaster сырой. Не рекомендуется для использования новичками.

Обновление

Модификация

patch

Исправления, обновления системы можно собрать в модуль.s*sf и загрузить поверх базы методом :

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

SFS (Smart File System)

SFS

Полное название	Smart File System
Limits
Макс. размер тома	127 GB
Макс. размер файла	4 GB
Макс. длина имени файла	107 characters
Features
Диапазон дат	January 1, 1978 — 2157
Дата резолюции	1/50s
Прозрачное сжатие	No
Транспорантное шифрование	No (provided at the block device level)
Другие
Операционная система	AmigaOS (version 1.279), AROS (1.84), MorphOS (1.223), Linux (1.0beta12)

SFS (англ. Smart File System ) — журналируемая файловая система, изначально разработанная для компьютеров Amiga, впоследствии используется в производных от AmigaOS операционных системах (AROS, MorphOS и др.). Проектировалась с учётом требований производительности, масштабируемости целостности данных. Используются блоки размером от 512 (29) до 32 768 (215) байт, а максимальный размер раздела может достигать 128 Гб.

SFS альтернативная файловая система, снимающая ограничения диска в 8 ГБ, максимального размера раздела в 4 Гб в FFS (Fast File System) и позволяет использовать жесткие диски любого размера с максимальным размером раздела 128GB.

Содержание

История

SFS написана на языке «C» и первоначально была создана и выпущена как бесплатное программное обеспечение в 1998 году Джоном Хендриксом. После того, как автор покинул Amiga в 2000 году, исходный код SFS была открыт и его развитие продолжилось Ральфом Шмидтом в рамках MorphOS.

С мая 2005 года исходный код SFS доступен по лицензии GNU LGPL. Развитие SFS на данный момент разветвилось — теперь есть версии MorphOS , AROS , AmigaOS 3 , и версия для AmigaOS 4 , которые имеют различные наборы функций , но остаются совместимы друг с другом. Кроме того, есть драйвер для Linux , чтобы читать тома Amiga SFS. GRUB изначально поддерживает ее, и есть свободные драйверы , чтобы использовать SFS из UEFI.

По состоянию на 2008, SFS была одной из независимых файловых систем до сих пор использующихся на компьютерах Amiga

Устройство и особенности SFS

Хорошая производительность файловой системы реализуется путём группирования множественных записей каталогов в единый блок и группированием блоков метаданных совместно в кластеры. Для отслеживания свободного места используется битовая карта, а файл данных следит за использованием экстентов, упорядоченных в структуру B+ дерева.

Целостность поддерживается ведением журнала откатов всех изменений сделанных с метаданными за определённый период времени. Журнал записывается на диск сначала в свободное место, а затем непосредственно поверх него записываются блоки метаданных. В случае отказа системы, сразу после монтирования файловая система будет помнить о незавершённой операции и откатит её назад к последнему целостному состоянию. По причинам связанным с производительностью гарантируется целостность только метаданных. Актуальные данные в файлах могут оставаться повреждёнными, если операция записи была прервана на середине. Интересной специфической особенностью SFS является способность дефрагментации самой себя непосредственно во время использования файловой системы, даже для заблокированных файлов. Процесс дефрагментации почти не имеет состояний (отдельно от местоположения, в котором работает), что означает возможность мгновенно его останавливать и запускать. В ходе дефрагментации сохранение целостности данных гарантируется и для метаданных, и для обычных данных.

Монтирование SFS в WinUAE

Источник

Архитектура файловой системы Puppy Linux

С высоты птичьего полёта

Эта диаграмма — картина файловой системы в целом:

На данной диаграмме каждый слой следует рассматривать как отдельную полноценную файловую систему с иерархией директорий от самого »/» (корня). Эти слои расположены друг над другом, и это достигается с применением файловой системы UnionFS. Довольно просто представить, как эта конструкция работает. Например, пусть на «розовом» уровне расположен файл /usr/lib/libgdkxft . Он также будет виден и на «синем» уровне. Однако если синий уровень уже сам содержит файл с точно таким же названием, то он виден уже не будет, так как на него «наслоился» тот же самый файл с более верхнего («розового») уровня.

Вот описание каждого из уровней:

ramdisk Это файловая система типа tmpfs, существующая в оперативной памяти, в которой создаются и изменяются файлы. pup_save.3fs Этот файл — постоянное хранилище, где все ваши данные, настройки, email, установленные пакеты и т.д. сохранены на постоянной основе. ».3fs» означает, что файл содержит файловую систему типа ext3. pup_xxx.sfs Этот файл и есть Puppy. Встроенные приложения, оконный менеджер, скрипты — всё это. Здесь ».sfs» означает, что данный файл содержит сжатую файловую систему типа squashfs, а «xxx» — номер версии Puppy. Например, для Puppy 3.01 «ххх» будет «301». *_xxx.sfs Эти файлы содержат дополнительные файловые системы типе squashfs. Здесь «*» может быть чем угодно. Например, devx_xxx.sfs — полная среда программирования С/С++.

Вот, что, однако, тут следует отметить. Всё это хозяйство находится «под ковром». Когда мы работаем с Puppy, то всё, что мы видим (с нашего верхнего уровня) — это единая файловая система. Таким образом, в нашем примере, мы видим файл /usr/lib/libgdkxft.so, и для нас не будет иметь значения, на каком уровне он находится на самом деле.

Заманчивая альтернатива уже существующей файловой системе squashfs — использовать какой-нибудь существующий дистрибутив линукса (underdog.lnx) как нижний уровень для неё:

Что приведенная выше диаграмма скрывает — это то, что самый нижний уровень в данном случае — раздел диска, а не сам файл underdog.lnx. Сам файл underdog.lnx — это просто текстовый файл, содержащий название этого раздела, например, «hda1».

При загрузке, Puppy прочитает файл underdog.lnx и смонтирует упомянутый в нём раздел как самый нижний уровень. Если окажется, что этот раздел содержит установленный на него дистрибутив линукса, то он целиком будет «просвечивать» через верхние уровни unionfs в Puppy.

При этом, мы будем видеть, как мы запускаем JWM и/или что-то ещё, будем видеть наш рабочий стол, и одновременно целый дистрибутив (из нижнего уровня) будет также доступен нам для работы: все приложения, среды программирования, менеджеры пакетов, и т.д.

Из первых двух диаграмм вы увидели, что уровни unionfs могут быть очень разными. В связи с этим (и еще с кое-чем другим), у Puppy появилась «переменная состояния» — PUPMODE, которая показывает в каком состоянии (конфигурации слоёв) Puppy в настоящий момент запущен. Эта переменная определена в файле /etc/rc.d/PUPSTATE как целое число. Например, «12». Каждое значение PUPMODE требует отдельного описания.

Первичная загрузка с live-CD — PUPMODE 5

Puppy запускается в этой конфигурации, когда вы впервые загружаете его с live-CD или USB-накопителя. Мы поговорим о примере с live-CD, поскольку наиболее вероятно, что это ваш самый первый опыт общения с Puppy.

В первый раз, когда вы вставляете live-CD и загружаетесь с него, у вас еще не определено никакого постоянного места хранения данных, и unionfs включает только два слоя: верхний — ваши «файлы для работы» (файловая система типа tmpfs в оперативной памяти) и нижний — pup_xxx.sfs (сжатая файловая система типа squashfs на live-CD), содержащий все файлы Puppy. Эти два слоя оказываются наложенными друг на друга, начиная с корневой директории »/», однако, также могут быть рассмотрены независимо — через их точки монтирования. Файловая система tmpfs смонтирована на чтение и запись в точку /initrd/pup_rw , а файловая система из pup_xxx.sfs смонтирована только на чтение в точку /initrd/pup_ro2 .

Таким образов, вы имеете возможность использовать Puppy, при этом не трогая ваш жесткий диск. Вы можете запускать приложения, конфигурировать, скачивать файлы из интернета, устанавливать пакеты, но всё это будет производиться только в tmpfs в оперативной памяти. Это и есть, так называемый, ramdisk. Объём рамдиска зависит от того, как много в вашем компьютере оперативной памяти (а еще, от того, есть ли у вас на жестких дисках своп-разделы линукса).

Интересное начинается, когда вы собираетесь закончить работу и выключить компьютер. Тогда запускается скрипт выключения /etc/rc.d/rc.shutdown , выводящий на экран окно, в котором спрашивает, хотите ли вы сохранить данную сессию. То есть, какие бы директории и файлы ни были созданы в рамдиске, все они в тот момент могут быть сохранены.

Тут появляется выбор. Если вы загрузились с live-CD, скорее всего, вы захотите сохраниться на жесткий диск, однако вы также можете выбрать и гибкий диск, USB-носитель, или даже тот же самый CD/DVD, с которого вы загрузились (при условии, что он записан в режиме мультисессии). Это очень просто: окно диалога предложит список разделов вам на выбор. При этом, окно диалога, также на выбор, предложит сохранить рамдиск вашей с сессией либо в виде файла, либо в виде раздела. В результате, например, будет создан файл pup_save.3fs, содержащий файловую систему ext3, размером 512МБ (как часто выбирают), или же, как альтернативу, вы выберите какой-либо существующий раздел, в который произведется сохранение. Часто выбор между файлом или разделом определяется тем, содержит ли раздел файловую систему одного из линукс-совместимых типов (напр. ext2, ext3, reiserfs). Если доступны только файловые системы типа FAT, то подойдёт только вариант с созданием файла pup_save.3fs.

Пока, допустим, мы сохранились в этом файле.

Вторичная загрузка с live-CD — PUPMODE 12

Итак, вы снова загружаете live-CD, зная, что сохранили свою предыдущую рабочую сессию в файле pup_save.3fs раздела жёсткого диска с файловой системой линукса, FAT, или NTFS. При этом Puppy загрузится в режиме PUPMODE 12.

Что произошло? Puppy обнаружил файл pup_save.3fs на жестком диске и решил смонтировать файловую систему из этого файла прямо в самый верхний уровень. Таким образом, тут нет никакого промежуточного рамдиска с его временной файловой системой tmpfs. Теперь в файл pup_save.3fs запись и чтение производятся напрямую. Этот сценарий очень подходит для загрузки на компьютерах с малым размером оперативной памяти. Рамдиск начальной стадии загрузки, то есть, файл initrd.gz присутствует в оперативной памяти, однако его размер составляет всего 1.9МБ.

Вторичная загрузка с USB — PUPMODE 13

Если вы установили Puppy на USB-флеш-накопитель, то, используя Универсальный Инсталлятор или вручную, вы создали загрузочный носитель с файлами vmlinuz (ядро линукса), initrd.gz (рамдиск начальной загрузки), pup_xxx.sfs (файловая система типа squashfs со всеми файлами ОС Puppy) и syslinux.cfg (конфигурационный файл программы syslinux). Ситуация напоминает таковую с live-CD — при первой загрузке Puppy будет в состоянии PUPMODE 5, поскольку никаких постоянных хранилищ информации пока им не создано. При первом выключении, как описывалось выше в разделе про PUPMODE 5, вы создадите постоянное хранилище — либо файл pup_save.3fs, либо целый раздел.

При второй загрузке, Puppy обнаружит это постоянное хранилище, но в этом случае поймет, что сам-то он расположен на носителе, для которого следует серьёзно ограничивать частоту записи. Поэтому Puppy запустится в режиме PUPMODE 13.

На приведенной диаграмме самый верхний слой занимает файловая система tmpfs рамдиска, в которую попадут все вновь созданные или модифицированные директории. Это — рабочая зона, и она имеет потенциальные огранчения в соответствии с количеством доступной оперативной памяти. Но, конечно, если у вас на жестком диске есть готовый своп-раздел линукса, то Puppy его задействует для повышения эффективного размера рамдиска.

В случае наличия постоянного хранилища информации на флеш-накопителе, смонтированном во втором уровне («оранжевом»), Puppy будет сохранять в него всё с самого верхнего уровня с периодичностью в 30 минут. С точки зрения unionfs, второй уровень монтрован только для чтения, и только в самый верхний уровень разрешена запись, однако Puppy способен периодически брать верхний уровень целиком и «сливать» его на нижний уровень. Тут надо отметить одну техническую особенность. «Сливать» — это не совсем точное выражение. В идеале, этого хотелось бы — сохранять всё на уровень постоянного хранения, и при этом каждый раз получать полностью свободный рамдиск. Тем не менее, когда я (Барри — прим. перев.) попытался это сделать, то тем самым разрушил unionfs. Так что, компромисс заключается в том, что содержимое самого верхнего уровня копируется (а не перемещается-«сливается» — прим. перев.) вниз на предыдущий уровень. И такой режим unionfs официально поддерживает. Иными словами, это означает, что рамдиск никогда по-настоящему не «сливается», и если вы загрузили много всякой всячины или инсталлировали достаточно большой пакет, то он может забиться под завязку. Чтобы обойти эту проблему, в Puppy имеется программа, запущенная в фоновом режиме (демон), которая предупредит вас, если свободная оперативная память будет на исходе. И если так случилось, то ваше спасение просто: перезагрузитесь.

Уточнение по поводу второго (сверху) уровня. Это — постоянное хранилище, но, как обсуждалось выше в секции PUPMODE 5, при первом выключении вам предлагают создать такое хранилище либо в файле (pup_save.3fs), либо в разделе носителя информации. В последнем случае, рабочая сессия может быть сохранена в целом разделе, но только если это раздел с файловой системой линукса. Тогда то, что монтируется как второй уровень будет разделом, а не файлом. В случае загрузки с USB-флеш накопителя, использовать целый раздел носителя для хранения персональных данных было бы очень неплохо. Файл pup_save.3fs имеет ограниченный размер, обычно 512МБ или еще меньше, если на разделе накопителя, куда он сохраняется, не так много свободного места. Кроме того, были сообщения на Puppy-форуме, что этот файл может быть увеличен только до размера 750МБ–1ГБ. Ну, полагаю, что последнее — не самая страшная проблема для большинства флеш-накопителей.

Если вы выбрали сохранение рабочей сессии прямо на раздел USB-носителя, то это должен быть линукс-раздел, то есть раздел с файловой системой ext2, ext3, или reiserfs. В то же время, сохранение файла pup_save.3fs может производиться на любой тип раздела накопителя — их обычно выпускают с файловой системой FAT16, что вполне подойдёт.

Полная инсталляция — PUPMODE 2

Многие пользователи Puppy знают, что существует 2 способа установки Puppy на жесткий диск: то, что мы называем «опицией 1» и «опцией 2».

Опция 1 — выбор с наименьшим проникновением в систему (наименее инвазивный), при котором просто производится копирование файлов vmlinuz, initrd.gz и pup_xxx.sfs в выбранный раздел носителя. Чтобы загружать Puppy, установленный таким способом, Универсальный Установщик предлагает создать загрузочный гибкий диск. Однако, в настоящий момент, загрузочный гибкий диск может загрузить только тот Puppy, который установлен на раздел с файловой системой FAT. Для загрузки Puppy также возможно сконфигурировать программы Grub или Lilo. Преимущество данной опции в том, что при таком раскладе установка Puppy никак не влияет на какие-либо другие разделы носителя, и, если на них уже установлены Windows или другие дистрибутивы Linux, то они останутся совершенно нетронутыми. При Опции 1 загрузка Puppy проходит в режиме PUPMODE12.

Опция 2 означает, что Puppy устанавливается на целый раздел, который должен быть линукс-разделом (ext2, ext3, reiserfs). Это рекомендуется разработчикам или вообще всем, кто собирается компилировать программы, так как такой способ экономит свободное место на диске.

Это — самая простая конфигурация из всех. Нет никакого рамдиска, а сам раздел смонтирован прямо на самый верхний уровень. На самом деле, если не надо загружать никаких ».sfs», то Puppy не будет использовать unionfs, поскольку нет никаких слоев.

PDEV1 , обозначенная на диаграмме — просто переменная в файле /etc/rc.d/PUPSTATE , содержащая название раздела, например hda1, который монтируется прямо в »/« (корень). Но как узнать, какое значение примет PDEV1 во время загрузки? Утверждать, что это значение записано в файле /etc/rc.d/PUPSTATE , который находится на загружаемом разделе — это все равно, что говорить, что яйцо было раньше курицы (яйцо действительно было раньше курицы, но Барри об этом, видимо, не знал — прим перев). Этот файл, в действительности существует только для скриптов, которым нужно знать, откуда Puppy загрузился. В данном случае, Puppy загружается с гибкого диска, с загрузочного USB-флеш накопителя или с помощью Grub или Lilo. Универсальный Установщик дает возможность задействовать на выбор: гибкий диск, USB или Grub.

Мультисессия на CD/DVD — PUPMODE 77

Данный режим используется для мультисессионных CD и DVD. В этом случае, наше постоянное хранилище состоит из папок на CD/DVD. Каждый раз при вылючении сессия сохраняется в физически новых папках, так что последние постепенно накапливаются на CD/DVD. При загрузке, эти папки считываются системой в обратном порядке и загружаются в рамдиск.

Считваются они во второй уровень («оранжевый»). Во время рабочей сессии, вновь созданные, а также изменённые директории и файлы будут записаны в самый верхний («зеленый») уровень. При выключении, этот уровень записывается на CD/DVD как новая папка.

Логика в нумерации режимов PUPMODE

Недавно я обсуждал режимы PUPMODE с пользователем Phil на форуме Puppy. Он загрузил Puppy2, используя GRUB , при этом имея initrd.gz, vmlinuz и pup_xxx.sfs (т.е все необходимые файлы Puppy) на одном из разделов жесткого диска. После этого он сохранил рабочую сессию прямо в загрузочный раздел.

Будем считать, что раздел называется /dev/hda2. Тогда ситуация выглядит так:

Я упомянул файл /etc/puppyversion , поскольку он сохраняется во время каждой сессии, и Puppy ищет его при загрузке, чтобы определить, имеются ли в данном разделе диска файлы, сохраненные Puppy. Обратите внимание, что файлы initrd.gz, pup_xxx.sfs и vmlinuz могут находиться в папках, например в /boot, при условии, конечно, что для этого вы также сконфигурируете GRUB соответствующим образом. В случае Phil, Puppy запустится в режиме PUPMODE 7, но чем это определяется? Какая логика стоит за этим?

PUPMODE — это двоичное число, где каждый бит (под номером … 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0) является флагом:

БИТ	ДЕСЯТ.ВЕЛИЧИНА	ЗНАЧЕНИЕ
0	1	используется для самого верхнего уровня tmpfs (/initrd/pup_rw) системы unionfs.
1	2	загрзочный раздел (PDEV1) содержит сохранённые сессии Puppy.
2	4	в загрузочном разделе (PDEV1) существует файл pup_xxx.sfs
3	8	существует файл pup_save.3fs (в котором сохранены сессии).
4	16
5	32
6	64	флаг мультисессий.

Например, мульсессионный CD/DVD запускается с PUPMODE=77, что есть 1+4+8+64. Вполне логично, как видите.

В случае Phil, Puppy запустится в режиме PUPMODE=6 (2+4), и, поскольку сохранённые сессии находятся на быстром носителе с неограниченным возможным числом операций записи, то тогда становится не нужно хранить в оперативной памяти самый верхний уровень — tmpfs. Обратите внимание, что этот tmpfs используется как промежуточное депо для сохранения рабочих файлов и директорий, и его существование оправдано только тогда, когда мы органичены по числу записей на носитель (напр. Флеш-память), или, когда текущая сессия должна быть сохранена на очень медленный носитель и/или только в строго определённое время (запись на дорожку мультисессионного CD/DVD), или же, когда мы заведомо хотим использовать всю систему, загруженной прямо в память (как бывает при первой загрузке Puppy).

Полная инсталляция Puppy («опция 2») запускается в режиме PUPMODE 2.

Решение о том, какой режим загрузки использовать, принимается внутри первого заргузочного скрипта /initrd/sbin/init.

Хотя, в случае полной установки на жесткий диск, файл initrd.gz не используется совсем, и первым запущенным скриптом является /etc/rc.d/rc.sysinit . Puppy полагает PUPMODE=2.

Начальный рамдиск

Первое событие, которое происходит при загрузке системы — это загрузка ядра линукса vmlinuz в оперативную память. За ним идет начальный рамдиск, который находиться в файле initrd.gz. Обратите внимание, что исключение составляет PUPMODE 2, т.е. вариант полной инсталляции на жесткий диск, в случае которой отдельного файла initrd.gz не существует (не совсем понимаю, что Барри имеет в виду, т.к., из моего личного опыта, при полной инсталляции, такой файл существует, правда, не обязательно в корневой директории раздела, а в там, откуда загружается GRUB. — прим. перев.). Когда начальный рамдиск загружен, на выполнение запускается скрипт /sbin/init. Ниже этот скрипт приведен в упрощенном виде для иллюстрации.

Похоже, тут много чего происходит! Но, на самом деле, всё это довольно просто. По сути, скрипт ищет загрузочный раздел и файл-хранилище или раздел-хранилище, используя параметр загрузки PMEDIA как ориентир. А когда находит их, то определяет соотвтствующий PUPMODE, а затем создает необхдимые уровни unionfs. В самом конце, скрипт выполняет команду pivot_root, которая подключает директорию /pup_new в качестве нового »/« корня файловой системы. Эта директория /pup_new — то место, где слиты воедино все слои unionfs.

Начальный рамдиск оставлен в памяти, и после работы pivot_root он будет перемещен в директорию /initrd. То есть, всё, что было »/», после pivot_root будет в /initrd. И именно в /initrd вы сможете потом получить доступ к слоям по-отдельности. Хотя последнее представляет интерес скорее для разработчиков, чем для пользователей.

Источник