Google plus boot на linux что это
Обновлено: 03.07.2024
Продолжаем изучать GNU/Linux и готовиться к сертификации от Red Hat (RHCSA).
Для работы какой-либо программы её нужно предварительно запустить. Какие-то программы мы запускаем сами, какие-то программы запускают другие программы. И при запуске компьютера есть определённая последовательность, какие программы что и зачем запускают. Процесс запуска операционной системы администратору нужно знать, потому что, во первых, это помогает выявить и решить какие-то проблемы, во вторых, это помогает какие-то проблемы предотвратить. Ну и в третьих помогает лучше понять работу операционной системы. Например, вспомните, мы с вами испортили запись в fstab, у нас система не прогрузилась, потом мы её исправили и всё заработало.
Есть много сценариев запуска операционной системы, которые зависят от определенных условий. Например, мы с вами говорили про BIOS и UEFI, и тут, как минимум, уже два сценария запуска – с использованием MBR или раздела EFI system partition. Также мы с вами разбирали стандартные разделы, LVM, RAID – и это тоже добавляет варианты – используется ли для корня стандартные раздел или какой-то нестандартный, допустим, LVM. Ну и сегодня мы будем говорить о загрузчиках, и мало того что есть разные загрузчики, даже с учётом того, что мы будем разбирать только один загрузчик – grub, у него есть разные версии, от чего тоже появляются вариации. Но не будем усложнять, обо всём по порядку.
Со всем вышесказанным мы знакомы, кроме загрузчика. Загрузчик – это программа, которая загружает операционную систему. Это особая программа, потому что она работает еще до того, как загрузилась операционная система, ядро и всякие другие программы. Тут можно понять, что у загрузчика должны быть свои, хотя бы минимальные драйвера для работы с компьютером – где-то он обращается к биосу, где-то напрямую к железу. При включении GNU/Linux-а мы видим такое окно – это такой интерфейс загрузчика Grub. Есть и другие загрузчики, но grub самый популярный, он стоит по дефолту на многих системах и чтобы не усложнять, мы будем говорить только о нём.
И так, при включении у нас появляется окно grub, где мы можем выбрать нужную операционную систему. Если у нас на дисках установлены разные операционные системы мы сможем загрузить любую из них. К тому же тут также есть возможность загрузить одну и ту же операционку с разными версиями установленного ядра. Также отсюда мы можем повлиять на процесс загрузки – например, нажать “e” на нужной записи и изменить какие-то параметры. Но мы к этому еще придём. Плюс grub можно кастомизировать – поменять шрифт, рамки, цвета, поставить фон и всё такое. Чтобы лучше понять grub нам нужно хотя бы разок пройтись по сценарию запуска операционной системы.
Возьмём самый простой сценарий BIOS – MBR – GRUB – корень на стандартном разделе. И так, вы нажали кнопку включения на компьютере, загрузился BIOS, какие-то свои задачи выполнил, а дальше обращается к порядку загрузки – диски, флешки, сеть и всё такое. Предположим, у нас на первом месте жесткий диск. BIOS загружает первый сектор - 512 байт этого диска, то есть MBR. Как мы помним, у нас в MBR есть загрузчик и таблица разделов. Для загрузчика выделено 446 байт – это очень маленький объём, куда невозможно поместить полностью grub – поэтому здесь лежит программа, в которой прописан блочный путь к основной части grub-а. Блочный – потому что поддержку файловой системы в такой маленький объём не запихнуть. Этот шаг, когда загружается маленькая часть grub из MBR называется этапом 1. В случае со старым железом BIOS мог видеть только первые 1024 цилиндра жесткого диска, т.е. примерно первые 500 мегабайт, а если основная часть grub-а находилась в другом месте – то не получилось бы его загрузить. Поэтому для таких случаев существовал этап 1.5, когда загружалась чуть большая часть grub-а, расположенная в первых 62 секторах диска, где лежали драйвера для файловых систем. Загрузив их grub мог уже полноценно найти и загрузить основную свою часть, которая лежит в директории /boot/grub – т.е. приступить к этапу 2.
Grub, загрузив свою основную часть, обращается к файлу /boot/grub/grub.cfg и берёт оттуда записи, что и как грузить. Если говорить про Linux, то задача grub – загрузить ядро и передать ему нужные параметры. Эти параметры видны в строчке linux – собственно, файл vmlinuz, который мы видели в директории /boot, файловая система, где лежит корень (root=..) и всякие дополнительные опции – например, rhgb – чтобы отображать анимацию, пока грузится операционная система и quiet – чтобы скрыть подробный вывод при запуске. Давайте, для примера, сотрём последние две опции (rhgb quiet) и нажмём ctrl+x, чтобы загрузиться. Как видите, теперь при загрузке отображается куча информации, что может быть полезно, если по какой-то причине система не грузится и мы пытаемся найти причину. Но после перезагрузки эти опции опять будут на месте, потому что мы их стёрли в текущей сессии, а не в конфиг файле.
Окей, grub запустил ядро. Что дальше? Ядро начинает запускаться, находить устройства и загружать драйвера. Но для этого ядру нужны модули. Вспомните про модульность ядра – у ядра есть встроенные модули и загружаемые. Встроенные уже в самом файле vmlinuz, а загружаемые лежат в директории /lib/modules/. Ядро загрузит то что сможет, используя встроенные модули, а дальше ядру нужен доступ в директорию /lib/modules. Для этого ядро должно примонтировать корень. Только вот такой нюанс – для того, чтобы примонтировать корень, ядру нужны модули – как минимум, модуль scsi и модуль файловой системы. Давайте посмотрим список встроенных модулей (cat /lib/modules/$(uname -r)/modules.builtin | grep -e scsi -e ext4 ). Как видите, тут есть модули scsi, но нет модуля ext4. То есть ядро просто не сможет примонтировать корень, чтобы взять оттуда модули. При этом, чтобы эти модули были, ему нужно примонтировать корень.
Можно было бы встроить в ядро все нужные модули, но это сделает ядро значительно тяжелее, файловых систем много, да и если брать LVM и прочее.. ну в общем не выход. Эта проблема решается по другому. В grub под строкой с linux есть еще одна строка – initrd – initial ram disk. Как видите, она указывает на файл. Этот файл – ram disk – временный образ корня, который специально предназначен для решения указанной проблемы. При загрузке grub монтирует этот файл в качестве корня и ядро может с ним работать. Собственно здесь оно находит все нужные драйвера для того, чтобы загрузить настоящий корень, после чего ядро переключается на основной корень. Этот временный корень не содержит все файлы, а только необходимый минимум, какие-то драйвера файловых систем и т.п., чтобы можно было перейти на нужный корень. Но в каких-то дистрибутивах сюда включены чуть ли не все драйвера и некоторые программы. И если у вас какие-то проблемы с корнем, не получается монтировать, или, например, вы хотите сделать fsck корня, то используя этот временный корень вы можете провести какие-то работы.
Но на самом деле, если присмотреться, файл называется не initrd, а initramfs – initial ram file system. Initramfs пришел на замену initrd, так как у initrd есть определённые недостатки. Например, initrd был файлом образом блочного устройства, внутри которого была файловая система, а значит ядру для работы с ним нужен был хотя бы один встроенный модуль файловой системы. Initramfs это больше архив, который распаковывается в виртуальную файловую систему tmpfs. А tmpfs является частью ядра, предназначенной для всяких файловых систем, работающих в оперативке. Так вот, когда ядро видит initramfs, оно берёт оттуда нужные модули, а также запускает программу, ну или просто скрипт с названием init. Она может выполнять какие-то команды, если этого захотели разработчики дистрибутива, и в итоге монтирует настоящий корень и переключается на него. Есть небольшие отличия в работе между initrd и initramfs, но такие подробности нам сейчас не нужны.
Так вот, после всей этой инициализации, когда ядро взяло нужные модули из initramfs, init запускает программу /sbin/init в настоящем корне, которая стартует систему инициализации. Система инициализации – это отдельная тема, которую будем разбирать в следующий раз. Пока что мы разобрали только один сценарий BIOS – MBR – GRUB – стандартный раздел. Давайте вкратце пройдёмся по нему – BIOS грузит загрузчик из MBR на 446 байт, это первый этап загрузки GRUB-а. Дальше GRUB грузит свой второй этап, ссылаясь на /boot/grub. Полностью загруженный GRUB видит в конфигах путь к ядру и initramfs, загружает ядро и initramfs в оперативку, ядро подгружает нужные модули благодаря initramfs, запускает init, который в итоге переключается на реальный корень и запускает программу /sbin/init – то есть систему инициализации. В других сценариях в целом многое будет схоже, но отличия всё же есть, давайте их разберём.
Заменим стандартный раздел на LVM. Допустим, корень у нас в LVM. Чтобы grub мог загрузить ядро и initramfs, ему нужен доступ в директорию /boot, но если они находятся на LVM разделе, grub не сможет их увидеть. В таких случаях директорию /boot выносили на отдельный стандартный раздел. Благодаря чему grub мог загрузить ядро и initramfs со стандартного раздела, а дальше ядро находило в initramfs модули для LVM и могло примонтировать реальный корень.
Но так было раньше, со старой версией Grub, которая сейчас называется grub-legacy. Современная версия grub называется grub2 и она поддерживает LVM, благодаря чему нет необходимости выносить /boot на отдельный раздел.
Если заменить BIOS на UEFI, то отпадает необходимость в загрузчике в MBR. При включении UEFI ищет раздел EFI system parititon и загружает оттуда bootx64.efi или grubx64.efi . А это запускает grub, который обращается к файловой системе, где находится директория /boot/grub и дальше всё как мы говорили.
Давайте посмотрим, как всё организовано на нашей виртуалке. Virtualbox для гостевых машин использует BIOS. Таблица разделов у нас dos, т.е. используется MBR (sudo fdisk -l /dev/sda). Ну и если посмотреть файловые системы (mount | gred sda), можно увидеть, что boot вынесен в отдельный раздел, а для корня используется LVM (mount | grep “ / “). При этом grub у нас второй версии (ls /boot/grub2). Если вы слушали внимательно, вы помните, что grub2 поддерживает LVM, и выносить /boot на стандартный раздел не нужно. Но официально RedHat рекомендует держать /boot всё таки на стандартном разделе. Объяснения почему я не нашел, но, предполагаю, что дело в решении проблем. Если у вас возникнут проблемы с LVM, вы не сможете загрузить даже ядро с initramfs, потому что они лежат на логическом разделе, вам придётся использовать live-cd. Стандартный раздел для /boot позволит вам прогрузить хотя бы ядро с initramfs. Хотя, возможно, есть и другие причины, но о причинах в документации ничего не сказано.
Ну и напоследок, давайте немного подредактируем grub. Хотя сам конфиг это /boot/grub2/grub.cfg (sudo cat /boot/grub2/grub.cfg ), вручную редактировать этот файл не стоит, он будет перезаписываться при обновлениях. Чтобы наши изменения оставались даже после обновления, нужно редактировать файл /etc/default/grub (sudo nano /etc/default/grub). Например, уберём rhgb и quiet в строчке GRUB_CMDLINE_LINUX и сохраним. После этого нужно обновить конфиг файл grub-а. Сначала убеждаемся, что всё нормально, просто запускаем команду grub2-mkconfig. Если всё нормально, то мы увидим будущий конфиг. Затем перенаправляем вывод этой команды в файл /boot/grub2/grub.cfg (sudo grub2-mkconfig | sudo tee /boot/grub2/grub.cfg ). Ну и для проверки можем перезагрузиться. Как видите, наши изменения сработали.
Ну и если говорить про initramfs, стоит упомянуть возможность добавлять в него определённые модули. Пример из практики – у вас есть виртуальная машина на гипервизоре ESXi, это такой коммерческий гипервизор от компании VMWare. И вам нужно перенести виртуальную машину на гипервизор KVM – свободный гипервизор, активно используемый в Linux-ах. Если вы просто перенесёте файлы, скорее всего у вас виртуальная машина просто не запустится. Причина – ядро виртуалки при запуске просто не увидит корень, у вас не будет дисков sda, sdb и т.д. Чтобы ядро увидело диски, ему нужны будут другие драйвера scsi – virtio. Но они не встроены ни в ядро (cat /lib/modules/$(uname -r)/modules.builtin | grep virtio), ни в initramfs (sudo lsinitrd /boot/initramfs-$(uname -r).img | grep virtio). Список модулей в initramfs можно увидеть с помощью команды lsinitrd /boot/initramfs-$(uname -r).img . Ну и чтобы добавить эти модули в initramfs, нужно создать файл в /etc/dracut.conf.d/ c каким-то названием .conf и списком необходимых модулей (add_drivers+=” virtio_blk virtio_scsi “ ). Ну и сгененировать новый образ initramfs (sudo dracut -f -v /boot/initramfs-$(uname -r).img $(uname -r) ). После чего можем убедиться, что новые модули будут в initramfs (sudo lsinitrd /boot/initramfs-$(uname -r).img | grep virtio).
Подводя итоги. Сегодня мы с вами разобрали, как операционная система запускается – куда обращаются BIOS и UEFI, что такое загрузчик и какова его роль, зачем нужна директория /boot, почему ядро и initramfs находятся в этой директории, ну и что такое initramfs.
В этой небольшой серии статей я попытаюсь пролить свет на тему построения Embedded Linux устройств, начиная от сборки загрузчика и до написания драйвера под отдельно разработанный внешний модуль с автоматизацией всех промежуточных процессов.
Платформой послужит плата BeagleBone Black с процессором производства Техасских Инструментов AM3358 и ядром Arm Cortex-A8, и, чтобы не плодить мигающие светодиодами мануалы, основной задачей устройства будет отправка смайлов в топовый чат, широко известного в узких кругах, сайта, в соответствии с командами от смайл-пульта. Впрочем, без мигания светодиодами тоже не обошлось.
Итак, на столе лежит чистая, т.е. без каких-либо предустановленных дистрибутивов, плата BeagleBone Black, блок питания, переходник USB-UART. Для общения с платой, переходник нужно подключить к 6-ти выводному разъему, где первый вывод обозначен точкой - это GND, выводы 4/5 - RX/TX соответственно. После установки скорости в какой-либо терминальной программе, например putty, на 115200, можно взаимодействовать с платой, о подключении подробнее и с картинками здесь.
Топовые чаты, пульты и светодиоды будут позже, а сейчас на плату подается питание и плата отвечает CCCCCCCCCCC
В переводе с бутлоадерского это означает, что первичному загрузчику, зашитому в ROM процессора, нечего загружать. Ситуацию проясняет Reference Manual, где на странице 5025 в разделе 26.1.5 описана процедура начальной загрузки. Процедура такая: первичный загрузчик проводит некоторую инициализацию: тактирование процессора, необходимой периферии, того же UART, и, в зависимости от логических уровней на выводах SYSBOOT, строит приоритетный список источников где можно взять следующий загрузчик, т.е. посмотреть сначала на MMC карте, SPI-EEPROM или сразу ждать данных по Ethernet.
Я использую способ загрузки с помощью SD карты, вот что говорит об этом раздел RM 26.1.8.5.5 на странице 5057: первичный загрузчик сначала проверяет несколько адресов 0x0/ 0x20000/ 0x40000/ 0x60000 на наличие так называемой TOC структуры, по которой он может определить загрузочный код, если так код не найти, то первичный загрузчик, предполагая на SD карте наличие файловой системы FAT, будет искать там файл с названием MLO, как это расшифровывается в RM не сказано, но многие склоняются что Master LOader. Возникает резонный вопрос, где же взять этот MLO?
Das U-Boot
Das U-Boot или просто U-Boot - Universal Boot Loader, один из самых, если не самый, распространенный загрузчик для встроенных систем, именно с его помощью можно создать требуемый вторичный загрузчик (MLO), который будет загружать третичный загрузчик (сам U-Boot), который будет загружать ядро Linux.
Перед скачиванием U-Boot, стоит сходить в репозиторий и найти тег последней версии, далее
U-Boot содержит больше тысячи конфигураций, в том числе нужную:
Это конфигурация платы AM335x evaluation module, этот модуль лежит в основе других плат, в том числе BeagleBone Black, что можно видеть, к примеру, по Device Tree, но о нем позже. Настраивается и собирается U-Boot с помощью Kconfig, то же, что используется и при сборке ядра Linux.
Установка нужного конфига:
Можно, к примеру, убрать, установленную по умолчанию, 2-х секундную задержку при загрузке платы с U-Boot
Boot options ---> Autoboot options ---> (0) delay in seconds before automatically booting
В вышеуказанных командах, используется компилятор по умолчанию, если таковой в системе установлен, и, скорее всего, он не подходит для ARM процессоров, и здесь пора упомянуть о кросскомпиляции.
ARM Toolchain
Один из видов кросскомпиляции это сборка на одной архитектуре, как правило x86-64, именуемой HOST, исходного кода для другой, именуемой TARGET. Например, для TARGET архитектуры ARMv7-A, ядра ARM CortexA-8 процессора AM3358, платы BeagleBone Black. К слову, чтобы не запутаться в ARM’ах, даже есть свой справочник, так их много и разных.
Сама сборка осуществляется набором инструментов - компилятор, компоновщик, runtime библиотеки, заголовочные файлы ядра; так называемый Toolchain. Toolchain можно собрать самостоятельно либо с помощью crosstool-NG, а можно взять готовый от компании Linaro, или самой ARM. Здесь я буду использовать Toolchain от ARM “GNU Toolchain for the A-profile Architecture Version 10.2-2020.11, x86_64 Linux hosted cross compilers, AArch32 target with hard float (arm-linux-none-gnueabihf)", если не вдаваться в излишние подробности, то это все означает, что набор инструментов будет работать на десктопной машине с Linux и собирать программы для 32-х битной ARM платформы с аппаратной поддержкой операций с плавающей запятой.
Теперь для успешной сборки U-Boot, нужно указать в переменных ARCH и CROSS_COMPILE требуемые архитектуру и путь к кросскомпилятору соответственно, например так
Либо использовать export ARCH/CROSS_COMPILE , чтобы каждый раз не набирать все это. Я, для наглядности, буду каждый раз набирать все это.
После сборки U-Boot, в папке появятся необходимые файлы, а именно
MLO - вторичный загрузчик (напомню, первичный зашит в самом процессоре)
u-boot.img - третичный загрузчик, собственно U-Boot
Для успешной загрузки с SD карты, нужно ее некоторым образом разметить. Карта должна содержать минимум два раздела, первый, отмеченный как BOOT, с файловой системой FAT, второй раздел с ext4. Разметить карту можно, к примеру, программой fdisk.
Теперь нужно просто скопировать результаты сборки U-Boot в FAT раздел, вставить карту в BeagleBone Black и в терминале наблюдать уже более осознанный ответ платы
В ответе платы есть такие строки
Failed to load ‘boot.scr’
Failed to load ‘uEnv.txt’
U-Boot, во время загрузки, смотрит наличие дополнительных команд, сначала в файле boot.scr, при его наличии, затем, если boot.scr не нашлось, в uEnv.txt. Эти файлы, помимо очередности при поиске, отличаются тем, что в файле uEnv.txt, дополнительные команды представлены в текстовом виде, т.е. он проще для восприятия и редактирования. U-Boot не создает файлы с дополнительными командами, делать это нужно самостоятельно.
Здесь происходят некоторые манипуляции в результате которых U-Boot загружает из SD карты в RAM по адресу [loadaddr] - образ ядра [zImage], и по адресу [fdtaddr] - дерево устройств [Flattened Device Tree]. Формируются аргументы, передаваемые ядру Linux, это параметры консоли, к которой подключен переходник USB-UART [console=ttyS0,115200n8], место размещения корневой файловой системы [bootpartition=mmcblk0p2], параметры разрешения на чтение/запись корневой файловой системы [rw], ее тип [ext4] и ожидание появления корневой файловой системы [rootwait]. Чтобы раскрутить всю цепочку действий U-Boot, можно, после того как U-Boot прекратит попытки найти что бы загрузить и выдаст приглашение на работу в виде =>, ввести команду printenv , она покажет значения всех переменных, которыми располагает U-Boot.
В завершении своей работы U-Boot, командой bootz , вместе с вышеуказанными аргументами и адресом дерева устройств, передает управление ядру Linux.
Ядро Linux
Прежде чем приступать к любым действиям с ядром, стоит заглянуть сюда и убедится в наличии необходимых пакетов. Следующим шагом нужно определиться с тем, какую версию ядра использовать. Здесь я использую версию 5.4.92 и вот по каким соображениям. Одной из основных причин того, что не стоит брать просто последнюю версию ядра, доступную на данный момент, наряду с наличием драйверов, является невозможность быстро протестировать это ядро на всем разнообразии платформ поддерживаемых Linux, а значит можно потратить кучу сил и времени на исправление неполадок, если что-то пойдет не так, и не факт что это вообще получится сделать. BeagleBone Black имеет официальный репозиторий, где можно найти версию ядра, протестированную на данной платформе, и long term версия 5.4.92 была последней на тот момент.
Нужный конфиг, расположенный в /arch/arm/configs, называется omap2plus_defconfig, OMAP - это название линейки процессоров, продолжением которых является AM3358, впринципе, подойдет и более общий multi_v7_defconfig.
Сам конфиг пока остается без изменений, поэтому можно просто его установить и запустить компиляцию ядра(zImage), модулей(modules) и дерева устройств(dtbs)
Проходит некоторое время.
Результат сборки, в виде zImage, находится в /arch/arm/boot, там же в папке /dts находится скомпилированное дерево устройств am335x-boneblack.dtb, оба отправляются на SD карту к файлам загрузчика. На этом FAT раздел SD карты можно считать скомплектованным. Итого, там присутствуют:
MLO - вторичный загрузчик
u-boot.img - третичный загрузчик
uEnv.txt - дополнительные команды загрузчика
zImage - образ ядра Linux
am335x-boneblack.dtb - скомпилированное дерево устройств платы
Еще при сборке ядра заказывались модули ядра, но они уже относятся к корневой файловой системе.
Корневая файловая система. BusyBox
Ядро получает корневую файловую систему путем монтирования блочного устройства, заданного в, переданном при запуске ядра, аргументе root=, и далее, первым делом, исполняет оттуда программу под названием init.
Если запустить BeagleBone Black, имея только вышеуказанные файлы для FAT раздела, то ядро будет паниковать по причине отсутствия init и, в целом, по причине пустой rootfs, т.е. корневой файловой системы.
Можно шаг за шагом создать все минимально необходимые компоненты корневой файловой системы, такие как оболочка, различные демоны запускаемые init, сам init, конфигурационные файлы, узлы устройств, псевдофайловые системы /proc и /sys и просто системные приложения. Для желающих совершать подобные подвиги, существует проект Linux From Scratch, здесь же я воспользуюсь швейцарским ножом встроенных систем с Linux, утилитой BusyBox.
Скачивание последней, на тот момент, версии:
Настройка конфигурации по умолчанию:
Чтобы не думать сейчас о разделяемых библиотеках, стоит установить статическую сборку BusyBox:
Settings ---> Build static binary (no shared libs)
Установка в папку по умолчанию _install:
Теперь в папке _install можно видеть будущую корневую файловую систему, в которую нужно добавить некоторые вещи.
Папки, помимо созданных BusyBox:
Стартовый скрипт. Дело в том, что, запускаемая в первую очередь, программа init, делает много полезного, например, выводит в консоль приглашение, но до выдачи приглашения, init проверяет наличие стартового скрипта /etc/init.d/rcS, и, при наличии, запускает его.
Этот скрипт монтирует псевдофайловые системы proc и sysfs, и ничего не мешает ему запускать, к примеру, пользовательскую программу, отвечающую за функционал устройства, но лучше будет делать это в отдельных скриптах, скомпонованных по функциональному назначению.
Стоит сказать, что работа init, на самом деле, начинается с чтения конфигурационного файла /etc/inittab, но BusyBox’овская init включает таблицу inittab по умолчанию, если таковой не окажется в корневой файловой системе.
Теперь пора вспомнить про модули ядра. Их также нужно разместить в корневой файловой системе в /lib/modules/5.4.92/, но сейчас они разбросаны по всей папке в которой собиралось ядро. Чтобы собрать модули в кучу, нужно в папке с ядром выполнить
Где в INSTALL_MOD_PATH указать путь к папке с корневой файловой системой, кросскомпилятор указывать не нужно, т.к. здесь модули ядра просто копируются по месту назначения. В результате папка /lib корневой файловой системы пополнится разделом /lib/mudules/5.4.92/ содержащим модули ядра, полученные при компиляции ядра.
Осталось скопировать все содержимое папки _install во второй раздел SD карты, тот который с ext4, и поменять владельца всего содержимого на root.
После запуска BeagleBone Black с корневой файловой системой, через 1.910315 секунды после старта ядра, система предложит активировать консоль и начать работу.
Но начать работу в такой системе, скорее всего не получится, т.к. в ней нет ничего кроме системных утилит BusyBox и моей небольшой программы, нарисовавшей приветствие, зато, эта система поможет получить общее представление о том, какая магия происходит внутри подобных устройств. Именно общее, т.к. в реальных устройствах, из-за необходимости минимизации времени загрузки, ограниченности ресурсов, заточенности под конкретную задачу, различий между ARM процессорами, построение системы может сильно отличаться. Например, на малинке, вообще сначала стартует графический процессор, который затем запускает все остальное.
По поводу же заявленных в начале драйверов, взаимодействия с внешними устройствами, автоматизации сборки и некоторого полезного функционала, пойдет рассказ в следующей статье.
Маркетинг и продажи: даю удочку, а не рыбу запись закреплена
Второй раз за неделю ночью прилетает вот такое в Инсте. И приходит смс со ссылкой и ещё с кодом. Что это такое, кто знает?И как поступить?
После 1 эпизода сменила пароль в Инсте и включила двухфакторную авторизацию.
Сейчас снова все менять? И менять только в Инсте или ещё где-то?
Постоянно меняю пароли
Никто не знает что это)))
Если используете сторонние сервисы, требующие пароль от Инстаграма, то возможно через них утекает пароль.
Может быть фишинг. Ненастоящее уведомление, которое заставляет вас слить им пароль.
Показать полностью.
Как быть:
- поменять пароль
- установить достаточно сложный пароль
- почистить браузерные экстеншены
- настроить двухфакторную аутентификацию
- не ходить по ссылкам
- не вводить нигде свой пароль (на сторонних сервисах или в устрашающих письмах)
adb devices
fastboot devices
Если что-то неправильно, то в списке подключенных устройств (List of devices attached) будет пусто.
Скрытые команды ADB
adb -d Команда посылается только на устройство подключенное через USB.
Внимание: Выдаст ошибку, если подключено больше одного устройства.
adb -e Команда посылается на устройство в эмуляторе.
Внимание: Выдаст ошибку, если подключено больше одного эмулятора.
adb -s Команда посылается на устройство с указанным серийным номером:
adb -p Команда посылается на устройство с указанным именем:
Если ключ -p не указан, используется значение переменной ANDROID_PRODUCT_OUT.
adb devices Список всех подсоединенных устройств.
adb connect [: ] Подсоединиться к андроид хосту по протококу TCP/IP через порт 5555 (по умолчанию, если не задан).
adb disconnect [ [: ]] Отсоединиться от андроид подключенного через TCP/IP порт 5555 (по умолчанию, если не задан).
Если не задан ни один параметр, отключиться от всех активных соединений.
adb push Копировать файл/папку PC->девайс.
adb pull [ ] Копировать файл/папку девайс->PC.
adb sync [ ] Копировать PC->девайс только новые файлы.
Ключи:
-l Не копировать, только создать список.
adb shell Запуск упрощенного unix shell.
Примеры использования
adb emu Послать команду в консоль эмулятора
adb install [-l] [-r] [-s] Послать приложение на устройство и установить его.
Пример: adb install c:/adb/app/autostarts.apk Установить файл autostarts.apk лежащий в папке /adb/app/ на диске с:
Ключи:
-l Блокировка приложения
-r Переустановить приложение, с сохранением данных
-s Установить приложение на карту памяти
Установка split apk
adb uninstall [-k] Удаление приложения с устройства.
Ключи:
-k Не удалять сохраненные данные приложения и пользователя.
adb wait-for-device Ждать подключения устройства.
Вы используете Instagram для развлечения или работы?adb start-server Запустить службу/демон.
adb kill-server Остановить службу/демон.
adb get-state Получить статус:
offline Выключен.
bootloader В режиме начальной загрузки.
device В режиме работы.
adb get-serialno Получить серийный номер.
adb status-window Непрерывный опрос состояния.
adb remount Перемонтировать для записи. Требуется для работы скриптов, которые изменяют данные на.
adb reboot bootloader Перезагрузка в режим bootloader.
adb reboot recovery Перезагрузка в режим recovery.
adb root Перезапуск демона с правами root
adb usb Перезапуск демона, прослушивающего USB.
adb tcpip Перезапуск демона, прослушивающего порт TCP.
adb ppp [параметры] Запуск службы через USB.
Note: you should not automatically start a PPP connection. refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1
Параметры:
defaultroute debug dump local notty usepeerdns
fastboot devices Список присоединенных устройств в режиме fastboot.
fastboot flash Прошивает файл .img в раздел устройства.
fastboot erase Стереть раздел.
Разделы: boot, recovery, system, userdata, radio
Пример: fastboot erase userdata Стирание пользовательских данных.
fastboot update Прошивка из файла имя_файла.zip
fastboot flashall Прошивка boot + recovery + system.
fastboot getvar Показать переменные bootloader.
Пример: fastboot getvar version-bootloader Получить версию bootloader.
fastboot flash:raw boot [ ] Создать bootimage и прошить его.
fastboot devices Показать список подключенных устройств.
fastboot continue Продолжить с автозагрузкой.
fastboot reboot Перезагрузить аппарат.
f astboot reboot-bootloader Перезагрузить девайсв режим bootloader.
Перед командами fastboot можно использовать ключи:
-w стереть данные пользователя и кэш
-s Указать серийный номер устройства.
-p
Указать название устройства.
-c Переопределить kernel commandline.
-i Указать вручную USB vendor id.
-b Указать в ручную базовый адрес kernel.
-n
Указать размер страниц nand. по умолчанию 2048.
Прошивка радио. Переименовываем радио в radio.img и кладем его в папку ADB.
@echo off
fastboot reboot-bootloader
echo После загрузки bootloader нажмите любую клавишу.
pause
fastboot flash radio radio.img
fastboot reboot
Восстановление прошивки из бэкапа.
@echo off
fastboot reboot-bootloader
echo После загрузки bootloader нажмите любую клавишу.
pause
fastboot flash userdata data.img
fastboot flash system system.img
fastboot flash boot boot.img
fastboot reboot
Прошивка анимации при загрузке Качаем бутанимацию. Переименовываем файл в bootanimation.zip и кладем его в папку ADB.
@echo off
adb remount
adb push bootanimation.zip /data/local Получение SuperCID (Дебрендинг
@echo off
adb devices
fastboot reboot-bootloader
echo После загрузки bootloader нажмите любую клавишу.
pause
fastboot oem writecid 11111111
fastboot reboot-bootloader
fastboot getvar cid
fastboot reboot
Прошивка рекавери. Распаковываем образ рекавери. Переименовываем файл в recovery.img и кладем его в папку с ADB.
@echo off
fastboot reboot-bootloader
echo После загрузки bootloader нажмите любую клавишу.
pause
fastboot flash recovery recovery.img
fastboot reboot
Прошивка загрузочного раздела Переименовываем кусок прошивки отвечающий за загрузку в boot.img и кладем его в папку ADB.
@echo off
fastboot reboot-bootloader
echo После загрузки bootloader нажмите любую клавишу.
pause
fastboot flash boot boot.img
fastboot reboot
Следует обратить внимание что задав переменную окружения ANDROID_LOG_TAGS она не будет работать в эмуляторе/устройстве, если вы будете использовать logcat в удаленном shell или используя adb shell logcat.
Вышеописанная команда export работает в ОС *nix и не работает в Windows.
Контроль формата вывода лога
При запуске logcat можно указать формат вывода используя параметр -v:
adb logcat [-v
Каждый раз, когда вы включаете свой компьютер с Linux, он проходит ряд этапов, прежде чем, наконец, отобразится экран входа в систему, который запрашивает ваше имя пользователя или пароль. Существует 4 различных этапа, которые каждый дистрибутив Linux проходит в типичном процессе загрузки.
В этом руководстве мы выделим различные шаги, предпринятые ОС Linux с момента включения до момента входа в систему. Обратите внимание, что это руководство сфокусировано на загрузчике GRUB2 и systemd init, поскольку они используются в настоящее время подавляющим большинством современных дистрибутивов Linux. Но существуют и другие загрузчики, например, дистрибутивы на основе Arch Linux используют systemd-boot.
Процесс загрузки состоит из следующих 4 шагов, которые мы обсудим более подробно:
- Инициализация системы: UEFI или BIOS (POST)
- Запуск загрузчика (GRUB2 или systemd-boot)
- Инициализация ядра
- Запуск systemd, родителя всех процессов
1. Инициализация системы: UEFI или BIOS
Инициализация системы под UEFI
- Система включена, выполняется самотестирование при включении (POST).
- После POST UEFI инициализирует оборудование, необходимое для загрузки (диск, контроллеры клавиатуры и т. д.).
- Прошивка считывает загрузочные записи в NVRAM, чтобы определить, какое приложение EFI запускать и откуда (например, с какого диска и раздела).
- Загрузочной записью может быть просто диск. В этом случае микропрограмма ищет системный раздел EFI на этом диске и пытается найти приложение EFI в резервном загрузочном пути \EFI\BOOT\BOOTX64.EFI (BOOTIA32.EFI в системах с IA32 (32-разрядным) UEFI). Так работают загрузочные съёмные носители UEFI.
- Прошивка запускает приложение EFI.
- Это может быть загрузчик или само ядро Arch, использующее EFISTUB.
- Это может быть какое-то другое приложение EFI, такое как оболочка UEFI, или менеджер загрузки, например systemd-boot или rEFInd.
Если включена безопасная загрузка, процесс загрузки будет проверять подлинность двоичного файла EFI по подписи.
Инициализация системы под BIOS
- Система включена, выполняется самотестирование при включении (POST).
- После POST BIOS инициализирует оборудование, необходимое для загрузки (диск, контроллеры клавиатуры и т. д.).
- BIOS запускает первые 440 байтов (область кода начальной загрузки основной загрузочной записи) первого диска в порядке дисков BIOS.
- Затем первый этап загрузчика в загрузочном коде MBR запускает свой второй этап (если есть) из одного из следующих источников:
- следующие секторы диска после MBR, то есть так называемый промежуток после MBR (только в таблице разделов MBR).
- загрузочная запись тома раздела или диска без разделов (VBR).
- загрузочный раздел BIOS (только GRUB в BIOS/GPT).
- Запускается фактический загрузчик.
- Затем загрузчик загружает операционную систему путём последовательной или прямой загрузки ядра операционной системы.
Проверка целостности BIOS (POST)
Процесс загрузки обычно инициализируется, когда пользователь нажимает кнопку включения — если ПК уже был выключен — или перезагружает систему с помощью графического интерфейса или командной строки.
Когда система Linux включается, включается BIOS (базовая система ввода-вывода) и выполняет самотестирование при включении (POST). Это проверка целостности, которая выполняет множество диагностических проверок.
В некоторых случаях раздаётся звуковой сигнал, особенно в случае отсутствия модуля RAM. Однако, если ожидаемое оборудование присутствует и функционирует должным образом, процесс загрузки переходит к следующему этапу.
2. Загрузчик (GRUB2 или systemd-boot)
Если компьютер запускает UEFI, то обычно она запускает приложение EFI, обычно располагающееся по пути \EFI\BOOT\BOOTX64.EFI (/boot/EFI/BOOT/BOOTX64.EFI) на загрузочном диске.
Если это BIOS, то после завершения POST, BIOS проверяет MBR (главную загрузочную запись) на предмет загрузчика и информации о разделах диска.
MBR — это 512-байтовый код, расположенный в первом секторе жёсткого диска, обычно это /dev/sda или /dev/hda, в зависимости от архитектуры вашего жёсткого диска. Обратите внимание, однако, что иногда MBR может находиться на Live USB или DVD-диске Linux.
В Linux существует 2 основных типа загрузчиков: GRUB2 и systemd-boot. Загрузчик GRUB2 — распространён в дистрибутивах на основе Debian. Загрузчик systemd-boot применяется в Arch Linux и основанных на этой ОС дистрибутивах.
Загрузчик GRUB2
GRUB2 означает GRand Unified Bootloader version 2. Как только BIOS обнаруживает загрузчик grub2, он запускается и загружает его в основную память (RAM).
Современный GRUB2 может работать и с UEFI (с помощью efibootmgr). В Arch Linux поддержка BIOS и UEFI собрана в один пакет grub. В Debian и производных дистрибутивах GRUB представлен двумя версиями:
Меню grub2 позволяет вам делать несколько вещей. Оно позволяет вам выбрать версию ядра Linux, которую вы хотите использовать. Если вы несколько раз обновляли свою систему, вы можете увидеть в списке разные версии ядра. Кроме того, он даёт вам возможность редактировать некоторые параметры ядра, нажимая комбинацию клавиш клавиатуры.
Кроме того, в настройке с двойной загрузкой, когда у вас есть несколько установок ОС, меню grub позволяет вам выбрать, в какую ОС загружаться. Файл конфигурации grub2 — это файл /boot/grub2/grub2.cfg. Основная цель GRUB — загрузить ядро Linux в основную память.
Загрузчик systemd-boot
systemd-boot (сокращенно sd-boot) — простой менеджер загрузки UEFI. Он предоставляет графическое меню для выбора записи для загрузки и редактор командной строки ядра. Systemd-boot поддерживает системы только с прошивкой UEFI.
systemd-boot загружает информацию о загрузочной записи из системного раздела EFI (ESP), обычно монтируемого в /efi/, /boot/ или /boot/efi/ во время запуска ОС, а также из расширенного раздел загрузчика, если он существует (обычно монтируется в /boot/). Фрагменты файла конфигурации, ядра, initrds и другие образы EFI для загрузки обычно должны находиться на ESP или разделе расширенного загрузчика. Ядра Linux должны быть собраны с CONFIG_EFI_STUB, чтобы их можно было напрямую запускать как образ EFI. Во время загрузки systemd-boot автоматически собирает список загрузочных записей из следующих источников:
- Загрузочные записи, определённые с помощью файлов описания спецификации загрузчика, расположенных в /loader/entries/ на ESP и в разделе расширенного загрузчика. Обычно они описывают образы ядра Linux со связанными образами initrd, но также могут описывать произвольные другие исполняемые файлы EFI.
- Унифицированные образы ядра в соответствии со спецификацией загрузчика в виде исполняемых двоичных файлов EFI в /EFI/Linux/ на ESP и в разделе расширенного загрузчика.
- Диспетчер загрузки Microsoft Windows EFI, если он установлен.
- Диспетчер загрузки Apple MacOS X, если он установлен.
- Бинарный файл EFI Shell, если он установлен
- Перезагрузка в опцию настройки прошивки UEFI, если она поддерживается.
systemd-boot поддерживает следующие функции:
3. Инициализация ядра
Ядро — это основа любой системы Linux. Он связывает оборудование ПК с базовыми процессами. Ядро контролирует все процессы в вашей системе Linux. После того как выбранное ядро Linux загружено загрузчиком, оно должно самораспаковаться из сжатой версии перед выполнением любой задачи. После самораспаковывания выбранное ядро монтирует корневую файловую систему и инициализирует программу /sbin/init, обычно называемую init.
Init всегда запускается первой программой, и ей назначается ID процесса или PID 1. Это процесс init, который порождает различных демонов и монтирует все разделы файловых систем, указанные в файле /etc/fstab.
Затем ядро монтирует начальный RAM-диск (initrd), который является временной корневой файловой системой, пока не будет смонтирована настоящая корневая файловая система. Все ядра находятся в каталоге /boot вместе с начальным образом RAM-диска.
4. запуск Systemd
Наконец, ядро загружает Systemd, заменяющий старый SysV init. Systemd является матерью всех процессов Linux и управляет, среди прочего, монтированием файловых систем, запуском и остановкой служб, и это лишь некоторые из её функций.
Systemd использует файл /usr/lib/systemd/system/default.target для определения состояния или цели, в которую должна загружаться система Linux.
- Для настольной рабочей станции (с графическим интерфейсом пользователя) целевое значение по умолчанию graphical.target.
- Для сервера целью по умолчанию является multi-user.target.
Вот виды целей systemd:
- poweroff.target: выключение системы.
- rescue.target: запускает сеанс спасательной оболочки.
- multi-user.target: настраивает систему на неграфическую (консольную) многопользовательскую систему.
- graphical.target: настройка системы на использование графического многопользовательского интерфейса с сетевыми службами.
- reboot.target: перезагружает систему.
Чтобы проверить текущую цель в вашей системе, выполните команду:
Вы можете переключаться с одной цели на другую, выполнив на терминале следующую команду:
Эта команда переводит систему в неграфическое состояние (после перезагрузки).
А эта команда возвращает в загрузку в графический интерфейс:
Процесс загрузки завершается, когда systemd загружает все демоны и устанавливает значение целевого уровня или уровня выполнения. Именно в этот момент вам будет предложено ввести имя пользователя и пароль, после чего вы получите доступ к своей системе Linux.
Читайте также: