[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f7d9LP4tOVOVV5JOWtUc2lpth1kSiTTTG1yAashFpfP0":3},{"data":4,"related":88},{"id":5,"title":6,"slug":7,"excerpt":8,"cover":9,"category":11,"author":14,"track":20,"level":23,"reading_minutes":26,"is_featured":27,"published_at":28,"updated_at":28,"body":29,"toc":30,"tags":60,"faqs":73,"related_services":83,"comments_enabled":86,"meta_title":19,"meta_description":87,"canonical_url":19,"noindex":27,"is_live":86},15,"سرور مهاجرت‌شده بوت نمی‌شود: وقتی initramfs درایور virtio ندارد","cloud-migration-initramfs-missing-virtio-root-device","بعد از مهاجرت VM به ابر، اینستانس در پنل running است اما با پیام ALERT! UUID=... does not exist به شل initramfs می‌افتد. ریشه مشکل، نبود درایور virtio در initramfs و نام‌گذاری قدیمی دیسک ریشه است.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F9cf1d1eb-33ce-41f0-9340-feacdaec7596.webp",{"name":12,"slug":13},"زیرساخت ابری و IaC","cloud-infrastructure",{"name":15,"slug":16,"role":17,"bio":18,"linkedin_url":19,"avatar_url":19},"تحریریه کلودیکپ","cloudicap-editorial","تیم محتوای کلودیکپ","تیم فنی و محتوای کلودیکپ؛ مهندسانی که هر روز با DevOps، Kubernetes و زیرساخت ابری کار می‌کنند و تجربه‌هایشان را اینجا می‌نویسند.",null,{"value":21,"label":22},"engineers","مهندسان",{"value":24,"label":25},"intermediate","متوسط",7,false,"2026-10-17T08:11:06+00:00","\u003Cp>یکی از سناریوهای پرتکرار در پروژه‌های مهاجرت به کلودیکپ این است: سرور مجازی از دیتاسنتر قدیمی با فرمت qcow2 یا raw اکسپورت می‌شود، ایمیج آپلود و به دیسک اینستانس تبدیل می‌شود، اینستانس ساخته می‌شود و همه‌چیز درست به نظر می‌رسد. در پنل، وضعیت ماشین \u003Ccode>running\u003C\u002Fcode> است؛ اما نه SSH جواب می‌دهد و نه پینگ. به کنسول سریال نگاه می‌کنی و می‌بینی بوت همان اول متوقف شده است:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">Gave up waiting for root file system device.  Common problems:\n - Boot args (cat \u002Fproc\u002Fcmdline)\n - Check rootdelay= (did the system wait long enough?)\n - Missing modules (cat \u002Fproc\u002Fmodules; ls \u002Fdev)\nALERT!  UUID=9f3ac1e2-4b7d-4a11-9c2e-1d8f0a6b3c55 does not exist.  Dropping to a shell!\n\nBusyBox v1.35.0 (Debian 1:1.35.0-4) built-in shell (ash)\n(initramfs) _\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>در برخی توزیع‌ها به‌جای این پیام، کرنل پنیک می‌کند:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>نشانه‌های تشخیصی که باید کنار هم بگذاری:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>در پنل کلودیکپ اینستانس \u003Ccode>running\u003C\u002Fcode> است و کنسول سریال کار می‌کند؛ یعنی هایپروایزر و ماشین سالم‌اند و مشکل داخل خود سیستم‌عامل است.\u003C\u002Fli>\n\u003Cli>در شل \u003Ccode>(initramfs)\u003C\u002Fcode> دستور \u003Ccode>ls \u002Fdev\u003C\u002Fcode> را بزن: اگر \u003Ccode>vda\u003C\u002Fcode> یا \u003Ccode>sda\u003C\u002Fcode> را نبینی، یعنی هیچ درایور بلوکی برای کنترلر جدید لود نشده است.\u003C\u002Fli>\n\u003Cli>اگر \u003Ccode>ls \u002Fdev\u002Fsda\u003C\u002Fcode> یا \u003Ccode>ls \u002Fdev\u002Fvda\u003C\u002Fcode> وجود دارد ولی بوت ادامه پیدا نمی‌کند، مشکل درایور نیست؛ مقدار \u003Ccode>root=\u003C\u002Fcode> در cmdline اشتباه است.\u003C\u002Fli>\n\u003Cli>اگر سیستم بالا می‌آید ولی شبکه نیست، مشکل از initramfs گذشته و به udev و cloud-init رسیده‌ایم.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"علت-ریشه‌ای\">علت ریشه‌ای\u003C\u002Fh2>\n\u003Cp>هسته لینوکس درایور دیسک و شبکه را از داخل initramfs لود می‌کند، نه از ماژول‌های روی دیسک. initramfs در زمان نصب یا آخرین \u003Ccode>update-initramfs\u003C\u002Fcode>، بر اساس سخت‌افزار همان لحظه ساخته شده است. روی سرور فیزیکی یا VMware، کنترلر دیسک \u003Ccode>megaraid_sas\u003C\u002Fcode>، \u003Ccode>mptspi\u003C\u002Fcode> یا \u003Ccode>ahci\u003C\u002Fcode> بوده و کارت شبکه \u003Ccode>e1000\u003C\u002Fcode> یا \u003Ccode>vmxnet3\u003C\u002Fcode>. روی ابر کلودیکپ که مبتنی بر KVM است، همه این‌ها با خانواده \u003Ccode>virtio\u003C\u002Fcode> جایگزین می‌شوند. اگر initramfs با \u003Ccode>MODULES=dep\u003C\u002Fcode> ساخته شده باشد، فقط درایور همان کنترلر قدیمی داخلش کپی شده و درایور \u003Ccode>virtio_blk\u003C\u002Fcode> اصلاً وجود ندارد. نتیجه: کرنل بوت می‌شود، initramfs اجرا می‌شود، هیچ دستگاه بلوکی پیدا نمی‌کند، UUID ریشه را نمی‌بیند و به شل می‌افتد.\u003C\u002Fp>\n\u003Cp>سه لایه مشکل را جدا کن، چون هر سه با هم شایع‌اند:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\u003Cth>لایه\u003C\u002Fth>\u003Cth>روی سرور قدیمی\u003C\u002Fth>\u003Cth>روی ابر کلودیکپ\u003C\u002Fth>\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\u003Ctd>کنترلر دیسک\u003C\u002Ftd>\u003Ctd>megaraid_sas \u002F mptspi \u002F ahci\u003C\u002Ftd>\u003Ctd>virtio_blk یا virtio_scsi\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>کارت شبکه\u003C\u002Ftd>\u003Ctd>e1000 \u002F vmxnet3 \u002F tg3\u003C\u002Ftd>\u003Ctd>virtio_net\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>نام دستگاه\u003C\u002Ftd>\u003Ctd>\u002Fdev\u002Fsda\u003C\u002Ftd>\u003Ctd>\u002Fdev\u002Fvda (یا sda در حالت IDE-emulation)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>نام اینترفیس\u003C\u002Ftd>\u003Ctd>eth0 با قواعد udev ثابت\u003C\u002Ftd>\u003Ctd>ens3 \u002F eth0 بسته به تنظیمات ایمیج\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>به این ترتیب حتی اگر درایور را اضافه کنی، ممکن است \u003Ccode>root=\u002Fdev\u002Fsda1\u003C\u002Fcode> در cmdline یا \u003Ccode>\u002Fdev\u002Fsda1\u003C\u002Fcode> در \u003Ccode>\u002Fetc\u002Ffstab\u003C\u002Fcode> هنوز به نام قدیمی اشاره کند و بوت در گام بعدی بشکند.\u003C\u002Fp>\n\u003Cblockquote>قانون طلایی مهاجرت: قبل از هر تغییری روی اینستانس، یک snapshot از دیسک بگیر. تمام دستورهای این مقاله روی نسخه snapshot قابل تکرار هستند و اگر جایی اشتباه شد، برمی‌گردی عقب.\u003C\u002Fblockquote>\n\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\n\u003Ch3 id=\"گام-۱-بوت-در-حالت-rescue\">گام ۱: بوت در حالت rescue\u003C\u002Fh3>\n\u003Cp>در پنل کلودیکپ، اینستانس را خاموش کن (نه reboot)، سپس از بخش Console گزینه boot در حالت rescue را فعال کن یا ایمیج rescue را به‌عنوان دیسک دوم وصل کن. بعد از بالا آمدن، دیسک‌ها را شناسایی کن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT\nblkid\nvgchange -ay\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>خروجی نشان می‌دهد ریشه روی \u003Ccode>\u002Fdev\u002Fvdb1\u003C\u002Fcode> است یا روی یک LV مثل \u003Ccode>\u002Fdev\u002Fmapper\u002Fvg0-root\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3 id=\"گام-۲-مانت-کردن-ریشه-و-ورود-به-chroot\">گام ۲: مانت کردن ریشه و ورود به chroot\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">mkdir -p \u002Fmnt\u002Froot\nmount \u002Fdev\u002Fvdb1 \u002Fmnt\u002Froot          # یا mount \u002Fdev\u002Fmapper\u002Fvg0-root \u002Fmnt\u002Froot\n\nfor d in dev dev\u002Fpts proc sys run; do\n  mount --rbind \u002F$d \u002Fmnt\u002Froot\u002F$d\ndone\n\nchroot \u002Fmnt\u002Froot \u002Fbin\u002Fbash\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر \u003Ccode>\u002Fboot\u003C\u002Fcode> پارتیشن جدا دارد، آن را هم داخل \u003Ccode>\u002Fmnt\u002Froot\u002Fboot\u003C\u002Fcode> مانت کن.\u003C\u002Fp>\n\u003Ch3 id=\"گام-۳-اصلاح-initramfs-دلینوکس-دبیان-اوبونتو\">گام ۳: اصلاح initramfs (دلینوکس\u002Fدبیان\u002Fاوبونتو)\u003C\u002Fh3>\n\u003Cp>اول ببین واقعاً virtio داخل initramfs هست یا نه:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">lsinitramfs \u002Fboot\u002Finitrd.img-$(uname -r) | grep -c virtio_blk\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر عدد صفر بود، ماژول‌ها را اضافه کن. با \u003Ccode>printf\u003C\u002Fcode> این کار را انجام می‌دهیم تا از مشکلات heredoc در شل rescue دور بمانیم:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">printf '%s\\n' virtio virtio_ring virtio_pci virtio_blk virtio_scsi virtio_net | tee -a \u002Fetc\u002Finitramfs-tools\u002Fmodules\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>سپس حالت ساخت initramfs را از \u003Ccode>dep\u003C\u002Fcode> به \u003Ccode>most\u003C\u002Fcode> تغییر بده تا همه درایورهای رایج داخل ایمیج قرار بگیرند:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">sed -i 's\u002F^MODULES=.*\u002FMODULES=most\u002F' \u002Fetc\u002Finitramfs-tools\u002Finitramfs.conf\ngrep '^MODULES=' \u002Fetc\u002Finitramfs-tools\u002Finitramfs.conf\nupdate-initramfs -u -k all\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>حالا دوباره بررسی کن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">lsinitramfs \u002Fboot\u002Finitrd.img-$(uname -r) | grep -E 'virtio_(blk|scsi|net)'\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>روی خانواده RHEL\u002FCentOS\u002FAlmaLinux این معادل با dracut است:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">dracut --force --add-drivers \"virtio_blk virtio_scsi virtio_net\" \u002Fboot\u002Finitramfs-$(uname -r).img\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3 id=\"گام-۴-اصلاح-fstab-و-پارامتر-root-کرنل\">گام ۴: اصلاح fstab و پارامتر root کرنل\u003C\u002Fh3>\n\u003Cp>در \u003Ccode>\u002Fetc\u002Ffstab\u003C\u002Fcode> هیچ دستگاهی را با نام ثابت نگه ندار. UUID را از \u003Ccode>blkid\u003C\u002Fcode> بگیر و جایگزین کن. نمونه فایل بعد از اصلاح:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">UUID=9f3ac1e2-4b7d-4a11-9c2e-1d8f0a6b3c55  \u002F          ext4  errors=remount-ro  0  1\nUUID=1c0a8b77-2e4f-4c2a-8d71-5a6e2f9b0c33  \u002Fboot      ext4  defaults           0  2\nUUID=4d9e2a10-6b31-4f88-a0c5-7e2b1d9a4f60  none       swap  sw                 0  0\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>همین UUID را در cmdline کرنل هم تأیید کن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">grep -m1 'root=' \u002Fboot\u002Fgrub\u002Fgrub.cfg\ngrep '^GRUB_CMDLINE_LINUX' \u002Fetc\u002Fdefault\u002Fgrub\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر \u003Ccode>root=\u002Fdev\u002Fsda1\u003C\u002Fcode> دیدی، آن را با \u003Ccode>root=UUID=...\u003C\u002Fcode> عوض کن و سپس grub را بازتولید کن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">update-grub\n# یا در توزیع‌هایی که update-grub ندارند:\ngrub-mkconfig -o \u002Fboot\u002Fgrub\u002Fgrub.cfg\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3 id=\"گام-۵-اینترفیس-شبکه-و-cloud-init\">گام ۵: اینترفیس شبکه و cloud-init\u003C\u002Fh3>\n\u003Cp>قواعد udev قدیمی که نام کارت شبکه را به MAC آدرس قبلی گره زده‌اند، حذف کن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">rm -f \u002Fetc\u002Fudev\u002Frules.d\u002F70-persistent-net.rules\nrm -f \u002Fetc\u002Fudev\u002Frules.d\u002F75-persistent-net-generator.rules\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>فایل netplan قدیمی با IP استاتیک دیتاسنتر قبلی، روی ابر بی‌معنی است. آن را با DHCP جایگزین کن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\">network:\n  version: 2\n  ethernets:\n    eth0:\n      dhcp4: true\n      dhcp6: false\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر نام اینترفیس جدید \u003Ccode>ens3\u003C\u002Fcode> است ولی فایل قبلی فقط \u003Ccode>eth0\u003C\u002Fcode> را توصیف می‌کند، یا نام فایل را تغییر بده یا در grub مقدار \u003Ccode>net.ifnames=0\u003C\u002Fcode> را به \u003Ccode>GRUB_CMDLINE_LINUX\u003C\u002Fcode> اضافه کن. بعد از بوت، \u003Ccode>netplan apply\u003C\u002Fcode> را اجرا کن (داخل chroot معنی ندارد).\u003C\u002Fp>\n\u003Cp>در پایان، وضعیت cloud-init را آماده کن تا اینستانس هویت جدید بگیرد:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">cloud-init clean --logs\nexit\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>از chroot خارج شو، مانت‌ها را برگردان و در پنل، حالت rescue را غیرفعال کن و اینستانس را روشن کن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">umount -R \u002Fmnt\u002Froot\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"بررسی-اینکه-مشکل-واقعا-حل-شده-است\">بررسی اینکه مشکل واقعاً حل شده است\u003C\u002Fh2>\n\u003Cp>بعد از بوت موفق، این چک‌لیست را کامل بزن:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">lsmod | grep -E 'virtio_(blk|scsi|net)'\ndmesg | grep -i -m3 virtio\nfindmnt \u002F -o SOURCE,FSTYPE\nip -br address\nsystemctl --failed\ncloud-init status --long\ncat \u002Fetc\u002Fmachine-id && hostnamectl\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cul>\n\u003Cli>اگر \u003Ccode>lsmod\u003C\u002Fcode> ماژول \u003Ccode>virtio_blk\u003C\u002Fcode> یا \u003Ccode>virtio_scsi\u003C\u002Fcode> را نشان دهد و \u003Ccode>findmnt \u002F\u003C\u002Fcode> منبع را \u003Ccode>\u002Fdev\u002Fvda*\u003C\u002Fcode> نمایش دهد، بوت از مسیر درست انجام شده است.\u003C\u002Fli>\n\u003Cli>خروجی \u003Ccode>systemctl --failed\u003C\u002Fcode> باید خالی باشد. خطاهای مربوط به سرویس‌های وابسته به IP قدیمی (nginx، postfix، haproxy) معمولاً همین‌جا خودشان را نشان می‌دهند.\u003C\u002Fli>\n\u003Cli>\u003Ccode>cloud-init status --long\u003C\u002Fcode> باید \u003Ccode>status: done\u003C\u002Fcode> باشد؛ اگر \u003Ccode>error\u003C\u002Fcode> داد، datasource درست تشخیص داده نشده و باید \u003Ccode>\u002Fetc\u002Fcloud\u002Fcloud.cfg.d\u002F\u003C\u002Fcode> را بررسی کنی.\u003C\u002Fli>\n\u003Cli>اگر دیسک را بزرگ‌تر کرده‌ای، فقط یک قدم مانده: \u003Ccode>growpart \u002Fdev\u002Fvda 1\u003C\u002Fcode> و سپس \u003Ccode>resize2fs \u002Fdev\u002Fvda1\u003C\u002Fcode> (یا \u003Ccode>xfs_growfs \u002F\u003C\u002Fcode>) و تأیید با \u003Ccode>df -h \u002F\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>قبل از مهاجرت، درایورهای virtio را عمداً اضافه کن.\u003C\u002Fstrong> یک \u003Ccode>MODULES=most\u003C\u002Fcode> و چند خط در \u003Ccode>\u002Fetc\u002Finitramfs-tools\u002Fmodules\u003C\u002Fcode> به‌اندازه ساعت‌ها عیب‌یابی شبانه ارزش دارد.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>هرگز در fstab و cmdline از نام دستگاه استفاده نکن.\u003C\u002Fstrong> UUID یا \u003Ccode>LABEL\u003C\u002Fcode> تنها مرجع قابل اتکاست؛ نام \u003Ccode>sda\u003C\u002Fcode> بین هایپرلایزرها جابه‌جا می‌شود.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>ایمیج را با ابزار استاندارد تبدیل کن.\u003C\u002Fstrong> ابزارهایی مثل \u003Ccode>virt-v2v\u003C\u002Fcode> خودشان درایورهای virtio را تزریق و fstab را اصلاح می‌کنند؛ اکسپورت خام qcow2 بدون این مرحله، همان چیزی است که این مقاله را لازم می‌کند.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>شبکه را DHCP-محور تحویل بده.\u003C\u002Fstrong> IP استاتیک را بعد از مهاجرت، از طریق cloud-init یا پنل تخصیص بده، نه داخل ایمیج.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>هویت ماشین را بازتولید کن.\u003C\u002Fstrong> \u003Ccode>machine-id\u003C\u002Fcode>، کلیدهای SSH هاست و hostname قدیمی روی چند اینستانس همزمان، هم مشکل امنیتی است هم باعث تداخل در \u003Ca href=\"\u002Fservices\u002Fmonitoring\">مانیتورینگ\u003C\u002Fa> می‌شود.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>همیشه ابتدا در محیط staging بوت کن.\u003C\u002Fstrong> یک اینستانس آزمایشی با همان ایمیج و همان مشخصات شبکه، چند دقیقه وقت می‌گیرد و کل ریسک را حذف می‌کند.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>مهاجرت ابری در بیشتر مواقع نه با خطای هایپرلایزر، بلکه با این جزئیات کوچک داخل سیستم‌عامل شکست می‌خورد؛ همان جاهایی که سال‌ها بدون مشکل کار کرده‌اند و کسی به آن‌ها نگاه نکرده است.\u003C\u002Fp>",[31,35,38,42,45,48,51,54,57],{"id":32,"text":33,"level":34},"علت-ریشه‌ای","علت ریشه‌ای",2,{"id":36,"text":37,"level":34},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":39,"text":40,"level":41},"گام-۱-بوت-در-حالت-rescue","گام ۱: بوت در حالت rescue",3,{"id":43,"text":44,"level":41},"گام-۲-مانت-کردن-ریشه-و-ورود-به-chroot","گام ۲: مانت کردن ریشه و ورود به chroot",{"id":46,"text":47,"level":41},"گام-۳-اصلاح-initramfs-دلینوکس-دبیان-اوبونتو","گام ۳: اصلاح initramfs (دلینوکس\u002Fدبیان\u002Fاوبونتو)",{"id":49,"text":50,"level":41},"گام-۴-اصلاح-fstab-و-پارامتر-root-کرنل","گام ۴: اصلاح fstab و پارامتر root کرنل",{"id":52,"text":53,"level":41},"گام-۵-اینترفیس-شبکه-و-cloud-init","گام ۵: اینترفیس شبکه و cloud-init",{"id":55,"text":56,"level":34},"بررسی-اینکه-مشکل-واقعا-حل-شده-است","بررسی اینکه مشکل واقعاً حل شده است",{"id":58,"text":59,"level":34},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[61,64,67,69,71],{"name":62,"slug":63},"Linux","linux",{"name":65,"slug":66},"مهاجرت ابری","mhagrt-abry",{"name":68,"slug":68},"initramfs",{"name":70,"slug":70},"virtio",{"name":72,"slug":72},"cloud-init",[74,77,80],{"question":75,"answer":76},"چرا سرور بعد از مهاجرت در پنل running است ولی SSH جواب نمی‌دهد؟","وضعیت running فقط سالم بودن ماشین مجازی در هایپرلایزر را نشان می‌دهد. اگر initramfs درایور virtio_blk را نداشته باشد، کرنل دیسک ریشه را پیدا نمی‌کند و در شل initramfs متوقف می‌شود؛ در نتیجه sshd هرگز اجرا نمی‌شود. با کنسول سریال و پیام ALERT! UUID does not exist این وضعیت را تأیید کن.",{"question":78,"answer":79},"آیا کافی است فقط ماژول virtio_blk را به initramfs اضافه کنم؟","خیر. اگر کنترلر دیسک ابر از نوع virtio-scsi باشد به virtio_scsi نیاز داری و برای شبکه هم virtio_net. بهترین کار تنظیم MODULES=most و افزودن هر سه ماژول (به‌همراه virtio_pci) و سپس اجرای update-initramfs -u -k all است.",{"question":81,"answer":82},"بعد از حل مشکل بوت، چرا سرور IP نمی‌گیرد؟","چون فایل netplan یا ifcfg از دیتاسنتر قبلی یک IP استاتیک و نام اینترفیس قدیمی (مثلاً eth0) را توصیف می‌کند، در حالی که کارت شبکه جدید ممکن است ens3 باشد. فایل را به DHCP تغییر بده، قواعد udev قدیمی را حذف کن و در صورت نیاز net.ifnames=0 را به cmdline کرنل اضافه کن.",[84,85,13],"cloud-migration","infrastructure-as-code",true,"رفع خطای ALERT! UUID does not exist بعد از مهاجرت سرور به ابر: افزودن virtio_blk و virtio_scsi به initramfs، اصلاح fstab و بازسازی grub به‌صورت گام‌به‌گام.",[89,102,114],{"id":90,"title":91,"slug":92,"excerpt":93,"cover":94,"category":96,"author":97,"track":98,"level":99,"reading_minutes":100,"is_featured":27,"published_at":101,"updated_at":101},14,"SSH وصل است ولی scp هنگ می‌کند؛ راز MTU در مهاجرت ابری","cloud-migration-mtu-scp-hangs","بعد از مهاجرت سرور به ابر، SSH وصل می‌شود اما scp و rsync وسط انتقال هنگ می‌کنند. ریشه ماجرا MTU کوچک‌تر شبکه overlay و مسدود بودن ICMP برای PMTUD است.",{"url":95,"alt":91},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F0d69eee7-4386-48c9-a8a3-17eaeb78c5b5.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},5,"2026-10-16T09:49:00+00:00",{"id":100,"title":103,"slug":104,"excerpt":105,"cover":106,"category":108,"author":109,"track":110,"level":111,"reading_minutes":112,"is_featured":27,"published_at":113,"updated_at":113},"قفل state ترافورم گیر کرده؛ آزادسازی امن بعد از کیل شدن apply","terraform-state-lock-stuck-force-unlock","وقتی پایپلاین CI وسط اجرای apply کشته می‌شود، قفل state ترافورم در جدول DynamoDB باقی می‌ماند و اجرای بعدی با خطای Error acquiring the state lock متوقف می‌شود. در این مقاله علت ریشه‌ای، روش آزادسازی امن و راه‌های پیشگیری را بررسی می‌کنیم.",{"url":107,"alt":103},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002Fe26789f7-eced-4abb-b6a9-a91adf9b7500.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},6,"2026-10-08T09:49:26+00:00",{"id":115,"title":116,"slug":117,"excerpt":118,"cover":119,"category":121,"author":124,"track":125,"level":126,"reading_minutes":26,"is_featured":27,"published_at":127,"updated_at":127},12,"خطای fsnotify watcher در Kubernetes؛ سقف inotify نود","kubernetes-fsnotify-watcher-inotify-limit","اگر پادهای Grafana، Prometheus یا هر اپلیکیشنی که از inotify استفاده می‌کند با خطای «failed to create fsnotify watcher: too many open files» کرش می‌کنند، مقصر سقف پیش‌فرض هسته لینوکس روی نود است.",{"url":120,"alt":116},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F4781a89b-ab2c-4250-9677-521b30f6f643.webp",{"name":122,"slug":123},"Kubernetes و کانتینر","kubernetes",{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-13T09:37:29+00:00"]