বুট প্রক্রিয়া — BIOS/UEFI, bootloader, kernel আর init

১ · পাওয়ার বাটন থেকে login — বুটের বড় ছবি

সকালে অফিসে ল্যাপটপের পাওয়ার বাটন চাপলেন। ২০–৩০ সেকেন্ড পরে login স্ক্রিন এলো। এই অল্প সময়ে কম্পিউটারের ভেতরে একটি অদ্ভুত সমস্যার সমাধান হয়। সমস্যাটি হলো: অপারেটিং সিস্টেম নিজেই একটি প্রোগ্রাম, আর প্রোগ্রাম চালাতে OS লাগে। তাহলে OS-কে মেমরিতে আনবে কে?

উত্তর হলো ধাপে ধাপে ছোট থেকে বড় প্রোগ্রাম চালানো। প্রথমে একটি খুব ছোট প্রোগ্রাম চলে, যেটি মাদারবোর্ডের চিপে স্থায়ীভাবে লেখা থাকে। সে একটু বড় একটি প্রোগ্রামকে ডিস্ক থেকে আনে। সেটি আরও বড়টিকে আনে। শেষে পুরো OS চলে আসে। ইংরেজি প্রবাদ “pulling yourself up by your bootstraps” (জুতার ফিতা ধরে নিজেকে টেনে তোলা) থেকে এর নাম bootstrapping, সংক্ষেপে বুট।

প্রথম মুহূর্তটি আরও একটু কাছ থেকে দেখি। পাওয়ার বাটন চাপলে power supply ভোল্টেজ স্থির করে মাদারবোর্ডকে একটি “Power Good” সংকেত পাঠায়। তখন CPU reset অবস্থা থেকে বেরিয়ে আসে। Reset-এর পর CPU-র register-গুলো নির্দিষ্ট মানে থাকে, আর সে একটি নির্দিষ্ট ঠিকানা থেকে প্রথম নির্দেশ পড়ে — একে বলে reset vector. x86 CPU-তে এই ঠিকানা 0xFFFFFFF0, প্রথম ৪ GiB ঠিকানা-জগতের একদম শেষ প্রান্তের ১৬ বাইট আগে। মাদারবোর্ড এই ঠিকানাটি RAM-এ নয়, firmware-এর flash চিপে জুড়ে রাখে। সেখানে সাধারণত একটি jump নির্দেশ থাকে, যা firmware-এর মূল কোডে লাফ দেয়। ARM চিপে (ফোন, Apple silicon, Raspberry Pi) ঠিকানা ভিন্ন, প্রায়ই চিপের ভেতরের একটি Boot ROM প্রথম চলে — কিন্তু নীতি একই: হার্ডওয়্যারে আগে থেকে ঠিক করা একটি জায়গা থেকে প্রথম নির্দেশ।

এই পর্বটি পর্ব ৪-এর হার্ডওয়্যার (CPU, memory, interrupt), পর্ব ৫-এর user mode আর kernel mode এবং পর্ব ৬-এর kernel-গঠনের ওপর দাঁড়িয়ে আছে। বুট শেষে যে প্রথম প্রসেসটি জন্মায়, সেখান থেকেই মডিউল ২ শুরু — পর্ব ৮-এ প্রসেস আর পর্ব ১০-এ fork/exec দেখবেন।

২ · Legacy BIOS — POST আর ৫১২ বাইটের MBR

BIOS (Basic Input/Output System) এসেছে ১৯৮১ সালের IBM PC থেকে। প্রায় তিন দশক ধরে PC এভাবেই বুট হয়েছে, আর অনেক পুরোনো কম্পিউটারে এবং কিছু virtual machine-এ আজও হয়। BIOS-এর প্রথম কাজ POST (Power-On Self-Test): CPU, RAM, কীবোর্ড কন্ট্রোলার আর ভিডিও কার্ড ঠিক আছে কি না যাচাই। গুরুতর সমস্যা হলে, স্ক্রিন চালু হওয়ার আগেই, BIOS কয়েকটি “বিপ” শব্দে জানায় — কত বিপ, কী অর্থ, তা নির্মাতাভেদে আলাদা। তারপর BIOS নিজের সেটিং (বুট-ক্রম, তারিখ-সময়) পড়ে — এগুলো থাকে ব্যাটারি-চালিত একটি ছোট মেমরিতে, যাকে ঐতিহাসিক কারণে CMOS বলে। পুরোনো ডেস্কটপে তারিখ বারবার ২০০০ সালে ফিরে গেলে সেজন্যই মেকানিক বলেন “CMOS ব্যাটারি বদলান।”

এরপর BIOS বুট-ক্রমের প্রথম ডিস্কের প্রথম সেক্টরটি — LBA 0 (LBA = Logical Block Address, ডিস্কের সেক্টরের ক্রমিক নম্বর), মাত্র ৫১২ বাইট — মেমরির 0x7C00 ঠিকানায় এনে রাখে। একে বলে MBR (Master Boot Record). BIOS কোনো file system বোঝে না; সে জানে শুধু তিনটি কাজ: সেক্টর ০ পড়া, শেষ দুই বাইট 55 AA কি না দেখা, তারপর সেখানে লাফ দেওয়া। এই দুই বাইটকে বলে boot signature.

৪৪৬ বাইটে একটি file system পড়ার কোড লেখা প্রায় অসম্ভব। তাই আধুনিক bootloader (যেমন GRUB 2) ভাগ করে কাজ করে: MBR-এর ছোট কোড শুধু ডিস্কের পরের কয়েকটি নির্দিষ্ট সেক্টর থেকে বড় একটি অংশ আনে। নিচের ডায়াগ্রামে পুরো BIOS-শিকলটি ধাপে ধাপে দেখুন:

MBR-এর একটি partition entry হাতে পড়া

প্রতিটি partition entry ১৬ বাইট। এর মধ্যে আজকের কাজে লাগে চারটি জিনিস: বাইট ০ — bootable চিহ্ন (0x80 মানে “এখান থেকে বুট”), বাইট ৪ — partition-এর type (একটি সংখ্যা, যেমন 0x07 = NTFS, 0x83 = Linux), বাইট ৮–১১ — শুরুর LBA, বাইট ১২–১৫ — মোট সেক্টর সংখ্যা। বাইট ১–৩ আর ৫–৭-এ পুরোনো CHS (cylinder-head-sector) ঠিকানা থাকে, যা আজ আর কেউ ব্যবহার করে না। সংখ্যাগুলো little-endian — অর্থাৎ ছোট বাইটটি আগে লেখা। নিচে একটি বাস্তবসম্মত entry ধাপে ধাপে পড়ুন:

এবার একই কাজ কোড দিয়ে। নিচের প্রোগ্রামটি একটি নমুনা MBR (হাতে বসানো বাইট) থেকে signature যাচাই করে চারটি entry ছাপে। আসল ডিস্কের সেক্টর পড়তে root অনুমতি লাগে (/dev/sda), তাই এখানে বাইটগুলো কোডেই বসানো:

#include <stdio.h>
#include <stdint.h>
#include <string.h>
static uint32_t le32(const uint8_t *p) {          /* little-endian bytes -> number */
    return p[0] | p[1] << 8 | p[2] << 16 | (uint32_t)p[3] << 24;
}
static const char *type_name(uint8_t t) {
    switch (t) {
    case 0x00: return "empty";        case 0x07: return "NTFS/exFAT";
    case 0x0C: return "FAT32 (LBA)";  case 0x82: return "Linux swap";
    case 0x83: return "Linux";        case 0xEE: return "GPT protective";
    default:   return "other";
    }
}
int main(void) {
    uint8_t mbr[512] = {0};                       /* sector 0 of a disk */
    const uint8_t part[3][16] = {                 /* boot,CHS(3),type,CHS(3),LBA start,size */
        {0x80,0,0,0, 0x07,0,0,0, 0x00,0x08,0x00,0x00, 0x00,0x20,0x03,0x00},
        {0x00,0,0,0, 0x83,0,0,0, 0x00,0x28,0x03,0x00, 0x00,0x00,0x40,0x01},
        {0x00,0,0,0, 0x82,0,0,0, 0x00,0x28,0x43,0x01, 0x00,0x00,0x40,0x00}};
    memcpy(mbr + 446, part, sizeof part);         /* table starts at byte 446 */
    mbr[510] = 0x55; mbr[511] = 0xAA;             /* boot signature */
    if (mbr[510] != 0x55 || mbr[511] != 0xAA) { puts("not a valid MBR"); return 1; }
    puts("signature 0x55AA OK");
    puts("#  boot  type  name            start LBA    sectors   size");
    for (int i = 0; i < 4; i++) {
        const uint8_t *e = mbr + 446 + 16 * i;
        uint32_t start = le32(e + 8), count = le32(e + 12);
        printf("%d  %-4s  0x%02X  %-14s %10u %10u  %5u MiB\n", i + 1,
               e[0] == 0x80 ? "yes" : "-", e[4], type_name(e[4]),
               start, count, count / 2048);       /* 2048 sectors x 512 B = 1 MiB */
    }
    return 0;
}

