Install linux to ram

Файловая система Linux полностью на tmpfs — скорость без компромиссов

Предыстория

Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.

Однако до недавнего времени мне не был известен способ, как реализовать подобное для Linux. Нет, безусловно, существует огромное количество линуксовых LiveCD, загружающихся в память при помощи опций ядра toram, copy2ram и т. д., однако это не совсем то. Во-первых, это сжатые файловые системы, обычно squashfs, поэтому любое чтение с них сопровождается накладными расходами на распаковку, что вредит производительности. Во-вторых, это достаточно сложная каскадная система монтирования (так как squashfs — рид-онли система, а для функционирования ОС нужна запись), а мне хотелось по возможности простого способа, которым можно «вот так взять и превратить» любой установленный на жесткий диск Linux в загружаемый целиком в RAM.

Но поскольку установка Debian не является предметом этой статьи, подробно ее описывать не буду.

Такой выбор в общем продиктован тем, что оперативной памяти никогда не бывает много и держать в ней что-то огромное вроде KDE не предполагалось. После установки необходимых для работы программ на жестком диске оказалось занято полтора гигабайта. Установка производилась в один раздел, без раздела swap. Оперативной памяти на компьютере установлено 16 гигабайт.

Собственно, способ

1. В файле /usr/share/initramfs-tools/scripts/local закомментируем строку:
checkfs $ root
и строку:
mount $ -t $ $ $ $
и сразу после нее вставим такой текст:

mkdir /ramboottmp
mount $ -t $ $ $ /ramboottmp
mount -t tmpfs -o size=100% none $
cd $
tar -zxf /ramboottmp/ram.tar.gz
umount /ramboottmp

2. Выполним команду mkinitramfs -o /initrd-ram.img
и после того, как она отработает, вернем файл /usr/share/initramfs-tools/scripts/local в исходное состояние.

3. В файле /etc/fstab закомментируем строку, описывающую монтирование корневого раздела / и вставим такую строку:
none / tmpfs defaults 0 0

4. Загрузим какой-нибудь другой линукс с LiveCD, чтобы полностью отвязаться от испытуемой операционной системы,
и заархивируем весь раздел с ее файловой системой:
cd /mnt/first && busybox tar -czf /mnt/work/ram.tar.gz *
после окончания вернем файл /etc/fstab в исходное состояние.

5. В итоге у нас получился линукс, состоящий всего из трех файлов:
кернела, initrd-ram.img и ram.tar.gz. Местонахождение ram.tar.gz указываем в параметре root= ядра в меню загрузчика grub:
title Linux in RAM
kernel /vmlinuz root=/dev/sdb1
initrd /initrd-ram.img

Это вся инструкция. Необходимые комментарии:
— checkfs закомментируем потому, что нет такого fsck для проверки tmpfs, не написали его;
— busybox tar используем для создания архива вместо простого tar из-за того, что в initrd нет простого tar, распаковывать наш архив будет именно busybox, и существует такой баг, что не сможет распаковать;
— звездочка в командной строке не страшна, так как в корне, обычно, нет скрытых файлов и папок, а в директориях они архивируются.
— /mnt/first — это примонтированный раздел с испытуемой ОС, а /mnt/work/ — это раздел для помещения архива.

Как это работает?

Мы изготовили специальный initrd, который при загрузке создает корневую файловую систему типа tmpfs (в этом вся соль, так как располагается она в оперативной памяти), затем смотрит на указанный в опции root= раздел, берет там файл архива, имя которого захардкожено (ram.tar.gz), и распаковывает из него все дерево ФС на эту tmpfs.

Так ФС оказывается в памяти.

Причем tmpfs обладает выгодными отличиями от рамдисков (в том числе от используемого мной для Windows) — она не блочное устройство, а файловая система, она занимает места в памяти ровно столько, сколько занимают файлы, и динамически увеличиватся, если что-то устанавливать, записывать новые файлы, и уменьшается, если деинсталлировать софт, удалять файлы. Остальная память доступна для работы ОС, программ. А еще Linux понимает, что это УЖЕ память и ее не надо кэшировать. Замечательная вещь!

Преимущества

Да, конечно, кэширование в современных ОС частично решает проблему низкой производительности дисковых устройств, но все равно необходимо время для первого прочтения файла с диска, а также он может быть выгружен из кэша в любое время и тогда понадобится время для его повторного чтения. Размещение же всей ОС в памяти является бескомпромиссным решением, гарантирующим максимально возможную скорость чтения и записи ее файлов. Простейший тест с помощью dd демонстрирует 3 гигабайта в секунду на последовательное чтение и 2 гигабайта в секунду на последовательную запись:

