Làm thế nào để Linux đối phó với một phân vùng khởi động / riêng biệt?


11

Tôi muốn tìm hiểu về cách Linux xử lý các phân vùng khởi động riêng biệt. Tôi không quan tâm đến việc thực sự làm điều này, nhưng tôi muốn biết làm thế nào điều này hoạt động dưới mui xe.

Hãy xem xét một ổ đĩa cứng sda, có hai phân vùng sda1sda2. Giả sử đó sda2rootphân vùng /chứa HĐH Linux.

Hiểu biết của tôi là bộ nạp khởi động GRUB2, được gắn kết /boot. Tuy nhiên, khi thư mục /bootnằm trên một phân vùng riêng biệt sda2, làm thế nào mà điều này có thể xảy ra trước khi /thực sự được gắn kết?

Làm thế nào để tương tác giữa BIOS, bản ghi khởi động chính và GRUB (hoặc các tệp /boot) xảy ra thành công trong trường hợp này? Có phải dữ liệu trong /bootkhông thực sự được gắn vào /hệ thống tập tin ở giai đoạn đầu này?

Lưu ý: câu hỏi này liên quan đến việc gắn phân vùng gốc, nhưng không thảo luận về phân vùng khởi động riêng.

Câu trả lời:


18

Đây là vấn đề trong sự hiểu biết của bạn:

Tôi hiểu rằng bộ tải khởi động GRUB2, được gắn vào / boot.

GRUB không được "gắn" khi khởi động. GRUB được cài đặt để /boot, và được nạp từ mã trong Master Boot Record. Dưới đây là tổng quan đơn giản về quy trình khởi động hiện đại, giả sử phân phối GNU / Linux với MBR / BIOS (không phải GPT / UEFI):

  1. BIOS tải.
  2. BIOS tải đoạn mã nhỏ trong Bản ghi khởi động chính.
  3. GRUB không vừa với 440 byte, kích thước của Master Boot Record. Do đó, mã được tải thực sự chỉ phân tích bảng phân vùng, tìm /bootphân vùng (mà tôi tin là được xác định khi bạn cài đặt GRUB vào Bản ghi khởi động chính) và phân tích thông tin hệ thống tệp. Sau đó, nó tải Giai đoạn 2 GRUB. (Đây là nơi đơn giản hóa đến.)
  4. GRUB Giai đoạn 2 tải mọi thứ nó cần, bao gồm cả cấu hình GRUB, sau đó trình bày một menu (hoặc không, tùy thuộc vào cấu hình người dùng).
  5. Trình tự khởi động được chọn. Điều này có thể là do thời gian chờ, bởi người dùng chọn một mục menu hoặc bằng cách khởi động một danh sách lệnh.
  6. Trình tự khởi động bắt đầu thực thi. Điều này có thể thực hiện một số việc - ví dụ, tải kernel, tải chuỗi cho bộ tải khởi động khác - nhưng giả sử rằng trình tự khởi động là GNU / Linux tiêu chuẩn.
  7. GRUB tải kernel Linux.
  8. GRUB tải ramdisk ban đầu .
  9. Ramdisk ban đầu gắn kết /bên dưới /new_root(có thể mở khóa bằng mật mã), bắt đầu udev, bắt đầu tiếp tục từ trao đổi, v.v.
  10. Ramdisk ban đầu sử dụng pivot_roottiện ích để thiết lập /new_rootnhư thật /.
  11. initbắt đầu Các phân vùng được gắn kết, daemon bắt đầu và hệ thống khởi động.

Lưu ý cách kernel chỉ được tải ở bước 7. Vì điều này, không có khái niệm gắn kết cho đến bước 7 . Đây là lý do tại sao /bootphải được gắn lại trong bước 9, mặc dù GRUB đã sử dụng nó.

Nó cũng có thể được sử dụng để xem phần GRUB 2 của trang Wikipedia trên GRUB.


Bạn xác định chính xác sự nhầm lẫn của tôi. Đây chỉ là những gì tôi đang tìm kiếm. Vì vậy, ban đầu /bootkhông đề cập đến một thư mục được gắn trên phân vùng gốc?
jII

@jesterII tuyệt vời! trong trường hợp đó, bạn có phiền khi chấp nhận câu trả lời này bằng cách nhấp vào dấu chọn ngay bên dưới mũi tên biểu quyết không?
strugee

7
Mã MBR không thể phân tích cú pháp một hệ thống tập tin. Nó tải hình ảnh lõi grub từ các khu vực không được sử dụng sau MBR trước phân vùng đầu tiên và mã đó hiểu cách tìm và gắn phân vùng / boot để tìm các tệp cấu hình grub, mô-đun bổ sung và hạt nhân của bạn. Ngoài ra p Pivot_root được coi là một bản hack bẩn và đã được thay thế bằng cách run-initxóa tất cả các tệp trong initramfs, sau đó chroots vào hệ thống tệp gốc.
psusi

Quy trình khởi động hiện đại bây giờ phải là quy trình khởi động Legacy khi UEFIngày càng có nhiều popurlar ;-) @strugee
Kiwy

1
@strugee, sau khi thảo luận về danh sách gửi thư của linux, có vẻ như hồi ức của tôi hơi bị tắt: họ đã ngừng cho phép p Pivot_root trên rootfs thực, vì vậy đó là lý do tại sao không ai sử dụng nó trong khi khởi động nữa. Systemd sử dụng nó khi tắt máy, không phải để trở về initrd ban đầu (tự loại bỏ khi chuyển sang root thực), mà để chuyển sang một cái mới được tải. Xem marc.info/?l=util-linux-ng&m=139100788306216&w=2
psusi

6

Câu hỏi 1

Tôi hiểu rằng bộ tải khởi động GRUB2, được gắn vào / boot. Tuy nhiên, khi thư mục / boot nằm trên phân vùng sda2 riêng biệt, làm thế nào mà điều này có thể xảy ra trước khi / thực sự được gắn kết?

Tôi không nghĩ rằng bạn hiểu là khá đúng ở đây. Từ trang Wikipedia GNU GRUB :

đoạn trích

Khi máy tính được bật, BIOS của máy tính sẽ tìm thiết bị khởi động chính được cấu hình (thường là đĩa cứng của máy tính) và tải và thực hiện chương trình bootstrap ban đầu từ bản ghi khởi động chính (MBR). MBR là khu vực đầu tiên của đĩa cứng và có số 0 (số đếm bắt đầu từ 0). Trong một thời gian dài, kích thước của một sector là 512 byte, nhưng kể từ năm 2009, có các đĩa cứng có sẵn với kích thước cung là 4096 byte, được gọi là đĩa Định dạng Nâng cao . Kể từ tháng 10 năm 2013, các đĩa cứng như vậy vẫn được truy cập trong các cung từ 512 byte, bằng cách sử dụng mô phỏng 512e .

Trong GRUB phiên bản 2 diễn ra như sau:

đoạn trích

Khởi động máy tính

Khi bật nguồn, điều sau đây xảy ra:

  • Phần cứng khởi tạo, đặt CPU thành chế độ thực (không có bộ nhớ ảo) và nhảy đến vị trí cố định 0xFFFF0 (được gắn cứng trong các mạch CPU)
  • Do đó, mã BIOS được lưu trữ trong ROM hoặc bộ nhớ flash được ánh xạ tới vị trí đó.
  • Mã BIOS nhìn vào dữ liệu cấu hình BIOS để xem thiết bị khởi động nào. Dữ liệu cấu hình BIOS này thường có thể được chỉnh sửa bằng cách nhấn một số chuỗi khóa đặc biệt ngay sau khi bật nguồn, khiến chương trình cấu hình BIOS chạy. Trong số những thứ khác, thiết bị khởi động thường có thể được chọn ở đây.
  • Mã BIOS tải MBR của thiết bị khởi động vào RAM. Hãy nhớ rằng MBR chỉ là 512 byte! Tất nhiên, dữ liệu được tải là chương trình & dữ liệu mà grub-install tự động tạo và ghi ở đó khi chương trình cài đặt grub được thực thi.
  • Mã BIOS nhảy đến địa chỉ bắt đầu của MBR được tải (tức là mã Grub thực thi lần đầu tiên kể từ khi bật nguồn).
  • Mã MBR của Grub tải một khu vực duy nhất có địa chỉ được nối cứng vào khối MBR. Sau đó, nó lặp lại các cặp (địa chỉ, len) trong khu vực đó tải tất cả dữ liệu đó từ đĩa vào bộ nhớ (tức là tải nội dung của tệp /boot/grub/core.imghoặc bản sao nhúng nhúng của nó). Sau đó, mã MBR nhảy đến mã được tải, tức là thực thi chương trình trong chương trình core.img.
  • Như được mô tả trong phần Cài đặt Grub Cảnh, thủ thuật nhúng địa chỉ khối đĩa thô này cho phép lưu trữ core.imgtrong không gian không có trong phân vùng và chưa bao giờ được định dạng dưới dạng hệ thống tệp (cài đặt nhúng nhúng). Và trong trường hợp này, nếu core.imgđược sửa đổi, miễn là phiên bản mới được nhúng nhúng vào cùng một vị trí, mã MBR không cần phải cập nhật.
  • Ngoài ra, có core.imgthể bên trong một hệ thống tệp thực và Grub có thể đọc core.imgnội dung tệp mà không cần trình điều khiển cho hệ thống tệp đó. Tuy nhiên, trong trường hợp này, nếu core.imgđược sửa đổi thì khối đầu tiên của tệp cũng có thể được cung cấp một địa chỉ mới trên đĩa; nếu điều này xảy ra thì MBR phải được cập nhật để trỏ đến vị trí mới này. Tuy nhiên, như core.imgthường được cập nhật bằng cách chạy grub-install, đây thường không phải là vấn đề.
  • Lưu ý rằng về mặt lý thuyết, nếu core.imgtrên một thiết bị khác với MBR và phần cứng mới được thêm vào thì bản ghi MBR do Grub tạo ra có thể không thể tải core.imgtệp chính xác ; id thiết bị mà khu vực đầu tiên core.imgđược tìm thấy được kết nối cứng vào MBR, không được tìm kiếm. Tuy nhiên không có giải pháp cho việc này; không có cách nào để nhúng tương đương lệnh Grub tìm kiếm Grub vào MBR 512 byte. Vấn đề này không có khả năng mặc dù; thông thường, core.imgđược nhúng trên cùng một thiết bị với MBR. Và một khi core.imgđã được tải, nó có thể sử dụng search.mod để tìm tất cả /boot/grubcác tệp khác và do đó miễn dịch với các sắp xếp lại phần cứng.
  • core.imgMã được thực thi bây giờ khởi tạo tất cả các mô-đun được tích hợp vào nó (được liên kết vào core.img); một trong những mô-đun này sẽ là trình điều khiển hệ thống tập tin có khả năng đọc hệ thống tập tin mà thư mục /boot/grubsống.
  • Nó cũng đăng ký một tập hợp các lệnh tích hợp: set, unset, ls, insmod.
  • Nếu một tập tin cấu hình của người dùng, thì đã được liên kết vào core.img, tập tin này được chuyển đến một trình phân tích cú pháp tập lệnh tích hợp rất đơn giản để xử lý. Các lệnh script trong tệp cấu hình chỉ có thể gọi các lệnh tích hợp hoặc liên kết. Các kịch bản đơn giản (ví dụ khởi động máy tính để bàn thông thường từ ổ đĩa cục bộ) không cần tệp cấu hình; thiết bị này được sử dụng cho những việc như khởi động qua pxe, nfs từ xa hoặc khi /boot/grubở trên thiết bị LVM.
  • Core.imgbây giờ tải tập tin “/boot/grub/normal.mod”động từ đĩa và nhảy vào chức năng nhập của nó. Lưu ý rằng bước này yêu cầu trình điều khiển hệ thống tệp thích hợp được thiết lập (nghĩa là tích hợp sẵn).

     ss của quá trình khởi động

LƯU Ý: Khi bạn thấy menu GRUB2 điển hình nơi bạn chọn OS / Kernel nào để khởi động, bạn sẽ tham khảo /boot/grubthư mục của hệ thống tại thời điểm này.

                                         ss của grub tui

Người giới thiệu


Ai đó nên sửa mục wikipedia đó vì nó sai. Giai đoạn 1 / 1.5 / 2 chỉ được áp dụng cho di sản grub. Chúng đã được loại bỏ hoàn toàn trong phần viết lại của grub2 và bạn sẽ không tìm thấy bất kỳ tài liệu tham khảo nào về các điều khoản đó trong tài liệu chính thức của grub 2.
psusi

@psusi - cảm ơn đã làm rõ. Tôi đã có một chút bối rối khi tôi thấy họ cũng được đề cập ở đó, vì tôi cũng nghe như vậy, rằng 1 / 1.5 / 2 đã biến mất. Tôi sẽ không biết ai sẽ yêu cầu chỉnh sửa các bài viết trên Wikipedia, tôi sẽ không cảm thấy đủ điều kiện để chỉnh sửa một bài đăng như vậy. Có lẽ cảnh báo nhóm GRUB2 sẽ là điều tốt nhất tiếp theo?
slm

@psusi - đây là ref. đến giai đoạn bị loại bỏ. tài liệu cho GRUB2: gnu.org/software/grub/manual/grub.html ... "Các tệp hình ảnh (xem Hình ảnh) tạo nên GRUB đã được sắp xếp lại; Giai đoạn 1, Giai đoạn 1.5 và Giai đoạn 2 không còn nữa."
slm

6

Linux (kernel) không quan tâm bạn có bao nhiêu phân vùng khởi động. Tải hạt nhân từ đĩa là công việc của bộ nạp khởi động (ví dụ grub, grub2, lilo) và những công cụ này cũng không quan tâm đến số lượng các địa điểm một hạt nhân có thể được bố trí. Họ chỉ quan tâm đến vị trí cụ thể.

Ví dụ, phân vùng khởi động của tôi là /dev/md1gương RAID mdadm được hỗ trợ bởi các phân vùng vật lý /dev/sde1/dev/sdf1. Tôi có thể gắn kết chúng riêng lẻ nếu tôi muốn và vì thế về mặt kỹ thuật này được tính là có hai phân vùng khởi động, mặc dù chúng nên chứa cùng một dữ liệu.

Có hai phân vùng cho / boot đối với tôi là một vấn đề khả dụng, nhưng chúng có thể khác nhau / phân vùng khởi động. Bước tiếp theo là làm thế nào để bộ nạp khởi động biết? Đây là cách thực hiện:

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

Đây là một đoạn trích từ một grub2cấu hình và bạn sẽ lưu ý rằng sự khác biệt duy nhất là root=hd0,1root=hd1,1thiết lập phân vùng khởi động nào mà tham chiếu.


Bây giờ để đi bộ bạn mặc dù một khởi động để bạn có thể hiểu những gì đang xảy ra ở đây.

  • BIOS đọc MBR từ ổ đĩa khởi động và nhảy đến bộ tải khởi động
  • Bộ tải khởi động (ví dụ grub2) được cấu hình để biết thiết bị và phân vùng nào chứa kernel của bạn. Grub2 truy cập phân vùng này trực tiếp và tải kernel của bạn vào bộ nhớ.
  • Bộ tải khởi động của bạn sau đó nhảy vào kernel và kernel khởi động máy của bạn.

Bộ tải khởi động không quan tâm bạn có bao nhiêu phân vùng khởi động, nó chỉ quan tâm đến vị trí của chúng và bạn phải cho nó biết thông tin đó.

Hạt nhân không quan tâm bạn có bao nhiêu phân vùng khởi động, bởi vì nó không bao giờ cần phải xem chúng (bạn chỉ cần có sẵn nó để thêm hạt nhân mới chẳng hạn).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.