Linux image extra virtual debian

Ставим Ubuntu из другого Linux/LiveCD

Речь в статье пойдёт об установке Ubuntu из другого Linux без использования ISO-образа. Нужно это прежде всего для создания кастомизированных тестовых окружений. Информации о такой процедуре в интернете достаточно, она легко гуглится, но, как выяснилось, в некоторых моментах существующие инструкции устарели, да, и все они обладают известным фатальным недостатком.

Итак, постановка задачи: есть голая виртуальная машина с выходом в интернет и EFI BIOS, есть некий линукс (в нашем случае это SystemRescue LiveCD), нужно получить установленную Ubuntu. И все действия должны быть легко автоматизированы, что их можно оформить в виде скрипта.

Прежде всего загружаемся в наш SysRCD. Работать мы будем по SSH, и чтобы он заработал, нужно установить пароль root и разрешить SSH в iptables (изначально в SysRCD запрещены любые входящие соединения):

И подключаемся по SSH:

Теперь нужно подготовить разделы на жёстком диске. Так как система у нас EFI, то таблица разделов будет GPT, нужен EFI FAT-раздел, а сама система будет находится на ext4-разделе. EFI-раздел может очень небольшим — буквально 10 МБ, но для стабильной работы обновлений системы лучше делать его хотя бы 32 МБ. И важное замечание! Во всех инструкциях написано, что раздел должен быть в формате FAT32, но на практике VirtualBox отказывается работать с маленьким EFI-разделом в таком формате (ну, или mkfs.vfat неправильно форматирует маленькие FAT32 разделы — тут нужны эксперименты)! Плюс, есть нюансы с размером диска, размером кластера и совместимостью с EFI биосами. Поэтому форматировать будем в FAT16. Разбивать будем при помощи parted.
Для того, чтобы пометить раздел как служебный EFI в parted ему нужно выставить флаг «esp».

Теперь форматируем вновь созданные разделы. Ещё раз обращаю внимание, что EFI-раздел форматируем в FAT16, иначе могут проблемы с VirtualBox.

Разворачивать базовую систему будет при помощи debootstrap. Но у нас не DEB-система и эта утилита отсутствует. Скачаем её из репозитория Debian и распакуем содержимое DEB-файла прямо в корень нашей системы. У нас LiveCD и такой грязный хак вполне приемлем. DEB-файлы это архивы типа AR, содержащие архивы типа «tar.gz».

Ставить будем Ubuntu 20.04 «Focal» — имя релиза указывается при вызове deboostrap. там же указывается репозиторий, откуда будут скачаны файлы.

Для разворачивания системы, нам естественно, нужно сначала примонтировать её корень в какую-то папку. Не мудрствуя лукаво используем для этого папку «/tmp/».

Теперь нам нужно настроить список репозиториев, откуда будут браться устанавливаемые и обновляемые пакеты. Список находится в файле /etc/apt/sources.list

Теперь настраиваем chroot-окружение и входим в нашу новую систему:

Первым делом настраиваем поддерживаемые локали. Обратите внимание, что добавляется CP866 (на самом деле она «IBM866»), которая до сих пор бывает актуальной при работе со windows-legacy данными.

Список поддерживаемых кодировок хранится в /etc/locale.gen Ещё раз обращаю внимание, что CP866/IBM866 по умолчанию там по какой-то причине нет, хотя в системе она есть.

Обновляем список пакетов и сразу ставим mc, aptitude, чтобы жить стало легче.

EFI раздел будет примонтирован в /boot/efi. Монтируем и настраиваем /etc/fstab.

Настраиваем часовой пояс. То же самое можно выполнить вызовом «dpkg-reconfigure tzdata«. Но нам же нужно, чтобы это можно было заскриптовать. Просмотреть список часовых поясов можно вызовом «timedatectl list-timezones».

Указываем, что аппаратные часы у нас хранят время в UTC. Обратите внимание, что «0» означает время в UTC.

Ставим ядро, дополнительные модули и заголовки ядра. Ядро ставим самое свежее из доступных и заточенное под виртуализацию:

Ставим поддержку консоли, сети, GRUB, SSH и всякие мелкие утилиты:

Это так же можно сделать в интерактивном режиме выполнив:
dpkg-reconfigure console-common
dpkg-reconfigure console-data
dpkg-reconfigure keyboard-configuration

Ставим GRUB на EFI-раздел:

Если нужно, то правим настройки GRUB в файле /etc/default/grub и обновляем конфигурацию GRUB вызовом:

Обновляем образ ядра, чтобы подхватились настройки консоли:

Задаём пароль root и разрешаем авторизацию root в SSH по паролю. Это нужно для того, чтобы можно было подключиться первый раз и залить SSH-ключи.
Для этого в файле настроек SSH-сервера /etc/ssh/sshd_config нужно добавить строку:
PermitRootLogin yes
Позже авторизацию root по паролю нужно не забыть запретить.

