نصب Debian Debootstrap

[norouzi90]

ممنون آقای Chappie ،

با راهنمایی هایی که فرموده بودید، حل شد. خیلی زحمت دادم. خدا خیرتان دهد.           

[Chappie]

❤️🙏✋

[norouzi90]

با سلام مجدد،

اگر در عکس 1 به دایرکتوری etc/init.d/ سیستم من نگاه کنید، در داخل این دایرکتوری  ۵۶ عدد فایل وجود دارد.
اگر به شکل ظاهری آیکن فایل ها نگاه کنید، سه تا فایل از لحاظ شکل ظاهری آیکن ها شبیه هم هستند و به شکل آیکن فایل ساده هستند ولی ۵۳ فایل دیگر علامتی بر روی آیکن دارند و بنظرم  فایل اجرایی می باشند.
این سه تا فایل به شکل آیکن  ساده عبارتند از:
agetty  ،  cgroups  ،savecache



اگر  به حالت Open as administrator وارد این دایرکتوری شده و فایل ها را باز کنید، نوشتجات درونی این سه تا فایل تماماً به رنگ سیاه هستند.( عکس های 2 و 3 )
 ولی آن ۵۳ فایل دیگر نوشته های درونشان به صورت رنگی می باشند. ( عکس های 4 و 5 )

چرا نوشتجات آن ۳ تا فایل تنها به رنگ سیاه است ولی نوشتجات آن ۵۳ فایل دیگر به‌صورت رنگی است؟

سطر اول این سه تا فایل این عبارت است:

کد: [انتخاب]

#!/usr/sbin/openrc-run

و سطر اول آن ۵۳ فایل دیگر بدین صورت است:

کد: [انتخاب]

#!/bin/sh
بنظرتان علت چیست؟ و چکار می شود کرد که آن سه تا فایل دیگر هم تبدیل به فایل اجرایی بشوند؟

آیا خطای ERROR: Plymouth faied to start به این قضیه مربوط است؟!!

[Chappie]

تفاوت رنگ‌ها از هایلایت ادیتور (Pluma) است، نه اجراشدنی/نشدنی بودن فایل. اسکریپت‌هایی که با

کد: [انتخاب]

#!/usr/sbin/openrc-runشروع می‌شوند را Pluma به‌صورت «Plain Text» تشخیص می‌دهد و رنگی نمی‌کند؛ پایین پنجره هم نوشته Plain Text. بقیه که

کد: [انتخاب]

#!/bin/shدارند، به‌صورت «sh» شناخته می‌شوند و رنگ می‌گیرند.
اجراشدنی بودن (Executable) را با آیکون نمی‌شود قطعی فهمید؛ با دستور زیر چک کن:

کد: [انتخاب]

ls -l /etc/init.d/agetty /etc/init.d/cgroups /etc/init.d/savecacheاگر اول پرمیشن‌ها -rwxr-xr-x نیست (فاقد x)، میتوانی اجراشدنی‌شان کنی , که خارج از بحث ماست و در این مورد هم سرخود نباید چیزی رو تغییر داد .
- - -
در نتیجه به خطای * ERROR: plymouth failed to start ربطی ندارد .

[Chappie]

سوال :
طبق این نوشته مثل اینکه یه دستکاری هایی کردید در کانفیگهای plymouth :

https://forum.ubuntu-ir.org/index.php?topic=158347.msg1250291#msg1250291

این کارها رو کنید و بعدش ریستارت کنید و نتیجه رو بگید :

کد: [انتخاب]

sudo apt-get purge plymouth plymouth-themes
sudo apt-get install plymouth plymouth-themes
sudo update-initramfs -u -k all


[norouzi90]

بعد از نصب سیستم دبیان به‌صورت Debootstrap  ، بلافاصله از timeshift استفاده کردم ، بنابراین جای نگرانی وجود ندارد بعد از هر نوع تغییری که شخصاً به سیستم می دهم، بر می گردم و با استفاده از timeshift سیستم را به حالت اولیه برمی گردانم، چون دقیقاً می دانم هر تغییری که بدهم بدون اطلاع شما، کار پیچیده می شود، بنابراین مطمن باشید وقتی موضوعی را در اینجا مطرح می کنم سیستم در حالت اولیه بعد از نصب دبیان به‌صورت  Debootstrap می باشد.

دستوراتی که فرموده بودید در عکس های 1 و 2 و 3 قابل مشاهده است، ولی همان خطا بعد از reboot سیستم هست.

به‌طور کلی با نصب سیستم دبیان به‌صورت  Debootstrap و با OpenRC ، دو تا خطا وجود دارد، یکی از خطاها مربوط به زمان بوت، که عبارت از:

: ERROR: Plymouth faied to start

و دیگری خطای مربوط به زمان shutdown  سیستم است، که عبارتند از: عکس 4

ERROR: apparmor failed to stop

فقط این دو تا خطا را در زمان بوت و خاموشی سیستم دارد.
حتی سیستم را یکباره دیگر از نو، به‌صورت دبیان  Debootstrap نصب کردم و اینبار برخلاف دفعه قبلی که ابتدا sysvinit را نصب کرده بودم وسپس OpenRC را نصب کردم، اینبار OpenRC را در مراحل نصب به‌صورت  Debootstrap ، از همان ابتدا نصب کردم، ولی تفاوتی در نتایج نداشت و این دو خطا در هر دو صورت وجود دارد.

[Chappie]

خروجی این دستور رو همینجا قرار بدید :

کد: [انتخاب]

sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep -i plymouth

[Chappie]

اگر دستور نوشته قبل خروجی داشت کارهای زیر رو انجام دهید :
بدون هیچ Plymouth

کد: [انتخاب]

# OpenRC
sudo rc-service plymouth stop
sudo rc-update del plymouth default
sudo rc-update del plymouth boot
sudo rc-update del plymouth shutdown
sudo rc-update del plymouth sysinit
sudo rc-update del plymouth-log sysinit
sudo rc-update -u


# SysV
sudo update-rc.d -f plymouth remove
sudo update-rc.d -f plymouth-log remove

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

کد: [انتخاب]

pgrep -x plymouthd >/dev/null && echo "plymouth: running" || echo "plymouth: not running"
plymouth --ping >/dev/null 2>&1 && echo "plymouth: running" || echo "plymouth: not running"

[norouzi90]

ممنون آقای   Chappie  ،

با اجرای دستوراتی که  فرمودید و در عکس 1 و 2 و 3 مشخص است و همچنین اضافه کردن splash به فایل  etc/default/grub/  بصورت:

کد: [انتخاب]

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
و سپس اجرای دستور:

کد: [انتخاب]

# update-grub
مشکل مربوط به نشان داده شدن خطای ERROR: plymouth failed to start در زمان بوت سیستم حل شد و دیگر این خطا در هنگام بوت دیده نمی شود. صفحه خالی عکس دبیان که مربوط به اجرای plymouth است، در هنگام بوت دیده می شود و فرآیند اجرای بوت در پشت زمینه انجام می گیرد که نشان می دهد که plymouth  کارش را در زمان بوت درست انجام می دهد.
 همچنین هنگام کار با سیستم و اجرای دستور rc-ststus –servicelist  در عکس 4 ، نشان می دهد که دو سرویس plymouth و plymouh-log به‌درستی stopped شده اند و نه started هستند و نه crashed و این را نشان می دهد که همه چیز درست است یعنی سرویس  plymouth  که بایستی در فرآیند بوت اجرا می شده و بعد از بوت stopped می شده، و به همین صورت انجام شده است.

ولی کلاً متوجه نشدم که چطوری این مساله را حل کردید. اگر به عکس 5 نگاه کنید با اجرای دستور  rc-update show  نشان می دهد که دیگر plymouth و plymouth-log در لیست خروجی این دستور جای ندارد. پس از کجا سیستم فهمیده که در زمان بوت سرویس plymouth را اجرا کند؟!

[Chappie]

خط زیر در ‎/etc/default/grub تعیین می‌کند پارامترهای کرنل در بوت عادی چه باشند:

کد: [انتخاب]

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"quiet ⇒ بیشتر پیام‌های متنی کرنل را پنهان می‌کند.
splash ⇒ به اسکریپت‌های initramfs می‌گوید Plymouth را اجرا کنند (اگر plymouth داخل initramfs باشد).
دستور:

کد: [انتخاب]

sudo update-grubفایل تنظیمات گراب را بازتولید می‌کند (grub.cfg در ‎/boot/grub/)، تا تغییر بالا در بوتِ بعدی اعمال شود.
splash فقط وقتی اثر دارد که plymouth نصب باشد و داخل initramfs قرار گرفته باشد.
در ستاپ تو (OpenRC/SysV را برای plymouth غیرفعال کرده‌ای)، اضافه کردن splash باعث می‌شود plymouth فقط در initramfs اجرا شود؛ userspace دیگر سعی به start نمی‌کند و ارور قبلی تکرار نمی‌شود.
- - -
«چراییِ ارور» و «چطور حل شد»:
علّت اصلی: Plymouth داخل initramfs در early-boot اجرا می‌شد؛ بعد که وارد userspace شدی، OpenRC/SysV دوباره خواستند همان سرویس را start کنند. چون دیمون یا از قبل در حال اجرا بود یا اصولاً نباید در userspace start می‌شد، اسکریپت init با کُد خطا برگشت و OpenRC پیام داد:

کد: [انتخاب]

* ERROR: plymouth failed to start.
راه‌حل مؤثر: مدیریت plymouth را به یک‌جا محدود کردیم:

در OpenRC/SysV، سرویس plymouth را از runlevelهای boot/default (و حتی shutdown در صورت عدم نیاز) حذف کردیم و فقط در صورت تمایل plymouth-log را در sysinit نگه داشتیم؛ یا کلاً هر دو را حذف کردیم.
(اختیاری) اگر splash را از GRUB برداری، اصلاً plymouth در initramfs هم اجرا نمی‌شود.
نتیجه: دیگر userspace تلاشی برای start مجدد plymouth نمی‌کند ⇒ تداخل/دوبار-استارت از بین رفت ⇒ ارور محو شد؛ لاگ‌های بوت هم همچنان در dmesg/سیس‌لاگ (و در صورت فعال بودن plymouth-log، در /var/log/boot.log) موجودند.
- - -
و ابتدا از این عکس فهمیدیم که از قبل استارت شده :
نشانه‌ها در خروجی plymouthd --debug:

کد: [انتخاب]

directory /run/plymouth already exists
plymouth is already running
این یعنی یک نمونه‌ی plymouthd از قبل (معمولاً در initramfs) بالا بوده و وقتی در userspace دوباره می‌خواهی استارتش کنی، می‌گوید «already running» و اسکریپتِ سرویس با خطا خارج می‌شود؛ همان چیزی که بعداً به * ERROR: plymouth failed to start می‌رسید.
الان که start در userspace را حذف کرده‌ای، دیگر تلاشِ دوباره‌ای انجام نمی‌شود و خطا باید برطرف شده باشد.
- - -

[Chappie]

initramfs چیه؟
اولین روت‌فایل‌سیستمِ موقتیه که کرنل بعد از لود شدن می‌خونه.
بوت‌لودر → کرنل و فایل initrd.img (همون initramfs فشرده) رو به RAM می‌ده.
کرنل اون آرشیو cpio رو به‌صورت tmpfs‌ مونت می‌کنه و اسکریپت /init داخلش رو به‌عنوان PID 1 اجرا می‌کنه (به این می‌گن early userspace).
کارهایش:
لود ماژول‌های ضروری (درایور دیسک/usb/raid/فایل‌سیستم…)
سرهم کردن RAID/LVM
بازکردن LUKS (اگر روت رمز شده باشه)
پیدا کردن و مونت کردن روت واقعی (/)
بعد با switch_root کنترل رو می‌ده به سیستم اصلی (systemd یا sysvinit/OpenRC) و خودش آزاد می‌شه.
- - -
Plymouth اونجا چی کار می‌کنه؟
اگر بسته‌ی plymouth نصب باشه و تو خط کرنل splash باشه، هوک‌هایش باعث می‌شن در initramfs استارت بشه.
نقش‌ها:
نمایش اسپلش (به‌جای پیام‌های متنی)،
I/O multiplexer: مثلا گرفتن پسورد LUKS با ظاهر قشنگ،
با plymouth-log بعدتر لاگ بوت رو می‌نویسه.
وقتی سیستم به userspace اصلی رسید، باید خاموشش کنه (plymouth --quit).
روی systemd، واحدهای plymouth-quit*.service این کار را می‌کنند.
روی SysV/OpenRC، اسکریپت /etc/init.d/plymouth این وظیفه را دارد (معمولاً: «در بوت stop، در shutdown start»).
اروری که می‌دیدی چرا بود؟
Plymouth از initramfs قبلاً بالا بود؛ userspace (OpenRC/SysV) دوباره خواست startش کند ⇒ «already running» و اسکریپت با خطا برگشت ⇒

کد: [انتخاب]

* ERROR: plymouth failed to start.با حذف استارتِ userspace (از runlevelها و لینک‌های SysV) مشکل حل شد.

[norouzi90]

آقای Chappie ،

ممنون از توضیحات ارزشمند و وقتی را که صرف این مشکل نمودید.

بنظرم تنها یک مشکل مانده، خطای مربوط به زمان shutdown  سیستم، یعنی : ERROR: apparmor failed to stop

بنظرتان برای حل این خطا از همین دستورات استفاده کنم و بجای  plymouth از apparmor استفاده کنم؟

سوال دیگری که ذهنم را مشغول کرده این است که، چرا در antiX Linux ، در init هایش و ایزوهایی که می دهد تنها runit, SysV وجود دارد و OpenRC نیست؟!! آیا OpenRC مثلا سخت تر بود که استفاده نکردند یا اینکه فقط یک کار سلیقه ای است؟

و سوال دیگرم این است آیا روش مشخص و دستورات معینی وجود دارد که من سرعت بوت در حالت systemd و SysV و یا OpenRC را باهم بسنجم؟

آیا استفاده از systemd و SysV و یا OpenRC فقط در سرعت بوت و فرآیندهای زمان بوت نقش اساسی دارد یا اینکه در زمان استفاده از سیستم بر روی سرعت سیستم هم تاثیر می گذارد؟

[norouzi90]

بنظرم تنها یک مشکل مانده، خطای مربوط به زمان shutdown  سیستم، یعنی : ERROR: apparmor failed to stop

بنظرتان برای حل این خطا از همین دستورات استفاده کنم و بجای  plymouth از apparmor استفاده کنم؟

عکس های 1 و 2 ، کپی کردن من از روی دست استاد، که این تلاش من ناکام ماند و به نتیجه نرسید.

هر چند که اینکار باعث شد در زمان shutdown دیگر شاهد ERROR: apparmor failed to stop نباشم ولی در سیستم در حال اجرا بایستی apparmor ، به حالت started باشد و نه به حالت stopped.

که عکس های 3 و 4 که بعد از reboot گرفتم نشان می دهد که apparmor با اجرای دستورات عکس های 2 و 3 به حالت stopped رسیده است، بنابراین داروی سردرد را نتوانستم برای معده درد بکار ببرم.

[Chappie]

همون کارهایی که کردید رو به قبلش برمیگردونیم
به runlevel درست (sysinit) برش گردان:

کد: [انتخاب]

sudo rc-update add apparmor sysinit
sudo rc-update -uلینک‌های SysV را حذف کردی، برگردان :

کد: [انتخاب]

sudo update-rc.d apparmor defaultsهمین الان استارتش کن و وضعیت را چک کن:

کد: [انتخاب]

sudo rc-service apparmor start
aa-status
rc-status --servicelist | grep -E 'apparmor|sysinit'
dmesg | grep -i apparmor | tail -n +1اگر aa-status لیست پروفایل‌ها را نشان بدهد و rc-status برای apparmor عبارت started را بدهد، همه‌چیز درست است.
- - -