dd if=/dev/zero of=/test bs=1M count=500
524288000 bytes (524 MB) copied, 0.268589 s, 2.0 GB/s

dd if=/test of=/dev/null bs=1M count=500
524288000 bytes (524 MB) copied, 0.167294 s, 3.1 GB/s

Это примерно в 30 раз быстрее, чем HDD, и в 8 раз быстрее, чем SSD.

Продвинутый тест с помощью fio демонстрирует iops 349059 при случайном чтении и complete latency 0.29 микросекунд (латентность на два-три (десятичных) ПОРЯДКА меньше, чем у SSD):

В работе

Вывод команды free в типовой рабочей ситуации:

total used free shared buffers cached
Mem: 16469572 3236968 13232604 2075372 65552 2687436

Сразу после загрузки используется около 2 гигабайт памяти, из которых 1.5 занимает файловая система. При наличии 16 гигабайт ОЗУ имеется большой простор для установки даже больших приложений, как LibreOffice или Blender. Размер файла ram.tar.gz примерно полгига, что позволяет хранить его, кернел и initrd на любой небольшой флешке или на CD. Жесткого диска может вообще не быть. Такая система неубиваема. Но главное — это, конечно, скорость работы.

В заключении тридцатисекундный скринкаст о фактической скорости запуска приложений в такой системе. Нет, это не открытие приложений из трея, это запуск программ с носителя, которым в данном случае является tmpfs:

Источник

Загрузка любого дистрибутива в RAM

Здравствуйте мои юные кали-хакеры и любители оставаться анонимными. С утра, ковыряя VDS (пользуюсь услугами ру-провайдера), [ДАННЫЕ УДАЛЕНЫ] запрос, и [ДАННЫЕ УДАЛЕНЫ] дамп диска [ДАННЫЕ УДАЛЕНЫ].

А теперь скрипт, который из кастомного, т.е. созданного и настроенного вами chroot’а создаёт initramfs образ, готовый к загрузке и работе в tmpfs.

С ним вы можете на любой системе прямо «на лету» свичнуться в tmpfs, хоть прямо сейчас, на своём компьютере. Предварительно установив в chroot любой дистрибутив по желанию и настроив его под себя. А потом скриптом упаковать его в initramfs образ и свичнуться, да.

Для создания минимального (от слова «маленький», а не «огрызок») образа потребуется squashfs-tools. Чтобы свичнуться «на лету» нужен kexec-tools. Установите их. В ядре должны быть включены опции: CONFIG_OVERLAY_FS=y , CONFIG_SQUASHFS=y и CONFIG_SQUASHFS_XZ=y . [личное мнение: ZSTD получается размером больше, чем XZ]

Например. Хотите генту?

На этом этапе мы получили ванильную генту в gentoo_chroot/. Рекомендую её настроить, хотя бы сделать chroot gentoo_chroot/ /bin/bash и установить passwd для root, иначе в систему вы не войдёте. Я не знаю, что это за особенность такая, не давать установить пароль если его нет. В моём CRUX когда пароль на root отсутствует и ты логинишься первый раз (в tty или в ssh по ключу), оно просто предлагает установить пароль. Какая тут может быть дыра в безопасности на свежеустановленной системе? Не знаю.

Предлагаю так же в gentoo_chroot/ скопировать модули и фирмварь для корректной работы текущего ядра и железа.

Ну и создадим образ наконец.

Усё. У нас теперь целая настоящая гента в gentoo_initrd файлике упакована. Давайте загрузимся же в неё скорее с текущим ядром.

Если вы не хотите делать kexec по каким-то причинам, то положите этот же образ в свой /boot, а в параметрах загрузки укажите initrd /gentoo_initrd. Перезагрузитесь и получите тот-же результат.

Ура! Гента загрузилась. Тоже самое можно проделать с любым дистрибутивом, просто установите его, настройте как вам угодно, а затем скриптом создайте initramfs образ. Я уж взял для примера Gentoo, не стал лишний раз приводить в пример CRUX.

Жмём Reset чтобы сбросить всё и загрузиться в свою систему с морально устаревшего M.2 NVMe накопителя обратно.

Перевёл свою VDS на работу в tmpfs. Диск /dev/vda отформатировал в NTFS. Рекомендую всем. 👍👍👍👍👍👍

Источник

Существует ли ОС Linux, которую можно полностью загрузить в оперативную память?

У меня на ПК 32 ГБ памяти. Этого более чем достаточно для ОС Linux. Существует ли простая в использовании версия Linux (желательно Ubuntu), которую можно загрузить с оптического или USB-диска и полностью запустить в оперативной памяти? Я знаю, что живой диск может быть загружен с жесткого диска, но с диска все равно что-то не так, и загрузка занимает некоторое время. Я хотел бы, чтобы все загружалось в оперативную память, а затем запускалось оттуда, полностью изменчиво. Любые файлы, которые мне нужно создать, будут сохранены на USB-диске.

Мне известно о http://en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM, но все это зависит от небольшого объема оперативной памяти. Я бы предпочел что-то вроде Ubuntu вместо этих легких версий.

Ubuntu может работать в оперативной памяти, но требует некоторых изменений вручную:

Я думаю, что все дистрибутивы могут быть запущены из оперативной памяти, вам нужно только внести некоторые изменения. Прочитайте эту ссылку

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

Puppy Linux — это дистрибутив, который может быть и предназначен для работы из оперативной памяти.

Parrot Security OS. У вас есть возможность загрузить ОС непосредственно в ОЗУ, я полагаю, что MXLinux также позволяет без конфигурационных файлов загружать ОС в ОЗУ непосредственно из начального загрузчика.

Меню загрузки Parrot & MX на самом деле имеет массу опций для различных способов запуска ОС. Существует две версии: «home» и «security», каждая из которых подходит для ежедневного водителя, в отличие от таких же дистрибутивов, как Kali. В основном это рабочий стол Debian MATE, а в меню на одной из вкладок указано «parrot OS», на этой вкладке вы найдете все свои утилиты хакеров / взломщиков. В остальном это просто Debian MATE, очень красивый рабочий стол.

Также это упрощает работу в сети и запуск / остановку процессов в меню приложений. Я загрузил его в 10 ГБ оперативной памяти ddr3 на компьютере с 2012 года, и он работает быстро. Кроме того, DietPi делает версию для X86, которая быстро работает в оперативной памяти.

Если вы не заботитесь о менеджерах пакетов, крошечное ядро ​​также запускается в оперативной памяти — это просто и странно.

Источник

Поместить систему полностью в RAM

Мой корень размером 2G с ноутбучного SATA копируется ровно две минуты.
Пробовал rsync’ом с ключами -ADEgHhIloprSstWX — 4 м. 50 с.
Может кто-то подскажет что-то по ускорению процесса загрузки.

Похоже моя проблема решилась. Просто убрал /dev, /sys, /proc, /run из exclude= tar’а.
Как проверить правильность примонтирования этих директорий к новому / в tmpfs?
Почему вообще это убирание их из exclude’а изменило ситуацию? Раньше не показывался ход загрузки OpenRC.

Сжатие ускорит в пару раз.

как система будет грузиться с харда, на котором всё сжато?
что ты имееь в виду? Можно конечно сжать всё кроме необходимого для работы этого скрипта, но тогда синхронизация замедлится

Может кто-то подскажет что-то по ускорению процесса загрузки.

А пробовал через cp это делать?

не поддерживает ACL и SeLinux

Есть тогда идея, но она довольно костыльна. командой dd делаешь образ диска и записываешь в /tmp и уже оттуда перемонтируешь.

как быть с exclude’ами? образ всего диска не нужен.
как потом ты в образ чрутится будешь?

как быть с exclude’ами? образ всего диска не нужен.

как потом ты в образ чрутится будешь?

Очевидно же что это надо делать в самом начале загрузки после запуска ядра.

объясни последовательность действий как ты собрался это делать

Что только не сделают, чтобы не покупать ssd.

объясни последовательность действий как ты собрался это делать

Но ведь когда ядро загружается, оно загружается с ОЗУ-диска, а потом перемонтирует корень. Так же есть другой вариант когда загружается ядро сразу с драйвером нужного диска и монтирует корень без привлечения ОЗУ-диска. Собственно надо изменить скрипт инициализации и загружать GRUB сразу образ корневой системы в память. Ну или перемонтировать корневую файловую систему.

загружать GRUB сразу образ корневой системы в память

как? всё равно мне нужны будут exclude

всё равно мне нужны будут exclude

Знать бы что это такое.

задолбали с XY проблемой

просто распакуй tar-архив с /dev/

А если не лень, то читай man 1 mknod

