هذا الموضوع هو تتمة لموضوع: تتبع الفرع التطويري Factory لتوزيعة openSUSE.
تحديث يوم 7-سبتمبر-2011 على الفرع التطويري المسمى Factory لتوزيعة openSUSE حمل معه ترقية لـ 95 حزمة من بينها النواة Linux 3.1rc5, المشغل الأساسي للنظام Systemd و تحديثات لعدد من أهم مكونات النظام.
هذه التحديثات تسببت في توقف خادم العرض Xorg عن العمل و لم تنجح معه أية محاولة لتشغيله يدويا.
عند تفقد محتوى ملف مخراجات خادم العرض كالتالي $ tail -n 20 /var/log/Xorg.0.log
لمحت في آخره وجود رسالة Segementation fault؛ و هذا غالبا مؤشر على علة برمجية في خادم العرض إو إحدى المكونات التي تتفاعل معه.
بحثت سريعا على القائمة البريدية الخاصة بالفرع Factory و لم أجد أي شيء مفيذ هناك. إنتظرت يوم ونصف وصول تحديثات تصحيحة إلى المستودع لكن لا جديد.
مدير الحزم zypper يسجل كل العمليات التي يقوم بها على الملف /var/log/zypp/history لذلك بتنفيذ الأمر التالي يمكن عرض كل العمليات التي أجريت السابع من سبتمبر:
لتنظيف المخرجات أكثر يمكن تنفيذ ما يلي:
تحديد سبب المشكلة بشكل دقيق ليس في مقدوري بعد لإفتقاري إلى مهارات تحليل و تعقب عمل البرامح و المكتبات أثناء عملها. لذلك الحل سيكون إما بتخفيض إصدارات حزم خادم العرض التي أظنها هي مصدر الخلل أو الرجوع إلى الوراء قليلا إلى آخر نقطة كان فيها مستودع Factory قادرا على أن يوفر نظام يعمل.
في كلتا الحالتين يجب أن أستعين بمستودع Factory-Tested. هذا المستودع على الأقل يضمن أن النظام الذي سيرتقي إليه سيستطيع تثبيت الحزم و تشغيل خادم العرض Xorg ولو داخل آلة تخيلية. لذلك هذا المستودع هو الذي ينصح به لمن يريد اختبار الإصدارات التطويرية و في نفس الوقت من دون مشاكل أو إنهيارات حرجة للنظام.
الطريق إلى الحل
1. إضافة المستودع factory-tested مع تفعيل خاصية الإحتفاض بالحزم المحملة.
2. تحديد أولويته على القيمة 100 بمعنى انه أقل أولوية مقارنة مع القيمة القياسية 99 التي تحصل عليها كل المستودعات المضافة. هذا من شأنه أن يجعل النظام دائما يفضل حزم factory على factory-testing.
3. تحديث المستودعات
4. تخفيض فقط الحزم التي أظنها سبب الخلل
=> إعادة تشغيل النظام و محاولة تشغيل خادم العرض بطريقة تلقائية و يدوية لم تنفع. تغيرت المخرجات قليلا لكن لا جدوى.
5. الرجوع إلى factory-testing بالترقية المخفضة للإصدارات الحزم.
تم اخباري بأنه سيتم تخفيض 90 حزمة و طلب مني حل الإعتماديات لثلاثة حزم (virtualbox-guest-kmp-desktop , aisleriot , kernel-desktop) بطريقة يدوية. اخترت Keep Obsolete بمعنى أتركها مهجورة.
بعد إنتهاء عملية الترقية المٌخفضة بنجاح حاولت إعادة تشغيل النظام لكن لم تستطع لا reboot و shutdown -r now من إعادة تشغيل النظام أو إيقافه.
6. إعادة تشغيل النظام.
* طلب دفع كل ما يوجد من مخزون الذاكرة المؤقتة للقرص الصلب كي يتم تخزينه فعليا.
* إعادة وصل قسم جذر النظام / بخاصية القراءة فقط (ro) كي أستطيع قطع الكهرباء من دون التسبب في مشاكل إضافية لم تعمل معي.
* الطلب من النواة أن تدفع كل مخزون الذاكرة المؤقت للقرص إلى القرص فعليا ثم تعيد وصل الأقسام بخاصية القراءة فقط ثم أن تنهار و تعيد تشغيل الجهاز بشكل آمن باستخدام Magic SysRq key
=> بعد إعادة تشغيل النظام عاد كل شيء كما كان إلى حالته الطبيعية.
تحديث 10-09-2011:
بعد أن خصصت ساعات للبحث في سبب المشكلة و حلها وصلت إلى ما يلي:
* بتنفيذ الأمر who -r يتضح أن النظام يبقى في مستوى التشغيل الثالث runlevel 3 و شيء ما يمنعه من الإنتقال إلى الخاس.
* الملف /etc/inittab يحدد المستوى الخامس كمستوى إفتراضي. أداة Yast تؤكد نفس الشيء.
* مسجل الجلسات هو gdm على /etc/sysconfig/displaymanager. تغيرها بـ xdm لم ينفع.
* محولة طلب التأكد من إعدادات النظام و تحديثها لم تنفع بواسطة /sbin/SuSEconfig
* خدمة /etc/init.d/xdm يبدأ عملها عندما يدخل النظام في المستوى الخامس حسب أداة Yast و chkconfig. إعتماداياتها المباشرة هي acpid earlyxdm kbd حسب الملف /etc/init.d/.depend.start محاولة التعديل على قيمة TARGETS و xdm: لم ينفع. عند تفقد حالة الإعتماديات الثلاثة إتضح أن خدمة kbd و earlyxdm لا تستطيع العمل لكنها ليست ضرورية و بالتالي خدمة xdm تعمل من دونهما.
* خادم العرض Xorg يشير في مخرجاته أن وحدة xvnc و xgi و vmwgfx لا تعمل بشكل صحيح لكنها لا تعيق عمله.
* الواجهة الرسومية يمكن الوصول إليها سواءا بتشغيل /usr/bin/gdm أو /etc/init.d/xdm أو بواسطة startx و xinit بعد إعداد خادم العرض و تعطيل الوحدات المسبوقة الذكر، أو بالإنتقال إلى المستوى الخامس يدويا /sbin/telinit 5
* مقارنة مجلد إعدادات النظام /etc/ قبل و بعد الترقية لم يعرض أي خلل أو شيء مشكوك فيه.
=> الحل الوحيد هو إخبار النواة بالإنتقال إلى المستوى الخامس بتمرير رقم 5 إلى سطر الإقلاع.
وصلات:
تحديث يوم 7-سبتمبر-2011 على الفرع التطويري المسمى Factory لتوزيعة openSUSE حمل معه ترقية لـ 95 حزمة من بينها النواة Linux 3.1rc5, المشغل الأساسي للنظام Systemd و تحديثات لعدد من أهم مكونات النظام.
هذه التحديثات تسببت في توقف خادم العرض Xorg عن العمل و لم تنجح معه أية محاولة لتشغيله يدويا.
عند تفقد محتوى ملف مخراجات خادم العرض كالتالي $ tail -n 20 /var/log/Xorg.0.log
لمحت في آخره وجود رسالة Segementation fault؛ و هذا غالبا مؤشر على علة برمجية في خادم العرض إو إحدى المكونات التي تتفاعل معه.
بحثت سريعا على القائمة البريدية الخاصة بالفرع Factory و لم أجد أي شيء مفيذ هناك. إنتظرت يوم ونصف وصول تحديثات تصحيحة إلى المستودع لكن لا جديد.
مدير الحزم zypper يسجل كل العمليات التي يقوم بها على الملف /var/log/zypp/history لذلك بتنفيذ الأمر التالي يمكن عرض كل العمليات التي أجريت السابع من سبتمبر:
$ grep '2011-09-07' /var/log/zypp/history
لتنظيف المخرجات أكثر يمكن تنفيذ ما يلي:
$ grep '2011-09-07' /var/log/zypp/history | grep -v '#' | cut -d '|' -f3-4 | tr -t '|' ' '
تحديد سبب المشكلة بشكل دقيق ليس في مقدوري بعد لإفتقاري إلى مهارات تحليل و تعقب عمل البرامح و المكتبات أثناء عملها. لذلك الحل سيكون إما بتخفيض إصدارات حزم خادم العرض التي أظنها هي مصدر الخلل أو الرجوع إلى الوراء قليلا إلى آخر نقطة كان فيها مستودع Factory قادرا على أن يوفر نظام يعمل.
في كلتا الحالتين يجب أن أستعين بمستودع Factory-Tested. هذا المستودع على الأقل يضمن أن النظام الذي سيرتقي إليه سيستطيع تثبيت الحزم و تشغيل خادم العرض Xorg ولو داخل آلة تخيلية. لذلك هذا المستودع هو الذي ينصح به لمن يريد اختبار الإصدارات التطويرية و في نفس الوقت من دون مشاكل أو إنهيارات حرجة للنظام.
الطريق إلى الحل
1. إضافة المستودع factory-tested مع تفعيل خاصية الإحتفاض بالحزم المحملة.
$ sudo zypper ar -f -k http://download.opensuse.org/factory-tested/repo/oss/ factory-tested
2. تحديد أولويته على القيمة 100 بمعنى انه أقل أولوية مقارنة مع القيمة القياسية 99 التي تحصل عليها كل المستودعات المضافة. هذا من شأنه أن يجعل النظام دائما يفضل حزم factory على factory-testing.
$ sudo zypper mr -p 100 factory-tested
3. تحديث المستودعات
$ sudo zypper ref
4. تخفيض فقط الحزم التي أظنها سبب الخلل
$ sudo zypper in -f -r factory-tested xorg-x11 xorg-x11-driver-input xorg-x11-driver-video x11-tools xorg-x11-server xorg-x11-xauth
=> إعادة تشغيل النظام و محاولة تشغيل خادم العرض بطريقة تلقائية و يدوية لم تنفع. تغيرت المخرجات قليلا لكن لا جدوى.
$ sudo /sbin/reboot $ startx
5. الرجوع إلى factory-testing بالترقية المخفضة للإصدارات الحزم.
$ sudo zypper dup --from factory-tested
تم اخباري بأنه سيتم تخفيض 90 حزمة و طلب مني حل الإعتماديات لثلاثة حزم (virtualbox-guest-kmp-desktop , aisleriot , kernel-desktop) بطريقة يدوية. اخترت Keep Obsolete بمعنى أتركها مهجورة.
بعد إنتهاء عملية الترقية المٌخفضة بنجاح حاولت إعادة تشغيل النظام لكن لم تستطع لا reboot و shutdown -r now من إعادة تشغيل النظام أو إيقافه.
6. إعادة تشغيل النظام.
* طلب دفع كل ما يوجد من مخزون الذاكرة المؤقتة للقرص الصلب كي يتم تخزينه فعليا.
$ sync
* إعادة وصل قسم جذر النظام / بخاصية القراءة فقط (ro) كي أستطيع قطع الكهرباء من دون التسبب في مشاكل إضافية لم تعمل معي.
$ sudo mount -o remount,ro /dev/mapper/system-root
* الطلب من النواة أن تدفع كل مخزون الذاكرة المؤقت للقرص إلى القرص فعليا ثم تعيد وصل الأقسام بخاصية القراءة فقط ثم أن تنهار و تعيد تشغيل الجهاز بشكل آمن باستخدام Magic SysRq key
$ sudo -s # echo 1 > /proc/sys/kernel/sysrq # echo s > /proc/sysrq-trigger # echo u > /proc/sysrq-trigger # echo b > /proc/sysrq-trigger
=> بعد إعادة تشغيل النظام عاد كل شيء كما كان إلى حالته الطبيعية.
تحديث 10-09-2011:
بعد أن خصصت ساعات للبحث في سبب المشكلة و حلها وصلت إلى ما يلي:
* بتنفيذ الأمر who -r يتضح أن النظام يبقى في مستوى التشغيل الثالث runlevel 3 و شيء ما يمنعه من الإنتقال إلى الخاس.
* الملف /etc/inittab يحدد المستوى الخامس كمستوى إفتراضي. أداة Yast تؤكد نفس الشيء.
* مسجل الجلسات هو gdm على /etc/sysconfig/displaymanager. تغيرها بـ xdm لم ينفع.
* محولة طلب التأكد من إعدادات النظام و تحديثها لم تنفع بواسطة /sbin/SuSEconfig
* خدمة /etc/init.d/xdm يبدأ عملها عندما يدخل النظام في المستوى الخامس حسب أداة Yast و chkconfig. إعتماداياتها المباشرة هي acpid earlyxdm kbd حسب الملف /etc/init.d/.depend.start محاولة التعديل على قيمة TARGETS و xdm: لم ينفع. عند تفقد حالة الإعتماديات الثلاثة إتضح أن خدمة kbd و earlyxdm لا تستطيع العمل لكنها ليست ضرورية و بالتالي خدمة xdm تعمل من دونهما.
* خادم العرض Xorg يشير في مخرجاته أن وحدة xvnc و xgi و vmwgfx لا تعمل بشكل صحيح لكنها لا تعيق عمله.
* الواجهة الرسومية يمكن الوصول إليها سواءا بتشغيل /usr/bin/gdm أو /etc/init.d/xdm أو بواسطة startx و xinit بعد إعداد خادم العرض و تعطيل الوحدات المسبوقة الذكر، أو بالإنتقال إلى المستوى الخامس يدويا /sbin/telinit 5
* مقارنة مجلد إعدادات النظام /etc/ قبل و بعد الترقية لم يعرض أي خلل أو شيء مشكوك فيه.
=> الحل الوحيد هو إخبار النواة بالإنتقال إلى المستوى الخامس بتمرير رقم 5 إلى سطر الإقلاع.
وصلات:
* Thread: how to start xserver automatically * Thread: Help With Default Runlevel * Thread: OpenSuSE 11.4 fails to boot properly
ليست هناك تعليقات:
إرسال تعليق