وقتی اسکریپت stop سرویس بی‌معنی یا خراب است (مثل AppArmor در دبیان که پیام می‌دهد: Action 'stop' is meaningless) و در زمان خاموشی ارور failed to stop می‌بینی.
با zap به OpenRC می‌گویی: «این سرویس را رها کن؛ لازم نیست در shutdown آن را stop کنی.»
می‌خواهی AppArmor در حین کار سیستم started باشد، اما در خاموشی پیام خطا ندهد.

کد: [انتخاب]

sudo nano /etc/local.d/apparmor-zap.stopمحتوای داخل فایل دقیقاً این باشد:

کد: [انتخاب]

#!/bin/sh
rc-service --ifexists apparmor zap
اجراشدنی‌اش کن:

کد: [انتخاب]

sudo chmod +x /etc/local.d/apparmor-zap.stop
سرویس local را برای اجرای اسکریپت‌های *.stop در زمان خاموشی، به runlevel خاموشی اضافه کن:

کد: [انتخاب]

sudo rc-update add local shutdown
sudo rc-update -u
(اختیاری) بررسی:

کد: [انتخاب]

rc-update show | grep -E '^local'
ls -l /etc/local.d/apparmor-zap.stop- - -
از این به بعد هنگام shutdown، قبل از اینکه OpenRC بخواهد stop بی‌معنی AppArmor را اجرا کند، این اسکریپت فقط «zap» می‌زند تا خطای
ERROR: apparmor failed to stop
دیگر دیده نشود و در طول کار سیستم AppArmor همچنان فعال بماند.
- - -
حذف/برگشت:

کد: [انتخاب]

sudo rm /etc/local.d/apparmor-zap.stop
sudo rc-update del local shutdown
sudo rc-update -u- - -
AppArmor یک LSM کرنلی است؛ در ابتدای بوت فعال می‌شود و پروفایل‌ها داخل کرنل load می‌شوند. «خاموش‌کردن» AppArmor در حین کار سیستم عملاً معنی‌دار نیست (LSM را نمی‌توان مثل یک دیمون stop کرد).
در دبیان، اسکریپت SysV مربوط به AppArmor یعنی /etc/init.d/apparmor برای عمل stop عمداً هیچ کاری نمی‌کند و پیام می‌دهد:

کد: [انتخاب]

Action 'stop' is meaninglessو (مهم) با کُد غیرصفر خارج می‌شود تا بگوید این عمل قابل انجام نیست.
OpenRC هنگام خاموشی، طبق روال همه‌ی سرویس‌ها را stop صدا می‌زند. وقتی به AppArmor می‌رسد، چون اسکریپت با کُد غیرصفر برمی‌گردد، OpenRC این را به‌صورت خطا گزارش می‌کند:

کد: [انتخاب]

* ERROR: apparmor failed to stopدر واقع «چیزی خراب نشده»؛ فقط اسکریپت می‌گوید «stop بی‌معنی است» و OpenRC آن را «failed» نمایش می‌دهد.
نتیجه: این پیام ظاهری/زیباشناختی است، نه خرابی واقعی. AppArmor باید در زمان اجرا started بماند و نیازی نیست در shutdown متوقف شود.
راه‌حلی که گفتیم دقیقاً برای همین‌اند:
AppArmor را در runlevel sysinit نگه دار (برای start) و از runlevel shutdown حذف کن تا OpenRC اصلاً stop صدا نزند.
یا قبل از خاموشی یک اسکریپت کوچک بگذار که روی AppArmor فقط zap بزند (علامت started را پاک کند) تا OpenRC دنبال stop نرود.
این‌طوری AppArmor در حین کار سیستم فعال می‌ماند، و در خاموشی هم دیگر پیام «failed to stop» نمی‌بینی.

[norouzi90]

AppArmor را در runlevel sysinit نگه دار (برای start) و از runlevel shutdown حذف کن تا OpenRC اصلاً stop صدا نزند.

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

بعد از اجرای دستورات عکس 1 و reboot سیستم، جواب شد عکس 2 و 3 یعنی اینکه هر چند که در هنگام shutdown دیگر آلارم ERROR: apparmor failed to stop نمی آید، ولی چه فایده در حین اجرای سیستم appamor ، متوقف شده. و در لیست rc-update show هم نیست.