Но ведь когда ядро загружается, оно загружается с ОЗУ-диска, а потом перемонтирует корень.

Так же есть другой вариант когда загружается ядро сразу с драйвером нужного диска и монтирует корень без привлечения ОЗУ-диска.

а это без initrd

я примонтировал старый корень в /mnt.
заглянул в /mnt/dev и увидел там кучу файов.
я их все удалил
теперь опять не показывается ход загрузки init.
плюс почему-то не подгрузился .bashrc рута. после перезагрузки подгрузился.

Что произошло? /dev ведь на диске не находится, это ведь часть ядра.
и кстати время загрузки ядра сократилось на полсекунды.
что я сделал?

и кстати время загрузки ядра сократилось на полсекунды.

сейчас опять как прежде.

Не нужно: для этого дисковые кеши в оперативке существуют

Что произошло? /dev ведь на диске не находится, это ведь часть ядра.

/dev это каталог, который определённо находится на диске.

В этом каталоге в большинстве дистрибутивов есть определённые специальные файлы — stdout, zero, full и тд. В процессе загрузки initrd монтирует в /dev специальную devfs, которая уже действительно контролируется ядром и скрывает те файлы, но они никуда не деваются и пока не подмотирован devfs — выполняют нужные функции.

заглянул в /mnt/dev и увидел там кучу файов. я их все удалил

ССЗБ. В слаке есть специальный пакет с /dev/, а у вас — без понятия.

Что произошло? /dev ведь на диске не находится, это ведь часть ядра.

ошибаешься. Это файлы. Их делают командой mknod (кстати, ЕМНИП в генте есть скрипт для этого), а уж потом mount монтирует к файлу девайс.

файлы надо создать, которые ты удалил.

Legioner , emulek спасибо
А sys proc run не существуют на диске?

Посмотри, как сделано в archboot. Там всё запихнуто в initrd и, соответственно, хранится на диске в сжатом состоянии. У такого подхода есть недостаток — с диска читается сразу всё, что, соответственно, занимает достаточно много времени.

А можно и в squashfs (см. archiso).

/sys, /proc, /run — это всё виртуальные файловые системы, они находятся в памяти и монтируются init’ом в начале загрузки. Первые две — это особые ФС (sysfs и procfs), последняя — обыкновенная tmpfs. Кстати, не забудь ещё примонтировать devtmpfs на /dev, tmpfs на /tmp и devpts на /dev/pts.

А sys proc run не существуют на диске?

/proc существует только в виде пустого каталога. Его нужно смонтировать командой mount -t proc /proc /mnt/rootfs/proc из другой системы (например если ты хочешь сделать chroot)

/sys монтировать не нужно, оно к ядру гвоздями прибито

/run это обычный каталог, его монтируют в память для того, что-бы можно было сделать read only корневой ФС (раньше это не получалось из-за всяких /etc/mtab, т.е. получалось, но криво)

PS: это без systemd, что там Леннарт придумал — яхз.

Там всё запихнуто в initrd и, соответственно, хранится на диске в сжатом состоянии. У такого подхода есть недостаток — с диска читается сразу всё, что, соответственно, занимает достаточно много времени.

никто не заставляет пихать в initrd всё. Достаточно ядра, основных каталогов, и ещё кастрированного шелла ash(шелл полезен при ремонте например). Тогда грузится мгновенно(в смысле до перемонтирования корня из памяти на основной носитель).

а если до этого сделал pivot_root?
в разных how_to по помещению системы в RAM говорится что надо делать
mount -M /dev /new_root/dev
mount -M /proc /new_root/proc
mount -M /sys /new_root/sys

я когда пробовал так делать в своём скрипте:
mount: wrong fs type, bad option, bad superblock on /dev,
missing codepage or helper program, or other error

In some cases useful info is found in syslog — try
dmesg | tail or so.

и тоже самое с /sys и /proc (но в запущенной системе получалось)

в других how-to — отмонтирование этих каталогов с последующим примонтированием в новый корень.
/dev у меня не получилось отмонтировать.

Как правильно сделать? или не надо ничего перемонтировать?

Так речь у ТС о том, как запихнуть в память всю систему. О том, что initrd — минимальный образ с модулями и скриптами для монтирования rootfs, я знаю.

всё разобрался. /dev, /sys, /proc не надо ни перемонтировать, ни отмонтировать, ни перемещать.
нужно только /dev скопировать

для чего это нужно? почему OpenRC это не делает?

если корень в tmpfs, зачем это делать?

Источник