ຄຳຖາມທີ່ພົບເລື້ອຍໆກ່ຽວກັບ Fedora CoreOS

Fedora CoreOS ແມ່ນລະບົບປະຕິບັດການທີ່ເນັ້ນໃສ່ຄອນເທນເນີ (container), ມີຂະໜາດນ້ອຍ, ເປັນແບບໂມໂນລິທິກ (monolithic), ແລະ ອັບເດດອັດຕະໂນມັດ. ມັນຖືກອອກແບບມາສຳລັບຄລັສເຕີ (cluster) ແຕ່ກໍສາມາດເຮັດວຽກແບບສະແຕນອາໂລນ (standalone) ໄດ້ເຊັ່ນກັນ, ປັບແຕ່ງມາໃຫ້ເໝາະສຳລັບ Kubernetes ແຕ່ກໍສາມາດໃຊ້ງານໄດ້ດີເຖິງວ່າບໍ່ມີມັນກໍຕາມ. ເປົ້າໝາຍຂອງມັນແມ່ນເພື່ອເປັນໂຮສ (host) ຂອງຄອນເທນເນີທີ່ດີທີ່ສຸດ ເພື່ອລັນວຽກຕ່າງໆໃນຄອນເທນເນີໄດ້ຢ່າງປອດໄພ ແລະ ຮອງຮັບການຂະຫຍາຍຕົວໄດ້.

Fedora CoreOS ແມ່ນລຸ້ນແຈກຢາຍຈາກຊຸມຊົນທີ່ສາມາດໃຊ້ງານໄດ້ຟຣີ ເຊິ່ງເປັນພື້ນຖານອັບສະຕຣີມ (upstream) ໃຫ້ກັບ RHEL CoreOS. ໃນຂະນະທີ່ Fedora CoreOS ຮອງຮັບການໃຊ້ງານຄອນເທນເນີທີ່ຫຼາກຫຼາຍ, ແຕ່ RHEL CoreOS ຈະເນັ້ນໃສ່ການເປັນລະບົບປະຕິບັດການສຳລັບ OpenShift ໂດຍສະເພາະ, ເຊິ່ງມີການປ່ອຍອອກມາ ແລະ ມີວົງຈອນຊີວິດການໃຊ້ງານໄປພ້ອມໆກັບແພລັດຟອມ.

Fedora Bootc ແມ່ນໂຄງການຂອງ Fedora ທີ່ມີເປົ້າໝາຍໃນການສ້າງ bootable containers ທີ່ອີງໃສ່ Fedora ແລະ CentOS. ເປົ້າໝາຍແມ່ນເພື່ອໃຫ້ Fedora CoreOS ສ້າງຂຶ້ນເທິງ Fedora Bootc ທັງໃນທາງເຕັກນິກ ແລະ ໃນຄວາມໝາຍກວ້າງໆຂອງການເປັນສ່ວນໜຶ່ງຂອງລະບົບນິເວດດຽວກັນ. ແຜນການ (roadmap) ສຳລັບເລື່ອງນີ້ສາມາດເບິ່ງໄດ້ ເທິງ GitHub.

Fedora CoreOS ໄດ້ເພີ່ມ ຮູບແບບສະຕຣີມ (stream model), ການເຊື່ອມຕໍ່ສະເພາະກັບແພລັດຟອມ ແລະ ໄຟລ໌ອິມເມຈຂອງດິສກ໌, ການຕັ້ງຄ່າຜ່ານ Ignition, ແລະ ເຄື່ອງມືເພີ່ມເຕີມກ່ຽວກັບການອັບເດດອັດຕະໂນມັດ. ເປົ້າໝາຍອີກຢ່າງໜຶ່ງແມ່ນເພື່ອໃຫ້ Fedora CoreOS ສາມາດເຮັດວຽກຮ່ວມກັບລະບົບນິເວດຂອງ Kubernetes ໄດ້ຢ່າງແໜ້ນແຟ້ນຍິ່ງຂຶ້ນ.

