CentOS 설치 프로그램의 자동 파티셔닝을 사용하여 파티셔닝과 RAID 1 구성이 완료된 CentOS 8을 설치했습니다. 출력은 다음과 같습니다 lsblk
.
sda 8:0 0 558.9G 0 disk
├─sda1 8:1 0 50G 0 part
│ └─md127 9:127 0 50G 0 raid1 /
├─sda2 8:2 0 20G 0 part
│ └─md126 9:126 0 20G 0 raid1 [SWAP]
├─sda3 8:3 0 1G 0 part
│ └─md125 9:125 0 1022M 0 raid1 /boot
├─sda4 8:4 0 600M 0 part
│ └─md124 9:124 0 600M 0 raid1 /boot/efi
└─sda5 8:5 0 487.3G 0 part
└─md123 9:123 0 487.2G 0 raid1 /home
sdb 8:16 0 558.9G 0 disk
├─sdb1 8:17 0 50G 0 part
│ └─md127 9:127 0 50G 0 raid1 /
├─sdb2 8:18 0 20G 0 part
│ └─md126 9:126 0 20G 0 raid1 [SWAP]
├─sdb3 8:19 0 1G 0 part
│ └─md125 9:125 0 1022M 0 raid1 /boot
├─sdb4 8:20 0 600M 0 part
│ └─md124 9:124 0 600M 0 raid1 /boot/efi
└─sdb5 8:21 0 487.3G 0 part
└─md123 9:123 0 487.2G 0 raid1 /home
보시다시피 /boot/efi 파티션은 다른 파티션과 마찬가지로 RAID 1에 미러링됩니다. 이제 데비안을 설치할 때 동일한 설정을 다시 만들려고 했지만 계속할 수 없습니다. 이런 방식으로 파티셔닝과 RAID 1을 설정하면 grub 설치 중에 설치 프로그램에서 실패 메시지가 표시됩니다(다른 오류 메시지는 없고 일반적인 "일부 설치 단계 실패" 메시지만 표시됨).
스크린샷:
ESP 파티션을 미러링하지 않으면 오류가 사라집니다.
나는 ESP 파티션을 미러링하는 것이 실현 가능하지 않다는 것을 알고 있으며 주위를 둘러보면 모두가 동의하는 것 같습니다. 그러나 CentOS 설치 프로그램은 어떻게든 이 작업을 수행합니다.
데비안에서 동일한 설정을 다시 생성하려면 어떻게 해야 합니까?
답변1
@cas의 의견 덕분에 제대로 작동하게 되었습니다.
주요 단계는 다음과 같습니다.
- Debian을 설치했지만 ESP 파티션에 대한 RAID를 설정하지 않았습니다. 파티셔닝 프로세스 중에 ESP 파티션이라는 라벨이 붙은 두 개의 동일한 파티션을 만들었습니다. 각각 위치하고
/dev/sda1
있어요/dev/sdb1
/boot/efi
다른 곳에서 내용을 복사했습니다(/boot/eficopy
).umount /boot/efi
mdadm --create --verbose /dev/md3 --level=1 --raid-devices=2 --metadata=1.0 /dev/sda1 /dev/sdb1
. 물론, 이미 활성화된 MD 기기라면/dev/md3
다른 기기로 변경하세요./dev/md3
mkfs.vfat /dev/md3
- 파티션의 UUID 찾기
/dev/disk/by-uuid
- 새로운 UUID로
/boot/efi
항목 변경/etc/fstab
mount /boot/efi
- 백업에서 데이터를
/boot/efi
다시 복사하세요.
재시작에 성공했습니다.
편집하다: 백업 파티션 대신에 /boot/efi
,
grub-install --efi-directory=/boot/efi
내용을 복원하는 작업(위의 9단계)을 수행했지만 이해할 수 없는 경고가 많이 표시되었습니다.
편집 2: Wiki 페이지에 따르면 사람들은 아마도 0.9 대신 메타데이터 버전 1.0을 사용하는 것을 고려해야 할 것입니다.mdadm 가이드.
버전 1.0에서는 (이 사용 사례의 경우) 슈퍼블록이 장치 끝에 배치되어야 하지만 1.1 및 1.2와 같은 일반적인 레이아웃 형식을 사용하는 "mdadm의 최신 기능"도 포함되어 있습니다.
답변2
수많은 문제를 겪은 후GIGABYTE의 솔루션, 나는 포기하고 완전히 다른 솔루션을 발명했습니다.
질문:
- 파일 시스템을 정렬해야 합니다.
- fsck.msdos는 실제로 SSD의 FAT에 실패한 쓰기를 처리하지 않습니다(쓰기 프로세스 중 전원 손실로 인해).
- mdraid1.0 트릭은 쓰기 의도를 사용하지 않는 경우에만 작동하는 것처럼 보이지만 이는 나쁜 생각입니다.
- Linux 커널은 순서화된 쓰기를 인식하지 못합니다. /boot/efi에 쓰면 도중에 전원이 꺼지면 부팅이 비활성화될 수 있습니다. 안타깝게도 DOS 커널이 (우연히) 이 작업을 올바르게 수행했습니다.
마지막 문제에 대한 나의 해결책은 결국 실제 미러를 버리고 업그레이드 후 알려진 양호한 상태에서 동기화된 EFI의 백업 복사본이 있는 두 번째 SSD를 유지하는 것이었습니다. 다양한 부분에서 완전한 솔루션을 조립했습니다.
16비트 어셈블리에 필요한 도구만 있으므로 이 솔루션은 보기만큼 이상합니다. 더 나은 도구가 없다는 점을 후회하지만 솔직히 stackexchange에서 명성을 얻기 위해 이러한 도구를 x64로 이식하지는 않을 것입니다. 어쨌든, 오래된 DOS 게임을 보관하려면 16비트 도구가 필요합니다. 우리가 여기서 하고 있는 일은 FreeDOS가 최신 시스템에서 유지 관리 작업을 수행하는 것입니다. 이는 흥미롭기도 하고 무섭기도 합니다.
필요할 것이예요:
(Dosbox-x는 SDL 콘솔이 있는 경우에도 작동하지만 SHUTDOWN.EXE도 필요합니다.)
FreeDOS(실제로 8086tiny에 포함되어 있으므로 더 이상 패키지가 없음)
내 거SSDFMT, 실제로 정렬된 파일 시스템을 내보냅니다.
내 것
flushbuf
, 내가 사용할 수 없는 에뮬레이터가 실제로 디스크에 강제로 쓰기 때문입니다. 이를 위해 8086tiny를 쉽게 패치할 수 있지만 이는 임시방편입니다.flushbuf
그 주장을 공개하고fdatasync
그것에 호소하십시오.
begin-base64 755 /boot/flushbuf
f0VMRgIBAQMAAAAAAAAAAAIAPgABAAAAeAAgAAAAAABAAAAAAAAAAHgAAAAA
AAAAAAAAAEAAOAABAAAAAAAAAAEAAAAFAAAAAAAAAAAAAAAAACAAAAAAAAAA
AAAAAAAA/gAAAAAAAAD+AAAAAAAAAAAQAAAAAAAAWEiD+AJ1QV9fSDH2uAIA
AAAPBUiFwHwJSJe4SwAAAA8F99h0G1C/AgAAAEiNNCX3ACAAugcAAAC4AQAA
AA8FWJe4PAAAAA8FvwIAAABIjTQl4AAgALoXAAAAuAEAAAAPBb8OAAAA69lV
c2FnZTogZmx1c2hidWYgZGV2aWNlCkVycm9yIQo=
====
(예, 이것은 완전한 Linux x64 바이너리입니다.)
- 문제 발생 시 이동식 미디어를 부팅하는 기능.
구성
이 답변은 /dev/sda1
및 장치를 사용하여 /dev/sda2
작성 되었습니다. /dev/sda
중화제의 정체 /dev/sdb
가 안정적인 시스템이 없다면 ,~ 해야 하다대신 가치를 사용하세요 /dev/disk/by-id/...
. /dev/disk/by-uuid
불가능한. 나를 믿어. 또한 /dev/disk/by-id/...
장치에 입력할 때마다 약이 투여되므로 모든 것을 스크립트로 작성해야 합니다 . 스크립트를 저장하기 위해 제가 찾은 가장 좋은 장소는 입니다 /boot
.
SSDFMT.COM을 8086tiny에 로드합니다
fd.img
(mtools
또는mount -o loop
다음을 사용할 수 있습니다).루트가 그러하듯이
(cd /boot/efi && tar -zcf /boot/efi-bak.tgz *)
umount /boot/efi
STTY_SAVE=`stty -g`
stty cols 80 rows 25
./8086tiny bios.bin fd.img hd.img
SSDFMT
SSDFMT에서 SSD의 실제 섹터 크기인 디스크 1(유일하게 보이는 디스크)을 선택한 다음 호환성 5를 선택합니다. 강제 LBA는 8086tiny에는 적용되지 않습니다.
앞으로 웨지 콘솔을 방지하려면 하드 드라이브에 FreeDOS를 설치해야 합니다.
QUITEMU
./8086tiny bios.bin fd.img hd.img
SYS C:
XCOPY /e *.* C:\
QUITEMU
/boot/flushbuf /dev/sda1
stty `$STTY_SAVE`
- 이렇게 하면 설치되지만
CONFIG.SYS
여전히AUTOEXEC.BAT
플로피 디스크의 파일을 가리킵니다. 이 문제를 해결해 봅시다.
mount /boot/efi
sed -i 's/A:\\/C:\\/g' /boot/efi/CONFIG.SYS
sed -i 's/A:\\/C:\\/g' /boot/efi/AUTOEXEC.BAT
- 이제 EFI를 복원할 시간입니다.
(cd /boot/efi && tar -zxf /boot/efi-bak.tgz)
- 업그레이드 및 재부팅 후 미러를 동기화하는 스크립트 생성(부팅이 정상인지 확인하기 위해)
#!/bin/sh -x
umount /boot/efi
/boot/flushbuf /dev/sda1 # replace sda1 and sdb1 with your devices
cat /dev/sda1 > /dev/sdb1
/boot/flushbuf /dev/sdb1
mount /boot/efi
- 역방향 스크립트 생성(파일 시스템을 복구할 수 없는 경우)
#!/bin/sh -x
[ -d /boot/efi/EFI ] && umount /boot/efi # probably won't be mounted
/boot/flushbuf /dev/sda2 # replace sda1 and sdb1 with your devices
cat /dev/sdb1 > /dev/sda1
/boot/flushbuf /dev/sda1
mount /boot/efi
- 7단계에서 제공된 스크립트를 실행합니다.
두 번째 디스크는 EFI 디스크로 부팅하기 위해 아직 완전히 등록되지 않았습니다. 내 운영 체제가 아닌 BIOS 설정에서 이 문제를 해결했다고 확신합니다.
시작 시 오류가 발견 되면 fsck.msdos
이를 수정하지 못할 수도 있습니다. 심각한 오류가 발견되면 SSDFMT의 Tear Write Fix를 먼저 실행해야 합니다. 어떻게? 에뮬레이터에서 EFI 파티션(!)을 부팅합니다.
실행 프로그램 스크립트는 다음과 같이 저장되어야 합니다.
#!/bin/sh -x
umount /boot/efi # making sure
./8086tiny bios.bin /dev/null @/dev/sda1
fsck.msdos /dev/sda1
/boot/flushbuf /dev/sda1
mount /boot/efi
이 스크립트를 실행하면 손상된 쓰기 확인/복구 프로세스를 수행한 후 DOS 프롬프트가 표시됩니다. QUITEMU를 실행하여 돌아올 수 있습니다. 나는 CHDKSK
에뮬레이터에서 실행할지 여부에 대해 솔직한 의견 차이가 있다고 확신합니다 . 경험이 부족해서 어느 것이 더 나은지 알 수 없습니다.
보너스: 주요 데비안 업데이트 후에 EFI 파티션 조각 모음을 하면 부팅 속도가 훨씬 빨라진다는 사실을 발견했습니다. (제가 아는 한 이는 부팅 로고 때문입니다.) DEFRAG.EXE를 grep할 수 있습니다.서지EFI 파티션에 복사하고 나중에 실행하세요.