8-900-374-94-44
[email protected]
Slide Image
Меню

Список пакетов entware: File doesn’t exist — Bitbucket

Содержание

Добавляем поддержку репозитория Entware на Android-боксе / Проекторы, ТВ, ТВ-боксы и приставки / iXBT Live

Для работы проектов iXBT.com нужны файлы cookie и сервисы аналитики. Продолжая посещать сайты проектов вы соглашаетесь с нашей Политикой в отношении файлов cookie

Entware — это менеджер ПО для встраиваемых систем, который открывает доступ к огромному количеству (более 1500) пакетов программ для Linux, расширяя возможности устройства, на котором он установлен. Чаще всего поддержкой Entware обладают продвинутые маршрутизаторы.

Зачем и кому вообще может понадобиться Entware на Android-боксе? Конечно, всё это для гиков и пытливых пользователей. Для тех, кто ищет, как ещё можно расширить функциональность своего бокса, как переложить определённые задачи на Android-бокс. Возьмите для простого примера топовые маршрутизаторы Keenetic Ultra или Keenetic Giga, которые сделаны на достаточно мощном SoC MediaTek MT7621AT (2 ядра MIPS1004Kc 880 МГц). А у вас в тумбочке под ТВ может простаивать большую часть времени копеечный китайский бокс с SoC Amlogic S912 (8 ядер ARM Cortex-A53 до 1,5 ГГц). Торрент-клиент Transmission на Keenetic Ultra выжмет 6-11 Мбайт/с максимум. А тот же Transmission, установленный из Entware, на боксе легко выжмет под 30 Мбайт/с, ограничиваясь лишь скоростью интерфейса USB 2.0. А может вам нужна удалённая система с доступом по SSH для простых экспериментов. Например, с интерпретатором Python, Ruby, PHP, Perl. Бокс легко с этим справится.

Никаких изменений в самой системе Android (TV) не произойдёт. Вам не нужно будет отдельно ставить Linux на бокс, специально перезагружать его в эту систему. Вы буду продолжать пользоваться Android (TV), как и раньше. А в фоне появится возможность использовать инструменты из Entware.


Содержание

  • Полная инструкция по установке
  • Простая инструкция по установке
  • Удаление Entware
  • Пример использования
Полная инструкция по установке

  • Не на все боксы можно установить Entware, но на большинство.
    Причины разные.
  • В системе на боксе должен быть root-доступ.
  • В системе на боксе должна быть поддержка скриптов init.d (метод добавления такой поддержки индивидуален для каждого бокса).

Основная сложность установки Entware на некоторых Android-устройствах — это «кривая» штатная программа wget (из busybox), которая не позволит вам развернуть Entware, или её отсутствие. opkg использует эту программу. Вам придётся самостоятельно найти подходящий «бинарник» wget и добавить его в систему, если вы столкнётесь с проблемой. Или просто поставить «правильный» BusyBox. Избежать этого можно, если вы воспользуетесь «Простой инструкцией по установке» — там разворачивается уже предустановленная система Entware (с предустановленным пакетом wget).

Разворачивать Entware будем во внутренней пользовательской памяти бокса. Чаще всего она доступна по пути «/data/media/0». При необходимости используйте другой путь или внешний носитель (он должен быть с файловой системой EXT3/4).

Установите программу Terminal Emulator. И запустите её.

Получите root-права:

su

Создайте папку entware внутри пользовательской памяти:

cd /data/media/0
mkdir entware

Для Entware нужны будут системные папки /bin и /opt, которых у вас нет. В bin будет находится ссылка на файл /system/bin/sh, а opt будет ссылаться на папку entware. Для их создания нужно будет временно разрешить запись в корневой папке.

mount -o rw,remount /
mkdir /opt
mkdir /bin
ln -s /system/bin/sh /bin/sh
mount -o ro,remount /
mount -o bind /data/media/0/entware /opt

Теперь вам нужно самостоятельно решить, для какой архитектуры устанавливать Entware — ARMv7 (32-разрядная) или AArch64 (64-разрядная). Зависит от того, какая у вас операционная система на боксе. Например, современные системы для Amlogic (как и процессоры) 64-разрядные.

Можете спокойно выбрать универсальный вариант ARMv7, он будет работать в обоих случаях.

wget http://bin.entware.net/armv7sf-k3.2/installer/alternative.sh

или

wget http://bin.entware.net/aarch64-k3.10/installer/alternative.sh
chmod +x alternative.sh

Установите Entware:

./alternative.sh

После установки нужно сделать небольшую корректировку. Некоторым программам из Entware может понадобиться файл /etc/resolv.conf, которого у вас в системе нет. Мы создадим ссылку на этот файл.

echo "nameserver 8.8.8.8" > /opt/etc/resolv.conf
echo "nameserver 8.8.4.4" >> /opt/etc/resolv.conf
/system/bin/mount -o rw,remount /system
ln -s /opt/etc/resolv.conf /system/etc/resolv.conf
/system/bin/mount -o ro,remount /system

Установите SSH-сервер (dropbear) и запустите основной скрипт Entware:

/opt/bin/opkg install dropbear
/opt/etc/init. d/rc.unslung start

Почти всё готово. Entware уже полноценно работает. Осталось только сделать скрипт 01entware для init.d, чтобы службы Entware запускались автоматически при старте системы. Terminal Emulator можно закрывать, он нам больше не нужен, как и прямой доступ к боксу.

