แก้ไขปัญหา Collabora CODE Container ไม่สามารถเริ่มต้นทำงานบนสถาปัตยกรรม ARM64 ได้

หากคอนเทนเนอร์ Collabora Online Development Edition (CODE) ปิดตัวลงทันทีบนเครื่อง ARM64 ให้เริ่มต้นด้วยการตรวจสอบความเข้ากันได้ของสถาปัตยกรรมก่อนที่จะเปลี่ยนแปลงการตั้งค่าเครือข่าย ใบรับรอง หรือการตั้งค่า WOPI ณ วันที่ 7 ตุลาคม 2026 collabora/codeที่เก็บข้อมูลอย่างเป็นทางการได้แสดงรายการเวอร์ชันดั้งเดิมlinux/arm64สำหรับรุ่นปัจจุบัน รวมถึงlatestแท็กและเวอร์ชันปัจจุบัน 26.04.4.2.1 นั่นหมายความว่าโฮสต์ ARM64 ที่ทันสมัยโดยทั่วไปไม่จำเป็นต้องใช้การจำลอง x86 เพียงเพื่อเรียกใช้ CODE ขั้นตอนการทำงานที่เป็นประโยชน์ที่สุดสำหรับผู้เริ่มต้นคือการยืนยันสถาปัตยกรรมของโฮสต์ ตรวจสอบแท็กรูปภาพที่แน่นอน ลบการตั้งค่า AMD64 ที่บังคับใช้ ดึงรูปภาพที่รองรับ ARM64 จากนั้นจึงค่อยแก้ไขปัญหาการกำหนดค่าระดับแอปพลิเคชัน

คู่มือนี้เน้นที่ปัญหาการเริ่มต้นระบบโดยเฉพาะ ไม่ได้สมมติว่าทุกปัญหาของ ARM64 มีสาเหตุเดียวกัน หากคอนเทนเนอร์เริ่มต้นได้สำเร็จ แต่ Nextcloud, ownCloud หรือโฮสต์ WOPI อื่นๆ ไม่สามารถเชื่อมต่อได้ นั่นเป็นอีกระดับของการแก้ไขปัญหา

สิ่งที่คุณควรรู้ก่อนทำการเปลี่ยนแปลงใดๆ

ARM64คือสถาปัตยกรรมซีพียู ARM 64 บิต โดยทั่วไป Linux จะรายงานว่าเป็น ARM64 ในaarch64ขณะที่ Docker มักจะติดป้ายกำกับเป้าหมายเดียวกันเป็นAMD64หรือที่เรียกว่า x86-64 เป็นสถาปัตยกรรมซีพียูที่แตกต่างออกไป อิมเมจคอนเทนเนอร์ประกอบด้วยไบนารีที่สร้างขึ้นสำหรับสถาปัตยกรรมหนึ่งหรือมากกว่านั้น Docker จะสามารถเลือกตัวเลือกที่ถูกต้องโดยอัตโนมัติได้ก็ต่อเมื่อแท็กของอิมเมจมีรายการ (manifest) ที่เข้ากันได้เท่านั้นlinux/arm64

อิมเมจแบบหลายแพลตฟอร์มคือแท็กอิมเมจเดียวที่มีไฟล์กำหนดค่าในรีจิสทรีชี้ไปยังการสร้างอิมเมจแยกต่างหากสำหรับสถาปัตยกรรมต่างๆ เช่น AMD64 และ ARM64 เอกสารของ Docker ระบุว่า เมื่อดึงอิมเมจแบบหลายแพลตฟอร์ม ระบบจะเลือกตัวเลือกที่เหมาะสมสำหรับโฮสต์โดยอัตโนมัติ ดูเอกสารเกี่ยวกับอิมเมจแบบหลายแพลตฟอร์ม ของ Docker สำหรับพฤติกรรมพื้นฐานเพิ่มเติม

สำหรับ Collabora CODE โดยเฉพาะ โปรดตรวจสอบรายการแท็ก collabora/code อย่างเป็นทางการบน Docker Hubแทนที่จะอ้างอิงจากบทช่วยสอนเก่าๆ บทความนี้ได้รับการตรวจสอบเมื่อวันที่ 7 ตุลาคม 2026 latestและ26.04.4.2.1มี แท็ก linux/arm64เฉพาะlatest-arm64ระบุไว้ด้วย เวอร์ชันเก่าๆ ที่ถูกปักหมุดไว้อาจแตกต่างกัน ดังนั้นแท็กที่คุณใช้งานจริงจึงมีความสำคัญมากกว่าคำกล่าวอ้างทั่วไปที่ว่า “Collabora รองรับ ARM”

เตรียมพร้อมสำหรับการแก้ไขปัญหาอย่างปลอดภัย

• เก็บสำเนาคำสั่งปัจจุบันdocker-compose.ymlหรือคำสั่งการใช้งาน ของคุณไว้ด้วย
• โปรดจดบันทึกแท็กรูปภาพ Collabora ที่คุณใช้ไว้ให้ถูกต้อง
• อย่าลบข้อมูลแอปพลิเคชันหรือการกำหนดค่ารีเวิร์สพร็อกซีเพียงเพื่อวินิจฉัยความไม่เข้ากันของสถาปัตยกรรม
• หากเป็นการใช้งานจริง ควรทดสอบแท็กทดแทนในระหว่างช่วงเวลาการบำรุงรักษาหรือบนโฮสต์ทดสอบก่อน

ผลลัพธ์ที่ต้องการนั้นง่ายมาก: Docker ควรดึงอิมเมจ ARM64 มาใช้ คอนเทนเนอร์ควรทำงานต่อไปแทนที่จะหยุดทำงานทันที และบันทึกการทำงานควรแสดงความคืบหน้าไปสู่การเริ่มต้น Collabora ตามปกติ แทนที่จะล้มเหลวด้วยข้อผิดพลาดเกี่ยวกับสถาปัตยกรรม

ขั้นตอนที่ 1: ยืนยันโฮสต์และสถาปัตยกรรม Docker

เรียกใช้การตรวจสอบเหล่านี้บนเครื่องที่ใช้งานคอนเทนเนอร์ Collabora จริง:

uname -m
docker info --format '{{.Architecture}}'
docker version

บนโฮสต์ Linux ARM 64 บิตดั้งเดิมuname -mโดยทั่วไปจะส่งคืนค่าaarch64ในขณะที่ Docker ควรรายงานarm64ค่า ชื่อเหล่านี้หมายถึงตระกูลสถาปัตยกรรมเดียวกันในบริบทนี้

หาก Docker รายงานว่าเป็น AMD64 ทั้งๆ ที่เครื่องจริงเป็น ARM64 ให้ตรวจสอบว่าคุณกำลังใช้ Docker context ระยะไกล เครื่องเสมือน หรือ Docker Desktop ที่มี backend ต่างกันหรือไม่ แก้ไขความกำกวมนั้นก่อนดำเนินการต่อ มิเช่นนั้น คุณอาจตรวจสอบระบบหนึ่งในขณะที่กำลังปรับใช้กับอีกระบบหนึ่ง

ข้อผิดพลาดใดที่บ่งชี้ถึงความไม่สอดคล้องกันของสถาปัตยกรรม?

สัญญาณทั่วไปได้แก่exec format errorข้อความแจ้งเตือนจากรีจิสทรีที่ระบุว่ามีปัญหาno matching manifest for linux/arm64หรือบริการ Compose ที่กำหนดค่าไว้อย่างชัดเจนด้วยplatform: linux/amd64ข้อความเหล่านี้เป็นหลักฐานที่ชัดเจนกว่าข้อความทั่วไปว่าแพลตฟอร์มไม่ตรงกัน

ขั้นตอนที่ 2: ตรวจสอบแท็กรูปภาพของ Collabora อย่างละเอียดก่อนดึงรูปภาพ

อย่าคิดว่าแท็กเก่าทุกแท็กจะรองรับแพลตฟอร์มเดียวกันกับแท็กในปัจจุบันlatestตรวจสอบเมตาเดต้าของรีจิสทรีสำหรับแท็กในระบบที่คุณใช้งาน:

