เหตุใดจึงยังคงใช้หมายเลขไดรฟ์ / พาร์ติชันอยู่

หลายครั้งโดยเฉพาะอย่างยิ่งเมื่อล้อเล่นกับ boot-loader ฉันจะเห็นไดรฟ์ตัวเลขและหมายเลขพาร์ติชันที่ใช้ ตัวอย่างเช่นในที่/boot/grub/grub.cfgฉันเห็นset root='hd0,gpt2'รายการบูต UEFI ของฉันมักจะอ้างอิงหมายเลขไดรฟ์ / พาร์ติชันและดูเหมือนว่าจะครอบตัดขึ้นในเกือบทุกบริบทที่เกี่ยวข้องกับ bootloaders

ตอนนี้เรามี UUID และ PARTUUID การจัดการกับพาร์ติชั่นในลักษณะนี้ดูเหมือนไม่เสถียรอย่างไม่น่าเชื่อ (ไม่รับประกันไดรฟ์ที่ติดตั้งในลำดับเดียวกันเสมอผู้ใช้สามารถย้ายลำดับของไดรฟ์ที่เสียบเข้ากับ mobo เป็นต้น)

คำถามของฉันจึงเป็นสองเท่า:

1. รูปแบบการกำหนดแอดเดรสนี้ไม่เสถียรอย่างที่ฉันได้อธิบายไว้ข้างต้นหรือไม่ ฉันขาดอะไรบางอย่างในมาตรฐานซึ่งหมายความว่าชุดรูปแบบนี้มีความน่าเชื่อถือมากกว่าที่ฉันคาดไว้หรือชุดรูปแบบการกำหนดแอดเดรสนี้จะทำให้ระบบของคุณไม่สามารถบูตได้จริง ๆ (จนกว่าคุณจะแก้ไขรายการบูตของคุณเป็นอย่างน้อย) ลำดับที่แตกต่างกันหรือเสียบเข้ากับช่องเสียบต่างๆบนเมนบอร์ดของคุณ?

2. หากคำตอบของคำถามข้างต้นคือใช่แล้วทำไมรูปแบบการกำหนดแอดเดรสนี้จึงยังคงใช้งานต่อไป จะไม่ใช้ UUID หรือ PARTUUID สำหรับทุกสิ่งที่จะมีเสถียรภาพมากขึ้นและสอดคล้องกันหรือไม่

รูปแบบการกำหนดหมายเลขธรรมดาไม่ได้ใช้จริงในระบบล่าสุด (ด้วย "ล่าสุด" เป็น Ubuntu 9 และใหม่กว่าการกระจายอื่นอาจปรับเปลี่ยนในยุคนั้นเช่นกัน)
คุณถูกต้องในการสังเกตพาร์ติชันรูทที่ถูกตั้งค่าด้วยโครงร่างการกำหนดหมายเลขธรรมดา แต่นี่เป็นค่าเริ่มต้นหรือการตั้งค่าย้อนกลับซึ่งมักจะถูกแทนที่ด้วยคำสั่งถัดไปเช่น:

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

สิ่งนี้จะเลือกพาร์ติชันรูทตาม UUID ของระบบไฟล์

ในทางปฏิบัติรูปแบบการกำหนดหมายเลขธรรมดามักจะเสถียร (ตราบใดที่ไม่มีการเปลี่ยนแปลงฮาร์ดแวร์) อินสแตนซ์เดียวที่ฉันสังเกตเห็นการกำหนดหมายเลขที่ไม่สามารถคาดเดาได้คือระบบที่มีไดรฟ์ USB จำนวนมากซึ่งระบุตามรูปแบบการให้บริการแบบมาก่อนได้ก่อนแล้วจึงจำลองเป็นไดรฟ์ IDE ไม่มีกระบวนการใดที่จะเกิดความสับสนดังนั้นฉันจึงถือว่าปัญหาในการใช้งานไบออสของระบบนั้น ๆ

หมายเหตุ: "root partition" ในบริบทนี้หมายถึงพาร์ติชั่นในการบู๊ตมันอาจแตกต่างจากพาร์ติชั่นที่มี "root aka. / system file"

พูดอย่างเคร่งครัดUUID ไม่ได้อยู่เลย

การกำหนดที่อยู่นั้นง่ายมาก: อ่านไดรฟ์ X ภาค Y - หรืออย่างอื่น อ่านที่อยู่หน่วยความจำ Z - หรืออื่น ๆ การพูดถึงง่ายรวดเร็วออกจากพื้นที่ไม่มากสำหรับการตีความและทุกที่

UUID ไม่ได้ระบุที่อยู่ แต่มันคือการค้นหาค้นหาบางครั้งกำลังรอให้อุปกรณ์ปรากฏและทำความเข้าใจกับระบบไฟล์ (★) และขึ้นอยู่กับจำนวนอุปกรณ์ที่มีอาจใช้เวลานานมาก และเมื่อพบแล้วให้กลับไปที่ตำแหน่งปกติ

ใน GRUB สิ่งนี้เรียกว่าsearch(★★) และใช้ได้เฉพาะเมื่อ GRUB เติบโตขึ้นแล้ว (ค้นหาเป็นโมดูลเช่นเดียวกับทุกระบบไฟล์ที่รองรับจึงใช้ได้เฉพาะหลังจากโหลดคอร์) ในลินุกซ์ก็ (ตัวอย่าง) เรียกว่าfindfs, findfs จะค้นหาอุปกรณ์ป้องกันในระบบที่กำลังมองหาระบบแฟ้มหรือพาร์ทิชัน

มันจะผ่าน blockdevices ทั้งหมดปลุกพวกเขาจากโหมดสแตนด์บายอ่านข้อมูลและผลลัพธ์อาจจะยังคงสุ่มถ้า UUID ไม่ซ้ำตามที่ควรจะเป็น (หลังddเกิดอุบัติเหตุหรือสิ่งที่คล้ายกัน) หรือคุณไม่ได้รับผลลัพธ์หาก UUID เปลี่ยน - UUID มีแนวโน้มที่จะเกิดข้อผิดพลาดในการกำหนดค่าเช่นกัน

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

สำหรับ bootloader นั้นอาจไม่จำเป็นต้องใช้ความพยายาม (ไม่ใช่ bootloader ทุกตัวรองรับระบบไฟล์ที่หลากหลายเช่น GRUB) หากhd0มีการรับประกันว่าเป็น "ดิสก์ที่เราบูทจาก" เนื่องจากสถานการณ์ (BIOS มีให้) และถ้าคุณสามารถแยกแยะปัญหาเกี่ยวกับลำดับไดรฟ์แบบสุ่มอาจไม่จำเป็นต้องผ่านรายการพาร์ติชั่นอื่น ๆ ค้นหา UUID

หากคุณมั่นใจในการกำหนดค่าของคุณเพียงพอที่จะบอกว่าสิ่งนั้นhd0,gpt2เป็นสิ่งที่คุณต้องการและมันต้องเป็นและมันไม่สามารถเป็นอย่างอื่นได้ บางครั้งการกำหนดที่อยู่ธรรมดาและเรียบง่ายก็ใช้ได้ดี

(★) ก่อนหน้านี้ฉันอธิบายเรื่องนี้สำหรับ LABEL ที่นี่ ...

ไม่มีมาตรฐานทั่วไปสำหรับป้ายชื่อคือมันคือทั้งหมดที่ถักด้วยมือ, ดูตัวอย่างการดำเนินงานนี้รูปแบบ superblocks ใน util หากคุณคิดค้นระบบไฟล์ใหม่ในวันพรุ่งนี้แม้ว่าจะมีป้ายกำกับมันจะไม่ปรากฏขึ้นจนกว่าจะมีการเพิ่มการสนับสนุน

... และมันก็เหมือนกันสำหรับ UUIDs

(★★) ที่จริงแล้ว GRUB searchมี--hintตัวเลือกและ ... ตอนนี้ฉันไม่ได้ตรวจสอบซอร์สโค้ดและมันไม่ได้จัดทำเป็นเอกสารในคู่มือของพวกเขา แต่ตัวเลือกดังกล่าวเหมาะสมที่จะให้สิ่งที่ดีที่สุดแก่คุณทั้งโลก: คำแนะนำควรบอกsearchให้ตรวจสอบพาร์ติชั่นนั้นก่อนและถ้า UUID ตรงกับที่คาดไว้มันระบุอุปกรณ์ด้วยความพยายามเพียงเล็กน้อยและถ้ามันไม่ตรงกันมันก็จะกลับไปที่การค้นหาแบบเต็มเพื่อให้สิ่งต่าง ๆ ทำงานได้ .

นอกจากนั้นพบว่า UUIDs ก่อนหน้านี้มีแนวโน้มที่จะถูกแคชดังนั้นจึงไม่จำเป็นต้องผ่านอุปกรณ์ทั้งหมดซ้ำแล้วซ้ำอีก - และนี่ใช้งานได้ดีเช่นกันหาก UUID ที่คุณกำลังมองหามีอยู่จริง ทำให้มันเป็นแคชในสถานที่แรก

นอกจากนี้อย่าลืมฉลาก พวกเขาไม่ได้มีความโดดเด่นเหมือน UUIDs แต่มีข้อมูลมากกว่าและทำให้มนุษย์ของคุณอ่านได้ หากเป็นเดสก์ท็อปของคุณหรือเป็น บริษัท ขนาดเล็ก - กล่าวอีกนัยหนึ่งคุณกำลังจัดการไดรฟ์ไม่กี่ถึงสองสามสิบตัวคุณอาจต้องการใช้ป้ายกำกับ UUID

เมื่อพิจารณาถึงคำตอบที่ยอดเยี่ยมของ @ frostschutz สำหรับคำถามของคุณหนึ่งสถานการณ์ที่คุณน่าจะชอบการเชื่อมโยงอุปกรณ์ "คลาสสิค" คือการตั้งค่า VM โดยเฉพาะอย่างยิ่งใน VM-for-Hire สมมติว่าคุณต้องการปรับแต่งภาพUbunzima 04.18 คุณสร้าง VM (throwaway) พร้อมดิสก์ 2 ตัวหนึ่งอันจะเป็นไดรฟ์ระบบ (ทิ้ง) และอีกอันหนึ่งที่คุณติดตั้งและปรับแต่ง สมมุติว่าคุณติดพาร์ติชันสำหรับบูต UEFI ด้วยถ้าคุณต้องการด้วงด้วงใหม่ในดิสก์ใหม่ของคุณ สมมติว่าคุณเลือกจุดเมานท์สำหรับพาร์ติชันเป้าหมายด้านล่าง/mntตารางการเมานต์ที่คุณต้องการจะเป็นดังนี้

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

ดังนั้นคุณจึงสร้างไดรฟ์ที่เหมือนกัน 2 ไดรฟ์จากอิมเมจที่พร้อมใช้งานจากผู้ให้บริการพร้อมเชื่อมต่อกับ VM ใหม่และบูตมัน ธรรมชาติ

• ระบบปฏิบัติการ distros ที่ทันสมัยทั้งหมด, Ubunzima 04.18จินตนาการของเราไม่ได้เป็นข้อยกเว้นพึ่งพาการติดตั้ง UUID ที่มีชื่อ
• ฮาร์ดไดรฟ์ทุกตัวที่นำออกจากภาพเดียวกันนั้นมี UUID เดียวกัน UUID นั้นไม่เหมือนกันดังนั้นจะเกิดอะไรขึ้น

คุณเห็นแล้วว่าสิ่งนี้เกิดขึ้นที่ไหน

ครั้งแรกที่แฟรงก์ควบคุมการบูตมันเลือกsda9เป็นพาร์ติชันสำหรับบูต EFI แต่ Linux ตัดสินใจที่จะsdb1นับใหม่เป็นรูท FS:

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

และเนื่องจากสคริปต์การเปิดตัวของฉันนั้นค่อนข้างไม่ได้เตรียมตัวไว้สำหรับเรื่องนั้นฉันจึงได้ภาพอึที่ไม่สามารถบูตได้ในตอนท้ายโดยไม่มีเครื่องมือเดียวที่บ่นในบันทึกระหว่างการสร้างแฟรงค์!

แน่นอนฉันพิมพ์ตารางเมานต์ในบันทึก และแน่นอนว่าการเลอะเทอะนั้นยากที่จะมองเห็นเนื่องจาก mount (8) พิมพ์เมาท์ตามลำดับครึ่งทางระหว่างการสุ่มและอุปกรณ์ที่ติดตั้งดังนั้นมันจึงไม่น่าแปลกใจที่ฉันไม่ได้เห็นมันทันที และจินตนาการว่าสคริปต์ตัวเดิม (แต่มีดิสก์จากภาพต่าง ๆ ) ก่อนหน้านี้ทำงานได้อย่างราบรื่นเหมือนกับ Glenfiddich อายุ 15 ปี คาดเดาว่าฉันใช้เวลาหลายชั่วโมงในการดึงเส้นผมของฉันไปที่ท่อนซุงเพื่อพยายามหาปัญหา?

ไม่มีกฎอย่างหนักและรวดเร็วที่ดีสำหรับทุกสถานการณ์ไม่ว่าจะเป็นเดสก์ท็อปพีซีไปจนถึง Linux ที่ฝังอยู่ในเราเตอร์ไปยังโทรศัพท์ Android ของคุณไปยังศูนย์ข้อมูลคลาวด์ คำตอบดังนั้นควรจะมีวัตถุประสงค์และประสบการณ์หรือความชอบของฉันนั้นแน่นอนไม่ใช่ ดังนั้นฉันจะแสดงตัวอย่างของการใช้เหตุผลเชิงตรรกะเมื่อเลือกระหว่างวิธีการระบุพาร์ติชันที่แตกต่างกัน:

• ปล่อยไว้คนเดียวถ้าคุณไม่มีเหตุผลที่จะไม่ทำ UUIDs เป็นค่าเริ่มต้นสำหรับ distros ที่ทันสมัยที่สุด หากเป็นการเพิ่มไดรฟ์ที่สองลองแล้วตัดสินใจ โอกาสที่คุณไม่จำเป็นต้องรู้ด้วยซ้ำ หากระบบของคุณยังคงบู๊ตและคุณสามารถเห็นและแบ่งพาร์ติชันอุปกรณ์ใหม่ให้จัดรูปแบบและเพิ่มลงใน fstab (โดย UUID, โดย LABEL หรือโดย/devลิงก์จะมีการพิจารณาแบบเดียวกัน) มันก็ต่อเมื่อระบบของคุณปฏิเสธที่จะบู๊ตหลังจากเสียบไดรฟ์พิเศษแล้วคุณมีปัญหา (และอาจจะเปลี่ยนลำดับการบู๊ตใน UEFI BIOS เป็นวิธีที่เร็วที่สุด)

  ในทางปฏิบัติการติดฉลากที่ขั้วต่อ SATA ไปที่ไดรฟ์ในเดสก์ท็อปของคุณอาจเป็นวิธีที่เร็วและง่ายที่สุดในขณะที่เปลี่ยนวิธีการบู๊ตระบบและการกู้คืนจากความล้มเหลวในการบูต แต่ถ้าคุณจัดการมันสำหรับโปรแกรมเมอร์ 50 คนที่คิดว่าการขว้างไดรฟ์เพิ่มเติมนั้นไม่ใช่ปัญหาที่ควรค่าแก่คุณอย่างน้อยที่สุดก็อย่าทดสอบขีด จำกัด ของโชคของคุณและตรวจสอบให้แน่ใจว่าไดรฟ์บูตเริ่มแรกนั้นดูด้วงhd0แล้ว sdaเป็นระบบ

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

  หาก lsblk (8) บอกว่าLABEL=bubba-bootคุณรู้ว่ามันถูกดึงออกมาจากเครื่องที่เรียกว่าbubba ; นอกจากนี้bubba-bootม้วนกว่าลิ้นของฉันง่ายกว่า6864c4ea-f9b9-46db-b875-4d7fc2981007ซึ่งตามรสนิยมของฉัน การทำให้มั่นใจว่าป้ายกำกับนั้นมีความเป็นเอกลักษณ์ในขณะที่คุณเปลี่ยน แต่สิ่งที่คุณได้รับคือความหมายของป้ายกำกับ

• /dev-การตั้งชื่อตามลิงก์เมื่อสั่งการกองพันของ VMs ที่มีอายุสั้นและบำรุงรักษาค่อนข้างต่ำซึ่งเป็นจุดเริ่มต้นของภาพเดียวกันและคุณจะไม่เดิมพันค่าจ้างรายสัปดาห์ของคุณที่ UUID ทั้งหมดของพวกเขาจะขึ้นอยู่กับสัญญาของ UU บริการใด ๆ ของVM ที่มีสติไม่ว่าจะเป็นVyper-Hบนเซิร์ฟเวอร์จริงของคุณหรือKugel Cloudหรืออะไรก็ตามจะไม่เรียกบูทไดรฟ์ของคุณsdeและอย่างที่สองและอีกอันหนึ่งsdc² ในอีกทางหนึ่งเครื่องทางกายภาพคุณสามารถจัดเรียงที่เดียวกันได้อย่างง่ายดายโดยการเชื่อมต่อสายเคเบิล SATA อย่างสร้างสรรค์

  ตอนนี้ฉันพูดนอกเรื่อง แต่ในสถานการณ์นี้ฉันไปเส้นทางเดียวกันกับการตั้งชื่ออีเธอร์เน็ตอินเตอร์เฟส“ สอดคล้อง”: ปิดใช้งานใน VMs อย่าเข้าใจฉันผิดการตั้งชื่อนั้นมีความสอดคล้องตราบใดที่ NIC ที่คุณใส่ลงในสล็อต PCI 4 จะไม่ข้ามไปที่ช่อง 5 ด้วยความตั้งใจของตัวเองในขณะที่คุณไม่ได้มอง (หรืออาจเป็นแม้ในขณะที่คุณอยู่ ไม่มีความละอายใด ๆ ) น่าเสียดายที่ในความเป็นจริง“ กองทัพของ VMs” นั้นมีอยู่จริง ในกรณีนี้ตอบโต้โดยสังเขปeth0มีความสอดคล้องมากกว่าenp0s4f6. ผู้ให้บริการ VM ไม่ได้สัญญาว่าจะใส่หมายเลข NIC เสมือนจริง 1 ในสล็อต 4 บน PCI บัส 0 เสมอ (และไม่มีเอนทิตีที่กล่าวถึง 3 ตัวจริง) และมันจะเป็นฟังก์ชัน 6 เสมอ แต่คุณสามารถสวยได้ พึ่งพาอินเทอร์เฟซแรกมากก่อนหน้าที่สองเนื่องจากปกติแล้วพวกเขาจะมีโมดูลไดรเวอร์เดียวกันโดยทั่วไปจากตระกูล virtio (และถ้า NIC แรกไม่เสมอeth0ไปNote²เดียวกันจะยังคงใช้งานอยู่)

  ---

igur เปรียบเปรยแน่นอน ฉันได้รับถ้าธุรกิจนี้นานเกินไปที่จะมีเหลือ
²หากพวกเขา, ฉันอย่างจริงจังต้องการพิจารณาวิ่งหนีเสียงกรีดร้องจากพวกเขาเปลี่ยนผู้ให้บริการหรือซอฟแวร์ไฮเปอร์ไวเซอร์ VM

แผนการทั้งสองสามารถผสมและจับคู่กับการแจกแจงลินุกซ์ส่วนใหญ่

ผลที่ตามมาอาจเป็นที่ต้องการหรือไม่พึงประสงค์ขึ้นอยู่กับกรณีการใช้งาน - ตัวอย่างเช่นหนึ่งอาจต้องการแบบแผนเก่า (และแม้กระทั่งปิดการใช้งานแฮ็กสไตล์ udev แบบถาวร) ถ้าร้อนแทนไดรฟ์ (ฮาร์ดแวร์เสมือนหรือฮาร์ดแวร์จริง) ต้องการ.

คำตอบสำหรับคำถามที่สองของคุณ ("ทำไมรูปแบบการกำหนดที่อยู่นี้จึงยังคงใช้อยู่ต่อไป?") คือฉันคิดว่าความเฉื่อย ใช่เป็นไปได้ทั้งหมดที่จะใช้เฉพาะ UUID ในดิสก์ที่แบ่งพาร์ติชัน GPT คุณสามารถใช้ UUID แทน/dev/xxxชื่อ/etc/fstabได้ และตอนนี้เรามีข้อกำหนดพาร์ติชันที่สามารถค้นพบได้ในหลายกรณีคุณไม่จำเป็นต้องระบุ UUID อีกต่อไปเพียงแค่แบ่งพาร์ติชันดิสก์ของคุณด้วยประเภทพาร์ติชันและพาร์ติชันจะถูกเลือกโดยอัตโนมัติ ในเครื่องของฉันroot=รายการขาดหายไปจากบรรทัดคำสั่งเคอร์เนล

และการพูดถึง boot loader: GRUB ส่วนใหญ่ไม่จำเป็นบนพีซี UEFI ที่ทันสมัยในแง่ที่ว่ามันมีส่วนเกี่ยวข้องกับการบูตเครื่อง ทุกวันนี้ GRUB ทำหน้าที่เป็นโปรแกรมตัวเลือกเคอร์เนลเท่านั้นซึ่งงานมีตัวเลือกที่ง่ายและดีกว่าเช่น systemd-boot