[РЕШЕНО] Выбираю материнскую плату, процессор и память

[dzhoser]

Ставить Buster или Bullseye? Видел на этом форуме отзывы, что Bullseye, хоть и получил звание stable, пока что ему не соответствует.

Мое мнение ставить Bullseye, так как вы ставите с нуля. Не соответствие со stable связаны с глобальными изменениями в механизмах настройки, из за этого у многих не работает старые костыли. При новой установки такого не будет. Плюс бонус будет в более расширенной поддержки железа.
Ставьте сразу разметки GPT, временно отключив другие носители.

[ek-nfn]

Мое мнение ставить Bullseye, так как вы ставите с нуля.

Поддерживаю. Если ставить с нуля, то нормально работает. На двух из 3-х компов пробовал обновить 10-ку до 11. В обоих случаях провал. Вроде встало, но глюки.... Сносил в обоих случаях. На третьем компе сразу ставил 11-ю в период ее тестового режима. При переходе ветки в stable проблем не наблюдаю.

[Gamliel]

Мое мнение ставить Bullseye, так как вы ставите с нуля.

Не совсем с нуля: подцепляю старый home-раздел. За почти двенадцать лет использования GNU/Линукса все переустановки у меня были, ЕМНИП, именно этим способом: на другой раздел, но со старым home-разделом.

Не соответствие со stable связаны с глобальными изменениями в механизмах настройки, из за этого у многих не работает старые костыли. При новой установки такого не будет.

Да,  sudo apt-get dist-upgrade  за все эти годы не делал ни разу. Пока не решил, буду ли делать его на VPS.

Ставьте сразу разметки GPT

Код Выделить Развернуть

$ sudo mount /dev/nvme0n1p1 /mnt
$ df -h | grep "^/dev/nvme0n1p1"
/dev/nvme0n1p1     127M          52M   75M           42% /mnt
$ ls /mnt/EFI/Debian/ -lh
итого 51M
-rwxr-xr-x 1 root root 202K янв 30  2021 config-4.19.0-14-amd64
-rwxr-xr-x 1 root root 202K мар 19 17:29 config-4.19.0-16-amd64
-rwxr-xr-x 1 root root  17M фев 28  2021 initrd.img-4.19.0-14-amd64
-rwxr-xr-x 1 root root  17M апр 17 23:01 initrd.img-4.19.0-16-amd64
-rwxr-xr-x 1 root root 3,3M янв 30  2021 System.map-4.19.0-14-amd64
-rwxr-xr-x 1 root root 3,3M мар 19 17:29 System.map-4.19.0-16-amd64
-rwxr-xr-x 1 root root 5,1M янв 30  2021 vmlinuz-4.19.0-14-amd64
-rwxr-xr-x 1 root root 5,1M мар 19 17:29 vmlinuz-4.19.0-16-amd64
Достаточно ли ESP-разделу 128 мегабайт? Какого размера гарантированно хватит? И оставлять ли на нём до установки какие-либо файлы, или все файлы и каталоги там удалить, а установщик сам положит туда нужное?

[dzhoser]

Достаточно ли ESP-разделу 128 мегабайт? Какого размера гарантированно хватит? И оставлять ли на нём до установки какие-либо файлы, или все файлы и каталоги там удалить, а установщик сам положит туда нужное?

Виндовс делает 100 Мб по-моему. 128 должно хватить. Если что потом можно переразметить. До установки желательно все отформатировать. Установщик должен сам туда положить файлы. Я бы отключил остальные носители и разметил бы в автоматическом режиме, а потом поправил бы fstab на нужный /home.

[Gamliel]

Виндовс делает 100 Мб по-моему. 128 должно хватить.

Так винда вообще считает себя единственной операционной системой. И делает всё, включая ESP-раздел, только для себя любимой. А у GNU/Линукса (во всяком случае, в старом добром GRUB'е) четыре варианта загрузки: две версии ядра и к каждой из них ещё и recovery. К тому же я, пожалуй, зарезервирую второй системный раздел — чтобы через два года поставить туда свежестабилизировавшийся Debian 12.

Если что потом можно переразметить.

Пока на носителе нет ничего ценного, можно без сожаления снести таблицу разделов и создать новую. А вот позже — GPartEd каждый раз перед перемещением начала раздела предупреждает, что это может привести к невозможности загрузки операционной системы с этого раздела. Думаю, в любом случае безопаснее заранее разметить и больше не трогать. Семь раз отмерь, один раз отрежь.

До установки желательно все отформатировать. Установщик должен сам туда положить файлы.

Понял, отформатирую. Но не всё, а два раздела: ESP и системный.

Я бы отключил остальные носители и разметил бы в автоматическом режиме, а потом поправил бы fstab на нужный /home.

Первое обязательно, но автоматической разметке я не доверяю. Всё же сразу подцеплю home-раздел на NVMe (но до установки, точнее до отключения всех SATA-накопителей, удостоверюсь в одинаковости содержания двух home-разделов: на SATA SSD и на NVMe). А после установки (и обратного подключения SATA-накопителей) заменю (почти) всё в /etc/ и многое в /var/lib/ (где ещё?) версиями из старой установки (Buster на SATA SSD).

Если бы я знал, что старую установку больше не удастся запустить, до выключения компьютера ввёл бы  apt-mark showmanual > software.lst. Но я этого не сделал. В каких файлах на бывшем системном разделе можно найти эту информацию? (В /media/user/Debian/var/log/apt/history.log* и /media/user/Debian/var/log/dpkg.log* есть информация только с августа 2020 года, а хотелось бы с момента установки. По названиям каталогов и прочих файлов в /media/user/Debian/etc/, /media/user/Debian/var/lib/ и /media/user/Debian/var/log/ удалось угадать некоторые программы, но это явно не всё.)

[dzhoser]

А упакованных логов в архивах нет? Если нет в них нужной информации они очистились logrotate.

[mrgoodvin]

При переносе системы: нужно было ставить grub-efi-amd64, efibootmgr с зависимостями в самом live носителе перед манипуляциями, и затем уже переносить систему (руководств в сети много по данной теме). efibootmgr так же вносит изменения в саму nvram EFI, так что если работать с ним напрямую то нужно быть осторожным. При инсталляции grub, efibootmgr вызывается автоматически если установлен он был конечно как пакет. Из под chroot удалить пакет в системе не загруженной можно и делал то, установить предполагаю тоже можно но ни разу не пробовал делать то уже другое.

В каких файлах на бывшем системном разделе можно найти эту информацию?

Увы, получить весь список пакетов установленных прежде в удобном виде уже нельзя как видится мне то, разве что восстановить старую систему и сохранить список, либо тот же вероятно chroot live для системы прежней не уверен. Можно глянуть /usr/bin|sbin|share.

[mrgoodvin]

Если нет в них нужной информации они очистились logrotate.

Не обязательно, ведь система то тоже ставилась изначально, и не всё в логи попало, и зависит конечно как еще от самой инсталляции.

[dzhoser]

На самом деле журналы не нужны, мы идём не в том направлении.

Код Выделить Развернуть

dpkg --get-selections | grep -v deinstall > mylist.txt
Получим список пакетов в mylist.txt
На новой системе

Код Выделить Развернуть

sudo apt-get install -y $(< mylist.txt)

Код Выделить Развернуть

sudo apt autoremove

[Gamliel]

А упакованных логов в архивах нет?

Есть. За один год.

Из под chroot удалить пакет в системе не загруженной можно и делал то, установить предполагаю тоже можно но ни разу не пробовал делать то уже другое.

Оказывается, можно и посмотреть:

Код Выделить Развернуть

$ apt-mark showmanual | wc -l
191
$ sudo mount /dev/sdc2 /mnt
$ sudo chroot /mnt
# apt-mark showmanual | wc -l
465
# apt-mark showmanual > software.lst

В каких файлах на бывшем системном разделе можно найти эту информацию?

Увы, получить весь список пакетов установленных прежде в удобном виде уже нельзя как видится мне то, разве что восстановить старую систему и сохранить список, либо тот же вероятно chroot live для системы прежней не уверен.

Именно chroot, Вы сами подсказали мне этот способ.

не всё в логи попало

Попало всё, но логи не хранятся вечно.

Код Выделить Развернуть

dpkg --get-selections | grep -v deinstall > mylist.txt
Получим список пакетов в mylist.txt

Код Выделить Развернуть

$ sudo mount /dev/sdc2 /mnt
$ sudo chroot /mnt
# dpkg --get-selections | grep -cv deinstall
2250
# apt-mark showauto | wc -l
1785
# apt-mark showmanual | wc -l
465
Думаю не ставить всё, а прежде просмотреть. Без зависимостей список почти в пять раз короче.

[dzhoser]

А какая разница? Зависимости так и так подтянутся.

[Aalexeey]

не был найден grub-install

Такое обычно сигнализирует о том что вы не в EFI "режиме", EFI BIOS был в каком-то другом режиме например режиме совместимости, и не "передал" загружаемой системе EFI "режим".

ESP-раздел я сделал размером 128 Мб. Достаточно ли?

Смотря какие у вас на него планы  , у меня там EFI образ Super Grub, Clonezilla и ISO образ Parted Magic. В раздел под root через /boot/efi... можно положить всё что угодно.

Bullseye, хоть и получил звание stable, пока что ему не соответствует

Для себя давно сделал вывод что stable он становится после того как перейдёт в oldstable. При этом надо учитывать что все те баги которые заморожены исправлены не будут, они так и будут там замороженные до конца релиза. Исправляют их почти везде но не в "стабильном" Debian. Кинуть в backports исправленные пакеты для них выдимо тоже выше их достоинства, пользователь должен страдать.

[Gamliel]

Переразметил NVMe, сделав ESP-раздел размером 256 Мб (видел где-то в сети мнение, что может понадобиться до двухсот, но мне нравятся степени двух), два раздела по 32 Гб и раздел 8Гб под своп (при RAM 16 Гб своп не сильно нужен, но блотварность софта и сайтов продолжает расти); скопировал на NVMe home-раздел, увеличив его до всего остававшегося неразмеченным пространства.

Установил Bullseye на первый из двух тридцатидвухгигабайтных разделов, сразу подцепив упомянутые своп и home. Скопировал со старого системного раздела /etc и ещё ряд конфигов. Установил ряд пакетов, имевшихся в старой установке. Задал пользовательскому и системному crontab'у всё то, что было в старой установке.

Пожалуй, всё в порядке. Ещё раз благодарю всех за помощь.

А какая разница? Зависимости так и так подтянутся.

Я почёл за лучшее сначала просмотреть список.

ESP-раздел я сделал размером 128 Мб. Достаточно ли?

Смотря какие у вас на него планы  , у меня там EFI образ Super Grub, Clonezilla и ISO образ Parted Magic. В раздел под root через /boot/efi... можно положить всё что угодно.

Теперь могу сказать, что было бы достаточно: gnome-disk-utility считает, что там занято порядка четырёх мегабайт, df — 512 байт, ls вообще не видит там ни одного файла:

Код Выделить Развернуть

$ ls /media/gamliel/ESP/ -lah
итого 4,5K
drwxr-xr-x  2 gamliel gamliel  512 янв  1  1970 .
drwxr-x---+ 3 root    root    4,0K сен  5 00:10 ..

Bullseye, хоть и получил звание stable, пока что ему не соответствует

Для себя давно сделал вывод что stable он становится после того как перейдёт в oldstable.

Ну, это IMHO слишком.

все те баги которые заморожены исправлены не будут, они так и будут там замороженные до конца релиза.

Насколько я понимаю, к исправлению уязвимостей это не относится.

Исправляют их почти везде но не в "стабильном" Debian.

Полагаю, не во всех дистрибутивах уделяется столько же внимания тестированию, как в Debian'е. За годы, пока очередная версия Debian'а готовится стать стабильной, разные пакеты многократно тестируются, в том числе на совместимость друг с другом. Просто заменить старую версию пакета новой и считать дело сделанным — не берусь утверждать, делают ли так в Ubuntu, Linux Mint'е и дистрибутивах с  rolling releases, в Debian'е же, полагаю, так не делают, ибо никто не может полностью предвидеть, что сломается из-за замены одного пакета.

Кинуть в backports исправленные пакеты для них выдимо тоже выше их достоинства, пользователь должен страдать.

То, что делают сопровождающие (maintainers) — это тяжёлая работа без зарплаты. И поместить в backports ещё один пакет — дело отнюдь не на одну минуту: нужно удостовериться, что этот пакет будет работать в этой версии Debian'а. Однажды я взял deb-файл от другой версии Debian'а и попытался установить, да только из этого ничего не вышло: пакету нужны другие версии зависимостей.

[Aalexeey]

Полагаю, не во всех дистрибутивах уделяется столько же внимания тестированию, как в Debian'е. За годы, пока очередная версия Debian'а готовится стать стабильной, разные пакеты многократно тестируются, в том числе на совместимость друг с другом. Просто заменить старую версию пакета новой и считать дело сделанным — не берусь утверждать, делают ли так в Ubuntu, Linux Mint'е и дистрибутивах с  rolling releases, в Debian'е же, полагаю, так не делают, ибо никто не может полностью предвидеть, что сломается из-за замены одного пакета.

Вы про Фому я про Ерёму. Когда я говорю Баги я не имею в ввиду стабильность и безопастность, я имею ввиду что в Debian'е замораживают версии приложений/пакеты даже если в нём уже выявили дефект (баг, упущение и.т.п.) функциональности, например в RH или Gentoo уже обнаружили баг cups вдруг не с того ни с сего неработы принтеров Samsung, но Debian'o делатели всё равно запихнули в Buster именно эту версию cups, несмотря на то что уже была следующая исправленная. Или другой пример upower в stretch, именно версии с вдруг переставшими работать с ним некоторыми моделями ups'ов, в то время как уже об этом знали и писали в нескольких других дистрибутивах. Зачем мне такие хоть трижды стабильные и безопастные пакеты если именно в них поломана и затем заморожена (причём они зовут это stable) поломанной поддержка моего оборудования?   

[Gamliel]

в Debian'е замораживают версии приложений/пакеты даже если в нём уже выявили дефект (баг, упущение и.т.п.) функциональности, например в RH или Gentoo уже обнаружили баг cups вдруг не с того ни с сего неработы принтеров Samsung, но Debian'o делатели всё равно запихнули в Buster именно эту версию cups, несмотря на то что уже была следующая исправленная. Или другой пример upower в stretch, именно версии с вдруг переставшими работать с ним некоторыми моделями ups'ов, в то время как уже об этом знали и писали в нескольких других дистрибутивах

Предыдущая версия уже́ была тщательно протестирована на совместимость с другими пакетами, а новая к тому моменту ещё не была столь же тщательно протестирована. Потому и замораживают testing за несколько месяцев до его превращения в stable, что иначе тестирование и допиливание новых поступающих версий отдельных пакетов будет продолжаться бесконечно, как путь к горизонту, и stable не выйдет ни через два года, ни через десять лет.

Зачем мне такие хоть трижды стабильные и безопастные пакеты если именно в них поломана и затем заморожена (причём они зовут это stable) поломанной поддержка моего оборудования?

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