ຫາກທ່ານພົບວ່າຈຳເປັນຕ້ອງປັບແຕ່ງ Fedora CoreOS ຢ່າງຫຼວງຫຼາຍ ເກີນກວ່າທີ່ ສ່ວນຂະຫຍາຍ OS ມີໃຫ້, ມັນອາດຈະເໝາະສົມກວ່າທີ່ຈະໄປສ້າງເທິງ Fedora Bootc ໂດຍກົງ. ໃນອະນາຄົດຈະສາມາດວາງຊັ້ນ (layer) ຂອງ Ignition ແລະ ຕົວຢ່າງເຊັ່ນ Zincati ເທິງນັ້ນໄດ້ຫາກຕ້ອງການ. ເຄື່ອງມືເຫຼົ່ານີ້ຖືກອອກແບບມາເພື່ອໃຊ້ງານທົ່ວໄປ ແລະ ບໍ່ໄດ້ຜູກມັດກັບ Fedora CoreOS ພຽງຢ່າງດຽວ.

ພວກເຮົາມີຊ່ອງທາງການສື່ສານໃໝ່ກ່ຽວກັບ Fedora CoreOS ດັ່ງນີ້:

ມີການປະຊຸມຊຸມຊົນເກີດຂຶ້ນທຸກໆອາທິດ. ເບິ່ງ Fedora CoreOS fedocal ສຳລັບຂໍ້ມູນທີ່ທັນສະໄໝທີ່ສຸດ.

ຫາກທ່ານຄິດວ່າທ່ານພົບກັບບັນຫາໃນ Fedora CoreOS, ສາມາດແຈ້ງບັນຫາໄດ້ທີ່ ລະບົບຕິດຕາມບັນຫາ ຂອງພວກເຮົາ.

ໄຟລ໌ຕ່າງໆຂອງ Fedora CoreOS ແມ່ນມີໃຫ້ຢູ່ທີ່ fedoraproject.org.

ແມ່ນແລ້ວ, Fedora CoreOS ມາພ້ອມກັບການອັບເດດອັດຕະໂນມັດ ແລະ ການປ່ອຍເວີຊັນໃໝ່ຢ່າງສະໝ່ຳສະເໝີ. ມີຊ່ອງທາງການອັບເດດທີ່ຫຼາກຫຼາຍເພື່ອຕອບສະໜອງຄວາມຕ້ອງການຂອງຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນ. Fedora CoreOS ໃຫ້ບໍລິການອັບເດດໂນດ (node-update) ໂດຍອີງໃສ່ເຕັກໂນໂລຊີ rpm-ostree, ເຊິ່ງມີສ່ວນປະກອບຂອງເຊີເວີທີ່ສາມາດເລືອກໂຮສດ້ວຍຕົນເອງໄດ້ (self-hosted).

Fedora CoreOS ຖືກຈັດກຽມດ້ວຍ Ignition. ການຕັ້ງຄ່າ cloud-init ທີ່ມີຢູ່ແລ້ວແມ່ນບໍ່ຮອງຮັບ ແລະ ຈະຕ້ອງໄດ້ປ່ຽນໄປເປັນຮູບແບບ Ignition ທີ່ທຽບເທົ່າກັນ.

ໄດເຣັກທໍຣີ /etc ແລະ /var ຖືກເມົາທ໌ (mounted) ເປັນແບບອ່ານ-ຂຽນ (read-write) ເຊິ່ງຊ່ວຍໃຫ້ຜູ້ໃຊ້ສາມາດຂຽນ ແລະ ແກ້ໄຂໄຟລ໌ໄດ້.

ໄດເຣັກທໍຣີ /etc ອາດຈະຖືກປ່ຽນແປງໂດຍການດີພລອຍ (deployments), ແຕ່ຈະບໍ່ຂຽນທັບການປ່ຽນແປງທີ່ຜູ້ໃຊ້ສ້າງຂຶ້ນ. ເນື້ອໃນພາຍໃຕ້ /var ຈະບໍ່ຖືກແຕະຕ້ອງໂດຍ rpm-ostree ເມື່ອມີການອັບເກຣດ ຫຼື ໂຣແບັກ (rollbacks). ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ, ກະລຸນາເບິ່ງທີ່ພາກ Mounted Filesystems.

Fedora CoreOS ລວມມີ Docker ແລະ podman ມາໃຫ້ໂດຍເລີ່ມຕົ້ນ. ລາຍຊື່ນີ້ອາດຈະປ່ຽນແປງໄປຕາມເວລາໂດຍອີງໃສ່ການມີສ່ວນຮ່ວມ ແລະ ການສະໜັບສະໜູນຂອງຊຸມຊົນ.

ໄດ້. ແນວໃດກໍຕາມ, Fedora CoreOS ບໍ່ໄດ້ລວມເອົາຕົວຈັດການຄອນເທນເນີ (container orchestrator) ຫຼື ເວີຊັນຂອງ Kubernetes ໃດໜຶ່ງມາໃຫ້ໂດຍສະເພາະຕັ້ງແຕ່ເລີ່ມຕົ້ນ.

ໃນ Fedora CoreOS, ຄອນເທນເນີແມ່ນວິທີການໃນການຕິດຕັ້ງ ແລະ ຕັ້ງຄ່າຊອບແວຕ່າງໆທີ່ບໍ່ໄດ້ມາພ້ອມກັບລະບົບປະຕິບັດການພື້ນຖານ. ກົນໄກການວາງຊັ້ນແພັກເກັດ (package layering) ທີ່ໃຫ້ໂດຍ rpm-ostree ຈະຍັງຄົງມີຢູ່ເພື່ອໃຊ້ໃນການແກ້ໄຂບັນຫາ (debugging) ເທິງເຄື່ອງ Fedora CoreOS, ແຕ່ພວກເຮົາຂໍແນະນຳຢ່າງຍິ່ງວ່າບໍ່ໃຫ້ໃຊ້ວີທີນີ້. ສຳລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້, ກະລຸນາເບິ່ງທີ່ ເອກະສານປະກອບ.

ອິມເມຈຂອງ FCOS ຖືກອອກແບບມາໃຫ້ມີຂະໜາດນ້ອຍທີ່ສຸດ. ບໍ່ແມ່ນທຸກເຄື່ອງມືແກ້ໄຂບັນຫາຈະຖືກລວມມາໃຫ້ໂດຍເລີ່ມຕົ້ນ. ແທນທີ່ຈະເປັນແນວນັ້ນ, ຂໍແນະນຳໃຫ້ໃຊ້ເຄື່ອງມື toolbox.

ການແກ້ໄຂບັນຫາດ້ວຍ Toolbx.

ຕົວຈັດການການອັບເດດ Zincati ລວມມີ ຍຸດທະສາດການອັບເດດແບບໃຊ້ການລັອກ (lock-based updates strategy) ເຊິ່ງຮອງຮັບແບັກເອນ (backends) ທີ່ຫຼາກຫຼາຍ.

Machine Config Operator (MCO) ຂອງ OKD ຈະຈັດການການອັບເດດຂອງ Fedora CoreOS ໃນຄລັສເຕີ OKD ໂດຍອັດຕະໂນມັດ. ນອກຈາກນັ້ນ MCO ຍັງຄວບຄຸມການປັບປ່ຽນການຕັ້ງຄ່າຂອງເຄື່ອງໃຫ້ກົງກັນ (reconciliation) ອີກດ້ວຍ.

ໃນປັດຈຸບັນ Fedora CoreOS ຖືກອັບໂຫຼດໄປຍັງ AWS ຣີຈຽນມາດຕະຖານເທົ່ານັ້ນ. ສຳລັບຣີຈຽນໃນສ່ວນອື່ນໆຂອງ AWS ເຊັ່ນ GovCloud ແລະ AWS China, ທ່ານຈະຕ້ອງອັບໂຫຼດອິມເມຈດ້ວຍຕົນເອງ.

ສັງເກດວ່າ Fedora CoreOS ໃຊ້ການວາງພາກສ່ວນ (partition layout) ແບບ BIOS/UEFI ທີ່ລວມເຂົ້າກັນ. ດ້ວຍເຫດນີ້, ມັນຈຶ່ງບໍ່ສາມາດໃຊ້ງານຮ່ວມກັບ aws ec2 import-image API ໄດ້ (ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ, ເບິ່ງ ການສົນທະນາທີ່ກ່ຽວຂ້ອງ). ແທນທີ່ຈະເປັນແນວນັ້ນ, ທ່ານຕ້ອງໃຊ້ aws ec2 import-snapshot ຮ່ວມກັບ aws ec2 register-image.

ເພື່ອຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບ API ເຫຼົ່ານີ້, ເບິ່ງເອກະສານຂອງ AWS ສຳລັບ ການນຳເຂົ້າສະແນັບຊອດ (importing snapshots) ແລະ ການສ້າງ EBS-backed AMIs.

ບໍ່ໄດ້. ການລັນຄອນເທນເນີຜ່ານ docker ແລະ podman ໃນເວລາດຽວກັນອາດເຮັດໃຫ້ເກີດບັນຫາ ແລະ ພຶດຕິກຳທີ່ບໍ່ຄາດຄິດ. ພວກເຮົາຂໍແນະນຳຢ່າງຍິ່ງວ່າບໍ່ໃຫ້ພະຍາຍາມໃຊ້ທັງສອງຢ່າງພ້ອມກັນ.

ສິ່ງທີ່ຄວນສັງເກດຄື ໃນ Fedora CoreOS ພວກເຮົາໄດ້ປິດ (disabled) docker.service ໄວ້ໂດຍເລີ່ມຕົ້ນ ແຕ່ມັນສາມາດເລີ່ມເຮັດວຽກໄດ້ງ່າຍຫາກມີການສື່ສານກັບ /var/run/docker.sock ເນື່ອງຈາກ docker.socket ຖືກເປີດ (enabled) ໄວ້ໂດຍເລີ່ມຕົ້ນ. ນີ້ໝາຍຄວາມວ່າຫາກຜູ້ໃຊ້ລັນຄຳສັ່ງ docker ໃດໜຶ່ງ (ຜ່ານ sudo docker) ຕົວເດມອນ (daemon) ກໍຈະຖືກເປີດໃຊ້ງານ.

ໃນ coreos/fedora-coreos-tracker#408 ໄດ້ມີການລະບຸວ່າ ຍ້ອນການເປີດໃຊ້ງານຜ່ານຊັອກເກັດ (socket activation), ຜູ້ໃຊ້ທີ່ໃຊ້ podman ສຳລັບຄອນເທນເນີອາດຈະໄປເປີດໃຊ້ງານ docker daemon ໂດຍບໍ່ໄດ້ຕັ້ງໃຈ. ນີ້ອາດເຮັດໃຫ້ຄວາມປອດໄພຂອງລະບົບຫຼຸດລົງຍ້ອນການເຮັດວຽກຮ່ວມກັນຂອງທັງສອງຄອນເທນເນີຣັນໄທມ໌ກັບໄຟວໍ (firewall) ເທິງລະບົບ. ເພື່ອປ້ອງກັນຄວາມຜິດພາດນີ້, ທ່ານສາມາດປິດການໃຊ້ງານ docker ຢ່າງຖາວອນໂດຍການເຮັດ mask ໃຫ້ກັບຢູນິດ systemd ຂອງ docker.service.

ອິມເມຈ x86_64 ທີ່ພວກເຮົາມີໃຫ້ ສາມາດໃຊ້ໄດ້ທັງການບູດແບບ BIOS (legacy) ຫຼື ການບູດແບບ UEFI. ພວກມັນມີການຕັ້ງຄ່າພາກສ່ວນແບບໄຮບຣິດ BIOS/UEFI ທີ່ຊ່ວຍໃຫ້ໃຊ້ໄດ້ທັງສອງແບບ. ຂໍ້ຍົກເວັ້ນຄືອິມເມຈແບບ metal4k 4k native, ເຊິ່ງເປົ້າໝາຍແມ່ນໃຊ້ກັບດິສກ໌ທີ່ມີເຊັກເຕີ (sectors) ແບບ 4k ແລະ ບໍ່ມີພາກສ່ວນບູດ BIOS ເນື່ອງຈາກດິສກ໌ແບບ 4k native ແມ່ນ ຮອງຮັບສະເພາະກັບ UEFI ເທົ່ານັ້ນ.

ການຕັ້ງຄ່າ Ignition ແມ່ນອິນເຕີເຟດລະດັບຕ່ຳ (low-level interface) ທີ່ໃຊ້ເພື່ອ ກຳນົດຊຸດການປັບແຕ່ງທັງໝົດສຳລັບອິນສະແຕນຊ໌ (instance). ໂດຍຫຼັກແລ້ວມັນຖືກອອກແບບມາໃຫ້ເປັນອິນເຕີເຟດທີ່ເຄື່ອງອ່ານໄດ້ (machine-friendly), ໂດຍມີເນື້ອໃນທີ່ເຂົ້າລະຫັດເປັນ JSON ແລະ ມີໂຄງສ້າງທີ່ແນ່ນອນເຊິ່ງກຳນົດຜ່ານ JSON Schema. ການຕັ້ງຄ່າ JSON ນີ້ຈະຖືກປະມວນຜົນໂດຍແຕ່ລະອິນສະແຕນຊ໌ຂອງ FCOS ເມື່ອມີການບູດເຄື່ອງຄັ້ງທຳອິດ.

ມີເຄື່ອງມືລະດັບສູງຫຼາຍຢ່າງທີ່ສາມາດສ້າງການຕັ້ງຄ່າ Ignition ໄດ້ໂດຍເລີ່ມຈາກຮູບແບບຂໍ້ມູນນຳເຂົ້າສະເພາະຂອງພວກມັນເອງ ເຊັ່ນ terraform, matchbox, openshift-installer, ແລະ Butane.

Butane ແມ່ນໜຶ່ງໃນເຄື່ອງມືລະດັບສູງດັ່ງກ່າວ. ໂດຍຫຼັກແລ້ວມັນຖືກອອກແບບມາໃຫ້ເປັນອິນເຕີເຟດທີ່ມະນຸດອ່ານໄດ້ງ່າຍ (human-friendly), ຈຶ່ງມີການກຳນົດລາຍການການຕັ້ງຄ່າທີ່ຫຼາກຫຼາຍກວ່າ ແລະ ໃຊ້ເອກະສານ YAML ເປັນຂໍ້ມູນນຳເຂົ້າ. ການຕັ້ງຄ່າ YAML ນີ້ຈະບໍ່ຖືກປະມວນຜົນໂດຍກົງໂດຍອິນສະແຕນຊ໌ຂອງ FCOS (ຈະມີພຽງການຕັ້ງຄ່າ Ignition ທີ່ໄດ້ຈາກການແປງເທົ່ານັ້ນທີ່ຈະຖືກໃຊ້).

ເຖິງວ່າມັນຈະຄ້າຍຄືກັນ, ແຕ່ການຕັ້ງຄ່າ Ignition ແລະ Butane ບໍ່ໄດ້ມີໂຄງສ້າງອັນດຽວກັນ; ດັ່ງນັ້ນ, ການແປງລະຫວ່າງພວກມັນຈຶ່ງບໍ່ແມ່ນພຽງແຕ່ການແປງຈາກ YAML ເປັນ JSON ໂດຍກົງເທົ່ານັ້ນ, ແຕ່ມັນຍັງກ່ຽວຂ້ອງກັບລໍຈິກ (logic) ເພີ່ມເຕີມ. Butane ຍັງມີຕົວຊ່ວຍໃນການປັບແຕ່ງຫຼາຍຢ່າງ (ຕົວຢ່າງ: ລາຍການສະເພາະຂອງການແຈກຢາຍ ແລະ ສ່ວນທີ່ຍໍ້ໃຫ້ເຂົ້າໃຈງ່າຍ) ເຊິ່ງບໍ່ມີຢູ່ໃນ Ignition ແລະ ເຮັດໃຫ້ຮູບແບບທັງສອງບໍ່ສາມາດໃຊ້ແທນກັນໄດ້. ນອກຈາກນັ້ນ, ຮູບແບບທີ່ແຕກຕ່າງກັນ (YAML ສຳລັບ Butane, JSON ສຳລັບ Ignition) ຍັງຊ່ວຍປ້ອງກັນການປົນເປຂໍ້ມູນນຳເຂົ້າໂດຍຄວາມຜິດພາດນຳອີກ.

ເລື່ອງນີ້ມີລາຍລະອຽດຢູ່ໃນ ເອກະສານການອອກແບບ.

ໂດຍສະຫຼຸບແລ້ວ Fedora CoreOS ໃຊ້ຮູບແບບ X.Y.Z.A

ລະບົບການຕັ້ງໝາຍເລກເວີຊັນອາດຈະມີການປ່ຽນແປງ ແລະ ບໍ່ໄດ້ມີໄວ້ເພື່ອໃຫ້ເຄື່ອງຈັກປະມວນຜົນ (parse).

ພວກເຮົາພົບວ່າໄຟລ໌ dnsmasq ສາມາດຖືກນຳໃຊ້ສຳລັບແອັບພລິເຄຊັນເທິງໂຮສໄດ້ຫຼາຍຢ່າງ, ລວມທັງ podman ແລະ NetworkManager. ດ້ວຍເຫດນີ້ພວກເຮົາຈຶ່ງລວມເອົາແພັກເກັດ dnsmasq ໄວ້ໃນຊັ້ນພື້ນຖານຂອງ OSTree, ແຕ່ພວກເຮົາບໍ່ແນະນຳໃຫ້ໃຊ້ dnsmasq.service ເທິງໂຮສໂດຍການ mask ມັນດ້ວຍ systemctl mask dnsmasq.service.

"ເປັນຫຍັງທ່ານຈຶ່ງ mask ເຊີວິດນີ້ໄວ້?"

dnsmasq ມີປະໂຫຍດໃນການລັນເຊີເວີ DHCP/DNS/TFTP ສຳລັບໄຄລເອັນ (clients) ພາຍນອກ (ເຊັ່ນ: ບໍ່ແມ່ນພາຍໃນໂຮສ) ເຊັ່ນກັນ, ແຕ່ສິ່ງນັ້ນແມ່ນພວກເຮົາຢາກໃຫ້ຜູ້ໃຊ້ເຮັດໃນຄອນເທນເນີຫຼາຍກວ່າ. ການໃສ່ເຊີວິດໄວ້ໃນຄອນເທນເນີຈະຊ່ວຍແຍກເຊີວິດທີ່ໃຫ້ບໍລິການນັ້ນອອກຈາກຄວາມເສຍຫາຍທີ່ອາດເກີດຈາກການປ່ຽນແປງໃນຊັ້ນຂອງໂຮສ. ຕົວຢ່າງ: ຫາກ NetworkManager ແລະ podman ເຊົາໃຊ້ dnsmasq, ພວກເຮົາກໍຈະເອົາມັນອອກຈາກໂຮສ ແລະ ເຊີວິດທີ່ທ່ານຕ້ອງໃຊ້ງານຢູ່ນັ້ນກໍຈະຢຸດເຮັດວຽກ.

"ແຕ່, ຂ້ອຍຢາກໃຊ້ງານມັນແທ້ໆ!"

ພວກເຮົາບໍ່ແນະນຳ, ແຕ່ຫາກທ່ານຕ້ອງການໃຊ້ງານມັນແທ້ໆ ທ່ານກໍສາມາດ unmask ແລະ ເປີດໃຊ້ງານມັນໄດ້:

ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ ເບິ່ງໄດ້ທີ່ ການສົນທະນາໃນລະບົບຕິດຕາມບັນຫາ.

systemd-repart ແມ່ນເຄື່ອງມືເພື່ອຂະຫຍາຍ ແລະ ເພີ່ມພາກສ່ວນ (partitions) ໃຫ້ກັບຕາຕະລາງພາກສ່ວນ. ໃນ Fedora CoreOS, ພວກເຮົາຮອງຮັບພຽງແຕ່ການໃຊ້ Ignition ເພື່ອສ້າງພາກສ່ວນ, ລະບົບໄຟລ໌ (filesystems) ແລະ ຈຸດເມົາທ໌ (mount points) ເທົ່ານັ້ນ, ດັ່ງນັ້ນ systemd-repart ຈຶ່ງຖືກ mask ໄວ້ໂດຍເລີ່ມຕົ້ນ.

Ignition ຈະເຮັດວຽກໃນຕອນບູດຄັ້ງທຳອິດໃນ initramfs ແລະ ຮັບຮູ້ໂຄງສ້າງດິສກ໌ສະເພາະຂອງ Fedora CoreOS. ມັນຍັງສາມາດກຳນົດຄ່າລະບົບໄຟລ໌ຣາກ (root filesystem) ໃໝ່ (ຕົວຢ່າງ: ຈາກ xfs ເປັນ ext4), ການຕັ້ງຄ່າ LUKS, ແລະ ອື່ນໆ…​ ເບິ່ງໜ້າ Configuring Storage ສຳລັບຕົວຢ່າງຕ່າງໆ.

ເບິ່ງຫົວຂໍ້ ເປັນຫຍັງຢູນິດ systemd dnsmasq.service ຈຶ່ງຖືກ mask ໄວ້ ສຳລັບຕົວຢ່າງການຕັ້ງຄ່າເພື່ອ unmask ຢູນິດນີ້.

ເຟີມແວ Wi-Fi ບາງຢ່າງຖືກແຍກອອກເປັນແພັກເກັດຍ່ອຍໃນ Fedora 39 ແລະ Fedora 40. Fedora CoreOS ຈະຍັງຄົງຮັກສາມັນໄວ້ຈົນກວ່າຈະຮອດ Fedora 41, ແຕ່ຈະສະແດງຂໍ້ຄວາມເຕືອນໃນຄອນໂຊນ (console) ຫາກ NetworkManager-wifi ຖືກວາງຊັ້ນໄວ້ໂດຍບໍ່ມີແພັກເກັດເຟີມແວ Wi-Fi ອື່ນໆວາງຊັ້ນຢູ່ນຳ.

ເພື່ອຮ້ອງຂໍໃຫ້ເຟີມແວ Wi-Fi ຍັງຄົງຖືກຕິດຕັ້ງໄວ້ເຖິງວ່າ Fedora CoreOS ຈະຕັດແພັກເກັດເຫຼົ່ານີ້ອອກໄປແລ້ວ, ກະລຸນາປະຕິບັດຕາມ ຂັ້ນຕອນການເປີດໃຊ້ Wi-Fi ໃນລະບົບທີ່ມີຢູ່.

ເມື່ອມີການຮ້ອງຂໍແພັກເກັດແລ້ວ, ທ່ານສາມາດປິດການແຈ້ງເຕືອນເພື່ອບໍ່ໃຫ້ມັນກວດສອບໃນການບູດຄັ້ງຕໍ່ໆໄປ.