Задаём настройки сетевых подключений. У нас netplan и networkd. Не забываем прописывать актуальные значения MAC-адресов адаптеров. На первом адаптере ставим статический адрес, а на второй работает DHCP (это NET-подключение к интернет). Обратите внимание, что IPv6 отключается указанием «link-local: [ ]» в настройках подключения.

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

Всё! Можно перегружаться и при загрузке с жёсткого диска загрузится уже наша свежеустановленная система.

Если это виртуальная машина VirtualBox, то после перезагрузки нужно ещё желательно поставить дополнения, подключаем «Guest Additions CD Image» и выполняем из-под нашей новой системы:

На этом всё. Дальше нужно подключиться по SSH и залить SSH ключи пользователей. После чего удалить настройку «PermitRootLogin yes» из /etc/ssh/sshd_config.

Если кому-то интересно, то вот такой образ Ubuntu 20.04 занимает 2.2 ГБ дискового пространства.

Источник

Для чего нужен пакет linux-image-extra и нужен ли он мне?

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

2 ответа

Этот ответ устарел для современных выпусков Ubuntu

Без пакета extra большинство аппаратных средств не будет работать!

Он содержит дополнительные драйверы, оставленные вне пакета базового ядра; устанавливайте его, только если вам нужны эти драйверы

Иногда, конкретный вариант linux-образа уменьшается, удаляя менее распространенные модули ядра (драйверы). В этом случае пакет linux-image-extra просто содержит все «лишние» модули ядра, которые были опущены.

Официально, это происходит только для изображения -virtual ; Наиболее распространенные гипервизоры (Virtualbox, VMWare, Xen, KVM) эмулируют четко определенный и ограниченный набор оборудования, поэтому хорошей идеей является удаление ненужных драйверов, которые увеличивают размер ядра / initrd. Вы всегда можете получить их обратно, установив пакет дополнений.

Команда ядра также, кажется, приняла этот метод для некоторых ядер mainline-PPA -generic ; рассуждения и решения остаются прежними — если похоже, что в базовом образе ядра отсутствует нужный модуль, установите дополнения.

Насколько я знаю, вышеупомянутый подход не был принят для Квантовых ядер — затрагивается только -виртуал , как обычно.

Источник

Использование ядер linux-virtual на гостевой машине под VirtualBox

Я собираюсь установить себе Ubuntu для учебных целей и экспериментов под VirtualBox.

В качестве хостовой системы будет выступать «Kubuntu 12.10 64-bit».

В репозиториях Ubuntu есть ядра linux-virtual, linux-image-virtual.

Стоит ли после установки системы под VirtualBox перейти на гостевой системе на их использование?

Наличие слова «virtual» не означает, что это особое ядро, которое нужно ставить в случае, если у вас система установлена в виртуальной машине.

Вы бы хоть почитали описание пакета:

Костик! Ну научись ты уже читать!

А что же это за пакет? Прочтём описание к тому пакету, на который он ссылается:

This package will always depend on the latest minimal generic kernel image used for virtual instances.

Костик! virtual instances прочёл?

Наличие слова «virtual» не означает, что это особое ядро, которое нужно ставить в случае, если у вас система установлена в виртуальной машине.

This package will always depend on the latest kernel image available for virtual machines.

Ты успел прочитать latest kernel image available for virtual machines, Костик?

на этот раз я погуглил за тебя, Джеффрик!

Мда, ну посмотрите содержимое пакета и научитесь уже читать и понимать то, что написно: http://packages.ubuntu.com/quantal/amd64/linux-image-virtual/filelist

Ещё раз, когда вы ставите этот пакет при обновлении системы у вас будет устанавливаться последнее доступное ядро в приведённой ссылке http://packages.ubuntu.com/quantal/linux-image-virtual будет устанавливаться на данные момент ядро linux-image-3.5.0-25-generic, когда выйдет следующее ядро, какое-нибудь linux-image-3.6.0-1-generic установится оно.

А если вы поставите жёстко пакет linux-image-3.5.0-25-generic то при выходе ядра, к примеру linux-image-3.6.0-1-generic у вас устанвоелнный пакет с ядром не обновиться.

Зачем виртуалбокс ? Есть же квм.

А по сабжу: не нужно. Необходимы хедеры ядра и сконпелять гостевые аддоны

И нашёл какой-то бред. Ключевые слова по ссылкам: «I don’t really know» и «I’m not aware of any tuning for performance or any functional difference that way». Информативно, аж жуть!

Ты это серьёзно что-ли? Ладно, разжёвываю ещё раз:

Пакет linux-virtual тянет по зависимостям эти два пакета:

linux-image-virtual и linux-headers-virtual

Читаем о предназначении этих пакетов:

This package will always depend on the latest kernel image available for virtual machines.

Слышишь, Костян: kernel image available for virtual machines. Это важно.

linux-image-virtual — ядро специально заточенное под работу в виртуальных машинах вроде VirtualBox и другие. Драйверы железа там заточены под виртуальные железки, все ненужное выкинуто, оптимизировано под аппаратную виртуализацию.

Ну не тупите вы уже, друзья!

бложик не доказательство

Слышишь, Костян: kernel image available for virtual machines. Это важно.

Сходи по приведённой мной ссылке http://packages.ubuntu.com/quantal/linux-image-virtual , на информацию о пакете из Ubuntu Quantal (12.10) и прочитай описание пакета:

This package will always depend on the latest minimal generic kernel image

Ни какого упоминания о том, что это ядро именно для виртуальных машин нет.

Такие ядра есть в дебиане. Стандартное+поддержка для квм, или +для другой конкретной виртуалки.

Ни какого упоминания о том, что это ядро именно для виртуальных машин нет.

Хорошо. По твоей ссылке щёлкни обзор это же пакета, только для precise http://packages.ubuntu.com/precise/linux-image-virtual Заметил? Linux kernel image for virtual machines.

у вас фгм. это не лечится.

по первой ссылке сказано, что там выкинуты почти все дрова. по второй то же самое, только в Официальном Источнике (тм).

дважды два сложить ты не осилил.

Ты не осилил даже ответ на поставленный вопрос:

Стоит ли после установки системы под VirtualBox перейти на гостевой системе на их использование?

Источник

Linux image extra virtual debian

JItsi BRoadcasting Infrastructure

Jibri provides services for recording or streaming a Jitsi Meet conference.

It works by launching a Chrome instance rendered in a virtual framebuffer and capturing and encoding the output with ffmpeg. It is intended to be run on a separate machine (or a VM), with no other applications using the display or audio devices. Only one recording at a time is supported on a single jibri.

• Jibri was built on ubuntu 16.04 (Xenial), and has been tested with the pre-built kernel and extra kernel modules ( linux-image-extra-virtual package). Any other distribution or kernel configuration MAY work but has not been tested.

ALSA and Loopback Device

• First make sure the ALSA loopback module is available. The extra modules (including ALSA loopback) can be installed on Ubuntu 16.04 using package name linux-image-extra-virtual
• Perform the following tasks as the root user
  • Set up the module to be loaded on boot: echo «snd-aloop» >> /etc/modules
  • Load the module into the running kernel: modprobe snd-aloop
  • Check to see that the module is already loaded: lsmod | grep snd_aloop
• If the output shows the snd-aloop module loaded, then the ALSA loopback configuration step is complete.

Ffmpeg with X11 capture support

• Jibri requires a relatively modern ffmpeg install with x11 capture compiled in. This comes by default in Ubuntu 16.04, by installing the ffmpeg package.
• If building Jibri for Ubuntu 14.04 (trusty), the mc3man repo provides packages. They can be used by the following in Ubuntu 14.04:

Google Chrome stable & Chromedriver

The latest Google Chrome stable build should be used. It may be able to be installed direclty via apt, but the manual instructions for installing it are as follows:

Add chrome managed policies file and set CommandLineFlagSecurityWarningsEnabled to false . It will hide warnings in Chrome. You can set it like so:

Chromedriver is also required and can be installed like so:

Miscellaneous required tools

See the debian control file for the dependencies that are required. These can be installed using the following: sudo apt-get install default-jre-headless ffmpeg curl alsa-utils icewm xdotool xserver-xorg-video-dummy

Jitsi Debian Repository

The Jibri packages can be found in the stable repository on downloads.jitsi.org. First install the Jitsi repository key onto your system:

Create a sources.list.d file with the repository:

Update your package list:

Install the latest jibri

• Jibri is currently meant to be run as a regular system user. This example creatively uses username ‘jibri’ and group name ‘jibri’, but any user will do. This has not been tested with the root user.
• Ensure that the jibri user is in the correct groups to make full access of the audio and video devices. The example jibri account in Ubuntu 16.04 are: «adm»,»audio»,»video»,»plugdev».

• Edit the jibri.conf file (installed to /etc/jitsi/jibri/jibri.conf by default) appropriately. You can look at reference.conf for the default values and an example of how to set up jibri.conf. Only override the values you want to change from their defaults in jibri.conf .

By default, Jibri logs to /var/log/jitsi/jibri . If you don’t install via the debian package, you’ll need to make sure this directory exists (or change the location to which Jibri logs by editing the log config

Configuring a Jitsi Meet environment for Jibri

Jibri requires some settings to be enabled within a Jitsi Meet configuration. These changes include virtualhosts and accounts in Prosody, settings for the jitsi meet web (within config.js) as well as jicofo sip-communicator.properties .

Create the internal MUC component entry. This is required so that the jibri clients can be discovered by Jicofo in a MUC that’s not externally accessible by jitsi meet users. Add the following in /etc/prosody/prosody.cfg.lua :

Create the recorder virtual host entry, to hold the user account for the jibri chrome session. This is used to restrict only authenticated jibri chrome sessions to be hidden participants in the conference being recordered. Add the following in /etc/prosody/prosody.cfg.lua :

Setup the two accounts jibri will use.

The first account is the one Jibri will use to log into the control MUC (where Jibri will send its status and await commands). The second account is the one Jibri will use as a client in selenium when it joins the call so that it can be treated in a special way by the Jitsi Meet web UI.

Источник