دبیان دیبوت استرپ

[Dragon-]

بازم همونه ! اون پوشه وجود نداره حتی توی اوبونتو زنده ! پس بایوس هست سیستمم ، دوست دیگری هم بودن که بایوس بود سیستمشون و مثل من ده ها بار اوبونتو رو که گفته شده از لگاسی پشتیبانی نمیکنه رو نصب کرده بودن ، چطور ممکنه؟

انگار دوباره پشتیبانی از legacy رو به نصاب برگردوندند، مطمئن نیستم.
خروجی efibootmgr چی میگه؟

خیر آینه ای معرفی نکردم ، توی بعضی موارد علاقه دارم از پیش فرض ها استفاده کنم ، پس همون آینه پیش فرض خودش که https هم هست استفاده شده !

به نظر میاد نسخه‌های جدیدِ debootstrap، به طور پیش‌فرض از پروتکل https استفاده می‌کنند. نسخه debootstrap توی دبیان bullseye، به طور پیش‌فرض از http استفاده می‌کنه.

نفهمیدم ، یعنی به جز دستور هایی که توی آموزش آقای بهزادی هست دیگه چه فرمانی رو باید بزنم ؟

دستوراتی که میگم شبیه دستورات اونجا هستند ولی یه سری چیز‌ها با هم فرق داره.
قبل از اینکه بخواهید وارد chroot بشید، با این دستورات، فایل‌سیستم‌های مورد نیاز رو سوار کنید. (با این فرض که پارتیشن مورد نظر، روی /mnt/ سوار شده)

کد: [انتخاب]

sudo mount --rbind --make-rslave /dev /mnt/dev
sudo mount --rbind --make-rslave /proc /mnt/proc
sudo mount --rbind --make-rslave /sys /mnt/sys
sudo mount --rbind --make-rslave /run /mnt/run به دستورات دقت کنید، می‌بینید که خیلی شبیه هم هستند و فرق‌های جزئی دارند. می‌تونید با یه حلقه تکرار، کار‌های بالا رو انجام بدید و کمتر تایپ کنید. اینجوری

کد: [انتخاب]

for i in dev proc sys run; do
sudo mount --rbind --make-rslave /$i /mnt/$i
done
bind-- اینطور عمل می‌کنه که یه دایرکتوری رو روی یه دایرکتوری دیگه سوار می‌کنه. عملکرد rbind-- شبیه bind-- هست با این تفاوت که چیز‌هایی که زیر دایرکتوری اول سوار شدند هم توی دایرکتوری دوم سوار میشن.
برای مثال دستور زیر، /dev/ رو روی /mnt/dev/ به صورت bind سوار می‌کنه.

کد: [انتخاب]

sudo mount --bind /dev /mnt/dev
یه فایل‌سیستم مجازی، روی /dev/pts/ سوار شده، دستور بالا، اون رو به صورت bind، روی /mnt/dev/pts/ سوار نمی‌کنه. فقط  /dev/ رو روی /mnt/dev/ سوار می‌کنه. استفاده از rbind-- باعث میشه که سوار کردن به صورت بازگشتی انجام بشه و چیز‌هایی که زیر دایرکتوری مبداء سوار شدند، زیر دایرکتوری مقصد هم سوار بشن.

مطمئن نیستم لازم باشه run رو وصل کنید، ولی بودنش نباید مشکل درست کنه.
در کمترین حالت، proc dev devpts و sys رو نیاز دارید تا سیستم داخل chroot بتونه به اینترنت وصل بشه و سخت‌افزار‌های سیستم در دسترسش باشه، این کمترین حالتی که میشه باهاش بدون مشکل خاصی نصب رو انجام داد.
اگه کامپیوتر توی حالت uefi بوت میشه، /sys/firmware/efi/efivars/ هم مورد نیاز هست تا گراب بتونه متغییر‌های EFI رو تغییر بده.
ممکنه به cgroup ها که زیر /proc/ سوار شدند، نیاز بشه ولی مطمئن نیستم.
سوار کردن چیز‌هایی که زیر dev sys و proc هست، نباید مشکلی ایجاد کنه، حداقل برای من اینجوری نبوده.

در صورتی که cgroup ها رو توی سیستم نصب شده سوار کنید، بعد دیگه نمی‌تونید به همین راحتی اون رو unmount کنید، باید آپشن f- رو به دستور umount بدید تا به اجبار اینکار انجام بشه؛ در این حالت فایل‌سیستم از داخل سیستم اصلی هم unmount میشه، با unmount شدن اون فایل‌سیستم از سیستم اصلی، systemd و خیلی چیز‌های دیگه، کارشون رو درست انجام نمیدن و باید کامپیوتر رو راه‌اندازی مجدد کنید تا درست بشه.

به خاطر همین، از آپشن make-rslave-- استفاده میشه. این باعث میشه تغییراتِ مربوط به سوار و unmount کردن، از سیستم اصلی به داخل chroot اعمال بشه ولی تغییراتی که گفتم، از داخل chroot به سیستم اصلی نرسه. در این حالت می‌تونید بدون مشکل و حتی بدون دادن آپشن f-، فایل‌سیستم‌های گفته شده رو unmount کنید.

make-slave-- هم وجود داره‌. مثل rbind-- و bind-- که عملکردشون شبیه هم هست با این تفاوت که rbind-- به صورت بازگشتی عمل می‌کرد، عملکرد make-rslave-- هم شبیه make-slave-- می‌مونه، با این تفاوت که عملکرد make-rslave-- به صورت بازگشتی هست

[سودو.]

خروجی efibootmgr چی میگه؟

کد: [انتخاب]

EFI variables are not supported on this system.


دستوراتی که میگم شبیه دستورات اونجا هستند ولی یه سری چیز‌ها با هم فرق داره.
قبل از اینکه بخواهید وارد chroot بشید، با این دستورات، فایل‌سیستم‌های مورد نیاز رو سوار کنید. (با این فرض که پارتیشن مورد نظر، روی /mnt/ سوار شده)
کد: [انتخاب]

sudo mount --rbind --make-rslave /dev /mnt/dev
sudo mount --rbind --make-rslave /proc /mnt/proc
sudo mount --rbind --make-rslave /sys /mnt/sys
sudo mount --rbind --make-rslave /run /mnt/run

 به دستورات دقت کنید، می‌بینید که خیلی شبیه هم هستند و فرق‌های جزئی دارند. می‌تونید با یه حلقه تکرار، کار‌های بالا رو انجام بدید و کمتر تایپ کنید. اینجوری
کد: [انتخاب]

for i in dev proc sys run; do
sudo mount --rbind --make-rslave /$i /mnt/$i
done


bind-- اینطور عمل می‌کنه که یه دایرکتوری رو روی یه دایرکتوری دیگه سوار می‌کنه. عملکرد rbind-- شبیه bind-- هست با این تفاوت که چیز‌هایی که زیر دایرکتوری اول سوار شدند هم توی دایرکتوری دوم سوار میشن.
برای مثال دستور زیر، /dev/ رو روی /mnt/dev/ به صورت bind سوار می‌کنه.
کد: [انتخاب]

sudo mount --bind /dev /mnt/dev


یه فایل‌سیستم مجازی، روی /dev/pts/ سوار شده، دستور بالا، اون رو به صورت bind، روی /mnt/dev/pts/ سوار نمی‌کنه. فقط  /dev/ رو روی /mnt/dev/ سوار می‌کنه. استفاده از rbind-- باعث میشه که سوار کردن به صورت بازگشتی انجام بشه و چیز‌هایی که زیر دایرکتوری مبداء سوار شدند، زیر دایرکتوری مقصد هم سوار بشن.

مطمئن نیستم لازم باشه run رو وصل کنید، ولی بودنش نباید مشکل درست کنه.
در کمترین حالت، proc dev devpts و sys رو نیاز دارید تا سیستم داخل chroot بتونه به اینترنت وصل بشه و سخت‌افزار‌های سیستم در دسترسش باشه، این کمترین حالتی که میشه باهاش بدون مشکل خاصی نصب رو انجام داد.
اگه کامپیوتر توی حالت uefi بوت میشه، /sys/firmware/efi/efivars/ هم مورد نیاز هست تا گراب بتونه متغییر‌های EFI رو تغییر بده.
ممکنه به cgroup ها که زیر /proc/ سوار شدند، نیاز بشه ولی مطمئن نیستم.
سوار کردن چیز‌هایی که زیر dev sys و proc هست، نباید مشکلی ایجاد کنه، حداقل برای من اینجوری نبوده.

در صورتی که cgroup ها رو توی سیستم نصب شده سوار کنید، بعد دیگه نمی‌تونید به همین راحتی اون رو unmount کنید، باید آپشن f- رو به دستور umount بدید تا به اجبار اینکار انجام بشه؛ در این حالت فایل‌سیستم از داخل سیستم اصلی هم unmount میشه، با unmount شدن اون فایل‌سیستم از سیستم اصلی، systemd و خیلی چیز‌های دیگه، کارشون رو درست انجام نمیدن و باید کامپیوتر رو راه‌اندازی مجدد کنید تا درست بشه.

به خاطر همین، از آپشن make-rslave-- استفاده میشه. این باعث میشه تغییراتِ مربوط به سوار و unmount کردن، از سیستم اصلی به داخل chroot اعمال بشه ولی تغییراتی که گفتم، از داخل chroot به سیستم اصلی نرسه. در این حالت می‌تونید بدون مشکل و حتی بدون دادن آپشن f-، فایل‌سیستم‌های گفته شده رو unmount کنید.

make-slave-- هم وجود داره‌. مثل rbind-- و bind-- که عملکردشون شبیه هم هست با این تفاوت که rbind-- به صورت بازگشتی عمل می‌کرد، عملکرد make-rslave-- هم شبیه make-slave-- می‌مونه، با این تفاوت که عملکرد make-rslave-- به صورت بازگشتی هست

ممنون ! عالی توضیح میدین !

[Dragon-]

با توجه به خروجی efibootmgr و چیز‌هایی که قبلا گقتید و مدل لپ‌تاپ شما، به احتمال خیلی زیاد، لپ‌تاپ از uefi پشتیبانی نمی‌کنه. مگه اینکه توی تنظیمات بایوس (یا uefi، اگه از uefi پشتیبانی کنه) غیر فعال شده باشه که خیلی بعید می‌دونم.

    https به دلیل اینکه از رمزنگاری استفاده می‌کنه، می‌تونه از http امن‌تر باشه. به طور کلی اگه درست از رمزنگاری استفاده نشه، ممکنه اصلا امنیتی بدست نیارید

الان یعنی من بهتره کدوم رو بزارم؟

https
اگه چیزی که باهاش توزیع رو نصب می‌کنید سالم باشه و همینطور آینه‌ای که انتخاب می‌کنید، یه گواهی درست داشته باشه و بعضی موارد رو رعایت کنه، زیاد نگران  امنیت نباشید. یه امنیت کافی بوجود میاد.

پس من برای اطمینان هر دو مخزن non-free و contrib رو فعال میکنم که همه جانبه پشتیبانی شم و موردی برام پیش نیاد !

اگه وایفای یا چیزی ندارید که به firmware های انحصاری نیاز نداره، می‌تونید قسمت non-free رو فعال نکنید. توی قسمت contrib هم فکر نکنم چیزی که بدرد شما بخوره پیدا بشه.
اول فقط قسمت main رو فعال کنید، اگه بعد از چیزی کار نکرد، میشه قسمت non-free رو فعال کنید و چیز‌های مورد نیاز رو نصب کرد.

در انتهای تمامی خطوط ؟ یعنی به این شکل؟

کد: [انتخاب]

deb http://deb.debian.org/debian bullseye main non-free contrib
deb http://deb.debian.org/debian bullseye-updates main non-free contrib
deb http://deb.debian.org/debian-security bullseye-security main non-free contrib


بله همین شکلی. عوض کردن جا‌های main contrib و non-free با هم، مشکلی درست نمی‌کنه. در صورتی که بخواهید، می‌تونید از https به جای http استفاده کنید. می‌تونید از یه آینه دیگه هم استفاده کنید.
می‌تونید مخزن backport رو هم فعال کنید. این مخزن فقط برای نسخه پایدار وجود داره.
دبیان بعضی بروزرسانی‌ها رو از طریق backport ارائه میده. بسته‌هایی که یه مدت توی شاخه آزمایشی (testing) بررسی شدند، اول وارد مخزن backports-sloppy میشن، یه مدت اونجا آزمایش میشن و بعد وارد مخزن backport میشن.
آزمایش‌هایی که روی بسته‌های مخزن backport انجام شده، کمتر از آزمایشاتی هست که روی بسته‌ها از مخزن اصلی شده، به خاطر همین ممکنه به پایداری بسته‌های داخل مخزن اصلی نرسن ولی جدیدتر هستند. من تا حالا مشکلی با بسته‌های backport شده ندیدم.
به طور پیش‌فرض، بسته‌ها از مخزن backport نصب و ارتقا داده نمیشن. باید مستقیم به apt بگید که اینکار رو انجام بده. یا توی تنظیمات apt، بگید که الویت مخزن backport، بالاتر هست.
اگه می‌خواهید مخزن backport رو داشته باشید، این رو ببینید.

کد: [انتخاب]

deb https://deb.debian.org/debian bullseye-backports main contrib non-freeمی‌تونید خط بالا رو به فایل sources.list اضافه کنید. یه راه دیگه هم این هست که اون رو توی یه فایل جدا با پسوند list. توی دایرکتوری زیر تعریف کنید.

کد: [انتخاب]

/etc/apt/sources.list.d
مثلا فرض کنید اسم فایل رو bullseye-backports.list در نظر گرفتید، فایلی که باید ایجاد کنید، میشه این

کد: [انتخاب]

/etc/apt/sources.list.d/bullseye-backports.listمهم نیست اسم فایل چی باشه، ولی پسوندش باید list. باشه.
حالا توی این فایل، خطی که بالا نوشتم رو اضافه کنید. الان مخزن backport اضافه شده. قبل از اینکه بتونید چیزی از او مخزن دریافت کنید، باید لیست مخازن رو بروزرسانی کنید. با یه apt update اینکار ممکنه.

می‌تونید از xfs هم استفاده کنید. xfs کمی سریعتره، اما نمی‌تونید بدون پاک کردن اطلاعات داخلش، اون رو کوچک کنید. ext4 این قابلیت رو داره

با این مشکلی ندارم اما تنها ایرادش همینه ؟ مشکل دیگه ای نخواهم داشت ؟ سرعت بیشترش وسوسم کرد که ازش استفاده کنم ! چیزی کم نداره از ext4

تنها ایرادی که من از اون می‌دونم همینه. پایداری خیلی بالایی هم داره. توی rhel و توزیع‌های مبتنی بر اون، از xfs معمولا به طور پیش‌فرض استفاده میشه.
rhel مخفف red hat enterprise linux هست. همون توزیعیه که شرکت red hat توسعه میده.
در مورد سرعت، انتظار نداشته باشید سرعت یهو دو برابر بشه، سرعت xfs از ext4 بیشتره ولی نه اونقدر که بگید ext4 بهش نمیرسه، xfs یه مقداری سریع‌تر عمل می‌کنه.
سرعت به مقدار زیادی، به سخت‌افزار مرتبط هست. ولی فایل‌سیستم می‌تونه به صورت بهینه از سخت‌افزار استفاده کنه تا شرایط بهتر بشه.

راستی این دبیانی که داریم نصب میکنیم کدوم نسخه از دبیان میشه ؟ میخوام گنوم ۴۰ داخل مخازنش باشه ، شاید دسکتاپ هم نصب کردم ! چون تا جایی که یادمه دبیان نسخه فوق العاده پایدار و بدون باگ برنامه ها رو داره ، و برای نسخه های جدید تر باید از دبیان ناپایدار و آزمایشی استفاده کرد

دبیان ۱۱
اسم دبیان ۱۱، bullseye هست. گنوم ۴۰ توی مخازن دبیان ۱۱ نیست و فکر نکنم اصلا به دبیان ۱۱ بیاد.
گنوم ۴۰ توی دبیان ۱۲ (bookworm) ولی دبیان ۱۲ هنوز توی شاخه آزمایشی قرار داره. احتمالا تا حدود ۱ سال و ۶ ماه دیگه توی همین شاخه می‌مونه تا اینکه وارد شاخه پایدار بشه و دبیان ۱۱ وارد شاخه پایدارِ قدیمی.
اگه واقع می‌خواهید گنوم ۴۰ داشته باشید، می‌تونید دبیان ۱۲ رو نصب کنید.

در ضمن یه سوال ؟ موقع نصب نیازی به مشخص کردن نوع معماری نبود ؟ آخه تو اینترنت دیدم که یه جا معماری رو هم مشخص کرد ! قصدم فقط بیشتر آموختنه نه زیر سوال بردن دانش شما : )

اگه موقع نصب با debootstrap، معماری رو مشخص نکنید، debootstrap از معماری فعلی استفاده می‌کنه. مثلا اگه debootstrap برای معماری ia32 یا همون x86 کامپایل شده باشه (نسخه 32 بیتی اکثر پردازنده‌های اینتل و amd توی 20 سال گذشته، خیلی وقته دیگه نسخه ۳۲ بیتی این پردازنده‌ها تولید نمیشه)، سیستمی که نصب میشه، از همین معماری استفاده می‌کنه. یا مثلا اگه debootstrap برای معماری x64 یا همون x86_64 کامپایل شده باشه، سبستم نصب شده هم از همین معماری استفاده می‌کنه.
شما می‌تونید یه برنامه‌ای که برای معماری x86 کامپایل شده رو روی پردازنده x86_64 اجرا کنید، ولی برعکسش نمیشه. یا اگه بشه، خیلی سخته و ممونه بعضی قابلیت‌های برنامه رو هم نداشته باشید.
با آپشن arch-- می‌تونید مشخص کنید که debootstrap نصب رو برای چه معماری انجام بده. اگه اون برنامه‌هایی که برای معماری کامپایل شدند، نتونند روی پردازنده شما اجرا بشن، باید از آپشن‌های foreign-- و second-stage-- به طور مناسب استفاده بشه.

توی حالت شما، debootstrap برای معماری x64 کامپایل شده و پردازنده شما هم از همین معماری استفاده می‌کنه، پس لازم نیست معماری رو مشخص کنید.

خروجی :

کد: [انتخاب]

dpkg: version 2.13.6-10 of libapparmor1:amd64 already installed, skipping
dpkg: version 0~20171227-0.2 of libargon2-1:amd64 already installed, skipping
dpkg: version 2:2.3.5-1 of libcryptsetup12:amd64 already installed, skipping
dpkg: version 1.8.7-1 of libip4tc2:amd64 already installed, skipping
dpkg: version 0.15-2 of libjson-c5:amd64 already installed, skipping
dpkg: version 28-1 of libkmod2:amd64 already installed, skipping
dpkg: version 1:2.44-1 of libcap2:amd64 already installed, skipping
dpkg: version 2:1.02.175-2.1 of dmsetup already installed, skipping
dpkg: version 2:1.02.175-2.1 of libdevmapper1.02.1:amd64 already installed, skipping
dpkg: version 247.3-6 of systemd already installed, skipping
dpkg: version 247.3-6 of systemd-timesyncd already installed, skipping

راستش نمی‌دونم نصب درست انجام شده یا نه. اگه ممکنه، اون پارتیشن رو دوباره فرمت کنید و debootstrap رو دوباره اجرا کنید.
گنوم ۴۰ توی ۱۱ نیست ولی توی دبیان ۱۲ هست. اگه گنوم ۴۰ رو می‌خواهید، نمی‌تونید یه تجربه از اون روی دبیان ۱۱ داشته باشید. میشه گنوم رو از کد کامپایل و نصب کنید، اما بعدش سیستم رو هم خراب می‌کنید.
شاید برای شما بهتر باشه که از دبیان ۱۲ استفاده کنید. برای اینکار موقعی که می‌خواهید با debootstrap نصب رو انجام بدید، به جای اسمِ bullseye، از bookworm استفاده کنید.
مخازن رو هم باید یکم تغییر بدید. شاخه آزمایشی، مخزن update و security و backport و اینجور چیز‌ها نداره. فقط یه مخزن اصلی هست. پس فایل sources.list شما، باید این شکلی باشه

کد: [انتخاب]

deb https://deb.debian.org/debian bookworm main
شاخه آزمایشی، در واقعیت، مخازن update و security داره اما چیزی داخل اونها نیست. نمی‌دونم کاربردشون چی هست و برای چی اونجا هستند.

[سودو.]

تنها ایرادی که من از اون می‌دونم همینه. پایداری خیلی بالایی هم داره. توی rhel و توزیع‌های مبتنی بر اون، از xfs معمولا به طور پیش‌فرض استفاده میشه.
rhel مخفف red hat enterprise linux هست. همون توزیعیه که شرکت red hat توسعه میده.
در مورد سرعت، انتظار نداشته باشید سرعت یهو دو برابر بشه، سرعت xfs از ext4 بیشتره ولی نه اونقدر که بگید ext4 بهش نمیرسه، xfs یه مقداری سریع‌تر عمل می‌کنه.
سرعت به مقدار زیادی، به سخت‌افزار مرتبط هست. ولی فایل‌سیستم می‌تونه به صورت بهینه از سخت‌افزار استفاده کنه تا شرایط بهتر بشه

پس با همین فرمت میکنم !

اگه واقع می‌خواهید گنوم ۴۰ داشته باشید، می‌تونید دبیان ۱۲ رو نصب کنید.

پس دبیان ۱۲ رو نصب میکنم !

اگه ممکنه، اون پارتیشن رو دوباره فرمت کنید و debootstrap رو دوباره اجرا کنید.

چند بار کردم ! بازم همونه ..

فقط یه مخزن اصلی هست. پس فایل sources.list شما، باید این شکلی باشه

یعنی همه چیز جمع شده توی یک مخزن ؟!

یعنی الان نمیتونیم با chroot وارد بشیم و ادامه مراحل رو انجام بدیم ؟

[Dragon-]

اگه ممکنه، اون پارتیشن رو دوباره فرمت کنید و debootstrap رو دوباره اجرا کنید.

چند بار کردم ! بازم همونه ..

هر دفعه همون خطا قبلی رو میگیرید؟

یعنی همه چیز جمع شده توی یک مخزن ؟!

توی شاخه‌های دبیان، هر برنامه‌ای که قابل نصب هست، توی مخزن اصلی قرار داره. مخازن updates و security و ...، برای شاخه پایدار وجود دارند.
از اونجایی که بسته‌ها خیلی کم توی شاخه پایدار ارتقا پیدا می‌کنند، یه راهکار لازمه تا بشه بعضی ارتقا‌ها رو سریع انجام داد.

مخزن updates برای این هست که ارتقا‌هایی که نمیشه صبر کرد تا توی نسخه بعدی داشتشون و امنیتی هم نیستند. برای مثال آپدیت‌های بسته‌های مرتبط با تنظیمات مربوط به مناطق زمانی، توی این مخزن قرار میگیره. نمیشه تا زمانی که نسخه جدید دبیان بیاد، ساعت سیستم درست نباشه.

مخزن security برای ارتقا‌های امنیتی هست. زمانی که یه مشکل امنیتی توی چیزی پیدا میشه، معمولا مدتی بعدش، وصله‌های امنیتی برای اون درست میشه. تیم امنیت دبیان، این وصله‌های امنیتی رو برای نسخه‌ای که توی شاخه پایدار هست، تغییر میدند، برنامه کامپایل میشه و توی مخازن security در دسترس قرار میگیره تا شما بتونید اون رو دریافت کنید.

مخزن backports و backports-sloppy رو قبلا توضیح دادم.
یه مخزن proposed-updates هم وجود داره‌. هر چند وقت یه بار، توی مخزن اصلی شاخه پایدار، بروزرسانی میاد. این بروزرسانی‌ها باعث میشن نسخه بعد . یکی افزایش پیدا کنه.
برای مثال اول دبیان 11.0 اومد، چند ماه پیش، 11.1 و چند روز پیش 11.2 اومد. توی این ارتقا‌ها، بعضی بسته‌های اصلی سیستم ازتقا پیدا می‌کنند. مثل کرنل، base-system و اینجور چیز‌ها.
قبل از اینکه این ارتقا‌ها وارد مخزن اصلی شاخه پایدار بشن، وارد مخزن proposed-updates میشن تا به خوبی آزمایش بشن و بعد وارد مخزن اصلی بشن.

یعنی الان نمیتونیم با chroot وارد بشیم و ادامه مراحل رو انجام بدیم ؟

اول با debootstrap نصب رو انجام بدید و مطمئن بشید درست انجام شده. اگه درست انجام بشه، آخرش چیزی شبیه این می‌نویسه.

کد: [انتخاب]

The base system installed successfullyبعد فایل‌سیستم‌های مورد نیاز رو سوار کنید و بعد می‌تونید با chroot وارد بشید و چیز‌ها رو درست کنید. می‌تونید بدون اینکه فایل‌سیستم‌های مورد نیاز رو سوار کنید، با chroot وارد بشید ولی اینجوری، بعضی کار‌های نصب درست انجام نمیشن.

وقتی که از chroot خارج میشید، اگه خواستید، می‌تونید فایل‌سیستم‌های سوار شده رو unmount کنید. اینجوری

کد: [انتخاب]

sudo umount -R /mnt/proc
sudo umount -R /mnt/sys
sudo umount -R /mnt/dev
sudo umount -R /mnt/runیا با یه حلقه تکرار کار رو راحت‌تر کنید.

کد: [انتخاب]

for i in proc sys dev run; do
sudo umount -R /$i
done

[سودو.]

هر دفعه همون خطا قبلی رو میگیرید؟

بله هر دفعه !

اگه درست انجام بشه، آخرش چیزی شبیه این می‌نویسه.

خیر چند بار امتحان کردم ، آخرش به این نمیرسه ، همش همونه که فرستادم براتون !
راهی هست برای عبور از این مشکل ؟

[Dragon-]

هیچ خطای دیگه‌ای هم قبلش نمیده؟
وقتی که سعی می‌کردید دوباره با debootstrap نصب رو انجام بدید، قبلش اطلاعات قبلی رو پاک می‌کردید یا نه؟
اگه نمیشه، اول اطلاعات قبلی رو پاک کنید (مثلا با فرمت مجدد پارتیشن یا استفاده از دستور rm) بعد اول با این دستور چنتا دایرکتوری که شاید لازم بشه رو بسازید و دوباره debootstrap رو اجرا کنید. (با فرض اینکه پارتیشن مورد نظر، روی /mnt/ سوار شده)

کد: [انتخاب]

sudo mkdir -p /mnt/tmp/user/0

[سودو.]

خیر فقط همون خروجی که براتون فرستادم ن بیشتر
ممکنه در نصب دیبوتسرپ مشکلی پیش اومده باشه ؟ خروجی نصب اون به درد میخوره ؟

بله حتی کل هارد رو دوباره و دوباره فرمت کردم و بارها پارتیشن بندی ! اما باز هم نتیجه همونه !

به دلایلی احتیاج داشتم اوبونتو رو نصب کنم و توی تاپیک دیگری عرض کردم که محتوای فایل تکستی رو از دست دادم ، اگر تونستم بازیابیش کنم ، هارد رو فرمت میکنم و امتحان میکنم این روشو

[سودو.]

ایول ! ترفندتون کار کرد ! خروجی :


https://paste.ubuntu.ir/qrbp


اگه مشکلی نداره بریم واسه بقیه مراحل !

ی سوال ؟ چرا این مشکل پیش میومد ؟

[سودو.]

؟

[behzad121]

؟

اسمتونو تغییر بدید. میخواید یکی دستور روی اسمتونو بزنه و سیستم طرف به فنا بره؟

[سودو.]

؟

اسمتونو تغییر بدید. میخواید یکی دستور روی اسمتونو بزنه و سیستم طرف به فنا بره؟

چرا باید وقتی کسی معنیشو نمیدونه بره امتحانش کنه ؟ خب نکنه ! مگه من گفتم برو بزن دستورو ! عقل سلیم میگه وقتی دستوری رو نمیشناسی امتحانش نکن ! کسی که از معنای دستور خبر نداشته باشه و همینجوری بره تستش کنه همون بهتر نیس سیستمش ب فنا بره ؟ من جهت فان قضیه اینو گذاشتم ...

[Dragon-]

ایول ! ترفندتون کار کرد ! خروجی :


https://paste.ubuntu.ir/qrbp


اگه مشکلی نداره بریم واسه بقیه مراحل !

ی سوال ؟ چرا این مشکل پیش میومد ؟

debootstrap نصب رو به درستی انجام داده.
این چیزی که گفتم، ترفند نیست، راه حل هست.
معمولا بسته‌ها موقع نصب، دایرکتوری‌های موقتی ایجاد می‌کنند تا اسکریپت‌های نصب، بعضی چیز‌ها رو به صورت موقتی اونجا ذخیره کنند.
اسکریپت‌ها، معمولا از دستور mktemp برای اینکار استفاده می‌کنند. دستور mktemp، با توجه به آپشن p- تصمیم می‌گیره که دایرکتوری موقتی رو کجا ایجاد کنه.
اگه اون آپشن به دستور داده نشه (که معمولا داده نمیشه)، محلی که دایرکتوری باید ایجاد بشه، با توجه به متغییر محیطی TEMPDIR انتخاب میشه.
مقدار TEMPDIR، معمولا به این شکل هست.

کد: [انتخاب]

/tmp/user/UIDبه جای UID، مقدار uid کاربر مورد نظر قرار می‌گیره. به جای user چیزی قرار نمی‌گیره. برای مثال، اگه uid کاربر شما 1000 باشه، مقدار TEMPDIR میشه این.

کد: [انتخاب]

/tmp/user/1000
debootstrap با دسترسی روت اجرا شده. uid کاربر روت همیشه برابر 0 هست. به خاطر همین mktemp سعی می‌کنه دایرکتوری‌های موقتی رو داخل دایرکتوری زیر بسازه

کد: [انتخاب]

/tmp/user/0از اونجایی که دایرکتوری بالایی توی محیط chroot وجود نداره، mktemp با خطا مواجه میشه. به همین دلیل، اسکریپت نصب هم با خطا خارج میشه. وقتی اسکریپت‌های نصب با خطا خارج میشن، dpkg هم خطا میده و آخرش نصب درست انجام نمیشه.

الان مخازن رو مثل قبل که گفتیم، تنظیم کنید.
نام کامپیوتر رو هم تنظیم کنید. کامپیوتر با این اسم توی شبکه نمایان میشه. این همون اسمی هست که وقتی bash باز میشه، قبل از علامت @ می‌بینید. (اگه فایل‌های تنظیمات bash، روی حالت پیش‌فرض باشند)
نام کامپیوتر، داخل فایل hostname، توی دایرکتوری /etc/ قرار داره. دقت کنید منظورم از /etc/، اونی هست که مربوط به سیستم نصب شده هست.
تا جایی که می‌دونم، اسم نباید شامل فاصله باشه، فقط هم باید از کاراکتر‌های ASCII تشکیل شده باشه.

بعد از تنظیم فایل hostname، فایل hosts رو هم تنظیم کنید.
باید نام ماشین رو به فایل hosts اضافه کنید، در غیر اینصورت هر بار که sudo رو اجرا کنید، یه اخطار میده که نمی‌تونه چیزی با نام کامپیوتر شما پیدا کنه.
مثلا اگه اسم کامپیوتر Debian-custom باشه و توی فایل hosts تعریف نشده باشه، هر بار که sudo رو اجرا می‌کنید، این خطا رو می‌بینید.

کد: [انتخاب]

unable to resolve host Debian-custom: Name or service not known
برای اینکه این اخطار رو نگیرید، چیزی شبیه این به فایل hosts اضافه کنید.

کد: [انتخاب]

HOSTNAME       127.0.1.1به جای HOSTNAME، نام کامپیوتر رو بنویسید.

برای شرایط شما، زیاد مهم نیست که hostname چی باشه. اگه توی محیطی بودید که کامپیوتر‌های زیادی وجود داشت، باید با دقت فایل‌های hosts و hostname رو تنظیم می‌کردید ولی از اونجایی که توی شرایط شما کامپیوتر‌های زیادی توی یه شبکه قرار ندارند، لازم نیست زیاد نگران این باشید. فقط حواستون باشه که اسم دو کامپیوتر توی شبکه، یکی نشه.

[سودو.]

عذر میخوام ، دفعه پیشی ک امتحان کردم راه حلتونو برای دبیان آزمایشی بود که کار کرد ( بوک ورم ) و اوبونتو رو نصب نداشتم و لایو بود و از طریق اون نصب میکردم ! الان تصمیم گرفتم همون دبیان پایدار رو نصب کنم کنار اوبونتوی نصب شده ! اینجوری شد دوباره که !


https://paste.ubuntu.ir/ffrc


البته نا گفته نماند ک پارتیشن بندیم اینجوریه ...

کد: [انتخاب]

sda1 , 15 gb xfs , root of installed ubuntu

sda2 , 3 gb swap

sda3 , 7 gb xfs , ready for install debian debootstrap

sda4 , 55 gb xfs , home of installed ubuntu

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

کد: [انتخاب]

sda1 , sda4 , sda3 , sda2

مشکل کجاس ؟

[behzad121]

عذر میخوام ، دفعه پیشی ک امتحان کردم راه حلتونو برای دبیان آزمایشی بود که کار کرد ( بوک ورم ) و اوبونتو رو نصب نداشتم و لایو بود و از طریق اون نصب میکردم ! الان تصمیم گرفتم همون دبیان پایدار رو نصب کنم کنار اوبونتو ! اینجوری شد دوباره که !


https://paste.ubuntu.ir/ffrc

...

انگار systemd داره دخالت می کنه. خروجی این دستور رو بذارید:

کد: [انتخاب]

cat /mnt/debootstrap/debootstrap.log