systemd-boot 부트로더 문제 해결
Ubuntu 20.04 사용중에 아마도 비교적 로우레벨로 시스템을 만진 CUDA version control 문제로 인해 추가적 패키지 설치 중에 시스템이 꼬여 GNOME이 제대로 런칭되지 않는 문제 발생. (이건 별도로 정리할 예정이나, 다른 것 없이 필요한 버전에 맞추어 CUDA toolkit runfile installer로 설치해준뒤 run command PATH 세팅 혹은 conda environ. variable로 설정해주는것이 최선인듯) 1년후 20.04 EOL이 다가오는 것에 대한 대응 겸 PopOS 22.04를 설치함, 그런데 윈도우쪽 SSD(SSD-1, 리눅스용은 SSD-2)에 있던 GRUB 부트로더가 맛이 가서 윈도우로 부팅이 불가해짐. 윈도우를 사용하지 않고 싶으나.. 공동인증서, 연구비 결제, Origin 등 어쩔 수 없는 부분이 있고 포맷 후 재설정하는 시간보다는 부트로더 복구가 더 빠를 것으로 판단. PopOS 재설치하며 GRUB이 깔려 있던 SSD-1의 부트 파티션을 지정하려고 했으나, 최근 EFI 부트 파티션의 권장용량이 1GB로 올랐다고 하며 이로 인해 400 MB 정도이던 기존 파티션에 설치가 불가. 이에 윈도우 시스템 파티션 뒤쪽을 2GB 줄여서 새로운 부트 파티션 지정, 기존 부트 파티션은 삭제. PopOS는 ArchLinux 등과 같이 좀 더 모던한 systemd-boot를 사용하여, 해당 새로운 부트 파티션에 윈도우 부트로더 정보를 복원시키기 위해 윈도우 설치 미디어를 사용하여 diskpart로 드라이브 인식하려 하였으나 윈도우 설치 파일이 담긴 USB 드라이브 외 인식이 되지 않음. 바이오스 초기화후에도 인식이 되지 않아 바이오스 펌워어 업데이트부터 하였는데, 30분 동안 완료가 되지 않아 벽돌이 된 줄 알고 식겁하였으나 다행히도 강제 리부팅후 업데이트 완료 및 정상 부팅. 그러나 드라이브 인식이 되지 않는 것은 여전하였고, 추가 검색 결과 모종의 이유로 Intel Rapid Storage Technology 드라이버가 필요하다는 사실을 알아냄. 메인보드 제조사에서 RST 드라이버 확보하여 윈도우 설치 화면에서 수동으로 드라이버 인식시켜 SSD-1, SSD-2 인식 성공. 이후 https://meroupatate.github.io/posts/bootloader/ 의 정보에 따라 diskpart에서 윈도우 시스템 파티션의 volume letter를 알아낸 뒤, bcdboot $volume$:\Windows 실행하여 systemd-boot에 윈도우 시스템에 대한 엔트리 생성. 이후 윈도우 부트로더 복구되었고 정상 부팅 가능하였으나, 선택 화면이 나오지 않음. 이는 PopOS 쪽에서 /boot/efi/loader/loader.conf에 timeout 10 변수 추가하여 해결.