docker buildx imagetools inspect collabora/code:latest

เอกสารประกอบการใช้งานคำสั่ง `buildx imagetools inspect`ของ Docker อธิบายวิธีการใช้คำสั่งนี้เพื่อแสดงแพลตฟอร์มที่มีอยู่ในอิมเมจรีจิสทรี คุณยังสามารถใช้ คำสั่งนี้ได้เช่นกัน โดย Docker ได้ อธิบายคำสั่งนี้ไว้ใน เอกสารอ้างอิงการตรวจสอบ manifestdocker manifest inspectของมัน

หากlinux/arm64ปรากฏขึ้น คุณสามารถใช้แท็กแบบหลายแพลตฟอร์มและปล่อยให้ Docker เลือกอิมเมจที่ถูกต้องได้ สำหรับการทดสอบแก้ไขปัญหาโดยเฉพาะ คลังเก็บข้อมูลอย่างเป็นทางการยังแสดงรายการไว้ด้วยlatest-arm64สำหรับการใช้งานจริงในระยะยาว แท็กเวอร์ชันที่แน่นอนที่คุณได้ทดสอบแล้วมักจะง่ายต่อการทำซ้ำมากกว่าlatestเนื่องจากlatestแท็กจะเปลี่ยนแปลงไปเมื่อมีการเผยแพร่เวอร์ชันใหม่

หากแท็กที่คุณปักหมุดไว้ไม่รวม ARM64 คุณมีสามทางเลือกดังนี้:

ขั้นตอนที่ 3: ลบการตั้งค่า AMD64 ที่ถูกแก้ไขโดยไม่ได้ตั้งใจออก และดึงข้อมูลออกมาอย่างเรียบร้อย

ข้อผิดพลาดที่พบบ่อยไม่ได้เกิดจากอิมเมจ Collabora เอง แต่เกิดจากไฟล์การปรับใช้ที่บังคับใช้แพลตฟอร์มที่ไม่ถูกต้อง Docker Compose กำหนดplatformระบบปฏิบัติการและสถาปัตยกรรมเป้าหมายที่ใช้ในการเลือกเวอร์ชันอิมเมจ เอกสารอ้างอิงบริการ Docker Composeแสดงค่าต่างๆ เช่นlinux/arm64/v8.

บนโฮสต์ ARM64 การตั้งค่านี้ดูน่าสงสัย:

services:
  collabora:
    image: collabora/code:latest
    platform: linux/amd64

หากคุณไม่ต้องการการจำลอง ให้ลบบรรทัดนั้นออก แล้วปล่อยให้ Docker เลือกเวอร์ชันดั้งเดิมของโฮสต์ หรืออีกทางเลือกหนึ่ง ให้ระบุplatform: linux/arm64เมื่อคุณต้องการกำหนดสถาปัตยกรรมอย่างชัดเจน

จากนั้นให้ลบเฉพาะคอนเทนเนอร์ที่ล้มเหลว แล้วดึงอิมเมจใหม่ อย่าลบข้อมูลถาวร เว้นแต่จะมีเหตุผลอื่นที่ต้องทำเช่นนั้น:

docker compose down
docker image rm collabora/code:latest 2>/dev/null || true
docker pull --platform linux/arm64 collabora/code:latest
docker compose up -d

หากคุณใช้แท็กสถาปัตยกรรมเฉพาะสำหรับการทดสอบวินิจฉัย ให้แทนที่ด้วยcollabora/code:latest-arm64. เมื่อคุณยืนยันว่าการปรับใช้ได้แล้ว ให้พิจารณาตรึงเวอร์ชันที่แน่นอน เช่น แท็ก 26.04.x ​​ที่ผ่านการทดสอบแล้ว แทนที่จะปล่อยให้ระบบที่ใช้งานจริงอยู่บนแท็กที่เปลี่ยนแปลงอยู่ตลอดเวลา

ขั้นตอนที่ 4: ตรวจสอบว่า CODE เริ่มทำงานแล้วก่อนที่จะแก้ไขปัญหาการรวมระบบ

หลังจากสร้างคอนเทนเนอร์ใหม่แล้ว ให้ตรวจสอบสถานะและบันทึกต่างๆ:

docker compose ps
docker compose logs --tail=100 collabora

สำหรับการใช้งานแบบคอนเทนเนอร์เดียว คำสั่งที่เทียบเท่ากันคือdocker ps -aและdocker logs --tail=100 <container-name>

เกณฑ์ความสำเร็จข้อแรกของคุณคือ คอนเทนเนอร์ต้องทำงานได้อย่างต่อเนื่องและไม่เกิดข้อผิดพลาดเกี่ยวกับ manifest หรือรูปแบบไฟล์ปฏิบัติการอีกต่อไป หลังจากนั้น คุณจึงค่อยตรวจสอบการเข้าถึงพอร์ต 9980 การตั้งค่า reverse proxy, TLS, โฮสต์ WOPI ที่อนุญาต หรือการรวมแอปพลิเคชัน เอกสารประกอบการใช้งาน Docker อย่างเป็นทางการ ของ Collabora เป็นแหล่งข้อมูลที่เหมาะสมในการตรวจสอบพารามิเตอร์การปรับใช้ในปัจจุบัน

ข้อผิดพลาดทั่วไปที่ผู้เริ่มต้นควรหลีกเลี่ยง

ติดตั้ง QEMU ก่อนตรวจสอบอิมเมจอย่างเป็นทางการ

การจำลองอาจมีประโยชน์เมื่อซอฟต์แวร์มีอยู่เฉพาะสำหรับสถาปัตยกรรม CPU อื่น แต่ภาพอิมเมจ Collabora CODE ปัจจุบันมีเวอร์ชัน ARM64 อยู่แล้ว การเพิ่มการจำลองก่อนอาจซ่อนปัญหาที่แท้จริงและเพิ่มขั้นตอนการทำงานอีก ควรเลือกใช้ ARM64 โดยตรงหากเวอร์ชัน CODE ที่คุณต้องการรองรับ

โดยถือว่า “ล่าสุด” และป้ายที่ปักหมุดไว้แบบเก่ามีความหมายเหมือนกัน

ความพร้อมใช้งานของแพลตฟอร์มนั้นเชื่อมโยงกับแท็กรูปภาพและไฟล์ Manifest เฉพาะ แท็กปัจจุบันอาจรองรับ ARM64 ในขณะที่เวอร์ชันเก่ากว่าอาจไม่รองรับ ตรวจสอบข้อมูลอ้างอิงที่แน่นอนในไฟล์ Compose ของคุณ

บังคับใช้แพลตฟอร์ม: linux/amd64 เนื่องจากคู่มือเก่าใช้แบบนั้น

การตั้งค่าดังกล่าวอาจทำให้โฮสต์ ARM64 ดึงเวอร์ชัน x86-64 มาใช้ แม้ว่าจะมีอิมเมจ ARM64 ดั้งเดิมอยู่ก็ตาม ลบการตั้งค่าที่กำหนดเองออก เว้นแต่คุณจะมีเหตุผลที่ชัดเจนและผ่านการทดสอบแล้วสำหรับการจำลอง

การเปลี่ยนแปลงการตั้งค่า WOPI, SSL หรือพร็อกซี ก่อนที่กระบวนการจะเริ่มทำงาน

ปัญหานี้exec format errorเกิดขึ้นก่อนที่ Collabora จะสามารถประมวลผลการกำหนดค่าระดับแอปพลิเคชันส่วนใหญ่ได้อย่างมีประสิทธิภาพ ควรแก้ไขปัญหาการเลือกสถาปัตยกรรมก่อน การแก้ไขปัญหาเครือข่ายและ WOPI ค่อยทำในภายหลัง

การลบวอลุ่มระหว่างการวินิจฉัย

ความไม่สอดคล้องกันของโครงสร้างสถาปัตยกรรมโดยปกติไม่จำเป็นต้องทำลายข้อมูลถาวร ควรจำกัดขอบเขตของการแก้ไขให้แคบเพื่อให้สามารถย้อนกลับไปยังเวอร์ชันก่อนหน้าได้ง่าย

แล้วถ้าหากไฟล์อิมเมจ ARM64 ยังคงอยู่ล่ะ?

หากในไฟล์ manifest ระบุไว้อย่างชัดเจนlinux/arm64และ Docker ดึงเวอร์ชันนั้นมาใช้ สถาปัตยกรรมก็จะไม่ใช่คำอธิบายหลักอีกต่อไป ในกรณีนั้น ให้บันทึกข้อมูลดังนี้:

• docker compose psหรือdocker ps -a
• บรรทัดบันทึก 100-200 บรรทัดสุดท้าย
• แท็ก CODE ที่ถูกต้อง
• เวอร์ชัน Docker Engine และ Compose ของคุณ
• ส่วนที่ไม่เป็นความลับของคำจำกัดความบริการ Compose ของคุณ

จากนั้นตรวจสอบสิทธิ์การเข้าถึง เส้นทางที่เชื่อมต่อ โปรไฟล์ความปลอดภัย แรงดันหน่วยความจำ ความขัดแย้งของพอร์ต ใบรับรอง หรือการกำหนดค่า WOPI ตามข้อความบันทึกจริง หลีกเลี่ยงการเปลี่ยนสถาปัตยกรรมซ้ำๆ เมื่อคุณตรวจสอบแล้วว่าอิมเมจที่ใช้งานอยู่เป็น ARM64

เส้นทางการตัดสินใจที่เป็นรูปธรรม

1. หากระบบโฮสต์ไม่ใช่ ARM64 ให้หยุดใช้การแก้ไขเฉพาะสำหรับ ARM64 และตรวจสอบแพลตฟอร์มที่แท้จริงแทน
2. หากโฮสต์เป็น ARM64 แต่แท็ก CODE ที่เลือกไม่มีไฟล์ manifest สำหรับ ARM64 ให้เปลี่ยนไปใช้แท็กเนทีฟที่รองรับ หรือเลือกกลยุทธ์การโฮสต์อื่นโดยเจาะจง
3. หากแท็กสนับสนุน ARM64 แต่ Compose บังคับใช้ AMD64 ให้ลบหรือแก้ไขplatformการตั้งค่า
4. หากไฟล์อิมเมจ ARM64 ที่ถูกต้องยังคงอยู่ ให้ถือว่าเป็นปัญหาการเริ่มต้นใช้งาน Collabora ทั่วไป และตรวจสอบบันทึกการทำงานแทนที่จะโทษสถาปัตยกรรมของ CPU ต่อไป

สรุปแล้ว

บนระบบ ARM64 ที่ทันสมัย ​​วิธีแก้ปัญหาที่นิยมใช้มักไม่ใช่การจำลอง ตามที่ตรวจสอบแล้วเมื่อวันที่ 7 ตุลาคม 2026 แท็ก CODE อย่างเป็นทางการของ Collabora ในปัจจุบันมีอิมเมจ ARM64 ดั้งเดิมอยู่แล้ว ตรวจสอบaarch64บนarm64โฮสต์ ตรวจสอบไฟล์ manifest ของอิมเมจอย่างละเอียด ลบการอ้างอิง AMD64 ที่ล้าสมัยหรือถูกบังคับ ดึงอิมเมจที่เข้ากันได้กับ ARM64 อีกครั้ง และตรวจสอบว่าคอนเทนเนอร์ยังคงทำงานอยู่ ลำดับขั้นตอนนี้ทำให้การแก้ไขปัญหาเป็นเรื่องง่ายสำหรับผู้เริ่มต้น และป้องกันไม่ให้การเปลี่ยนแปลง SSL, proxy หรือ WOPI ที่ไม่เกี่ยวข้องมาบดบังปัญหาความไม่ตรงกันของแพลตฟอร์มพื้นฐาน