Rpi-imager: الخيارات المتقدمة لا تعمل على نظام التشغيل windows 10

تم إنشاؤها على ١٩ مارس ٢٠٢١  ·  32تعليقات  ·  مصدر: raspberrypi/rpi-imager

كنت أرغب في استخدام الخيارات المتقدمة وتمكين ssh افتراضيًا. ولكن بعد كتابة sd-card ssh لم يتم تمكينه .. لذلك جربت خيارات أخرى ولم تنجح أيضًا.

أنا أستخدم نسخة تصوير v1.6 على جهاز كمبيوتر يعمل بنظام Windows 10.

التعليق الأكثر فائدة

هل يمكنك المحاولة إذا كان هذا يعمل بشكل أفضل؟

حاولت ذلك وهي تعمل كما هو متوقع. تم إنشاء "firstrun.sh" قسم FAT الخاص بي مع كافة التكوينات المحددة. العمل الجيد @ maxnet ، شكرا لك!

ال 32 كومينتر

ما الصورة التي كنت تكتبها؟

وهل قمت بالفعل بالتحقق من Pi أن عملية sshd لا تعمل؟
(مجرد عدم القدرة على الاتصال يمكن أن يكون له أسباب أخرى).

إذا بدلاً من وضع بطاقة SD في Pi ، قمت بوضعها مرة أخرى في جهاز الكمبيوتر الخاص بك فور الكتابة ، فهل قمت بإنشاء ملف يسمى firstrun.sh على قسم FAT؟

وإذا لم يكن الأمر كذلك ، فهل هناك أي اختلاف بناءً على ما إذا قمت بتحديد المربع "إخراج الوسائط عند الانتهاء"؟

شكرا على الرد!

الصورة هي الأصل Rasberry Pi OS (32-BIT) تاريخ الإصدار 2021-01-11
راجعت على Pi نفسها لـ ssh. ولكن ليست وظيفة تمكين ssh فقط التي لا تعمل. لا شيء يعمل في قائمة الخيارات. جربت الخيارات الأخرى أيضًا. حاولت أيضًا استخدام بطاقات SD مختلفة للتأكد ؛)

لقد قمت للتو بفحص واستخدام بطاقة sd أخرى ، وفعلت كل شيء تمامًا كما كان من قبل ولم يتم إنشاء ملف يسمى firstrun.sh.
كان إخراج مربع الوسائط غير مرتبك.

نعم. أنا أنظر في هذه المشكلة إلى أبعد من ذلك ، ويبدو أن جهاز التصوير لديه مشكلة مع بطاقات sd كبيرة ومحركات أقراص USB.

لقد جربت بطاقة sd بسعة 16 جيجا بايت وبواسطة تصوير البطاقة أنتجت الملف firstrun.sh المطلوب. كانت بطاقات sd الأولى التي كنت أستخدمها 32 و 128 جيجا بايت. بعد ذلك جربت محرك أقراص USB خارجيًا بسعة 250 جيجا بايت ولكن لم تنجح. لا يوجد ملف firstrun.sh.
لذا فإن المشكلة تكمن في حجم بطاقة sd ربما؟

كان إخراج مربع الوسائط غير مرتبك

التحقق من ذلك لا يحدث فرقا؟

هل يحتفظ محرك الأقراص الخاص بك بنفس حرف محرك الأقراص قبل التصوير وبعده؟

إخراج مربع وسائط الاختيار أو إلغاء التحديد لا يحدث أي فرق حرف محرك الأقراص الخاص بي يبقى كما هو.

في الوقت الحالي ، ليست مشكلة كبيرة لأنني لا أكتب نظام التشغيل على بطاقات sd بشكل يومي. ولكن مهلاً ، فإن تعيين هذه الخيارات يجعل إجراءات تثبيت نظام التشغيل أكثر سهولة بالنسبة لي لأن تشغيل ssh افتراضيًا يعني أنه يمكنك تثبيت نظام التشغيل دون الحاجة إلى توصيل شاشة بـ RPI. يمكنك إعداد RPI بالكامل عن طريق الاتصال عن بعد عبر ssh

كانت بطاقات sd الأولى التي كنت أستخدمها 32 و 128 جيجا بايت. بعد ذلك جربت محرك أقراص USB خارجيًا بسعة 250 جيجا بايت ولكن لم تنجح. لا يوجد ملف firstrun.sh.
لذا فإن المشكلة تكمن في حجم بطاقة sd ربما؟

تم اختباره على بطاقة Samsung SD بسعة 64 جيجابايت و 32 جيجابايت من Toshiba ، لذا لا ينبغي أن يكون الحجم نفسه مشكلة.

قد تكون محركات أقراص USB الأحدث مشكلة إذا كانت تتحدث بروتوكول UASP بدلاً من بروتوكول تخزين USB كبير السعة.
لديّ Samsung T7 SSD ، لا يتعامل معه Windows على أنه وحدة تخزين قابلة للإزالة ولكن كمحرك داخلي ، وبالتالي لا يقوم بتعيين حرف محرك أقراص إليه تلقائيًا بعد التصوير. بدلاً من ذلك ، يتعين عليك الانتقال إلى إدارة قرص Windows وتعيين حرف محرك أقراص يدويًا حتى تتمكن من رؤية الملفات الموجودة على قسم FAT على الإطلاق.
عند استخدام محرك الأقراص هذا ، من الواضح أنه لا يمكن لـ Imager إصلاح الملفات تلقائيًا ، لكنه يعرض رسالة خطأ واضحة في هذه الحالة:

Capture

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

لدي مشاكل مماثلة. يظهر لي الخطأ "غير قادر على كتابة firstrun.sh". سأقوم بتضمين لقطة شاشة ولكن++ X يتعارض مع Snagit 2021 لذلك اضطررت إلى تعطيله. ؛)

حدث الخطأ مع بطاقة SD بسعة 32 غيغابايت ولكن ليس مع بطاقة ذاكرة USB بسعة 16 غيغابايت.

لدي مشاكل مماثلة. يظهر لي الخطأ "غير قادر على كتابة firstrun.sh".

هذا يعني أن Windows قد أشار إلى أن قسم FAT قد تم تعيين حرف محرك أقراص له (وإلا ستحصل على "لم يقم نظام التشغيل بتحميل قسم FAT32" بدلاً من ذلك) ، ولكن فتح الملف للكتابة لا يزال فشلًا.
ربما يكون هناك تأخير في تعيين Windows لحرف محرك أقراص ، وعندما ينتهي نظام الملفات من التثبيت.
إذا كان الأمر كذلك ، فقد نحتاج إلى إعادة المحاولة عدة مرات.

بعد تلقي الخطأ ، هل يمكنني رؤية الملفات الموجودة على قسم FAT في المستكشف دون الحاجة إلى إعادة شحن البطاقة أو القيام بأي شيء خاص؟

أستطيع أن أرى قسم FAT32 ولكن بالطبع لا يوجد ملف firstrun.sh. على جهازي هو E: لدي قسمان على محرك الأقراص الثابتة (لا تسأل). ولكنه أيضًا E: لعصا USB.

أستطيع أن أرى قسم FAT32 ولكن بالطبع لا يوجد ملف firstrun.sh.

نعم.
هل يمكنك المحاولة إذا كان هذا يعمل بشكل أفضل؟

تصوير - 1.7beta.zip

الانتظار حتى 3 ثوانٍ للتحقق مما إذا كان config.txt موجودًا على حرف محرك الأقراص قبل متابعة كتابة التغييرات.

يعمل كما هو متوقع. تم اختباره باستخدام بطاقة SD بسعة 32 جيجابايت من الإنشاء حتى دورة التمهيد على Pi 4.

شكرا.

يعمل كما هو متوقع.

من الجيد أن تسمع.

@ TeeSee64 هل يمكنك أيضًا تجربة الإصدار التجريبي؟
(لا توجد فكرة عما إذا كان يفعل أي شيء لمشكلتك ، لأن لديك أعراضًا مختلفة).

تضمين التغريدة
نعم! أستطيع أن أؤكد أن المشكلة قد تم حلها باستخدام الإصدار 1.7 بيتا. يقوم الآن بكتابة ملف firstrun.sh وجميع الخيارات تعمل. يعمل مع كل من بطاقة sd 128 جيجا بايت ومحرك أقراص USB سعة 250 جيجا بايت

شكرا لك !!

مرحبًا @ maxnet ، لدي نفس المشكلة مثلCharlesGodwin. جربت أيضًا 1.7 بيتا ، لكن للأسف لا تعمل معي. تم تغيير رسالة الخطأ فقط بسبب تغييراتك. يعرض الآن "تعذر التخصيص. الملف 'I: \ / config.txt' غير موجود.".
قد تكون المشكلة أن قسم FAT32 مثبت على "J: \" بدلاً من "I: \".
أنا آسف ولكني حاليًا غير قادر على إجراء أي تحليل إضافي حول سبب تثبيته على "J: \" أو لماذا يعتقد المصور أنه مثبت على "I: \" ، ولكن على الأقل أردت مشاركة هذا معك .

قد تكون المشكلة أن قسم FAT32 مثبت على "J: \" بدلاً من "I: \".

حسنًا ، أعتقد أن لدينا تقارير حول عدم إصدار أحرف محركات الأقراص ، وتم تعيين حرف محرك أقراص جديد لمحرك الأقراص من قبل.
مثل: https://github.com/raspberrypi/rpi-imager/issues/31
لم ينجح أبدًا في إعادة إنتاج أي من هذه المشكلات بالرغم من ذلك. لذلك لا فكرة عن سبب ذلك.
ربما هناك شيء ما يحمل قفلًا على محرك الأقراص (بعض خدمات النظام أو ماسح الفيروسات؟)

أم أن البطاقة لم تكن متوفرة لدي مطلقًا: من قبل؟
ما هو حرف محرك الأقراص الذي تم عرضه عند تحديد محرك الأقراص في Imager؟

يفترض المصور أن أول وحدة تخزين يخبرنا Windows أنها مرتبطة بمحرك الأقراص هي قسم FAT الذي نبحث عنه.
لست متأكدًا مما إذا كانت هناك آلية أفضل ، مثل البحث في جميع وحدات التخزين المرتبطة بمحرك الأقراص عن config.txt بدلاً من ذلك.

إذا بدأت "diskpart" من موجه الأوامر ، وكتبت "list volumes" ، فهل يُظهر I: و J: هناك؟
يمكنك أيضًا محاولة تحديدها باستخدام "تحديد حجم [عدد وحدة التخزين]" ، ومعرفة ما إذا كان "حجم التفاصيل" (و "قسم التفاصيل" "قرص التفاصيل") يطبع أي شيء خارج عن المألوف.

ربما هناك شيء ما يحمل قفلًا على محرك الأقراص (بعض خدمات النظام أو ماسح الفيروسات؟)

لا أعتقد ذلك.

ما هو حرف محرك الأقراص الذي تم عرضه عند تحديد محرك الأقراص في Imager؟

تعرض البطاقة ، التي تم تصويرها بالفعل ، "Mounted as I: \، J: \" (مترجم ، باستخدام النسخة الألمانية).
جربته أيضًا ببطاقة غير مستخدمة. يعرض "Mounted as J: \" (I: \ مفقود كومبليتي ، أيضًا في المستكشف. لا تسألني لماذا ...)

إذا بدأت "diskpart" من موجه الأوامر ، وكتبت "list volumes" ، فهل يُظهر I: و J: هناك؟

لا ، يظهر فقط J: \ هناك. ولكن في المستكشف يظهر كلاهما ، I: \ و J: \.

يفترض المصور أن أول وحدة تخزين يخبرنا Windows أنها مرتبطة بمحرك الأقراص هي قسم FAT الذي نبحث عنه.

ويبدو أن المشكلة.

maxnet مجرد فكرة ...
ربما مفهرس بحث windows؟ في بعض الأحيان عندما أحاول إزالة بطاقة SD بأمان من جهاز الكمبيوتر الخاص بي ، يكون ذلك مستحيلًا لأن مفهرس بحث windwos مشغول على تلك البطاقة. بعد لحظات قليلة ، أصبح المفهرس جاهزًا ويمكن الإزالة الآمنة.

ربما مفهرس بحث windows؟

نقوم بالاستعانة بمصادر خارجية لمسح جدول الأقسام في بداية Imaging إلى الأداة المساعدة diskpart من Microsoft ، على أمل أن تعرف كيفية جعل كل خدمة من خدمات Microsoft تتوقف عن استخدام محرك الأقراص ، وتحرير جميع الأقفال / أحرف محركات الأقراص بشكل صحيح.
بخلاف خدمات النظام ، هناك أيضًا برامج تابعة لجهات خارجية ترغب في المطالبة بفتح ملف والاحتفاظ به داخل "معلومات وحدة تخزين النظام" على كل محرك أقراص.
على سبيل المثال ، أتذكر من المعروف أن Symantec Endpoint Security يحافظ على إمساك الدفاتر حول الملفات التي تم مسحها ضوئيًا بالفعل وتوقيعات تلك الملفات هناك.
لهذا السبب ذكرت برامج فحص الفيروسات.

تضمين التغريدة

هل يمكنك المحاولة إذا كان هذا يعمل بشكل أفضل؟

تصوير - 20210322.zip

يجب البحث في جميع نقاط التحميل المرتبطة بمحرك الأقراص عن config.txt بدلاً من البحث الأول فقط.

@ maxnet حتى لو تغير حرف محرك الأقراص المثبت تلقائيًا قبل وبعد كتابة الصورة ، أفترض أن رقم القرص الفعلي لن يتغير؟ لذا ربما يمكنك استخدام بعض عناصر WMI لربط أحرف محركات الأقراص قبل وبعد وميض الصورة؟ : shrug: بدلاً من ذلك ، أعتقد أنه يمكنك استخدام حجم محرك الأقراص الأولي ، لأنه من غير المحتمل أن يكون لدى المستخدم محركان بنفس الحجم الأولي متصلين؟ (وهذا أيضًا لن يتغير قبل / بعد الوميض)

@ maxnet حتى لو تغير حرف محرك الأقراص المثبت تلقائيًا قبل وبعد كتابة الصورة ، أفترض رقم القرص الفعلي
لن يتغير؟ لذا ربما يمكنك استخدام بعض عناصر WMI لربط أحرف محركات الأقراص قبل وبعد وميض الصورة؟

لقد قمنا بالفعل بإحضار قائمة الأحجام التي تنتمي إلى رقم محرك الأقراص الفعلي هذا بعد التصوير.

ومع ذلك ، في حالة CRGer ، يتم إرجاع مجلدين (I: و J :) على أنهما ينتميان إلى محرك الأقراص الفعلي .
افترضنا سابقًا أن أول واحد هو قسم FAT ، ولكن في حالته ، يكون الرمز الثاني هو المجلد الصالح الوحيد.
يجب أن يقوم الرمز الجديد بفحص كلا المجلدين اللذين تم إرجاعهما من أجل config.txt

قد ينتهي الأمر بلعبة الصديق الخلد. ربما رمز في مربع حوار "ما هو محرك الأقراص ، من فضلك" عندما يفشل كل شيء آخر.

آه ، لقد أسأت الفهم ، أعتذر عن الضوضاء! :غمزة:

هل يمكنك المحاولة إذا كان هذا يعمل بشكل أفضل؟

حاولت ذلك وهي تعمل كما هو متوقع. تم إنشاء "firstrun.sh" قسم FAT الخاص بي مع كافة التكوينات المحددة. العمل الجيد @ maxnet ، شكرا لك!

أرى هذه المشكلة على ubuntu تحاول كتابة Raspberry PI OS Lite ، يبدو أنها لا تنتظر وقتًا طويلاً حتى يتم تحميل قسم التمهيد ، قبل محاولة كتابة firstrun.sh إلى القسم. هل هناك بناء مع تأخير أطول لأوبونتو؟

أيضًا بدلاً من الانتظار لمدة 3 ثوانٍ تعسفيًا ، ماذا عن مجرد اختبار ما إذا كان يمكنك الوصول إلى القسم في حلقة لمدة 60 ثانية قبل الخطأ أو شيء من هذا القبيل؟

أرى هذه المشكلة على ubuntu تحاول كتابة Raspberry PI OS Lite ، يبدو أنها لا تنتظر وقتًا كافيًا للتمهيد
قسم ليتم تحميله ، قبل محاولة كتابة firstrun.sh إلى القسم. هل هناك بناء مع تأخير أطول لأوبونتو؟

هل هذا واحد يعمل بشكل أفضل؟

rpi-imager-ubuntu-20210324.zip

أيضًا بدلاً من الانتظار لمدة 3 ثوانٍ بشكل تعسفي ، ماذا عن مجرد اختبار ما إذا كان يمكنك الوصول إلى القسم في حلقة على سبيل المثال 60
ثوان قبل الخطأ أو شيء من هذا القبيل؟

كمرجع: يستغرق الأمر 0.008 ثانية قبل تثبيت قسم FAT على كمبيوتر Ubuntu الخاص بي.

أرى هذه المشكلة على ubuntu تحاول كتابة Raspberry PI OS Lite ، يبدو أنها لا تنتظر وقتًا كافيًا للتمهيد
قسم ليتم تحميله ، قبل محاولة كتابة firstrun.sh إلى القسم. هل هناك بناء مع تأخير أطول لأوبونتو؟

راجع للشغل هل استخدمت .deb من موقع Raspberry Pi الإلكتروني سابقًا ، أم الأداة التي قدمتها canonical؟

نظرًا لأن شخصًا آخر يذكر أن المشكلة تحدث فقط في الخاطف: https://www.raspberrypi.org/forums/viewtopic.php؟f=63&p=1842486

لماذا تتم مناقشة Ubuntu rpi-imager في قضية بعنوان الخيارات المتقدمة لا تعمل على Windows 10

لن يجدها أحد

لماذا تتم مناقشة Ubuntu rpi-imager في قضية بعنوان الخيارات المتقدمة لا تعمل على Windows 10

هذه مشكلة في العنوان أكثر من كونها مشاكل مختلفة.

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

يجب ألا يحدث هذا في أنظمة Linux العادية.
ولكن قد يحدث ذلك في حزمة snap التابعة لجهة خارجية والتي لم نقم بإنشائها.
حسنًا ، كأثر جانبي للتغلب على هذه المشكلة على Windows ، قد يحل مشكلة المفاجئة أيضًا ...

أعتقد أن المشكلة _ يمكن إعادة تسميتها إلى "الخيارات المتقدمة لا تكتب الإعدادات على بطاقة SD" ، ولكن لا يبدو أنها تستحق العناء إذا كان لدىmaxnet بالفعل إصلاح محتمل في متناول اليد؟ : قليلا_ابتسامة_الوجه:

أعتقد أنه يمكن إعادة تسمية المشكلة إلى "الخيارات المتقدمة وليس كتابة الإعدادات على بطاقة SD" ، ولكن لا يبدو الأمر يستحق العناء إذا كانmaxnet
لديه بالفعل إصلاح محتمل في متناول اليد؟

أظن أن المشكلة قد تم إصلاحها بالفعل.
لكن ترك هذا مفتوحًا في الوقت الحالي ، لمنع الآخرين الذين يستخدمون الإصدار 1.6 (بدلاً من git الأحدث) من فتح إصدار جديد.

ثابت في 1.6.1

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات