เอกสาร Asahi Linux: การบูต macOS Sonoma ล้มเหลว
(github.com/AsahiLinux)- ที่เก็บเอกสารของ Asahi Linux ทำหน้าที่เป็น ซอร์สของเว็บไซต์เอกสาร รวมถึงหน้าว่าด้วยการบูต macOS Sonoma ล้มเหลว และจัดการข้อมูลที่เกี่ยวข้องบน GitHub
- เอกสารถูกแบ่งเป็น หมวดหมู่ เช่น
alt,fw,hw,platform,project,swเพื่อให้ค้นหาตามหัวข้อได้ - ส่วน
hwว่าด้วยฮาร์ดแวร์ของ Mac ที่ใช้ Apple Silicon และแยกย่อยเป็นcpu,devices,peripherals,socเพื่อจำแนกรายละเอียดฮาร์ดแวร์ - เว็บไซต์เอกสารถูกสร้างด้วย Zensical และสามารถทดสอบในเครื่องได้ด้วยการติดตั้งแพ็กเกจ Python แล้วรัน
zensical serve - เว็บไซต์จะถูกสร้างใหม่ด้วย CI ทุกครั้งที่มีคอมมิต และเผยแพร่ผ่าน GitHub Pages
บทบาทของที่เก็บเอกสาร Asahi Linux
- ที่เก็บนี้ใช้จัดการเอกสารของเว็บไซต์ Asahi Linux documentation
- เอกสารถูกจัดเป็น หมวดหมู่ ตามหัวข้อ
โครงสร้างหมวดหมู่เอกสาร
alt: เอกสารการรองรับระบบปฏิบัติการทางเลือกและ Linux distributionfw: เอกสารเกี่ยวกับ เฟิร์มแวร์ และอินเทอร์เฟซเฟิร์มแวร์ที่ผู้ผลิตควบคุมhw: เอกสารฮาร์ดแวร์ที่เกี่ยวข้องกับ Apple Silicon Maccpu: เอกสารเกี่ยวกับแอปพลิเคชันโปรเซสเซอร์devices: เอกสารเกี่ยวกับ Mac รุ่นเฉพาะperipherals: เอกสารฮาร์ดแวร์ภายใน Apple Silicon Mac ที่ไม่ใช่ตัว SoC เองsoc: เอกสารเกี่ยวกับบล็อกฮาร์ดแวร์ที่รวมอยู่ใน Apple Silicon SoC
platform: เอกสารที่ใช้กับแพลตฟอร์ม Apple Silicon โดยรวมproject: เอกสารการจัดการโครงการและรายการที่ไม่เกี่ยวกับฮาร์ดแวร์หรือซอฟต์แวร์sw: เอกสารเกี่ยวกับ ซอฟต์แวร์ ที่ไม่ใช่เฟิร์มแวร์
การบิลด์ในเครื่องและวิธีการเผยแพร่
- เว็บไซต์ถูกสร้างด้วย Zensical
- Zensical ติดตั้งเป็น แพ็กเกจ Python
- หากดิสทริบิวชันไม่มีแพ็กเกจให้ สามารถติดตั้งด้วย
pipได้
- หากดิสทริบิวชันไม่มีแพ็กเกจให้ สามารถติดตั้งด้วย
- การบิลด์เอกสารเพื่อทดสอบในเครื่องทำได้หลังติดตั้ง Zensical แล้ว โดยรันคำสั่งต่อไปนี้
$ zensical serve
- เว็บไซต์จะถูกสร้างใหม่โดย CI ทุกครั้งที่มีคอมมิต
- เว็บไซต์ที่บิลด์แล้วจะเผยแพร่ผ่าน GitHub Pages
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
สำหรับข้อสันนิษฐานว่าแค่ เปลี่ยนอัตรารีเฟรช อย่างเดียวทำให้การบูตเสียหายได้อย่างไร Twitter ของเขาก็น่าอ่านเช่นกัน: https://social.treehouse.systems/@marcan/111329614147717090
เพราะมองว่า Apple ไม่ชอบอาการจอกะพริบตอนสลับโหมดจอภาพ และการสลับเปิด/ปิด ProMotion ทำให้เกิดการกะพริบจากการสลับโหมด
ดังนั้นจึงสันนิษฐานว่า Apple น่าจะเก็บค่านี้ไว้ที่ไหนสักแห่งใน NVRAM แล้วให้นำไปใช้ตอนหน้าจอเปิดขึ้นระหว่างช่วงบูตแรก ๆ เพื่อไม่ให้กะพริบอีกตอน macOS บูต
ปัญหาคือไม่ได้ทดสอบกับ bootloader ของ OS รุ่นเก่า ทำให้เมื่อโหมดนี้เปิดอยู่ การส่งต่อ/การเริ่มต้นจอภาพ ล้มเหลวแบบหายนะ
สมัย BIOS ก็พอเข้าใจได้ แต่หลังจากมี UEFI แล้ว หน้าจอตั้งค่า EFI อะไรพวกนี้ก็น่าจะแสดงที่ความละเอียด native ของจอ หรืออย่างน้อยก็อัตราส่วนภาพ native ได้ แต่ที่เห็นจริงมีแต่หน้าจอแบบ 1024x768 ถูกยืดบนจอ 16:9 ซึ่งดูแย่มาก
ด้วยพลังประมวลผลทุกวันนี้ เราไม่ควรต้องเห็นการกะพริบในชีวิตตรงไหนเลย แต่ผมไม่ชอบที่หลายคนยอมรับ สัญญาณรบกวนทางสายตา ตอนต่อจอว่า “แค่นี้ก็พอแล้ว”
quiet splashเพื่อสร้าง ประสบการณ์บูตที่ลื่นไหล แต่กลับทำให้เวลาบูตเพิ่มขึ้นหลายวินาทีและต้องกู้ระบบด้วย USB บูตหลายครั้งตอนนี้ผมยอมรับการกะพริบกับข้อความ systemd ได้แล้ว
ทุกวันนี้การบูตก็แค่ไม่กี่วินาที และเอาจริง ๆ ตอนนี้ก็อธิบายยากแล้วว่าทำไมตอนนั้นถึงหมกมุ่นขนาดนั้น
แอปที่ผมเคยเห็นว่าทำงานไม่ถูกกับอัตรารีเฟรชแบบแปรผันมีแค่ Genshin บน Windows ตัวเดียว และถ้าเป็นจอรุ่นใหม่ก็ไม่น่ามีปัญหา เพราะ VRR รองรับลงไปถึง 60Hz จึงไม่มีอาการกะพริบจากการเพิ่มเฟรมเป็นสองเท่าเวลาสลับไปมาระหว่าง 60Hz กับ 120Hz
ผมเจอปัญหาเดียวกันเป๊ะตอนอัปเดต MacBook Pro M1 ที่ใช้ทำงานไปเป็น Ventura 13.6 และคิดว่าเป็นเหตุการณ์โดดเดี่ยวล้วน ๆ
ไม่ได้บูตคู่ด้วย ติดตั้ง macOS ไว้อย่างเดียว
ระหว่างอัปเดตต่ออยู่กับ Thunderbolt Display ซึ่งดูเหมือนจะให้ผลคล้ายกับที่บทความลิงก์ไว้พูดถึง คือการเปลี่ยนไปใช้อัตรารีเฟรชที่ไม่ใช่ ProMotion
หลังจากทำ DFU restore จาก Mac อีกเครื่องแล้ว ต้องรันตัวติดตั้ง macOS Sonoma ผ่าน USB และโชคดีที่มันตรวจพบการติดตั้งเดิม จึงอัปเกรดทับที่เดิมและข้อมูลยังอยู่
อีกอย่าง ผมเสียเวลาไปมากเพราะทำ DFU restore ไม่ได้ ก่อนจะมารู้ทีหลังว่า ใช้สาย Thunderbolt ไม่ได้ ต้องใช้สาย USB-C ธรรมดา Apple Configurator ถึงจะตรวจพบ Mac อีกเครื่อง
ปกติแล้วสายแบนด์วิดท์สูงที่มีฟีเจอร์มากกว่า มักจะยังใช้งานได้แม้กับฝั่งที่ไม่รองรับฟีเจอร์ทั้งหมด เลยค่อนข้างน่าแปลกใจ
ถ้าวันหลังต้องชุบชีวิต Mac ที่กลายเป็นก้อนอิฐขึ้นมา ผมอยากจำเรื่องนี้ไว้
รู้สึกเหมือนต้องร้องเพลงให้เทพ Mac OS ในจินตนาการฟัง แล้วหวังว่าดวงดาวจะเรียงตัวถูก โน้ตบุ๊กถึงจะโผล่บน Mac เครื่องที่สอง
แถมพอร์ต USB-C ที่เสียบสายก็สำคัญด้วย ต้องเป็นพอร์ตแรกทางซ้ายอีก ไม่รู้ว่าทำไม
แต่สุดท้ายก็ชุบชีวิตกลับมาได้โดยทำตามวิดีโอของ Mr. Macintosh
พอไป Apple Store เขาก็กู้คืนเครื่องทันทีและลบข้อมูลทั้งหมด พอมีอัปเดตถัดไป ปัญหาเดิมก็เกิดซ้ำอีก
พอเป็นแบบนี้ก็ยากจะพิสูจน์ว่าการแก้ของพวกเขาไม่ได้แก้ถาวรจริง ๆ
มีแต่จอดำ และต่อกับโน้ตบุ๊ก USB-C เครื่องอื่นก็เป็นเหมือนเดิม
เปลี่ยนสาย ถอดปลั๊กจอ รีเซ็ตโรงงานก็ไม่ช่วย แต่ช่องอินพุตอื่นอย่าง HDMI กับ DisplayPort ยังทำงานได้
ผมไม่คิดว่าการที่มันพังระหว่างอัปเกรดเป็นเรื่องบังเอิญ และขอแนะนำอย่างยิ่งว่าในระหว่างอัปเกรด อย่าเสียบอะไรกับ MacBook นอกจากที่ชาร์จ
โชคดีที่ข้อมูลยังอยู่หลังทำ DFU revive แต่ตอนแรกผมคิดว่าเป็นเหตุการณ์โดดเดี่ยวที่แบตเตอรี่หมดก่อนอัปเดตเสร็จจนทำให้บางอย่างเสียหาย
แต่มีความเป็นไปได้สูงว่าจอสำรองเป็นสาเหตุ
ผมพยายามติดตั้ง MacBook ใหม่ แต่การกู้คืนผ่านเว็บในตัวไม่ทำงาน วันนี้เลยต้องทำ DFU restore
ระบบพื้นฐานเป็น 13.2 และหลังจากดาวน์โหลดไฟล์ 13.6 ทั้งหมด แถบความคืบหน้าก็ขึ้นถึง 100% แล้วพ่นข้อผิดพลาดออกมา
ดูเหมือนจะเป็นความไม่เข้ากันระหว่างระบบพื้นฐาน 13.2 กับตัวติดตั้ง 13.6 และคุณภาพของ Apple ช่วงนี้แย่มาก
ผมคิดว่าอย่างน้อยพวกเขาคงทดสอบสถานการณ์พื้นฐานที่สุดก่อนปล่อยซอฟต์แวร์ x.6 แล้ว แต่ไม่ใช่เลย
ที่แย่กว่านั้นคือ แทบหาวิธีทางการหรือไม่เป็นทางการในการสร้างตัวติดตั้งบูตผ่าน USB โดยไม่มี Mac เครื่องอื่น หรือทำ DFU restore โดยไม่มี Mac เครื่องอื่นไม่ได้
ไม่รู้ว่าพวกเขาคิดว่าผมอาศัยอยู่ใน Apple Store หรือเปล่า
ผมไม่มี Mac เครื่องอื่น และสุดท้ายก็ทำ DFU restore ได้ด้วย libimobiledevice ต้องขอบคุณคนที่สร้างมันขึ้นมา
แต่เรื่องแบบนี้ไม่ควรเกิดขึ้น และ Windows หรือ Linux โปร่งใสกว่า macOS มาก
สิ่งต่าง ๆ อย่างข้อกำหนดให้เข้าถึงเครือข่าย เฟิร์มแวร์ที่อยู่บน SSD และการล็อกฮาร์ดแวร์ ให้ความรู้สึกเหมือนซ่อนตัวรอสร้างปัญหาในช่วงเวลาที่ลำบากที่สุด
ในทางกลับกัน Windows แค่บูตจากแฟลชไดรฟ์ USB ในลิ้นชักก็พอ
ประมาณหนึ่งปีก่อนติดตั้ง Avahi Linux แล้วลบออก ตอนนี้อัปเกรดต่อจาก 12.6 ไม่ได้
คงต้องหาไดรฟ์ภายนอกมาสำรองทุกอย่าง แล้วทำ DFU restore กับ M1 Max MBP ถึงจะอัปเป็น Sonoma ได้
เขาบอกว่า “อย่าให้ฉันต้องจ่ายเงิน นี่เป็นปัญหาที่ Apple สร้าง และเป็นปัญหาซอฟต์แวร์ล้วน ๆ ถ้าช่างอ้างว่าเป็นความเสียหายของฮาร์ดแวร์ นั่นคือผิด” ก็คงต้องหวังให้เป็นแบบนั้น
ถ้าเป็น ปัญหาที่มีเอกสารระบุไว้ ซึ่งกระทบกับฮาร์ดแวร์รุ่นและเวอร์ชันซอฟต์แวร์บางชุด โอกาสที่จะถูกคิดเงินมีน้อยมาก
ตอน 2011 MacBook Air มีปัญหา SSD เสียในระดับฮาร์ดแวร์ ผมบอกเพื่อนร่วมชั้นบางคนให้ดู หน้าข้อบกพร่องของฮาร์ดแวร์ แล้วพวกเขาก็ได้ซ่อมฟรีแทนที่จะต้องจ่าย 800 ดอลลาร์
ไม่รู้ว่า Apple ช่วงนี้เกิดอะไรขึ้น
หลังจากเกือบตาย Apple ได้สร้างหนึ่งในแบรนด์ที่ดีที่สุดของโลก ด้วยการโฟกัสอย่างไร้ปรานีและทุ่มเทอย่างคลั่งไคล้กับการมอบประสบการณ์ระดับพรีเมียมทั้งระบบ เพื่อให้ราคาพรีเมียมและมาร์จินสูงของตัวเองสมเหตุสมผล
ถ้าคุณชอบแนวทางของพวกเขา ตั้งแต่วินาทีที่ซื้อ มันก็ “แค่ใช้งานได้” แต่ก็นั่นแค่จนไม่นานมานี้
วันนี้ผมเจอ ประสบการณ์แบบคาฟคา จนรู้สึกเหมือนเป็นการแกล้งกันอย่างร้ายกาจ และเพราะ Apple แทบไม่เคยพังเละเทะขนาดนี้ ผมเลยไม่มีแผนสำรองสำหรับช่วงเวลาสำคัญจริง ๆ
ถ้ามีคำแนะนำว่าจะติดต่อทางโทรศัพท์กับคนที่ยอมทำสิ่งที่จำเป็นเพื่อแก้ปัญหาให้ลูกค้าประจำได้อย่างไร ก็อยากฟัง แต่สายซัพพอร์ตด่านแรกตอนนี้รู้สึกเหมือนม้าหมุนแห่งการรอคอยไม่มีที่สิ้นสุด เลยไม่ได้คาดหวังมากนัก
แบรนด์ยังเหมือนเดิม แต่คนส่วนใหญ่เปลี่ยนไปแล้ว
เรื่องแบบนี้เห็นได้ตลอดในอุตสาหกรรมวิดีโอเกม เช่น Blizzard, Bungie, 343 Industries
บางทีโปรแกรมเมอร์และวิศวกรรุ่นใหม่อาจกำลังจัดการกับ codebase ที่ซับซ้อนมาก และอาจไม่มีใครเข้าใจมันทั้งหมดอย่างสมบูรณ์จนกว่าจะมีอะไรพัง
มีผลเฉพาะกับอุปกรณ์ที่ใช้ชิป Apple Silicon และจอ ProMotion เท่านั้น ส่วน Intel ไม่ได้รับผลกระทบ
นี่เป็นเงื่อนไขทางออกฉุกเฉินสำหรับคนที่ใช้อุปกรณ์เก่า
อีกตัวหนึ่งอาจเกิดขึ้นได้กับอุปกรณ์ Apple Silicon ทุกเครื่อง
ประมาณหนึ่งสัปดาห์หลังอัปเกรดเป็น Sonoma เครื่อง 2020 M1 MacBook Air ของผมก็กลายเป็นอิฐ แต่ไม่แน่ใจว่าเกี่ยวกันหรือไม่
ผมสงสัยว่าอาจเกี่ยวกับการอัปเดต
โชคดีที่กฎหมายรับประกันที่นี่ทำให้ได้เปลี่ยน logic board ฟรี แต่ความอยากเปลี่ยนไปใช้ iPhone ในวันถัดมาก็เย็นลงทันที
เช่น Big Sur ทำให้ MBP ปี 2013 และ 2014 หลายเครื่องกลายเป็นอิฐ: https://www.macrumors.com/2020/11/15/macos-big-sur-update-br...
ผมเองก็โดน และเหมือนผู้ใช้จำนวนมาก ปัญหาหายไปหลังเปลี่ยนบอร์ด I/O
ในกรณีของผม ประกันหมดไปนานแล้ว เลยซื้ออะไหล่ราคา 10 ดอลลาร์จาก Ebay มาเปลี่ยนเอง
ในทางกลับกัน Google Pixel ที่ผมเคยมี ตลอด 2 ปีมันกลายเป็นอิฐเองประมาณสองครั้ง
วันหนึ่งเปิดฝาขึ้นมาแล้วเครื่องไม่ติด ถ้าไม่มี AppleCare คงต้องจ่ายค่าซ่อม 500 ดอลลาร์
ประมาณ 2 สัปดาห์ก่อน ผมวางมันไว้บนเตียงในห้องโรงแรมโดยเปิดฝาไว้ แล้วจับหน้าจอดึงเข้ามาใกล้ หน้าจอก็แตกเพียงเพราะแรงกดเบา ๆ จากนิ้ว
กรณีของปัญหาทั้งสองอย่างนี้ใน Air มีให้เห็นเต็มอินเทอร์เน็ต
ตอนแรกผมชอบ M1 Air มากจริง ๆ แต่ตอนนี้มันพิสูจน์แล้วว่าเป็นอุปกรณ์ที่ไม่น่าไว้ใจเกินไปสำหรับผม
ไม่ว่าผู้ผลิตรายไหน ปัญหาซอฟต์แวร์และฮาร์ดแวร์ก็ย่อมเกิดขึ้นได้ในระดับหนึ่ง
อ่านคอมเมนต์ที่นี่แล้วก็สงสัยว่า คนใน Hacker News จำนวนมากเคยเจอผู้ใช้ทั่วไปจริง ๆ ในชีวิตประจำวันบ้างไหม
ไม่ใช่พวกกี๊กหรือผู้ใช้ช่ำชองคนอื่น ๆ แต่หมายถึงคนธรรมดาในคอกข้าง ๆ ที่รู้เรื่องคอมพิวเตอร์เท่าที่จำเป็นต่อการทำงานเท่านั้น
สงสัยจริง ๆ ว่าพวกเขาคิดว่าผู้ใช้ต้องการ ตัวเลือกโหมดกราฟิก ตอนบูตหรือเปล่า
ในบรรดาผู้ใช้ Mac จะมีสัดส่วนสักเท่าไหร่กันที่ใช้บูตโหลดเดอร์ทางเลือก หรือรู้ด้วยซ้ำว่ามันคืออะไร
ถ้าได้ใช้เวลาในหน้างานที่ต้องซัพพอร์ตอุปกรณ์จำนวนมากในองค์กรใหญ่ ๆ สักหน่อย ก็จะรู้ว่าผู้ใช้สนใจสิ่งที่เราคิดว่าสำคัญจริงไหม
รวมถึงโหมดกู้คืนเมื่อระบบเหล่านั้นถูกตั้งเป็น OS สำหรับบูตเริ่มต้นด้วย และ System Recovery ก็จะได้รับผลกระทบจนกว่าจะมีการอัปเกรด OS ครั้งถัดไป
ต่อให้ผู้ใช้จะ “ไม่สนใจ” หรือ “ไม่เข้าใจว่าหมายถึงอะไร” เรื่องนี้ก็ยังส่งผลต่อผู้ใช้ทั่วไปได้มากพอ
ลองนึกถึงจำนวนการแจ้งเตือนและคำเตือนด้านความปลอดภัยที่โผล่มาระหว่างที่ต้องทำงานก็ได้
ท้ายที่สุดมันคือ muscle memory
คำเตือนด้านความปลอดภัย ถ้าเพิกเฉยระบบอาจถูกเจาะได้ แต่ในกรณีนี้ วันหนึ่งมันอาจช่วยกู้ระบบและงานของคุณได้ จึงยากจะบอกว่าไร้ค่า
ปัญหานี้อาจเกิดกับผู้ใช้ที่ต้องการใช้ macOS สองเวอร์ชัน ไม่ว่าด้วยเหตุผลใดก็ตาม และโดยเฉพาะในหมู่ผู้เชี่ยวชาญสายครีเอทีฟ ก็ไม่ใช่เรื่องแปลกมากนัก
สรุปคือ ใน macOS Sonoma รุ่นล่าสุดและ 13.6 Ventura มีบั๊กในการอัปเกรดที่ทำให้ Mac บางเครื่องกลายเป็นเครื่องดับเปิดไม่ขึ้น และทำให้ใช้ recoveryOS ไม่ได้ จนเกิดหน้าจอดำที่ต้องใช้ DFU revive
ปัญหาของ Sonoma ดูเหมือนจะเกิดบ่อยที่สุดกับ Mac ที่บูตคู่: https://support.apple.com/en-us/HT208891
การอัปเกรด Ventura ก็อาจมีปัญหาด้วยเหตุผลที่ไม่ชัดเจน หากรีเฟรชเรตของจอแสดงผลถูกตั้งเป็นค่าที่ไม่ใช่ ProMotion
เอกสารนี้อยู่ในวิกิ Asahi Linux เพราะนักพัฒนา Asahi Linux เป็นผู้พบปัญหา แต่ไม่ได้เป็นปัญหาที่จำกัดเฉพาะ Asahi
จริง ๆ แล้ว หากเรียกใช้ตัวติดตั้ง Asahi Linux ก็สามารถตรวจจับได้ว่า Mac เครื่องนั้นจะได้รับผลกระทบจากปัญหานี้หรือไม่ แม้สุดท้ายจะไม่ได้ติดตั้ง Asahi Linux ก็ตาม
รายละเอียดเพิ่มเติมดูได้ในบทความ
มีพาร์ทิชัน OSX ที่บูตได้อยู่สองพาร์ทิชัน และโดนกับการอัปเกรดทั้งสองครั้ง
ผมไม่ค่อยคุ้นกับ Mac เท่าไร เลยต้องงมแก้อยู่หนักมาก และยังต้องเรียนรู้ด้วยว่า DFU มีอยู่จริงและทำอะไรได้บ้าง
โชคดีที่ลูกสาวมี Mac เลยสามารถใช้ DFU ได้โดยไม่ต้องเอาไปที่ Apple Store
อย่างน้อยก็เป็นเรื่องน่ายินดีอยู่บ้างที่มี บุคคลที่สาม คอยค้นหาปัญหาของ macOS อย่างจริงจัง