Подключитесь по SSH к боксу. Для Windows можете использовать популярный клиент PuTTY. Пользователь: root, пароль: 12345. Пароль можете изменить с помощью команды passwd.


Установите Midnight Commander (в нём удобный редактор файлов).

opkg install mc

Нам нужно создать файл 01entware в папке init.d. Место нахождения этой папки зависит от вашей системы. Самый простой вариант, если у вас в системе используется SuperSU, это папка /system/su.d. Выставите разрешение на запуск для этого скрипта. Если у вас прошивка Ugoos AM3 2.x, то просто в настройках системы включите «Пользовательские скрипты» (Настройки > Системные > Пользовательские скрипты), а сам скрипт положите в папку init. d в корне пользовательской памяти. Дополнительные разрешения выставлять не нужно. Предположим, что у вас в системе есть SuperSU, мы воспользуемся su.d.

/system/bin/mount -o rw,remount /system
mkdir /system/su.d
mcedit /system/su.d/01entware

Вставьте содержимое (Shift + Insert):

Спойлер

#!/system/bin/sh

/system/bin/mount -o rw,remount /
/system/bin/mkdir /opt
/system/bin/mkdir /bin
ln -s /system/bin/sh /bin/sh
/system/bin/mount -o ro,remount /

/system/bin/mount -o bind /data/media/0/entware /opt

/system/bin/mount -o rw,remount /system
ln -s /opt/etc/resolv.conf /system/etc/resolv.conf
/system/bin/mount -o ro,remount /system

/opt/etc/init.d/rc.unslung start

Сохраните изменения (F2) и выйдите из редактора (F10).

chmod +x /system/su. d/01entware
/system/bin/mount -o ro,remount /system

Всё готово!

Простая инструкция по установке

Загрузите архив entware_armv7.tar.gz и поместите его в корень пользовательской памяти вашего бокса (распаковывать не надо). Это базовая, уже развёрнутая система Entware (armv7sf-k3.2) с установленными пакетами wget и dropbear (SSH). Загрузите скрипт 01entware. При необходимости измените путь к пользовательской памяти MEDIA_PATH внутри скрипта. Поместите скрипт в папку init.d. Место нахождения этой папки зависит от вашей системы. Самый простой вариант, если у вас в системе используется SuperSU, это папка /system/su.d (воспользуйтесь любым файловым менеджером с поддержкой root). Выставите разрешение на запуск для этого скрипта. Если у вас прошивка Ugoos AM3 2.x, то просто в настройках системы включите «Пользовательские скрипты» (Настройки > Системные > Пользовательские скрипты), а сам скрипт положите в папку init.

d в корне пользовательской памяти. Дополнительные разрешения выставлять не нужно.

Перезагрузите бокс. Готово, Entware у вас на боксе. Архив entware_armv7.tar.gz будет удалён автоматически. Если архив не удалён, значит вы выбрали неверную папку init.d (скрипты из которой не запускаются системой) или указали неверный путь MEDIA_PATH.

Подключитесь по SSH к боксу. Для Windows можете использовать популярный клиент PuTTY. Пользователь: root, пароль: 12345. Пароль можете изменить с помощью команды passwd.


Можете установить Midnight Commander и запустить его:

opkg install mc
mc

Может установить Python:

opkg install python3

Удаление Entware

  1. Удалите скрипт 01entware из папки init.d.
  2. Перезагрузите бокс.
  3. Удалите папку entware из пользовательской памяти.
Пример использования

Простой пример — Transmission. Подключитесь по SSH к боксу. Установите Transmission (демон и web-интерфейс):

opkg install transmission-web transmission-daemon-openssl

Установите сертификаты для трекеров, которые используют HTTPS:

opkg install ca-bundle ca-certificates

Установите mc для удобного редактирования файлов:

opkg install mc

На подключённом к боксу диске создайте папку, в которую будут загружаться торренты — Torrents. Идентификатор диска (или путь в целом) у вас будет свой (используйте буфер обмена, если путь сложный):

mkdir /mnt/media_rw/f6f7d733-7c2e-d401-80f3-d7337c2ed401/Torrents

Откройте конфигурационный файл Transmission:

mcedit /opt/etc/transmission/settings.json

Параметров у Transmission много. На досуге вы все сможете изучить и изменить (в том числе и через графическую оболочку на других устройствах). Для начала измените самые необходимые параметры:

"download-dir": "/mnt/media_rw/f6f7d733-7c2e-d401-80f3-d7337c2ed401/Torrents"
"peer-limit-global": 100
"peer-limit-per-torrent": 50
"port-forwarding-enabled": true

Вставлять из буфера в mcedit можно с помощью Shift + Insert. Сохраните изменения (F2) и выйдите из редактора (F10).

Осталось немного изменить скрипт запуска Transmission, чтобы демон запускался после того, как в системе будет смонтирован диск (топорно, но для примера сойдёт — вы потом напишите правильный способ), избегая лишних хлопот, например, когда есть незаконченные загрузки:

mcedit /opt/etc/init.d/S88transmission

После первой строчки добавьте следующие команды, заменив путь к вашей папке с торрентами на диске:

Спойлер

while [! -d «/mnt/media_rw/f6f7d733-7c2e-d401-80f3-d7337c2ed401/Torrents» ]
do
sleep 15
done

Сохраните изменения и выйдите из редактора.

Запустите Transmission (после перезагрузки бокса он будет запускаться автоматически):

/opt/etc/init.d/S88transmission start

Готово. Можете с любого устройства (в том числе и смартфона) подключаться к Transmission через web-интерфейс (http://IP_БОКСА:9091/transmission/web/ ). Можете в Windows, например, на ноутбуке использовать Transmission Remote GUI. Практически для всех платформ есть клиент для удалённого управления Transmission, т.к. программа очень популярная.



Или для примера можете поставить netdata.

opkg install netdata
/opt/etc/init.d/S60netdata start

С помощью браузера подключитесь к вашему боксу (порт 19999) и увидите детальную статистику по ресурсам бокса с диаграммами и графиками.


Или можете примонтировать Яндекс.Диск прямо в файловой системе бокса (можно добавить в автозагрузку).

opkg install wdfs
mkdir /data/media/0/yandex
wdfs https://webdav. yandex.ru /data/media/0/yandex -o accept_sslcert,username=******@yandex.ru,password='******',allow_other

Новости

Публикации

Колонка Tribit StormBox Blast имеет всего три недостатка — это цена, отсутствие микрофона и заряд через сетевой шнур. Звук не только громкий, но и светлый, с акцентом на середину, что отличает от…

Использование недорогих цифровых микроскопов существенно облегчает работу с мелкими деталями. Такие микроскопы позволяют детально рассмотреть предметы, делать фото, снимать видео, сохранять нужное…

TouYinger D8 – новая модель 1LCD проектора с нативным FHD разрешением, с поддержкой 4К видео (в качестве процессора выступает Amlogic T972 равный Amlogic S905X3), наличием автофокуса (с помощью…

Всем привет. Сегодня расскажу о доступном и популярном QLED телевизоре TCL C635 с диагональю 55 дюймов. Это относительно неплохой телевизор среднего класса с изображением, которое по качеству,…

Tribit StormBox Blast — это отличный выбор для тех, кто ищет портативную колонку с высоким качеством звука и длительным временем автономной работы. Данная модель обладает высокой мощностью и…

В этом обзоре я проверю аккумулятор TFN-PB-281-BK Solid 10 black. Полностью заряжу и разряжу его, узнаю его реальную ёмкость. Технические характеристики…

Менеджер пакетов opkg. Offline инсталляция пакетов в образ корневой файловой системы / Хабр

Широко известный в узких кругах легковесный менеджер пакетов opkg получил распространение в embedded Linux не случайно. Opkg используется во многих встраиваемых дистрибутивах и проектах, например, в OpenEmbedded, Yocto Project, OpenWRT, Ångström, Arago Project и некоторых других. Менеджер прост в эксплуатации, для полноценной работы вполне достаточно встроенной справки, а на просторах всемирной паутины множество статей о том, как устроен сам пакет ipk (opkg работает с таким форматом): как его создать, как установить и т.д и т.п. Однако подавляющее большинство информации посвящено тому, как работать на уже установленной на целевую платформу (target) системе в online-режиме, но специфика Embedded подразумевает, что образ корневой файловой системы, а также ядро готовятся заранее на некоторой инструментальной платформе (host), отличной от целевой. Иными словами, собираем ядро и файловую систему на рабочем компьютере, упаковываем в образ, образ тиражируем на железо. Эта статья посвящена тому, как с помощью менеджера opkg установить пакеты в подготавливаемый образ rootfs.

Путь граблей и велосипедов

Много лет назад в бытность инженера одного небольшого завода, когда я запустил Linux на первой платке собственного производства, с помощью opkg установил из удаленного репозитория все требуемые пакеты, настроил все приложения, начальник лаборатории сказал: «Отлично! Теперь сделай то же самое на всех устройствах в партии». «Да не вопрос!» – ответил я. Система же есть, она запущена, она работает. Копируем все файлы из корня на внешний носитель, затем упаковываем в образ и радуемся жизни! В то время я не понимал, что при работе операционная система выполняет ряд локальных настроек, создает временные файлы, файлы конфигурации, генерирует какие-то ключи, а при первом запуске выполняет еще и скрипты инициализации. Хотя перенос файлов с одной работающей системы на другую методом тупого копирования с носителя и давал результат, но эффективность данного метода очень скоро для меня стала сомнительной. Получить «чистую» систему таким образом невозможно: система помнит свою предыдущую жизнь в другом аппаратном теле, и время от времени ее душат фантомные боли.

Еще одна бредовая идея

На target смонтировать внешний накопитель с rootfs, выполнить chroot и ставить пакеты. Комментировать не буду.

Следующим шагом для меня стало понимание структуры самого покета *.ipk. По сути вещей, пакет ipk является архивом, распаковать который можно легко с помощью команды:

ar -x *.ipk

В результате получим:

 .
├── control.tar.gz
├── data.tar.gz
└── debian-binary 

В архиве data.tar.gz содержатся файлы, которые должны быть помещены в корневую директорию target’а.
В архиве control.tar.gz содержатся служебные файлы: файл с описанием и скрипты. Идея простая: так как ipk – это всего лишь архив со скриптами, то мы можем всегда руками распаковать его в директорию с файловой системой, а потом запустить (если есть в этом необходимость) скрипты. Вот только все зависимости пакета нам придется устанавливать также вручную.
А если зависимости имеют еще зависимости? Возникает идея, может быть написать скрипт для автоматизации процесса? Как это часто бывает в мире linux, если перед тобой возникла задача, то, скорее всего, такая задача возникла не перед тобой одним, и, скорее всего, ты в этом деле не первый.
Далеко ходить не пришлось, на самом деле в сам менеджер пакетов opkg заложен такой режим, когда пакеты устанавливаются в неактивную файловую систему rootfs. При этом, архитектура host-машины (где запускаются утилиты opkg) и target-машины могут быть отличными. Такой режим называется Offline mode. В таком режиме opkg становится мощнейшим инструментом кросс-разработки.

Собираем opkg для host

Для работы в режиме Offline opkg должен запускаться на host’е. С давних пор на моем рабочем компьютере обосновалась Ubuntu (сейчас стоит Ubuntu 14.04 LTS), на ней и будем строить наш инструментарий. Мне не удалось найти репозиторий с opkg для Ubuntu, потому собираем набор утилит из исходников.
Получить исходные коды можно с git репозитория Yocto Project:

    git clone git://git.yoctoproject.org/opkg.git
    cd opkg

Для тех кого пугает git

можно обойтись и без него. На момент написания статьи, актуальная версия утилиты – opkg-0.3.1. Качаем исходники с сайта и распаковываем:

tar xzf opkg-0.3.1.tar.gz
cd opkg-0.3.1/

На самом деле настройка и компиляция проекта выполняется достаточно стандартным способом, но есть некоторые нюансы, и потому все по порядку.
Запускаем:

./autogen.sh

На заметку: если запустить ./autogen.sh с параметром --clean, то удалятся все труды по конфигурации проекта.
После выполнения ./autogen.sh в директории с исходниками появляется скрипт configure, он выполнит настройку пакета, определит и задаст системозависимые переменные. В результате работы скрипта создается Makefile. Посмотреть все опции скрипта можно стандартным способом:

./configure --help

Собирать пакет будем под текущую платформу, потому опции настройки кросс-компиляции пропускаем. Озаботимся инсталляцией. По умолчанию, выполнив make install, скрипт раскидает все полезные файлы (бинарники, скрипты, документация) по корневой директории: /etc, /usr/local, а это нам совершенно ни к чему. Мы ведь не собираемся использовать opkg для настройки пакетов в текущей системе? Кроме того, установив менеджер в системные папки, для использования утилит потребуются права суперпользователя, на мой взгляд, это излишне при настройке образа embedded linux. Скрипт configure.sh позволяет задать префикс для директории установки пакета. Указав в качестве префикса любую рабочую директорию, мы сообщим инсталлятору куда ставить пакет. При необходимости можно отдельно задать префикс для архитектурозависимых (бинарники и библиотеки) и архитектуронезависимых (скрипты и документация) файлов.
С фантазией у меня всегда было слабовато, потому для инсталляции в домашнем каталоге создадим каталог opkg_offline.

mkdir ${HOME}/opkg_offline

Выполним конфигурацию:

./configure --prefix=${HOME}/opkg_offline

При необходимости доставляем требуемые зависимости. Так мне на Ubuntu 14.04 для успешной сборки понадобилось доставить libarchive-dev, libcurl4-gnutls-dev, libssl-dev, libgpgme11-dev.

А как это сделать?

sudo apt-get install libarchive-dev
sudo apt-get install libcurl4-gnutls-dev
sudo apt-get install libssl-dev
sudo apt-get install libgpgme11-dev

Компилируем и устанавливаем opkg:

make  
make install  

В результате в директории opkg_offline имеем:

opkg_offline
├── bin
│   ├── opkg
│   ├── opkg-check-config
│   └── opkg-key
├── lib
│   ├── libopkg. a
│   ├── libopkg.la
│   ├── libopkg.so -> libopkg.so.1.0.0
│   ├── libopkg.so.1 -> libopkg.so.1.0.0
│   ├── libopkg.so.1.0.0
│   └── pkgconfig
│       └── libopkg.pc
└── share
├── man
│   └── man1
│       ├── opkg.1
│       └── opkg-key.1
└── opkg
└── intercept
├── depmod
├── ldconfig
└── update-modules

Менеджер пакетов собран и установлен. Исполняемые файлы находятся в директории opkg_offline/bin. Для работы с ними можно в переменную PATH прописать путь, либо для каждой сессии терминала вызывать экспорт (export), либо делать как я делаю – перейти в каталог opkg_offline и запустить непосредственно ./bin/opkg.

Краткий курс анатомии

Коротко рассмотрим как работает менеджер пакетов в стандартном режиме. После выполнения команды opkg update, утилита читает файлы конфигураций, которые по умолчанию расположены в /etc/opkg и имеют расширение . conf. Из этих файлов система определяет тип архитектуры, например armv5hf-vfp или armv5tehf-vfp (поддерживаемых архитектур может быть несколько, для каждой можно задать приоритет), список репозиториев и некоторые настройки самой программы. Далее для каждого репозитория из списка скачивается архив типа *_Packages.gz. Архивы по умолчанию помещаются в директорию var/cache/opkg/. После распаковки содержимое помещается в var/lib/opkg/lists. В каждом архиве лежит текстовый файл со списком пакетов в репозитории. Для каждого пакета помимо названия указана версия, архитектура, размер, краткое описание, лицензия, а самое главное – зависимости. На основании этих файлов менеджер пакетов по запросу может выдать информацию о требуемом пакете, а при его установке определить все зависимости и разрешить их.
Команда opkg list выдаст все доступные для установки пакеты; команда opkg list-installed покажет только установленные пакеты, команда opkg info покажет информацию об указаном пакете, а если он установлен, то и время установки.
Для установки пакета следует выполнить opkg install packname. В результате требуемый пакет из репозитория будет скачен во временную директрию и распокован. Все файлы из архива data.tar.gz разойдутся по своим местам в rootfs, а на основании содержимого control.tar.gz в каталоге var/lib/opkg/info будут созданы служебные файлы: packname.control – полная информация о пакете, packname.list — список директорий, по которым разошлись файлы из data.tar.gz (по этому списку пройдется opkg при удалении пакета), и файлы скриптов, типа packname.postinst, packname.preinst, packname.prerm, packname.postrm, назначения которых понятны из названия. Информация об установленном пакете будет добавлена в файле var/lib/opkg/status в виде (пример для популярного minicom):

Package: minicom
Version: 2.6.2-r0.2
Depends: libtinfo5 (>= 5.9), libc6 (>= 2.17)
Status: install ok installed
Architecture: armv7ahf-vfp-neon
Installed-Time: 1454529423

Важно обратить внимание на Status. Если пакет был установлен по всем правилам: все файлы скопированы на свое место, все скрипты выполнены, то статус будет Status: install ok installed. При работе в режиме offline все файлы будут скопированы, но скрипты не выполнятся, такие пакеты будут помечены как Status: install ok unpacked.
На этот случай в opkg предусмотрен специальный механизм пост конфигурации пакетов. Запускается он командой opkg configure <packname>. Если указать имя определенного пакета, то будут выполнены скрипты из var/lib/opkg/info для этого пакета; если имя опустить, то менеджер произведет конфигурацию для всех пакетов, у которых статус Status: install ok unpacked. Таким образом, при установке пакетов на host в режиме offline, при первой загрузке операционной системы на target следует выполнить opkg configure. Доверить это можно либо специальному скрипту, либо, если используется systemd, специальному сервису.

Работа с целевой rootfs

Настало время попробовать систему в деле. Для примера установим эмулятор терминала последовательного порта minicom.
Для установки пакетов нам понадобится распакованный образ корневой файловой системы целевой платформы rootfs. Предположим, что в rootfs установлен менеджер opkg, a в директории etc/opkg существуют файлы конфигурации *.conf. Если же его там нет, или по какой-то причине мы не хотим использовать конфигурацию из rootfs, мы можем через параметр указать какой файл настроек использовать: -f etc/opkg/opkg.conf. Путь к целевой файловой системе передаем через параметр --offline-root /path/to/rootfs.
Обновляем списки пакетов:

bin/opkg update --offline-root /path/to/rootfs

Просматриваем список доступных пакетов, ищем minicom.

bin/opkg list --offline-root ~/board/rootfs/angstrom/rootfs-v2015. 10 | grep minicom
minicom - 2.7-r0.0 - Text-based modem control and terminal emulation program  Minicom is a
minicom-dbg - 2.7-r0.0 - Text-based modem control and terminal emulation program - Debugging files
minicom-dev - 2.7-r0.0 - Text-based modem control and terminal emulation program - Development
minicom-doc - 2.7-r0.0 - Text-based modem control and terminal emulation program - Documentation

Смотрим информацию о пакете:

bin/opkg info minicom --offline-root ~/board/rootfs/angstrom/rootfs-v2015.10
    Package: minicom
    Version: 2.7-r0.0
    Depends: libtinfo5 (>= 5.9), libc6 (>= linaro-2.20)
    Status: unknown ok not-installed
    Section: console/network
    Architecture: armv7at2hf-vfp-neon
    Maintainer: Angstrom Developers <[email protected]>
    MD5Sum: e4d11b7277fbc1c7db6bbd97ac52ca2c
    Size: 79354
    Filename: minicom_2.7-r0.0_armv7at2hf-vfp-neon.ipk
    Description: Text-based modem control and terminal emulation program  Minicom is a text-based modem control and terminal emulation program for Unix-like operating systems

Устанавливаем пакет:

bin/opkg install minicom --offline-root ~/board/rootfs/angstrom/rootfs-v2015. 10

В файле var/lib/opkg появилась запись:

    Package: minicom
    Version: 2.7-r0.0
    Depends: libtinfo5 (>= 5.9), libc6 (>= linaro-2.20)
    Status: install user unpacked
    Architecture: armv7at2hf-vfp-neon
    Installed-Time: 1454594718

После того, как с созданного образа была запущена система и отработала команда opkg configure, запись в файле изменилась:

    Package: minicom
    Version: 2.7-r0.0
    Depends: libtinfo5 (>= 5.9), libc6 (>= linaro-2.20)
    Status: install user installed
    Architecture: armv7at2hf-vfp-neon
    Installed-Time: 1454594718

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

rm -rvf  ~/board/rootfs/angstrom/rootfs-v2015. 10/var/cache/opkg/*  
rm -rvf  ~/board/rootfs/angstrom/rootfs-v2015.10/var/lib/opkg/lists/*

На заметку: опция --volatile-cache позволит очистить кэш автоматически при завершении работы.

Вместо заключения

Несмотря на работоспособность, у Offline mode есть некоторые недостатки. Дело в том, что команда opkg configure запускает на выполнение только \*.postinst, но остается нерешенным вопрос с выполнением скриптов \*.preinst. В силу того, что \*.preinst встречается достаточно редко в пакетах, для меня является приемлемым в ручном режиме просмотреть скрипты, и при необходимости отработать их при первом запуске целевой системы (специальны service для systemd). Буду благодарен за совет.

Почитать по теме:


  • IPK-пакет или с чем его едят
  • OpenWrt.OPKG Package Manager. Наиболее внятный help.
  • Yocto Project. Репозиторий. Исходники

hibernate — выберите сущность по умолчанию, когда существуют две или более сущности с одинаковым именем — Spring Boot, Spring Data JPA,

Задавать вопрос

спросил

Изменено 7 лет, 9 месяцев назад

Просмотрено 11 тысяч раз

Я использую jpa данных spring для сохранения. Есть ли способ, при котором один объект может быть помечен как используемый по умолчанию, если существует более одного объекта с одним и тем же именем. Что-то вроде аннотации @Primary, используемой для решения проблемы множественных зависимостей bean-компонентов

 @Entity(name = "ORGANIZATION")
@Table(имя = "ОРГАНИЗАЦИЯ")
открытый класс DefaultOrganization {
     ***
}
@Entity(имя = "ОРГАНИЗАЦИЯ")
@Table(имя = "ОРГАНИЗАЦИЯ")
организация общественного класса {
     ***
}
 

Обновлено

Поясню. Я использую аннотацию spring-boot @EntityScan, которая выполняет сканирование пакета, если два объекта с одинаковым именем найдены в двух разных пакетах, тогда должен быть способ, при котором только один объект выбирается и регистрируется, а другой отклоняется. Что касается имен сущностей, то даже я знаю, что не может быть двух сущностей с одинаковыми именами. Я спрашиваю об этом в контексте spring-boot и spring-data-jpa

 @Entity(name = "ORGANIZATION")
@Table(имя = "ОРГАНИЗАЦИЯ")
@PrimaryEntity
открытый класс DefaultOrganization {
     ***
}
@Entity(имя = "ОРГАНИЗАЦИЯ")
@Table(имя = "ОРГАНИЗАЦИЯ")
организация общественного класса {
     ***
}
 

Поскольку DefaultOrganization помечен @PrimaryEntity, DefaultOrganization должен быть выбран с помощью @EntityScan, а Организация должна быть отклонена.

Note : @PrimaryEntity is non JPA Standard custom annotation that can be processed by spring-boot @EntityScan

  • spring
  • hibernate
  • jpa
  • spring-boot
  • spring-data-jpa

4

Невозможно иметь повторяющееся имя для двух разных сущностей в одном проекте, даже если сущности находятся в двух разных пакетах.

Ссылка 1

Имена классов объектов

По умолчанию имя объекта представляет собой неполное имя класса объектов (т. е. короткое имя класса без имени пакета). Другое имя объекта можно задать явно, используя атрибут name аннотации Entity:

 @Entity(name="MyName")
открытый класс MyEntity {
}
 

Имена объектов должны быть уникальными. Когда два класса сущностей в разных пакетах имеют одно и то же имя класса, во избежание конфликта требуется явная установка имени сущности.

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но никогда не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Справочник по инструментам EF Core (Консоль диспетчера пакетов) — EF Core

  • Статья
  • 9 минут на чтение

Инструменты консоли диспетчера пакетов (PMC) для Entity Framework Core выполняют задачи разработки во время разработки. Например, они создают миграции, применяют миграции и генерируют код для модели на основе существующей базы данных. Команды выполняются внутри Visual Studio с помощью консоли диспетчера пакетов. Эти инструменты работают как с проектами .NET Framework, так и с проектами .NET Core.

Если вы не используете Visual Studio, вместо этого мы рекомендуем инструменты командной строки EF Core. Инструменты .NET Core CLI являются кроссплатформенными и запускаются в командной строке.

Установка инструментов

Установите инструменты консоли диспетчера пакетов, выполнив следующую команду в консоли диспетчера пакетов :

 Install-Package Microsoft.EntityFrameworkCore.Tools
 

Обновите инструменты, выполнив следующую команду в консоли диспетчера пакетов 9. 0018 .

 Пакет обновления Microsoft.EntityFrameworkCore.Tools
 

Проверьте установку

Убедитесь, что инструменты установлены, выполнив следующую команду:

 Get-Help about_EntityFrameworkCore
 

Вывод выглядит следующим образом (он не говорит вам, какую версию инструментов вы используете):

                     _/\__
               ---==/ \\
         ___ ___ |. \|\
        | __|| __| | ) \\\
        | _| | _| \_/ | //|\\
        |___||_| / \\\/\\
ТЕМА
    about_EntityFrameworkCore
КРАТКОЕ ОПИСАНИЕ
    Предоставляет сведения об инструментах консоли диспетчера пакетов Entity Framework Core.
<Список доступных команд здесь опущен.>
 

Использование инструментов

Перед использованием инструментов:

  • Поймите разницу между целевым и стартовым проектом.
  • Узнайте, как использовать инструменты с библиотеками классов .NET Standard.
  • Для проектов ASP.NET Core задайте среду.

Целевой и запускаемый проект

Команды относятся к проекту и стартовому проекту .

  • Проект также известен как целевой проект , потому что именно здесь команды добавляют или удаляют файлы. По умолчанию проект по умолчанию , выбранный в консоли диспетчера пакетов , является целевым проектом. Вы можете указать другой проект в качестве целевого проекта, используя параметр -Project .

  • Стартовый проект — это проект, который создается и запускается инструментами. Инструменты должны выполнять код приложения во время разработки, чтобы получить информацию о проекте, такую ​​как строка подключения к базе данных и конфигурация модели. По умолчанию Startup Project в Solution Explorer — это запускаемый проект. Вы можете указать другой проект в качестве запускаемого, используя параметр -StartupProject .

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

  • Контекст EF Core и классы сущностей находятся в библиотеке классов . NET Core.
  • Консольное или веб-приложение .NET Core ссылается на библиотеку классов.

Также можно поместить код миграции в библиотеку классов отдельно от контекста EF Core.

Другие целевые платформы

Инструменты консоли диспетчера пакетов работают с проектами .NET Core или .NET Framework. Приложения с моделью EF Core в библиотеке классов .NET Standard могут не иметь проекта .NET Core или .NET Framework. Например, это верно для приложений Xamarin и универсальной платформы Windows. В таких случаях вы можете создать проект консольного приложения .NET Core или .NET Framework, единственная цель которого — выступать в качестве стартового проекта для инструментов. Проект может быть фиктивным проектом без реального кода — он нужен только для предоставления цели для инструментов.

Зачем нужен фиктивный проект? Как упоминалось ранее, инструменты должны выполнять код приложения во время разработки. Для этого им необходимо использовать среду выполнения . NET Core или .NET Framework. Если модель EF Core находится в проекте, предназначенном для .NET Core или .NET Framework, инструменты EF Core заимствуют среду выполнения из проекта. Они не могут этого сделать, если модель EF Core находится в библиотеке классов .NET Standard. Стандарт .NET не является реальной реализацией .NET; это спецификация набора API, которые должны поддерживать реализации .NET. Поэтому .NET Standard недостаточно, чтобы инструменты EF Core могли выполнять код приложения. Пустой проект, который вы создаете для использования в качестве стартового проекта, предоставляет конкретную целевую платформу, в которую инструменты могут загружать библиотеку классов .NET Standard.

Среда ASP.NET Core

Среду для проектов ASP.NET Core можно указать в командной строке. Этот и любые дополнительные аргументы передаются в Program.CreateHostBuilder.

 Update-Database -Args '--environment Production'
 

Общие параметры

В следующей таблице показаны параметры, общие для всех команд EF Core:

Параметр Описание
-Контекст Класс DbContext для использования. Только имя класса или полное имя с пространствами имен. Если этот параметр опущен, EF Core находит класс контекста. Если имеется несколько классов контекста, этот параметр является обязательным.
-Проект Целевой проект. Если этот параметр опущен, в качестве целевого проекта используется проект по умолчанию для консоли диспетчера пакетов .
-StartupProject Запуск проекта. Если этот параметр опущен, в качестве целевого проекта используется стартовый проект в свойствах решения .
-Args <Строка> Аргументы, переданные приложению.
-Подробный Показать подробный вывод.

Чтобы показать справочную информацию о команде, используйте PowerShell Команда Get-Help .

Tip

Параметры Context , Project и StartupProject поддерживают расширение табуляции.

Add-Migration

Добавляет новую миграцию.

Параметры:

Параметр Описание
-Name Имя миграции. Это позиционный параметр, и он является обязательным.
-OutputDir <строка> Каталог, используемый для вывода файлов. Пути относятся к целевому каталогу проекта. По умолчанию «Миграции».
-Пространство имен Пространство имен, используемое для сгенерированных классов. По умолчанию генерируется из выходного каталога.

Общие параметры перечислены выше.

Bundle-Migration

Создает исполняемый файл для обновления базы данных.

Параметры:

Параметр Описание
-Вывод Путь создаваемого исполняемого файла.
- Сила Перезаписать существующие файлы.
- Автономный Также упакуйте среду выполнения .NET, чтобы ее не нужно было устанавливать на машину.
-TargetRuntime <строка> Целевая среда выполнения, для которой выполняется пакет.
-Каркас Целевая структура. По умолчанию первый в проекте.

Общие параметры перечислены выше.

Drop-Database

Удаляет базу данных.

Параметры:

Параметр Описание
-Что если Показать, какая база данных будет удалена, но не удалять ее.

Общие параметры перечислены выше.

Get-DbContext

Выводит список и получает информацию о доступных типах DbContext .

Общие параметры перечислены выше.

Get-Migration

Список доступных миграций.

Параметры:

Параметр Описание
-Соединение Строка подключения к базе данных. По умолчанию используется значение, указанное в AddDbContext или OnConfiguring.
-Без подключения Не подключаться к базе данных.

Общие параметры перечислены выше.

Optimize-DbContext

Создает скомпилированную версию модели, используемой DbContext .

Дополнительную информацию см. в разделе Скомпилированные модели.

Параметры:

Параметр Описание
-OutputDir Каталог для размещения файлов. Пути относятся к каталогу проекта.
-Пространство имен Пространство имен, используемое для всех сгенерированных классов. По умолчанию генерируется из корневого пространства имен и выходного каталога плюс CompiledModels .

Общие параметры перечислены выше.

В следующем примере используются значения по умолчанию, и он работает, если в проекте есть только один DbContext :

 Optimize-DbContext
 

В следующем примере модель оптимизируется для контекста с указанным именем и помещается в отдельную папку и пространство имен:

 Optimize-DbContext -OutputDir Models -Namespace BlogModels -Context BlogContext
 

Удаление-миграция

Удаляет последнюю миграцию (откатывает изменения кода, сделанные для миграции).

Параметры:

Параметр Описание
- Сила Отменить миграцию (откатить изменения, примененные к базе данных).

Общие параметры перечислены выше.

Scaffold-DbContext

Генерирует код для DbContext и типы сущностей для базы данных. Чтобы Scaffold-DbContext сгенерировал тип объекта, таблица базы данных должна иметь первичный ключ.

Параметры:

Параметр Описание
-Соединение Строка подключения к базе данных. Для проектов ASP.NET Core 2.x значение может быть name=<имя строки подключения> . В этом случае имя происходит от источников конфигурации, настроенных для проекта. Это позиционный параметр, и он является обязательным.
-Provider Используемый провайдер. Обычно это имя пакета NuGet, например: Microsoft.EntityFrameworkCore.SqlServer . Это позиционный параметр, и он является обязательным.
-OutputDir <строка> Каталог для размещения файлов классов сущностей. Пути относятся к каталогу проекта.
-ContextDir Каталог для размещения файла DbContext . Пути относятся к каталогу проекта.
-Пространство имен Пространство имен, используемое для всех сгенерированных классов. По умолчанию генерируется из корневого пространства имен и выходного каталога.
-ContextNamespace Пространство имен, используемое для созданного класса DbContext . Примечание: переопределяет -Namespace .
-Контекст Имя класса DbContext для создания.
-Схемы Схемы таблиц и представлений, для которых создаются типы сущностей. Если этот параметр опущен, включаются все схемы. Если используется этот параметр, то все таблицы и представления в схемах будут включены в модель, даже если они не включены явно с помощью параметра -Table.
-Таблицы Таблицы и представления, для которых создаются типы сущностей. Таблицы или представления в определенной схеме могут быть включены с использованием формата «schema.table» или «schema.view». Если этот параметр опущен, включаются все таблицы и представления.
- Аннотации данных Используйте атрибуты для настройки модели (где это возможно). Если этот параметр опущен, используется только свободный API.
- Уседатабасенамес Используйте имена таблиц, представлений, последовательностей и столбцов точно так, как они появляются в базе данных. Если этот параметр опущен, имена баз данных изменяются, чтобы более точно соответствовать соглашениям о стилях имен C#.
- Сила Перезаписать существующие файлы.
-NoOnConfiguring Не создавать DbContext.OnConfiguring .
-НетПлюрализ Не используйте множественное число.

Общие параметры перечислены выше.

Пример:

 Scaffold-DbContext "Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer - Модели OutputDir
 

Пример, который формирует только выбранные таблицы и создает контекст в отдельной папке с указанным именем и пространством имен:

 Scaffold-DbContext "Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models -Tables "Blog", "Post" -ContextDir Context -Context BlogContext -ContextNamespace New.Namespace
 

В следующем примере строка подключения считывается из конфигурации проекта, возможно, заданной с помощью инструмента Secret Manager.

 Scaffold-DbContext "Name=ConnectionStrings:Blogging" Microsoft.EntityFrameworkCore.SqlServer
 

Script-DbContext

Создает сценарий SQL из DbContext. Обходит любые миграции.

Параметры:

Параметр Описание
-Вывод Файл для записи результата.

Общие параметры перечислены выше.

Script-Migration

Создает сценарий SQL, который применяет все изменения из одной выбранной миграции в другую выбранную миграцию.

Параметры:

Параметр Описание
-От Начало миграции. Миграции можно идентифицировать по имени или идентификатору. Число 0 — это частный случай, означающий 9.0056 до первой миграции . По умолчанию 0.
-Кому Завершение миграции. По умолчанию используется последняя миграция.
-Идемпотент Создайте сценарий, который можно использовать в базе данных при любой миграции.
-Без транзакций Не создавать операторы транзакций SQL.
-Вывод Файл для записи результата. ЕСЛИ этот параметр опущен, файл создается с сгенерированным именем в той же папке, что и файлы среды выполнения приложения, например: /obj/Debug/netcoreapp2.1/ghbkztfz.sql/ .

Общие параметры перечислены выше.

Tip

Параметры To , From и Output поддерживают расширение табуляции.

В следующем примере создается сценарий для миграции InitialCreate (из базы данных без каких-либо миграций) с использованием имени миграции.

 Миграция сценария 0 InitialCreate
 

В следующем примере создается сценарий для всех миграций после миграции InitialCreate с использованием идентификатора миграции.

 Скрипт-миграция 201805021_InitialCreate
 

Update-Database

Обновляет базу данных до последней миграции или указанной миграции.

Параметр Описание
- Миграция Целевая миграция.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *