حلّ المجتمع

تعرض صفحة الشبكة في ZimaOS عدم وجود أي واجهات رغم أن اتصال Ethernet يعمل

A November 2025 multi-NIC server case where Intel I226-V Ethernet obtained a DHCP address and carried traffic, but the ZimaOS 1.5.x Network page showed no configurable interfaces. IceWhale asked the user to remove the router reservation and use ZimaClient, while deeper community diagnostics pointed toward interface discovery or lshw parsing. No public final fix was posted.

هذا النقاش حول الشبكة، المنشور في نوفمبر 2025، ليس حالة عادية من نوع «لا توجد شبكة في ZimaOS». كان الخادم متصلًا بالإنترنت، ولديه عنوان DHCP، وينقل البيانات عبر واجهة إيثرنت Intel I226-V، ومع ذلك كانت الإعدادات > الشبكة تعرض قسم اتصال فارغًا ولا توفر طريقة لتهيئة عنوان IP ثابت. كما كان الجهاز يضم منفذي I226-V بسرعة 2.5GbE وواجهتي Intel X710 SFP+، مما جعله نظامًا متعدد بطاقات الشبكة أكثر تعقيدًا من الأجهزة التي صُممت واجهة شبكة ZimaOS في الأصل لتدعمها.

تطوّر النقاش الأصلي عبر حجوزات جهاز التوجيه، وتبديل المنافذ، وإعادة التشغيل الداخلية ETHS تجارب التهيئة، واختبار واجهة API، وأخيرًا خطأ دفع أحد أعضاء الفريق إلى الاشتباه في lshw التحليل. انتهت المحادثة العامة بعد أن أرسل المستخدم معلومات الأجهزة بشكل خاص، لذلك لا يوجد إصلاح نهائي منشور.

كانت صفحة الشبكة فارغة رغم إمكانية الوصول إلى الخادم

إعدادات شبكة ZimaOS تعرض قسم اتصال فارغًا رغم أن الخادم لديه عنوان شبكة يعمل
تمكن المستخدم من الوصول إلى ZimaOS عبر عنوان DHCP الخاص به، لكن صفحة الشبكة لم تعرض أي واجهة فعلية لتهيئتها.

هذا التمييز أساسي. لم تكن المشكلة «عدم وجود برنامج تشغيل إيثرنت» بالمعنى البسيط، لأن واجهة إيثرنت واحدة على الأقل كانت مفعّلة وتنقل البيانات.

كان لدى الخادم أربعة منافذ شبكة فعلية

تضمنت الأجهزة المصدر:

  • واجهتا Intel I226-V بسرعة 2.5GbE؛
  • واجهتا Intel X710 SFP+؛
  • منصة AMD Ryzen 7 PRO 8845HS؛
  • عدة محركات NVMe، وكان يخطط لتخزين كبير على محركات HDD.

اتصل المستخدم في البداية عبر أحد منافذ 2.5GbE، وحصل على عنوان DHCP يبدأ تقريبًا بـ 192.168.1.125.

لم يكن حجز جهاز التوجيه هو السبب الجذري

سأل Zima-Giorgio المستخدم عن كيفية حصوله على العنوان. فأوضح المستخدم أن DHCP خصّصه له، ثم حجز جهاز التوجيه عنوان IP هذا.

أزال المستخدم الحجز لاحقًا كما طُلب منه. حصل ZimaOS على عنوان DHCP مختلف، مما أثبت أن الواجهة لا تزال قادرة على الاتصال بجهاز التوجيه، لكن صفحة الشبكة ظلت فارغة.

هذه النتيجة السلبية مهمة: لم تُحل مشكلة واجهة المستخدم بمجرد إزالة حجز العنوان الثابت في جهاز التوجيه.

التبديل بين منفذي I226-V لم يُصلح واجهة المستخدم

تساءل المستخدم عما إذا كان الاتصال بواجهة 2.5GbE الثانية بدلًا من الأولى يسبب إرباكًا لـ ZimaOS. فنقل الكابل إلى منفذ I226-V الآخر، وأعاد تشغيل الجهاز، وحصل هناك أيضًا على عنوان يعمل.

ظل قسم الإعدادات > الشبكة لا يعرض أي واجهة.

أكد ifconfig وجود واجهة إيثرنت فعّالة

أظهر المنشور اللاحق مخرجات eth0 مثل:

  • في حالة UP وRUNNING؛
  • عنوان IPv4 مُعيّن 192.168.1.123;
  • واستقبال الحزم وإرسالها؛
  • مع الإبلاغ عن عدم وجود أخطاء في حالة الاتصال.

وهذا دليل قوي على أن واجهة الشبكة في Linux كانت تعمل، بينما أخفقت طبقة إدارة ZimaOS في تعدادها بشكل صحيح.

انتقل النقاش بعد ذلك إلى تهيئة ETHS في ZimaOS

طرفية ZimaOS تعرض عدة أجهزة Ethernet من Intel عبر PCI وتهيئة الشبكة الداخلية أثناء استكشاف مشكلة اكتشاف الواجهات وإصلاحها
كشفت الآلة عن عدة وحدات تحكم في الشبكة من Intel، مما وجّه النقاش نحو كيفية اختيار ZimaOS للواجهات التي يعرضها في واجهة الإدارة.

الملف الداخلي zimaos.conf أظهر الملف ETHS = فارغة. ثم جرّبت ردود من المجتمع ومن جهات قريبة من الفريق إدخال عناوين PCI في ذلك الحقل وإعادة تشغيل خدمات ZimaOS.

لم تُعد تلك التعديلات صفحة الشبكة للمستخدم.

استهدفت إحدى محاولات ETHS الواجهات الخاطئة

لاحظ المستخدم أن عناوين PCI المقترحة أولًا كانت تشير إلى منافذ SFP+ بدلًا من واجهات 2.5GbE. ثم جرّب عناوين PCI الخاصة بـ I226-V بدلًا منها.

حتى بعد تصحيح الأجهزة المستهدفة وإعادة تشغيل الخدمات، ظلت صفحة الإعدادات لا تعرض الواجهات. وهذا سبب آخر لعدم اعتماد ETHS تعديلًا بوصفه حلًا مثبتًا.

كشف النقاش عن حدّ تاريخي لافتراضات الأجهزة

ذكر أحد الردود أن أعمال التوافق السابقة الخاصة بالشبكة والعرض استهدفت أساسًا أجهزة ZimaCube، وأن الأجهزة الأخرى قد تحتاج إلى معلومات PCI صريحة. ويساعد ذلك التعليق في تفسير سبب احتمال أن يختبر خادم صغير عام مزود بأربع بطاقات شبكة مسارًا لم تختبره الأجهزة الأبسط.

لا ينبغي قراءة ذلك على أنه متطلب حالي يفرض إعدادًا يدويًا على جميع أجهزة ZimaOS التابعة لجهات خارجية ETHS التهيئة.

أنتجت واجهة برمجة التطبيقات المحلية لواجهات الشبكة خطأً

بعد فشل تعديلات التهيئة، اختبر النقاش واجهة شبكة ZimaOS المحلية لبرمجة التطبيقات:

curl http://127.0.0.1/v2/zimaos/network/interfaces

حوّل الخطأ المُعاد التحقيق بعيدًا عن تهيئة عنوان IP الثابت ونحو الخدمة المسؤولة عن اكتشاف معلومات الأجهزة أو تسلسلها.

التشخيص العام النهائي أشار إلى تحليل lshw

أفاد رد لاحق بأن خطأ واجهة برمجة التطبيقات يشير إلى مشكلة في تحليل lshw المعلومات وطلب من المستخدم جمع قائمة كاملة بالأجهزة في /DATA/lshw.logثم أرسل المستخدم النتيجة بشكل خاص.

لأن النقاش العام يتوقف عند هذه النقطة، يجب ألا تخترع الصفحة نتيجة هندسية. والعبارة الأخيرة المدعومة هي أن الفريق اشتبه في تحليل معلومات الأجهزة ونقل التشخيص التفصيلي إلى الرسائل الخاصة.

كان طلب تعريف Intel X710 موضوعًا منفصلًا

كما أراد المستخدم دعم منفذي X710 SFP+، وكان يأمل في النهاية باستخدام تجميع الروابط. وقال Zima-Giorgio إن طلب دمج برنامج التشغيل سيُحال إلى المراجعة.

ينبغي عدم الخلط بين ذلك الطلب وواجهة I226-V العاملة التي كانت تحمل اتصال إدارة ZimaOS بالفعل.

لا تحاول حل مشكلة واجهة المستخدم المفقودة فورًا بفرض nmcli

فكّر المستخدم في تطبيق عنوان IP ثابت عبر nmcli لأن الواجهة كانت مفقودة. يمكن لذلك تهيئة شبكات Linux، لكنه لا يُصلح سبب فشل ZimaOS في تعداد الواجهة، كما توفر إصدارات ZimaOS اللاحقة عناصر تحكم مدعومة لعناوين IP الثابتة في الإعدادات.

في نظام حالي، استخدم سلوك الشبكة الحالي في ZimaOS بوصفه خط الأساس لما ينبغي أن يظهر في الإعدادات.

ينبغي أن يعرض ZimaOS الحالي منافذ Ethernet الفعلية

تنص إرشادات الشبكات الحالية على أن واجهات Ethernet الفعلية ينبغي أن تظهر مع اسم الواجهة وحالة الارتباط والسرعة المتفاوض عليها وعنوان IP المعيّن. إذا كان لدى Linux واجهة عاملة لكن صفحة الشبكة فارغة، فاجمع تشخيصات خدمة الإدارة بدلًا من الاستمرار في تغيير إعدادات جهاز التوجيه.

ما ينبغي جمعه لحالة مشابهة حاليًا

  • إصدار ZimaOS الدقيق؛
  • lspci -nn لجميع وحدات التحكم في الشبكة؛
  • مخرجات الواجهة والعنوان الحاليين؛
  • حالة الارتباط لكل منفذ فعلي؛
  • لقطة شاشة لصفحة الشبكة؛
  • نتائج واجهات برمجة التطبيقات أو السجلات ذات الصلة بشبكة ZimaOS عند طلب فريق الدعم؛
  • جردًا للأجهزة مثل lshw إذا بدت خدمة تعداد الواجهات متوقفة عن العمل.

ما الذي يثبته الموضوع فعليًا

كان الخادم قادرًا على الاتصال بالشبكة عبر واجهة Intel I226-V، بينما فشل قسم إعدادات ZimaOS في إظهارها. ولم تُصلح إزالة حجز جهاز التوجيه أو التبديل بين منافذ I226-V أو دورات إيقاف التشغيل والتشغيل أو التعديلات اليدوية ETHS لم تُصلح التعديلات العرض. وانتهى التحقيق إلى اشتباه في lshw مشكلة في التحليل مع متابعة خاصة.

الأسئلة الشائعة حول واجهة الشبكة المفقودة

هل كان الخادم غير متصل فعليًا؟

لا. كان لديه عنوان DHCP، وكانت واجهة Ethernet النشطة تنقل البيانات.

هل أدى إزالة حجز جهاز التوجيه إلى إصلاح صفحة الشبكة؟

لا. حصل الخادم على عنوان DHCP جديد، لكن ظلت عناصر التحكم الخاصة بالواجهة مفقودة.

هل أدى التبديل إلى منفذ I226-V الآخر إلى حل المشكلة؟

لا.

هل أدت التعديلات اليدوية على ETHS إلى حل المشكلة؟

لم يتم تأكيد أي حل علني نتيجةً لتلك التجارب.

ما آخر دليل تشخيصي علني؟

أدى خطأ في واجهة برمجة التطبيقات إلى توجيه النقاش نحو احتمال lshw مشكلة في تحليل المعلومات.