نصب Debian Debootstrap

[norouzi90]

مرحله 20 یا نهایی )

کد: [انتخاب]

Finalizing

    Run apt clean for good measure.
    Remove resolv.conf so it gets recreated at boot: rm /etc/resolv.conf
    Exit the chroot with the exit command.
    Unmount the filesystems with umount just to be extra safe. Hint: unmount the devices mounted to /boot/efi and /home first before running umount /dev/sdX.

That's it. Reboot and enjoy.
در پایان نصب دبیان بصورت  Debootstrap این کارها را می کنیم:

کد: [انتخاب]

# apt cleanعکس 1

Remove resolv.conf so it gets recreated at boot: rm /etc/resolv.conf

همانطور که در عکس 2 می توانید مشاهده کنید، در این دستور العملی که من استفاده می کنم این دستور در جای نامناسبی داده شده است و خطا می دهد، برای حل این مشکل ابتدا با دستور :

کد: [انتخاب]

# exit
از chroot خارج می شویم و سپس از دستور زیر برای حذف فایل مربوطه اقدام می کنیم:

کد: [انتخاب]

# rm /mnt//etc/resolv.confعکس 2

Exit the chroot with the exit command.

اجرای این دستور exit در اینجا دیگر لازم نیست، چون در دستورات قبلی ما از محیط chroot با فرمان exit خارج شدیم.



برای امنیت بیشتر، فایل‌سیستم‌ها را با umount از حالت mount خارج می کنیم.
نکته: قبل از اجرای umount /dev/sda، ابتدا دستگاه‌هایی را که در /boot/efi و /home نصب شده‌اند، از حالت مانت خارج می کنیم، برای اینکار از دستورات زیر استفاده می کنیم:

کد: [انتخاب]

# umount /dev/sda1

کد: [انتخاب]

# umount /dev/sda4

کد: [انتخاب]

# umount /dev/sda3

[norouzi90]

من دبیان را به‌صورت Debootstrap و مینیمال با systemd از طریق دبیان لایو به سیستم اصلی ام نصب کردم.
حالا می خواهم بیایم  و نگاه کنم و ببینم که اصلاً سیستمی که ایجاد کرده ام  کار می کند؟ بوت می شود؟ و …


در اینجا به ترتیب ۵ عکس گذاشته ام.

عکس 1:
خوب خدا را شکر، گراب  در همین ابتدا بعد از اعلان بایوس، قابل مشاهده است. پس می توانیم امیدوار باشیم که حداقل این یکی درست است تا برسیم به بقیه.

عکس 2:
به‌به ، اعلان دبیان هم آمد.

عکس 3:
تعدادی خطا مربوط به زمان بوت سیستم.

عکس 4:
ولی خطاهای بوت در آن حد نبودند، که مانع ورود ما به سیستم اصلی امان و خط فرمان شوند.در اینجا بعد از اعلان خطاها وارد خط فرمان دبیان می شویم.


بررسی خطاهای مربوط به عکس 3 :

در ایجا ما با دو نوع خطای متفاوت مواجه می شویم:

۱- خطای    fsck.ext4  for  dev/sda3 
۲- خطاهای مربوط به نبودن firmware های مربوطه


حل خطای    fsck.ext4  for  dev/sda3  :
برای حل این خطا بسته e2fsprogs   را نصب می کنیم.

بسته e2fsprogs  : این بسته شامل برنامه‌هایی برای ایجاد، بررسی و نگهداری سیستم‌های فایل مبتنی بر ext2/3/4 است. همچنین شامل برنامه "badblocks" است که می‌تواند برای اسکن بلوک‌های خراب روی دیسک یا سایر دستگاه‌های ذخیره‌سازی استفاده شود.
فکر کنم بایستی نصب این بسته در قسمت chroot به آموزش نامه Ian LeCorbeau اضافه گردد.


حل خطای مربوط به نبودن firmware های مربوطه:
برای حل این خطا از این دستورها استفاده می کنم:

کد: [انتخاب]

# apt update

# apt install firmware-linux

# reboot

# apt install firmware-realtek