signature 0x55AA OK
#  boot  type  name            start LBA    sectors   size
1  yes   0x07  NTFS/exFAT           2048     204800    100 MiB
2  -     0x83  Linux              206848   20971520  10240 MiB
3  -     0x82  Linux swap       21178368    4194304   2048 MiB
4  -     0x00  empty                   0          0      0 MiB

৩ · UEFI আর GPT — আধুনিক পথ

BIOS-এর সীমাবদ্ধতা অনেক: ১৬-bit real mode-এ চলে, মাত্র ১ MiB ঠিকানা সরাসরি দেখতে পায়, ডিস্ক সম্পর্কে জানে শুধু সেক্টর, নেটওয়ার্ক বা গ্রাফিক্সের জন্য প্রমিত কোনো ব্যবস্থা নেই, আর MBR-এর ৩২-bit LBA-র কারণে ডিস্কের সীমা ২ TiB. ১৯৯০-এর দশকের শেষে Intel তাদের Itanium সার্ভার চিপের জন্য EFI (Extensible Firmware Interface) নকশা করে। ২০০৫ সালে কয়েকটি কোম্পানি মিলে UEFI Forum গঠন করে, আর নাম হয় UEFI (Unified EFI). ২০১০-এর দশকে প্রায় সব নতুন PC UEFI-তে চলে যায়; বহু বছর পুরোনো OS চালানোর জন্য UEFI-র ভেতরে BIOS-এর অনুকরণ (CSM, Compatibility Support Module) রাখা হতো, যা নতুন প্ল্যাটফর্মে ক্রমশ বাদ পড়ছে।

UEFI-র মূল পরিবর্তনটি দর্শনগত: সেক্টরের বদলে ফাইল। UEFI firmware নিজেই FAT file system পড়তে পারে। ডিস্কে একটি ছোট FAT32 partition থাকে, নাম EFI System Partition (ESP), সাধারণত ১০০ MiB থেকে ১ GiB. তার ভেতরে bootloader-গুলো সাধারণ ফাইল — \EFI\ubuntu\shimx64.efi, \EFI\Microsoft\Boot\bootmgfw.efi. কোন ফাইল চালাতে হবে, তা লেখা থাকে মাদারবোর্ডের NVRAM-এ রাখা কয়েকটি “boot entry” ভেরিয়েবলে। কোনো entry না মিললে firmware একটি নির্দিষ্ট পথ খোঁজে: \EFI\BOOT\BOOTX64.EFI — এজন্যই বুটেবল USB কোনো সেটিং ছাড়াই কাজ করে।

ডিস্কের partition table-ও বদলেছে। GPT (GUID Partition Table) UEFI স্পেসিফিকেশনেরই অংশ। এতে LBA 0-এ একটি “protective MBR” থাকে — একটিমাত্র entry, type 0xEE, পুরো ডিস্ক জুড়ে — যাতে পুরোনো tool ডিস্কটিকে “ফাঁকা” ভেবে মুছে না ফেলে। LBA 1-এ GPT header, LBA 2 থেকে partition entry-র তালিকা (ডিফল্টে ১২৮টি entry, প্রতিটি ১২৮ বাইট)। প্রতিটি partition-এর type আর পরিচয় একটি ১২৮-bit GUID; ESP-র type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B. Header আর তালিকার CRC32 checksum থাকে, আর ডিস্কের শেষ সেক্টরগুলোতে থাকে একটি backup কপি — প্রথম দিক নষ্ট হলেও partition হারায় না।

Linux-এ boot entry দেখার কমান্ড efibootmgr (root লাগে, তাই এখানে চালানো যাবে না)। নিচে একটি dual-boot ল্যাপটপের নমুনা আউটপুট, সংক্ষিপ্ত করা:

$ sudo efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,0002
Boot0000* Windows Boot Manager   HD(1,GPT,...)/\EFI\Microsoft\Boot\bootmgfw.efi
Boot0001* ubuntu                 HD(1,GPT,...)/\EFI\ubuntu\shimx64.efi
Boot0002* UEFI: USB Flash Disk   PciRoot(0x0)/Pci(0x14,0x0)/USB(...)

৪ · Secure Boot — বিশ্বাসের শিকল

বুটের সময় যে কোড চলে, সেটি OS-এর আগে চলে — antivirus, firewall, এমনকি kernel-এর সব সুরক্ষা তখনো জন্মায়নি। তাই কোনো ক্ষতিকর প্রোগ্রাম যদি bootloader-এর জায়গা দখল করতে পারে (একে বলে bootkit), সে OS-এর নিচে বসে থাকে, আর OS তাকে সহজে দেখতেই পায় না। Secure Boot এই ঝুঁকি কমানোর জন্য UEFI-র একটি বৈশিষ্ট্য।

নীতিটি সরল: প্রতিটি ধাপ পরেরটিকে চালানোর আগে তার ডিজিটাল স্বাক্ষর যাচাই করে। Firmware-এর NVRAM-এ কয়েকটি key-তালিকা থাকে: PK (Platform Key — মালিক, সাধারণত PC নির্মাতা), KEK (যারা তালিকা হালনাগাদ করতে পারে), db (অনুমোদিত স্বাক্ষর বা hash) আর dbx (বাতিল — পরে দুর্বল প্রমাণিত হয়েছে এমন bootloader). Firmware কেবল সেই .efi চালায়, যার স্বাক্ষর db-তে আছে আর dbx-এ নেই। এভাবে firmware → shim → GRUB → kernel → kernel module পর্যন্ত একটি chain of trust তৈরি হয়।

Linux distro-গুলো কীভাবে এতে ঢুকল? বেশিরভাগ PC-র firmware-এ নির্মাতারা Microsoft-এর key বসিয়ে বিক্রি করেন। তাই Ubuntu, Fedora, Debian-এর মতো distro একটি ছোট প্রথম-ধাপ bootloader ব্যবহার করে — shim — যেটি Microsoft-এর UEFI CA দিয়ে স্বাক্ষরিত, আর ভেতরে distro-র নিজের key রাখে। shim সেই key দিয়ে GRUB আর kernel যাচাই করে। নিজের বানানো kernel module চালাতে চাইলে ব্যবহারকারী নিজের key “enroll” করতে পারেন (MOK, Machine Owner Key).

নিজের কম্পিউটারে Secure Boot চালু আছে কি না দেখার নিরাপদ উপায় (কোনো কিছু বদলায় না):

$ mokutil --sb-state
SecureBoot enabled
$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

PS C:\> Confirm-SecureBootUEFI
True

৫ · Bootloader — GRUB 2, systemd-boot আর Windows Boot Manager

Bootloader-এর কাজ তিনটি: (১) OS-এর kernel ফাইল খুঁজে RAM-এ আনা, (২) kernel-কে দরকারি তথ্য দেওয়া (command line, memory map, initramfs কোথায়), (৩) একাধিক OS বা একাধিক kernel থাকলে বাছাইয়ের সুযোগ দেওয়া। এরপর সে kernel-এ লাফ দিয়ে নিজে বিদায় নেয়। তিনটি বহুল-ব্যবহৃত bootloader পাশাপাশি দেখুন:

GRUB-এর মেনুর একটি entry আসলে কয়েকটি কমান্ডের তালিকা। grub.cfg-এর একটি সরলীকৃত অংশ:

menuentry 'Ubuntu' {
    search --no-floppy --fs-uuid --set=root 25a980c0-...   # কোন partition
    linux  /boot/vmlinuz-6.8.0-137-generic root=UUID=25a980c0-... ro quiet splash
    initrd /boot/initrd.img-6.8.0-137-generic
}

linux লাইনটি kernel ফাইল দেখায় আর তার পরের সব শব্দ হয়ে যায় kernel command line; initrd লাইনটি initramfs দেখায়। কনফিগ বদলানোর নিয়ম distro-ভেদে ভিন্ন — এটি AI প্রায়ই গুলিয়ে ফেলে:

৬ · Kernel জেগে ওঠে — decompress, memory, hardware আর root mount

Bootloader লাফ দেওয়ার মুহূর্তে kernel একটি সংকুচিত ফাইল — vmlinuz-এর “z” সেই সংকোচনের ইঙ্গিত। প্রথম কয়েকশো নির্দেশ একটি ছোট decompressor, যে kernel-এর বাকি অংশ RAM-এ খুলে সেখানে লাফ দেয়। তারপর kernel-এর আসল প্রথম C ফাংশন start_kernel() চলে। মোটা দাগে kernel এই কাজগুলো করে:

1. CPU আর মেমরি সাজানো: firmware-এর দেওয়া memory map (BIOS-এ “e820” তালিকা, UEFI-তে EFI memory map) দেখে কোন RAM ব্যবহারযোগ্য বোঝে, নিজের page table তৈরি করে virtual memory চালু করে (মডিউল ৫-এ বিস্তারিত), memory allocator প্রস্তুত করে।
2. Interrupt, timer আর scheduler: interrupt table বসায় (পর্ব ৪), ঘড়ি চালু করে, scheduler প্রস্তুত করে — এখন থেকে একাধিক কাজ পালাক্রমে চলতে পারবে।
3. হার্ডওয়্যার খোঁজা: x86 PC-তে firmware-এর ACPI টেবিল, আর অনেক ARM বোর্ডে bootloader-এর দেওয়া device tree বলে দেয় কোথায় কোন যন্ত্র আছে। Kernel PCI, USB ইত্যাদি bus স্ক্যান করে আর ভেতরে-জোড়া driver চালু করে।
4. প্রথম দুই প্রসেস: kernel নিজের ভেতরে দুটি কাজ তৈরি করে — PID 1 (যে পরে init হবে) আর PID 2 (kthreadd, kernel-এর নিজস্ব thread-গুলোর জনক)।
5. Root file system মাউন্ট: command line-এর root=UUID=… অনুযায়ী আসল ডিস্কের partition খুঁজে / হিসেবে জোড়া, তারপর সেখান থেকে /sbin/init চালানো।

শেষ ধাপে একটি ডিম-মুরগি সমস্যা আছে। Root partition হয়তো একটি NVMe SSD-তে, LVM-এর ভেতরে, LUKS দিয়ে এনক্রিপ্ট করা। এটি পড়তে লাগবে NVMe driver, LVM tool আর পাসওয়ার্ড চাওয়ার প্রোগ্রাম। কিন্তু এগুলো তো root partition-এর ভেতরেই রাখা! সব driver kernel-এর ভেতরে জুড়ে দিলে kernel বিশাল হয়ে যেত — তাই distro-গুলো driver-কে module হিসেবে রাখে (পর্ব ৬)।

সমাধান initramfs (initial RAM file system): একটি ছোট সংকুচিত আর্কাইভ (cpio ফরম্যাট), যেটি bootloader kernel-এর সাথেই RAM-এ এনে রাখে। Kernel এটিকে মেমরিতে একটি অস্থায়ী / হিসেবে খুলে তার /init চালায়। এই ছোট জগৎ দরকারি module লোড করে, দরকার হলে ডিস্কের পাসওয়ার্ড চায়, আসল root খুঁজে মাউন্ট করে, তারপর switch_root করে — অস্থায়ী জগৎ মুছে আসল ডিস্কের /sbin/init-কে PID 1 হিসেবে চালায়। পুরোনো পদ্ধতির নাম ছিল initrd (একটি RAM-ডিস্ক image); নাম রয়ে গেছে, তাই ফাইলের নাম এখনো প্রায়ই initrd.img.

এবার একটি চলমান Linux-এর kernel নিজের বুট সম্পর্কে কী বলে, দেখি। নিচের কোড এই পাতার Linux কন্টেইনারে চলে:

cat /proc/uptime
read up idle < /proc/uptime
secs=${up%.*}
echo "kernel up for: $((secs / 3600)) h $((secs % 3600 / 60)) min, CPUs: $(nproc)"
if [ -d /sys/firmware/efi ]; then echo "firmware: UEFI"; else echo "firmware: BIOS (or hidden)"; fi
echo "--- kernel command line ---"
if ! cat /proc/cmdline 2>/dev/null; then
    echo "(hidden inside this container)"
fi

6906866.88 9897034.33
kernel up for: 1918 h 34 min, CPUs: 2
firmware: BIOS (or hidden)
--- kernel command line ---
BOOT_IMAGE=/boot/vmlinuz-6.8.0-137-generic root=UUID=25a980c0-526d-4f97-9b82-d579b9ea2532 ro consoleblank=0 mpt3sas.max_queue_depth=1000 vultr ds=vultr console=ttyS0,115200n8 console=tty0

৭ · PID 1 — SysV init থেকে systemd

Kernel-এর শেষ কাজ user space-এ প্রথম প্রোগ্রামটি চালানো। Linux kernel প্রথমে initramfs-এর /init, তারপর command line-এর init=, তারপর /sbin/init, /etc/init, /bin/init আর শেষ চেষ্টা হিসেবে /bin/sh খোঁজে; কোনোটিই না পেলে panic. এই প্রোগ্রামটির প্রসেস নম্বর (PID) সবসময় ১, আর একে বলে init. এর তিনটি বিশেষ দায়িত্ব: বাকি সব সার্ভিস চালু করা, যে প্রসেসের বাবা-মা মারা গেছে তাদের দত্তক নিয়ে শেষ অবস্থা “সংগ্রহ” করা (zombie পরিষ্কার — পর্ব ১০), আর shutdown-এ সবাইকে গুছিয়ে বন্ধ করা। PID 1 নিজে মারা গেলে Linux kernel panic করে — পুরো সিস্টেমের ভিত্তি এটি।

তিন প্রজন্মের init

systemd-এ প্রতিটি সার্ভিস, mount, socket, timer হলো একটি unit — একটি ছোট টেক্সট ফাইল। একগুচ্ছ unit-কে একসাথে নাম দেওয়া যায়, যাকে বলে target: sysinit.target (মৌলিক প্রস্তুতি), basic.target, multi-user.target (পুরোনো runlevel ৩-এর মতো), graphical.target (runlevel ৫-এর মতো), rescue.target আর emergency.target (মেরামতের জন্য)। একটি সার্ভিসের unit ফাইল এমন দেখায়:

[Unit]
Description=OpenBSD Secure Shell server
After=network.target              # ক্রম: network.target-এর পরে চালু হবে

[Service]
ExecStart=/usr/sbin/sshd -D
Restart=on-failure                # মরে গেলে আবার চালানো হবে

[Install]
WantedBy=multi-user.target        # multi-user.target চাইলে এটিও চালু হবে

নিচে একটি ছোট সার্ভার বুটের সরলীকৃত চিত্র — প্রতিটি সার্ভিস কত মিলিসেকেন্ড নেয় তা কাল্পনিক, কিন্তু ক্রমের নিয়ম আসল systemd-এর মতো:

এই হিসাবটি একটি ছোট সিমুলেটরে চালিয়ে দেখুন। কোডটি unit-গুলোকে dependency-র “ঢেউ” অনুযায়ী সাজায় (গ্রাফের ভাষায় topological sort), আর প্রতিটি unit-এর শেষ সময় = তার সবচেয়ে দেরিতে শেষ হওয়া dependency + নিজের সময়:

// unit: [time it takes in ms, units it must start After]
const units = {
  'systemd-journald.service': [40, []],
  'systemd-udevd.service':    [120, []],
  'local-fs.target':          [0, ['systemd-udevd.service']],
  'sysinit.target':           [0, ['local-fs.target', 'systemd-journald.service']],
  'basic.target':             [0, ['sysinit.target']],
  'NetworkManager.service':   [300, ['basic.target']],
  'network.target':           [0, ['NetworkManager.service']],
  'sshd.service':             [60, ['network.target']],
  'cron.service':             [20, ['basic.target']],
  'getty@tty1.service':       [10, ['basic.target']],
  'multi-user.target':        [0, ['sshd.service', 'cron.service', 'getty@tty1.service']],
};
const done = {}, from = {};                        // finish time, slowest dependency
let wave = 0;
while (Object.keys(done).length < Object.keys(units).length) {
  const ready = Object.keys(units).filter(u => !(u in done) &&
    units[u][1].every(d => d in done)).sort();
  if (ready.length === 0) { console.log('ordering cycle!'); break; }
  const fin = {};
  for (const u of ready) {
    const deps = units[u][1];
    from[u] = deps.reduce((a, d) => (a === null || done[d] > done[a] ? d : a), null);
    fin[u] = (from[u] ? done[from[u]] : 0) + units[u][0];
  }
  Object.assign(done, fin);
  console.log(`wave ${++wave}: ` + ready.map(u => `${u} (done @${fin[u]}ms)`).join(', '));
}
const chain = [];
for (let u = 'multi-user.target'; u; u = from[u]) chain.unshift(`${u} @${done[u]}ms`);
console.log('critical chain: ' + chain.join(' -> '));

wave 1: systemd-journald.service (done @40ms), systemd-udevd.service (done @120ms)
wave 2: local-fs.target (done @120ms)
wave 3: sysinit.target (done @120ms)
wave 4: basic.target (done @120ms)
wave 5: NetworkManager.service (done @420ms), cron.service (done @140ms), getty@tty1.service (done @130ms)
wave 6: network.target (done @420ms)
wave 7: sshd.service (done @480ms)
wave 8: multi-user.target (done @480ms)
critical chain: systemd-udevd.service @120ms -> local-fs.target @120ms -> sysinit.target @120ms -> basic.target @120ms -> NetworkManager.service @420ms -> network.target @420ms -> sshd.service @480ms -> multi-user.target @480ms

এই পাতার কন্টেইনারে PID 1 কে?

echo "PID 1 is: $(ps -p 1 -o comm=)"
echo "This shell: PID $$, parent PID $PPID"
echo "--- every process in this container ---"
ps -e -o pid,ppid,comm
echo "--- kernel ---"
uname -sr

PID 1 is: podman-init
This shell: PID 2, parent PID 1
--- every process in this container ---
    PID    PPID COMMAND
      1       0 podman-init
      2       1 bash
      4       2 ps
--- kernel ---
Linux 6.8.0-137-generic

অন্য OS-এ PID 1-এর কাজ কে করে

৮ · মোবাইল ফোনের বুট আর dual boot

আপনার Android ফোনেও একই রিলে দৌড়, শুধু দৌড়বিদদের নাম আলাদা। চিপের ভেতরে স্থায়ীভাবে লেখা Boot ROM প্রথমে চলে, যেটি কারখানার পরে আর বদলানো যায় না। সে নির্মাতার স্বাক্ষরিত bootloader যাচাই করে চালায়; bootloader boot partition থেকে Linux kernel আর ramdisk আনে; kernel চালায় Android-এর নিজস্ব init, যে init.rc পড়ে সার্ভিস চালু করে, তার মধ্যে zygote — যার থেকে প্রতিটি অ্যাপের প্রসেস জন্মায়।

নিরাপত্তার কেন্দ্রে Android Verified Boot (AVB): প্রতিটি partition-এর hash একটি স্বাক্ষরিত তালিকায় (vbmeta) থাকে, আর বিশাল system partition-এর প্রতিটি block পড়ার সময়ই যাচাই হয় dm-verity দিয়ে। Rollback protection পুরোনো, দুর্বল সংস্করণে ফিরে যাওয়া আটকায়। Bootloader “unlock” করলে (কাস্টম ROM বসানোর জন্য) ফোন বুটের সময় সতর্কবার্তা দেখায় আর নিরাপত্তার জন্য ডেটা মুছে দেয়। iPhone-এও শিকল একই ধাঁচের: Boot ROM → iBoot → kernel, প্রতিটি ধাপ Apple-এর স্বাক্ষর যাচাই করে। মোবাইল OS-এর বাকি গল্প পর্ব ৫৪-এ।

Dual boot — এক কম্পিউটারে দুই OS

অনেক শিক্ষার্থী একই ল্যাপটপে Windows আর Ubuntu রাখেন। UEFI-তে এটি তুলনামূলক সহজ: দুই OS-এর bootloader একই ESP-তে পাশাপাশি দুটি ফোল্ডারে থাকে, আর NVRAM-এ দুটি boot entry. সাধারণত GRUB মেনুতে Windows-এর entry-ও থাকে (GRUB শুধু bootmgfw.efi-কে চালিয়ে দেয় — একে বলে chainloading). কিছু পরিচিত সতর্কতা:

• দুই OS একই মোডে: একটি UEFI আর অন্যটি Legacy/CSM মোডে ইনস্টল করলে একটি থেকে অন্যটির মেনু দেখা যায় না।
• সাধারণত আগে Windows, পরে Linux: Windows ইনস্টলার অন্য OS-এর মেনু যোগ করে না, আর বড় Windows আপডেট কখনো কখনো BootOrder-এ নিজেকে প্রথমে বসায়। তখন firmware সেটিং বা efibootmgr দিয়ে ক্রম ঠিক করতে হয় — কোনো partition মোছার দরকার নেই।
• Fast Startup: Windows-এর “Fast Startup” আসলে আংশিক hibernation — বন্ধ করার সময় kernel-এর অবস্থা ডিস্কে লিখে রাখে, আর Windows partition “ব্যবহারে আছে” অবস্থায় থাকে। তখন Linux থেকে সেই partition-এ লেখা ঝুঁকিপূর্ণ; dual boot-এ এটি বন্ধ রাখাই প্রচলিত পরামর্শ।
• ঘড়ি: Windows ডিফল্টে hardware clock-কে স্থানীয় সময় ধরে, Linux ধরে UTC — তাই OS বদলালে ঘড়ি ৬ ঘণ্টা এদিক-ওদিক দেখাতে পারে (বাংলাদেশ UTC+6). একটি OS-এর সেটিং বদলে দুটিকে মেলাতে হয়।

৯ · বুট কেন ব্যর্থ হয় — recovery আর বুট-সময় মাপা

বুট একটি শিকল, তাই যেকোনো কড়া ভাঙলে থেমে যায়। ভালো খবর হলো, কোথায় থেমেছে দেখলেই বোঝা যায় কোন কড়া ভেঙেছে — ঠিক যেমন compiler-এর error দেখে বোঝা যায় কোন ধাপের সমস্যা।

Recovery-র ধারণা: প্রতিটি সিস্টেমে মেরামতের একটি “বিকল্প পথ” থাকে, যা ভাঙা কড়াটি এড়িয়ে চলে। Linux-এ GRUB মেনুর “Advanced options”-এ পুরোনো kernel বা recovery mode; grub rescue>-এ সীমিত কমান্ড দিয়ে GRUB-কে তার ফাইলের ঠিকানা বলে দেওয়া যায়; আর সবচেয়ে নির্ভরযোগ্য পথ — একটি live USB থেকে বুট করে নিজের ডিস্ক মাউন্ট করা, তারপর bootloader আবার ইনস্টল বা initramfs আবার তৈরি করা। Windows-এ WinRE (Windows Recovery Environment) — Startup Repair, System Restore, পুরোনো আপডেট সরানো, Safe Mode — প্রায়ই নিজেই সমাধান করে; উন্নত ব্যবহারকারীরা সেখানকার command prompt থেকে bcdboot দিয়ে বুট-ফাইল আবার তৈরি করেন। সব ক্ষেত্রে প্রথম নিয়ম: কোনো কিছু লেখার আগে lsblk বা Disk Management দিয়ে নিশ্চিত হোন কোন ডিস্ক কোনটি, আর আগে ব্যাকআপ।

বুটে কত সময় লাগল — systemd-analyze

systemd বুটের প্রতিটি পর্বের সময় নিজেই মাপে। নিচে একটি ল্যাপটপের নমুনা আউটপুট (এই পাতার কন্টেইনারে systemd নেই, তাই এটি চালানো যাবে না):

$ systemd-analyze
Startup finished in 6.204s (firmware) + 2.511s (loader) + 1.873s (kernel) + 4.390s (userspace) = 14.979s
graphical.target reached after 4.352s in userspace.

$ systemd-analyze blame | head -4
2.104s NetworkManager-wait-online.service
 812ms snapd.service
 455ms dev-nvme0n1p2.device
 301ms systemd-journal-flush.service

$ systemd-analyze critical-chain
graphical.target @4.352s
└─multi-user.target @4.350s
  └─snapd.service @3.501s +812ms
    └─basic.target @3.489s

প্রথম লাইনটিই পুরো পর্বের সারাংশ: firmware (POST, ডিভাইস প্রস্তুত), loader (GRUB-এর মেনু-অপেক্ষাসহ), kernel (initramfs পর্যন্ত), userspace (systemd থেকে target). blame দেখায় কে বেশি সময় নিয়েছে — কিন্তু সাবধান, যে সার্ভিস সমান্তরালে চলে সে বেশি সময় নিলেও বুট দেরি না-ও করতে পারে। আসল প্রশ্ন critical chain-এ কে আছে। প্রায়ই সবচেয়ে বড় অংশটি firmware-এর, যা OS থেকে কমানো যায় না; Windows-এ একই ধরনের তথ্য পাওয়া যায় Event Viewer-এর Diagnostics-Performance লগে। পারফরম্যান্স মাপার পদ্ধতি পর্ব ৫৭-এ।

১০ · AI-এর যুগে বুট-সমস্যা — দ্রুত পরামর্শ, সাবধানে প্রয়োগ

বুট-সমস্যা মানেই চাপ — ল্যাপটপ চালু হচ্ছে না, কাল প্রেজেন্টেশন। এমন সময়ে AI-কে জিজ্ঞেস করা স্বাভাবিক, আর AI প্রায়ই কাজের কথাও বলে। কিন্তু বুটের কমান্ডগুলো ডিস্কের সবচেয়ে সংবেদনশীল অংশে লেখে; একটি ভুল ডিস্কের নাম বা ভুল মোডের কমান্ড পুরো ডেটা মুছে দিতে পারে। AI আপনার ডিস্ক দেখতে পায় না — সে জানে না আপনার মেশিন UEFI না BIOS, ডিস্ক /dev/sda না /dev/nvme0n1, distro Ubuntu না Fedora.

AI-এর বুট-পরামর্শ প্রয়োগের আগে — চেকলিস্ট

• নিজের firmware মোড (UEFI/BIOS), partition style (GPT/MBR), distro আর সংস্করণ AI-কে জানিয়েছি
• প্রতিটি কমান্ডের ডিস্ক বা partition-এর নাম lsblk -f দিয়ে নিজে মিলিয়েছি — অনুমানে নয়
• লেখার কমান্ডের আগে গুরুত্বপূর্ণ ফাইলের ব্যাকআপ আছে, আর live USB হাতে আছে
• কমান্ডটি man পাতা বা distro-র অফিসিয়াল উইকিতে মিলিয়ে দেখেছি
• নিরাপত্তা বন্ধ করার পরামর্শ (Secure Boot off, chmod 777, সব কিছু sudo দিয়ে) এলে আগে বিকল্প খুঁজেছি
• মেরামতের পর আবার বুট করে প্রতিটি OS আর systemd-analyze-এর ফল যাচাই করেছি