# reboot
 بسته firmware-linux ، این بسته به میان‌افزار آزاد و غیرآزاد وابسته است که ممکن است با درایورها در هسته لینوکس استفاده شوند. موردی ندارد این بسته را نصب نمایید.

بسته firmware-realtek ، این بسته شامل میان‌افزار باینری برای تراشه‌های اترنت، وای‌فای، بلوتوث و صدای Realtek است که توسط درایورهای مختلف پشتیبانی می‌شوند. چون سیستم من از مارک Realtek استفاده کرده، بنابراین بایستی این بسته را نصب کنم تا firmware های مربوط به سخت افزارش نصب شود، اگر در سیستم شما مارک دیگری است، این بسته را نصب نکنید و جستجو کرده و بسته مناسب با مارک تان را نصب نمایید.

حتماً بعد از نصب firmware از هر نوعی ، بایستی سیستمتان را reboot نمایید.

عکس 5 : بعد از بوت مجدد، عکس 5 این را به ما نشان می دهد، که مشکلات موجود در عکس 3 با نصب بسته هایی که در بالا توضیح دادم، حل گردیده است.
بنابراین می توان از سیستمی که از طریق Debootstrap نصب شده، استفاده برد.

[norouzi90]

من در ارسالی های قبلی، دبیان را به‌صورت Debootstrap و به‌صورت مینیمال و systemd نصب کردم و با رفع خطاها سیستم بدون مشکل کار کرد.

الان من می خواهم  دبیان را به‌صورت Debootstrap و به‌صورت مینیمال و  systemd free   و بصورت sysvinit در سیستم اصلی ام نصب کنم. برای اینکار همه چیز را در سیستمم پاک کردم.

طبق آموزشی که من در پیش گرفته ام همه چیز مثل مراحل قبلی است، بجز اینکه به‌جای بسته های مرتبط با systemd بایستی بسته های مرتبط با sysvinit را نصب نمایم.یعنی بدین صورت:

کد: [انتخاب]

Installing init and the kernel

We need a kernel and init system. This could be done later but I prefer getting it out of the way first.

    For systemd:

# apt instal systemd systemd-sysv libpam-systemd libsystemd0

    For sysvinit:

# apt install sysvinit-core sysv-rc orphan-sysvinit-scripts elogind libpam-elogind

    Install the kernel:

# apt install linux-image-amd64

Swap amd64 for another architecture if you need.
ولی اینجا یک مسله مهمی وجود دارد، اگر به عکس 1 نگاه کنید، می توانید ببینید که بسته linux-image-amd64  به بسته های:

 
systemd  و   systemd-cryptsetup   و   systemd-timesyncd  و   libsystemd-shared

وابسته است.

نمی دانم چکار کنم؟ آیا راهی بنظرتان می رسد که در دبیان از دست این بسته ها  خلاص بشوم.
( امیدوارم که مرا بسویDevuan  و  antiX  و  توزیع های دیگر راهنمایی نکنید، نمی خواهم در این مورد بحث کنم)

لطفاً هر ایده ای که به ذهنتان می رسد، بگویید. رویش کار خواهم کرد.

[Chappie]

۱ )
بسته‌ی linux-image-amd64 در Debian وابستگی غیرمستقیم (indirect dependency) به systemd داره.
اما این وابستگی از نوع Recommends یا Suggests است، نه همیشه "Depends".
 توضیح:

Depends: یعنی بدونش پکیج کار نمی‌کنه.

Recommends: یعنی نصبش مفیده ولی اجباری نیست.

Suggests: یعنی صرفاً پیشنهاده.

مشکل اینه که apt به‌طور پیش‌فرض Recommends‌ها رو هم نصب می‌کنه.
در نتیجه systemd همراه کرنل میاد حتی اگه لازم نباشه.

۲ )
به عنوان ایده :
بعد از اینکه وارد chroot شدی :

کد: [انتخاب]

apt install sysvinit-core sysv-rc orphan-sysvinit-scripts elogind libpam-elogindجلوگیری از نصب مجدد systemd :

کد: [انتخاب]

apt-mark hold systemd systemd-sysv libpam-systemd
برای اطمینان بیشتر، این فایل هم بساز:

کد: [انتخاب]

cat > /etc/apt/preferences.d/nosystemd << "EOF"
Package: systemd*
Pin: release *
Pin-Priority: -1
EOFالان می‌تونی با خیال راحت کرنل کامل نصب کنی چون systemd قفل شده:

کد: [انتخاب]

apt install linux-image-amd64
و بعد ادامه راهی که میرفتید ...

[Chappie]

اون فایلی که ساختیم چکار میکنه :
apt چطور تصمیم می‌گیرد چه چیزی نصب شود؟

وقتی در دبیان (یا هر توزیع مبتنی بر آن) دستور apt install را اجرا می‌کنی، apt باید بین چند نسخه یا مخزن تصمیم بگیرد که کدام بسته را نصب کند.

برای این کار از چیزی به نام APT pinning system استفاده می‌کند.
هر بسته یک اولویت (priority) دارد که با عدد Pin-Priority مشخص می‌شود.
- - -
فایل /etc/apt/preferences.d/nosystemd چیست؟

فایلی است که به apt می‌گوید:

«اگر اسم بسته با systemd شروع می‌شود، حتی اگر لازم بود، نصبش نکن.»
- - -
Package: systemd*
هر بسته‌ای که نامش با systemd شروع شود (مثلاً systemd, systemd-sysv, systemd-timesyncd, libpam-systemd …)
Pin: release *
از هر مخزنی باشد، فرقی ندارد (deb, updates, security … همه را شامل شود)
Pin-Priority: -1
نمره‌ی اولویت منفی → یعنی «هرگز نصب نکن»

[esmaeelE]

برای نصب نرم‌افزارها با apt می‌تونید از فلگ no install recommend استفاده کنید تا بسته اضافی نصب نشود.
بهتره هر مرحله‌ها به شکل جدا در یک shell script قرار دهید و گام‌ها را به هم متصل کنید. به این شکل نگهداری پروژه ساده‌تر می‌شه.

[norouzi90]

ممنون آقای esmaeelE ، دوست عزیز.

 

برای نصب نرم‌افزارها با apt می‌تونید از فلگ no install recommend استفاده کنید تا بسته اضافی نصب نشود.

اگر بخواهیم این روش را بررسی کنیم.

حالت اول:

کد: [انتخاب]

apt install  linux-image-amd64       

کد: [انتخاب]

Installing dependencies:
  apparmor     dbus-session-bus-common  initramfs-tools-core  libdevmapper1.02.1  linux-base                       systemd-timesyncd
  busybox      dbus-system-bus-common   klibc-utils           libexpat1           linux-image-6.12.48+deb13-amd64  udev
  cpio         dmsetup                  kmod                  libjson-c5          linux-sysctl-defaults            zstd
  dbus         dracut-install           libapparmor1          libklibc            logsave
  dbus-bin     initramfs-tools          libcryptsetup12       libkmod2            systemd
  dbus-daemon  initramfs-tools-bin      libdbus-1-3           libsystemd-shared   systemd-cryptsetup


حالت دوم:

کد: [انتخاب]

apt install --no-install-recommends linux-image-amd64

کد: [انتخاب]

Installing dependencies:
  cpio             initramfs-tools-bin   kmod          libkmod2           linux-image-6.12.48+deb13-amd64  udev
  dracut-install   initramfs-tools-core  libapparmor1  libsystemd-shared  logsave
  initramfs-tools  klibc-utils           libklibc      linux-base         systemd

اگر تمرکزمان را فقط بر روی بسته های مربوط به systemd بگذاریم، در حالتی که از  no-install-recommends-- استفاده می کنیم،
بسته های libsystemd-shared و systemd نصب می شوند ولی بسته های systemd-timesyncd و systemd-cryptsetup نصب نمی شوند.
در حالت اول که از  no-install-recommends--  استفاده نمی کنیم، هر چهار تای این بسته ها نصب می شوند.

برای بکارگیری این روش برایم دو تا مشکل وجود دارد:

۱- من با Installing dependencies و  Recommends مشکلی ندارم و حتی ضروری می دانم که آنها نصب بشوند ولی تا حد امکان می خواهم نگذارم بسته های مرتبط با sysytemd نصب شوند. با بکارگیری این روش بایستی بعد بیایم و دوباره بسته هایی مانند:

apparmor  و busybox و dbus  و dmsetup و zstd و غیره را نصب کنم.

۲-با بکارگیری این روش همچنانکه گفتم بسته های libsystemd-shared و systemd  باز هم نصب می شوند.

بهتره هر مرحله‌ها به شکل جدا در یک shell script قرار دهید و گام‌ها را به هم متصل کنید. به این شکل نگهداری پروژه ساده‌تر می‌شه.

متاسفانه در این زمینه اطلاعاتم در حد صفر است.

[esmaeelE]

برای کاربرد خاص شما در نصب debootstrap بررسی نکردم ولی دو گزینه apt دارد که احتمالا در این مورد مفید باشند.

apt mark hold و دیگری apt pin
این دو را ترکیب کنید و از نصب بسته‌ها جلوگیری کنید.

کد: [انتخاب]

https://unix.stackexchange.com/a/316745/235261
https://dev1galaxy.org/viewtopic.php?pid=49005#p49005


[norouzi90]

ممنون دوست عزیز آقای Chappie ، اگر کمک های شما نبود فکر می کنم تا این مرحله نمی رسیدم.

سوال۱:
چرا در قسمت hold ، بسته  libsystemd-shared را جزو آنها قرار نداده بودید؟
راستش من روش شما را رفتم و خیلی هم لذت بردم، برای اینکه پیاز داغش را زیادتر کنم بسته  libsystemd-shared را هم جزو hold شدگان قرار دادم، دیگر در نصب  linux-image-amd64  هیچگونه آثاری از بسته های systemd نبود، در اینجا خیلی کیف کردم و ادامه نصب را بدون مشکل به جلو رفتم، سیستم هم بدون مشکل خاصی بوت شد ولی بعد مشکلات آغاز شد حتی دستور apt update هم در خط فرمان جواب نمی داد و به سایت دبیان وصل نمی شد. مجبور شدم دوباره چیزی که نصب کرده بودم حذف کنم. شاید هم عجله کردم و با نصب چند بسته مشکل برطرف می شد.

دقیقا سوال اساسی من این است:
آیا  بسته  libsystemd-shared  یکی از سنگ بنا و ستون اساسی دبیان است؟ آیا بدون این بسته اوضاع تا حد غیر ممکن بغرنج می شود؟
فعلا تمرکز اساسی ام را بر روی روش شما گذاشته ام، ولی این  بسته  libsystemd-shared  برایم حسابی اوضاع شده، آیا روش جایگزینی وجود دارد که بجای کارکرد این بسته برایم کار کند؟

سوال دیگر:
اگر بخواهیم بعدا بسته ای را از حالت hold خارج کنیم از چه دستوری باید استفاده کنیم؟

[Chappie]

libsystemd-shared
کتابخانهٔ runtime داخلی systemd (مورد استفاده توسط خود systemd و برخی ابزارهای پایه مثل udev, dbus, policykit, apt به‌طور غیرمستقیم)
- - -
چرا نباید libsystemd-shared (یا libsystemd0) رو hold یا block کنی

چون خیلی از بسته‌های «غیر systemd» — حتی در حالت sysvinit — به کتابخانه‌های عمومی systemd نیاز دارن، نه daemon خودش.

برای مثال:

dbus-daemon, udisks2, apt-transport-https, policykit, elogind, udev
→ همگی به libsystemd0 یا libsystemd-shared لینک شدن.

این کتابخانه‌ها Daemon نیستن، بلکه فقط کتابخانهٔ سطح پایین C هستن که برای سازگاری استفاده می‌شن.
یعنی حتی وقتی systemd حذف شده باشه، وجود این فایل‌های .so برای عملکرد سایر سرویس‌ها لازمه.
- - -
چه اتفاقی افتاد وقتی تو libsystemd-shared رو هم hold کردی

وقتی اون بسته رو hold کردی یا pin کردی،
apt نتونست libsystemd-shared.so رو آپدیت یا resolve کنه → در نتیجه dbus و apt و networking بعضاً از کار افتادن چون یکی از dependencyهای سطح پایینشون قفل شد.

نتیجه:

apt update نمی‌تونه به‌درستی gnutls و dbus و policykit رو لود کنه

بعضی از سرویس‌ها که به این lib لینک شدن (حتی غیر systemd) crash یا hang می‌کنن

- - -
پیشنهاد دقیق  برای hold

اگر بخوای یک setup تمیز و بی‌دردسر داشته باشی:

کد: [انتخاب]

apt-mark hold systemd systemd-sysv libpam-systemd
و در /etc/apt/preferences.d/nosystemd فقط بنویس:

کد: [انتخاب]

Package: systemd systemd-sysv libpam-systemd
Pin: release *
Pin-Priority: -1
نه بیشتر.
- - -
libsystemd-shared و libsystemd0 خودشون systemd نیستن،
فقط کتابخانه‌هایی هستن که خیلی از بسته‌ها برای کارکرد عمومی‌شون بهشون لینک شدن.
حذف یا hold کردنشون باعث اختلال در apt، dbus، udev، و network میشه.
- - -
 دستور اصلی برای برداشتن حالت hold

کد: [انتخاب]

sudo apt-mark unhold package_name

برای دیدن اینکه چه بسته‌هایی در حالت hold هستن:

کد: [انتخاب]

apt-mark showhold

[norouzi90]

libsystemd-shared و libsystemd0 خودشون systemd نیستن،
فقط کتابخانه‌هایی هستن که خیلی از بسته‌ها برای کارکرد عمومی‌شون بهشون لینک شدن.

This internal shared library provides common code used by various systemd
components. It is supposed to decrease memory and disk footprint.
The shared library is not meant for public use and is not API or ABI stable.

این کتابخانه مشترک داخلی، کد مشترکی را که توسط اجزای مختلف systemd استفاده می‌شود، ارائه می‌دهد. قرار است فضای اشغال شده توسط حافظه و دیسک را کاهش دهد. این کتابخانه مشترک برای استفاده عمومی در نظر گرفته نشده و از نظر API یا ABI پایدار نیست.

ببخشید ولی بنظرم این مطالب با هم جور درنمی آید. عکس 1

[Chappie]

libsystemd-shared واقعاً بخشی از سورس systemd است.

در پروژهٔ اصلی systemd، فقط برای استفادهٔ داخلیِ خودِ systemd ساخته شده.

دبیان هنگام بسته‌بندی، systemd را به چند بسته جدا تقسیم می‌کند.

یکی از آن بسته‌ها همین libsystemd-shared است که توسط udev و چند ابزار دیگر لازم است.

این کتابخانه daemon نیست و init سیستم را کنترل نمی‌کند.

اگر حذف شود، udev و بعضی برنامه‌های پایه از کار می‌افتند.

پس دبیان آن را نگه می‌دارد، حتی وقتی خود systemd حذف شده باشد.

نتیجه: وجودش به معنی «داشتن systemd» نیست؛ فقط یک وابستگی فنی است تا سیستم بدون systemd هم کار کند.
- - -
apt از کار افتاد نه چون خودش systemd می‌خواست،
بلکه چون تو کتابخانه‌ای رو قفل کردی که udev و dbus بدونش بوت نمی‌شن —
و اون‌ها زیرساخت ارتباطی apt با سیستم هستند.
- - -
libsystemd-shared در اصل بخشی از سورس systemd است و برای استفاده‌ی داخلی خودِ systemd ساخته شده.

این کتابخانه فقط شامل کدهای مشترک بین اجزای systemd (مثل journald, logind, udev) است تا حجم حافظه و دیسک کمتر شود.

API و ABI این کتابخانه پایدار نیست، یعنی هر نسخه از systemd باید دقیقاً نسخه‌ی خودش از libsystemd-shared را داشته باشد.

دبیان systemd را به چند بسته جدا تقسیم می‌کند تا حتی در حالت بدون systemd هم سیستم بوت شود.

در دبیان، udev از همان سورس systemd ساخته می‌شود و به libsystemd-shared وابسته است.

بنابراین حتی اگر systemd daemon حذف شود، libsystemd-shared باید بماند تا udev و دیگر اجزای پایه کار کنند.

libsystemd0 برعکس، کتابخانه‌ی عمومی و پایدار است که بسیاری از برنامه‌ها (مثل apt، dbus، cups، policykit) برای لاگ و اعلان به آن لینک شده‌اند.

اگر libsystemd-shared را hold یا حذف کنی، نسخه‌ی udev دیگر با آن match نمی‌کند و udev از کار می‌افتد.

وقتی udev یا dbus fail کنند، apt و خیلی از ابزارهای سیستمی هم نمی‌توانند اجرا شوند.

نتیجه: systemd را می‌توان حذف کرد، اما libsystemd-shared و libsystemd0 باید بمانند، چون بدون آن‌ها کل زیرساخت سخت‌افزار و ارتباطات درون سیستم از کار می‌افتد.
- - -
خلاصه‌ی نهایی:

systemd را می‌توان کاملاً حذف کرد،
اما کتابخانه‌های آن (libsystemd0 و libsystemd-shared) باید بمانند،
چون udev و ده‌ها ابزار پایه‌ی لینوکس برای اجرا به آن‌ها لینک شده‌اند.
حذف یا hold آن‌ها باعث قطع عملکرد udev، dbus و در نتیجه apt می‌شود.

[Chappie]

این لینکها رو هم ببینید شاید براتون نکته ای داشته باشه :

https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time

https://nosystemd.org

[norouzi90]

آقای Chappie ، ممنون از همه مَحبت هایتان و بخاطر وقتی که می گذارید.

نتیجه: systemd را می‌توان حذف کرد، اما libsystemd-shared و libsystemd0 باید بمانند، چون بدون آن‌ها کل زیرساخت سخت‌افزار و ارتباطات درون سیستم از کار می‌افتد.
- - -
خلاصه‌ی نهایی:

systemd را می‌توان کاملاً حذف کرد،
اما کتابخانه‌های آن (libsystemd0 و libsystemd-shared) باید بمانند،
چون udev و ده‌ها ابزار پایه‌ی لینوکس برای اجرا به آن‌ها لینک شده‌اند.
حذف یا hold آن‌ها باعث قطع عملکرد udev، dbus و در نتیجه apt می‌شود.

با توجه به عکسهای 1 و 2 و 3 که از توزیع antiX گرفته ام، بنظر میرسد می توان در دبیان هم systemd و هم libsystemd-shared وهم libsystemd0 نصب نباشند و بدون آنها هم، سیستم از هم نپاشد و apt هم کار کند و بدون آنها لزوما کل زیرساخت سخت‌افزار و ارتباطات درون سیستم از کار نخواهد افتاد.

با توجه به عکس 4 که از توزیع antiX گرفته ام، بنظر میرسد می توان در دبیان هم systemd و هم libsystemd-shared وهم libsystemd0 نصب نباشند و بدون آنها هم بسته dbus و بسته های زیر مجموعه آن کار کنند.

ولی با توجه به عکس  5 که از توزیع antiX گرفته ام،بنظر میرسد نمی توان در دبیانی که systemd و  libsystemd-shared وlibsystemd0   نصب نباشند، بتوان از بسته های udev و libudev1 استفاده کرد.

با توجه به عکس  6 که از توزیع antiX گرفته ام،بنظر میرسد نمی توان در دبیانی که systemd و  libsystemd-shared وlibsystemd0   نصب نباشند، بتوان از بسته network-manager استفاده کرد.

با توجه به عکس  7 و 8 که از توزیع antiX گرفته ام، بنظر می رسد در توزیع antiX آمده اند و بجای بسته network-manager از بسته های ifupdown و wpasupplicnt استفاده کرده اند.

متاسفانه و متاسفانه در درازمدت توزیع هایی مانند antiX مجبورند برای ادامه بقایشان حداقلی از systemd را در سیستمشان پذیرا  باشند.

با تشکر مجدد از دوست خوبم آقای Chappie .

[norouzi90]

ادامه عکس ها.