Linux ມີຫຼາຍໃບຫນ້າ: ວິທີການເຮັດວຽກກ່ຽວກັບການແຈກຢາຍໃດໆ

ການສ້າງແອັບພລິເຄຊັນສໍາຮອງທີ່ເຮັດວຽກກ່ຽວກັບການແຈກຢາຍໃດໆບໍ່ແມ່ນວຽກງ່າຍ. ເພື່ອຮັບປະກັນ Veeam Agent ສໍາລັບ Linux ເຮັດວຽກກ່ຽວກັບການແຈກຢາຍຈາກ Red Hat 6 ແລະ Debian 6, ໄປຫາ OpenSUSE 15.1 ແລະ Ubuntu 19.04, ທ່ານຕ້ອງແກ້ໄຂບັນຫາຕ່າງໆ, ໂດຍສະເພາະແມ່ນການພິຈາລະນາວ່າຜະລິດຕະພັນຊອບແວປະກອບມີໂມດູນ kernel.

ບົດ​ຄວາມ​ໄດ້​ຖືກ​ສ້າງ​ຂຶ້ນ​ໂດຍ​ອີງ​ໃສ່​ເອ​ກະ​ສານ​ຈາກ​ຄໍາ​ປາ​ໄສ​ໃນ​ກອງ​ປະ​ຊຸມ Linux Peter 2019.

Linux ບໍ່ແມ່ນພຽງແຕ່ຫນຶ່ງໃນລະບົບປະຕິບັດການທີ່ນິຍົມຫຼາຍທີ່ສຸດ. ໂດຍພື້ນຖານແລ້ວ, ນີ້ແມ່ນເວທີບົນພື້ນຖານທີ່ທ່ານສາມາດສ້າງສິ່ງທີ່ເປັນເອກະລັກ, ບາງສິ່ງບາງຢ່າງຂອງທ່ານເອງ. ຂໍຂອບໃຈກັບນີ້, Linux ມີການແຜ່ກະຈາຍຈໍານວນຫຼາຍທີ່ແຕກຕ່າງກັນໃນຊຸດຂອງອົງປະກອບຊອບແວຂອງເຂົາເຈົ້າ. ແລະບັນຫານີ້ເກີດຂື້ນ: ເພື່ອໃຫ້ຜະລິດຕະພັນຊອບແວເຮັດວຽກກ່ຽວກັບການແຈກຢາຍໃດໆ, ທ່ານຕ້ອງຄໍານຶງເຖິງລັກສະນະຂອງແຕ່ລະຄົນ.

ຜູ້ຈັດການຊຸດ. .deb ທຽບກັບ .rpm

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍບັນຫາທີ່ຊັດເຈນຂອງການແຈກຢາຍຜະລິດຕະພັນໃນທົ່ວການແຈກຢາຍທີ່ແຕກຕ່າງກັນ.
ວິທີທົ່ວໄປທີ່ສຸດໃນການແຈກຢາຍຜະລິດຕະພັນຊອບແວແມ່ນການໃສ່ຊຸດໃສ່ບ່ອນເກັບມ້ຽນເພື່ອໃຫ້ຜູ້ຈັດການຊຸດທີ່ສ້າງຂຶ້ນໃນລະບົບສາມາດຕິດຕັ້ງມັນໄດ້ຈາກບ່ອນນັ້ນ.
ຢ່າງໃດກໍຕາມ, ພວກເຮົາມີສອງຮູບແບບຊຸດທີ່ນິຍົມ: rpm и deb. ນີ້ຫມາຍຄວາມວ່າທຸກຄົນຈະຕ້ອງສະຫນັບສະຫນູນ.

ໃນໂລກຂອງຊຸດ deb, ລະດັບຄວາມເຂົ້າກັນໄດ້ແມ່ນເຮັດໃຫ້ປະລາດ. ແພັກເກັດດຽວກັນຕິດຕັ້ງແລະເຮັດວຽກໄດ້ດີເທົ່າທຽມກັນໃນທັງ Debian 6 ແລະ Ubuntu 19.04. ມາດຕະຖານສໍາລັບຂະບວນການສ້າງຊຸດແລະເຮັດວຽກກັບພວກມັນ, ວາງໄວ້ໃນການແຈກຢາຍ Debian ເກົ່າ, ຍັງຄົງມີຄວາມກ່ຽວຂ້ອງຢູ່ໃນ Linux Mint ແລະ OS ປະຖົມໃຫມ່. ດັ່ງນັ້ນ, ໃນກໍລະນີຂອງຕົວແທນ Veeam ສໍາລັບ Linux, ຫນຶ່ງຊຸດ deb ສໍາລັບແຕ່ລະແພລະຕະຟອມຮາດແວແມ່ນພຽງພໍ.

ແຕ່ໃນໂລກຂອງການຫຸ້ມຫໍ່ rpm, ຄວາມແຕກຕ່າງແມ່ນຍິ່ງໃຫຍ່. ທໍາອິດ, ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າມີສອງຜູ້ຈັດຈໍາຫນ່າຍເອກະລາດຢ່າງສົມບູນ, Red Hat ແລະ SUSE, ເຊິ່ງຄວາມເຂົ້າກັນໄດ້ແມ່ນບໍ່ຈໍາເປັນ. ອັນທີສອງ, ຜູ້ຈັດຈໍາຫນ່າຍເຫຼົ່ານີ້ມີຊຸດແຈກຢາຍຈາກສິ່ງເຫຼົ່ານັ້ນ. ສະ​ຫນັບ​ສະ​ຫນູນ​ແລະ​ການ​ທົດ​ລອງ​. ມັນບໍ່ຈໍາເປັນຕ້ອງມີຄວາມເຂົ້າກັນໄດ້ລະຫວ່າງພວກມັນ. ມັນໄດ້ຫັນອອກວ່າ el6, el7 ແລະ el8 ມີຊຸດຂອງຕົນເອງ. ຊຸດແຍກຕ່າງຫາກສໍາລັບ Fedora. ແພັກເກດສໍາລັບ SLES11 ແລະ 12 ແລະອັນແຍກຕ່າງຫາກສໍາລັບ openSUSE. ບັນຫາຕົ້ນຕໍແມ່ນການຂຶ້ນກັບແລະຊື່ຊຸດ.

ບັນຫາການເພິ່ງພາອາໄສ

ແຕ່ຫນ້າເສຍດາຍ, ຊຸດດຽວກັນມັກຈະສິ້ນສຸດພາຍໃຕ້ຊື່ທີ່ແຕກຕ່າງກັນໃນການແຈກຢາຍທີ່ແຕກຕ່າງກັນ. ຂ້າງລຸ່ມນີ້ແມ່ນບັນຊີລາຍຊື່ບາງສ່ວນຂອງການຂຶ້ນກັບແພັກເກັດ veeam.

ສໍາລັບ EL7:
ສໍາລັບ SLES 12:

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• fuse-libs
• file-libs
• veeamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• libstdc++6
• libmagic1
• libfuse2
• veeamsnap-kmp=3.0.2.1185

ດັ່ງນັ້ນ, ບັນຊີລາຍຊື່ຂອງການເພິ່ງພາອາໄສແມ່ນເປັນເອກະລັກສໍາລັບການແຈກຢາຍ.

ສິ່ງທີ່ຮ້າຍແຮງກວ່າເກົ່າແມ່ນເມື່ອສະບັບປັບປຸງເລີ່ມເຊື່ອງພາຍໃຕ້ຊື່ຊຸດເກົ່າ.

ຕົວຢ່າງ:

ຊຸດໄດ້ຖືກປັບປຸງໃນ Fedora 24 ຄັກ ຈາກຮຸ່ນ 5 ເຖິງຮຸ່ນ 6. ຜະລິດຕະພັນຂອງພວກເຮົາຖືກສ້າງຂຶ້ນດ້ວຍຮຸ່ນ 5 ເພື່ອຮັບປະກັນຄວາມເຂົ້າກັນໄດ້ກັບການແຈກຢາຍເກົ່າ. ເພື່ອໃຊ້ຫ້ອງສະຫມຸດຮຸ່ນທີ 5 ເກົ່າໃນ Fedora 24, ຂ້ອຍຕ້ອງໃຊ້ຊຸດ ncurses-compat-libs.

ດັ່ງນັ້ນ, ມີສອງຊຸດສໍາລັບ Fedora, ມີຄວາມເພິ່ງພາອາໄສທີ່ແຕກຕ່າງກັນ.

ຫນ້າສົນໃຈຫຼາຍ. ຫຼັງຈາກການປັບປຸງການແຈກຢາຍຕໍ່ໄປ, ຊຸດ ncurses-compat-libs ກັບເວີຊັ່ນ 5 ຂອງຫ້ອງສະໝຸດມັນປະກົດວ່າບໍ່ສາມາດໃຊ້ໄດ້. ມັນແພງສໍາລັບຜູ້ຈັດຈໍາຫນ່າຍທີ່ຈະລາກຫ້ອງສະຫມຸດເກົ່າເຂົ້າໄປໃນສະບັບໃຫມ່ຂອງການແຈກຢາຍ. ຫຼັງຈາກເວລາໃດນຶ່ງ, ບັນຫາກໍ່ຊ້ຳແລ້ວຊ້ຳອີກໃນການແຈກຢາຍ SUSE.

ດັ່ງນັ້ນ, ບາງການແຈກຢາຍຕ້ອງຫຼຸດລົງການເພິ່ງພາອາໄສຢ່າງຊັດເຈນຂອງເຂົາເຈົ້າ ncurses-libs, ແລະແກ້ໄຂຜະລິດຕະພັນເພື່ອໃຫ້ມັນສາມາດເຮັດວຽກກັບສະບັບໃດຂອງຫ້ອງສະຫມຸດ.

ໂດຍວິທີທາງການ, ໃນຮຸ່ນ 8 ຂອງ Red Hat ບໍ່ມີຊຸດ meta ອີກຕໍ່ໄປ python, ເຊິ່ງຫມາຍເຖິງອາຍຸທີ່ດີ python 2.7. ມີ python2 и python3.

ທາງເລືອກກັບຜູ້ຈັດການຊຸດ

ບັນຫາກ່ຽວກັບການເພິ່ງພາອາໄສແມ່ນເກົ່າແກ່ແລະເຫັນໄດ້ຊັດເຈນດົນນານ. ພຽງແຕ່ຈື່ການເພິ່ງພາອາໄສ hell.
ເພື່ອປະສົມປະສານຫ້ອງສະຫມຸດແລະແອັບພລິເຄຊັນຕ່າງໆເພື່ອໃຫ້ພວກມັນເຮັດວຽກຢ່າງຫມັ້ນຄົງແລະບໍ່ຂັດແຍ້ງ - ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນວຽກງານທີ່ຜູ້ຈັດຈໍາຫນ່າຍ Linux ພະຍາຍາມແກ້ໄຂ.

ຜູ້ຈັດການຊຸດພະຍາຍາມແກ້ໄຂບັນຫານີ້ໃນທາງທີ່ແຕກຕ່າງກັນຫມົດ. Snappy ຈາກ Canonical. ແນວຄວາມຄິດຕົ້ນຕໍ: ແອັບພລິເຄຊັນເຮັດວຽກຢູ່ໃນ sandbox ທີ່ໂດດດ່ຽວແລະຖືກປົກປ້ອງຈາກລະບົບຕົ້ນຕໍ. ຖ້າແອັບພລິເຄຊັນຕ້ອງການຫ້ອງສະໝຸດ, ພວກມັນຈະຖືກສະໜອງໃຫ້ກັບແອັບພລິເຄຊັນເອງ.

Flatpak ຍັງອະນຸຍາດໃຫ້ທ່ານເອີ້ນໃຊ້ແອັບພລິເຄຊັນໃນ sandbox ໂດຍໃຊ້ Linux Containers. ແນວຄວາມຄິດຂອງ sandbox ຍັງຖືກນໍາໃຊ້ AppImage.

ວິທີແກ້ໄຂເຫຼົ່ານີ້ຊ່ວຍໃຫ້ທ່ານສ້າງຊຸດຫນຶ່ງສໍາລັບການແຈກຢາຍໃດໆ. ໃນ​ກໍ​ລະ​ນີ​ຂອງ Flatpak ການຕິດຕັ້ງແລະການເປີດຕົວແອັບພລິເຄຊັນແມ່ນເປັນໄປໄດ້ເຖິງແມ່ນວ່າບໍ່ມີຄວາມຮູ້ຂອງຜູ້ເບິ່ງແຍງລະບົບ.

ບັນຫາຕົ້ນຕໍແມ່ນວ່າບໍ່ແມ່ນທຸກແອັບພລິເຄຊັນສາມາດດໍາເນີນການຢູ່ໃນ sandbox ໄດ້. ບາງຄົນຕ້ອງການການເຂົ້າເຖິງໂດຍກົງກັບເວທີ. ຂ້າພະເຈົ້າບໍ່ໄດ້ເວົ້າກ່ຽວກັບໂມດູນ kernel, ເຊິ່ງຂຶ້ນກັບ kernel ຢ່າງເຂັ້ມງວດແລະບໍ່ເຫມາະສົມກັບແນວຄວາມຄິດ sandbox.

ບັນຫາທີສອງແມ່ນວ່າການແຈກຢາຍທີ່ນິຍົມໃນສະພາບແວດລ້ອມວິສາຫະກິດຈາກ Red Hat ແລະ SUSE ຍັງບໍ່ທັນມີການສະຫນັບສະຫນູນສໍາລັບ Snappy ແລະ Flatpak.

ໃນເລື່ອງນີ້, Veeam Agent ສໍາລັບ Linux ບໍ່ສາມາດໃຊ້ໄດ້ snapcraft.io ບໍ່ຢູ່ flathub.org.

ເພື່ອສະຫຼຸບຄໍາຖາມກ່ຽວກັບຜູ້ຈັດການຊຸດ, ຂ້າພະເຈົ້າຢາກສັງເກດວ່າມີທາງເລືອກທີ່ຈະປະຖິ້ມຜູ້ຈັດການຊຸດທັງຫມົດໂດຍການລວມເອົາໄຟລ໌ຄູ່ແລະສະຄິບສໍາລັບການຕິດຕັ້ງພວກມັນເຂົ້າໄປໃນຊຸດດຽວ.

ມັດດັ່ງກ່າວຊ່ວຍໃຫ້ທ່ານສ້າງຊຸດທົ່ວໄປສໍາລັບການແຈກຢາຍແລະເວທີທີ່ແຕກຕ່າງກັນ, ດໍາເນີນຂະບວນການຕິດຕັ້ງແບບໂຕ້ຕອບ, ປະຕິບັດການປັບແຕ່ງທີ່ຈໍາເປັນ. ຂ້ອຍພຽງແຕ່ພົບແພັກເກັດດັ່ງກ່າວສໍາລັບ Linux ຈາກ VMware.

ອັບເດດບັນຫາ

ເຖິງແມ່ນວ່າບັນຫາການເພິ່ງພາອາໄສທັງຫມົດຈະຖືກແກ້ໄຂ, ໂຄງການອາດຈະດໍາເນີນການແຕກຕ່າງກັນກ່ຽວກັບການແຈກຢາຍດຽວກັນ. ມັນກ່ຽວກັບການອັບເດດ.

ມີ 3 ຍຸດທະສາດການປັບປຸງ:

• ງ່າຍ​ທີ່​ສຸດ​ແມ່ນ​ບໍ່​ເຄີຍ​ປັບ​ປຸງ​. ຂ້ອຍຕັ້ງເຄື່ອງແມ່ຂ່າຍແລະລືມມັນ. ເປັນຫຍັງຕ້ອງອັບເດດຖ້າທຸກຢ່າງເຮັດວຽກ? ບັນຫາເລີ່ມຕົ້ນໃນຄັ້ງທໍາອິດທີ່ທ່ານຕິດຕໍ່ສະຫນັບສະຫນູນ. ຜູ້ສ້າງການແຈກຢາຍພຽງແຕ່ສະຫນັບສະຫນູນການປ່ອຍສະບັບປັບປຸງ.
• ທ່ານສາມາດໄວ້ວາງໃຈຜູ້ຈັດຈໍາຫນ່າຍແລະຕັ້ງຄ່າການປັບປຸງອັດຕະໂນມັດ. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ການ​ໂທ​ຫາ​ສະ​ຫນັບ​ສະ​ຫນູນ​ມີ​ແນວ​ໂນ້ມ​ທັນ​ທີ​ຫຼັງ​ຈາກ​ການ​ປັບ​ປຸງ​ບໍ່​ສໍາ​ເລັດ​.
• ທາງເລືອກຂອງການປັບປຸງຄູ່ມືພຽງແຕ່ຫຼັງຈາກແລ່ນມັນຢູ່ໃນໂຄງສ້າງພື້ນຖານການທົດສອບແມ່ນຫນ້າເຊື່ອຖືທີ່ສຸດ, ແຕ່ລາຄາແພງແລະໃຊ້ເວລາຫຼາຍ. ບໍ່ແມ່ນທຸກຄົນສາມາດຈ່າຍໄດ້.

ເນື່ອງຈາກຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນໃຊ້ກົນລະຍຸດການປັບປຸງທີ່ແຕກຕ່າງກັນ, ມັນຈໍາເປັນຕ້ອງສະຫນັບສະຫນູນທັງການປ່ອຍຫລ້າສຸດແລະທັງຫມົດທີ່ປ່ອຍອອກມາກ່ອນຫນ້ານີ້. ນີ້ສັບສົນທັງຂະບວນການພັດທະນາແລະການທົດສອບແລະເພີ່ມຄວາມເຈັບຫົວໃຫ້ກັບທີມງານສະຫນັບສະຫນູນ.

ຄວາມຫລາກຫລາຍຂອງເວທີຮາດແວ

ແພລະຕະຟອມຮາດແວທີ່ແຕກຕ່າງກັນແມ່ນບັນຫາທີ່ສ່ວນໃຫຍ່ແມ່ນສະເພາະກັບລະຫັດພື້ນເມືອງ. ຕໍາ່ສຸດທີ່, ທ່ານຕ້ອງໄດ້ເກັບກໍາຂໍ້ມູນຖານສອງສໍາລັບແຕ່ລະເວທີທີ່ສະຫນັບສະຫນູນ.

ໃນໂຄງການ Veeam Agent ສໍາລັບ Linux, ພວກເຮົາຍັງບໍ່ສາມາດສະຫນັບສະຫນູນສິ່ງໃດແດ່ເຊັ່ນ RISC ນີ້.

ຂ້າພະເຈົ້າຈະບໍ່ໄດ້ຢູ່ໃນລາຍລະອຽດກ່ຽວກັບບັນຫານີ້. ຂ້າພະເຈົ້າຈະອະທິບາຍບັນຫາຕົ້ນຕໍ: ປະເພດທີ່ຂຶ້ນກັບເວທີ, ເຊັ່ນ: size_t, ການຈັດລຽງໂຄງສ້າງແລະຄໍາສັ່ງ byte.

ການເຊື່ອມໂຍງແບບຄົງທີ່ ແລະ/ຫຼືແບບເຄື່ອນໄຫວ

ແຕ່ຄໍາຖາມແມ່ນ "ວິທີການເຊື່ອມໂຍງກັບຫ້ອງສະຫມຸດ - ແບບເຄື່ອນໄຫວຫຼືແບບຄົງທີ່?" ຕົກເປັນມູນຄ່າສົນທະນາ.

ຕາມກົດລະບຽບ, ແອັບພລິເຄຊັນ C/C++ ພາຍໃຕ້ Linux ໃຊ້ການເຊື່ອມໂຍງແບບເຄື່ອນໄຫວ. ນີ້ເຮັດວຽກໄດ້ດີຖ້າແອັບພລິເຄຊັນຖືກສ້າງຂຶ້ນໂດຍສະເພາະສໍາລັບການແຈກຢາຍສະເພາະ.

ຖ້າຫນ້າວຽກແມ່ນເພື່ອໃຫ້ກວມເອົາການແຈກຢາຍຕ່າງໆທີ່ມີໄຟລ໌ຄູ່ຫນຶ່ງ, ຫຼັງຈາກນັ້ນທ່ານຕ້ອງສຸມໃສ່ການແຈກຢາຍທີ່ສະຫນັບສະຫນູນເກົ່າແກ່ທີ່ສຸດ. ສໍາລັບພວກເຮົາ, ນີ້ແມ່ນ Red Hat 6. ມັນມີ gcc 4.4, ເຊິ່ງເຖິງແມ່ນວ່າມາດຕະຖານ C ++ 11 ບໍ່ຮອງຮັບ. ຢ່າງເຕັມທີ່.

ພວກເຮົາສ້າງໂຄງການຂອງພວກເຮົາໂດຍໃຊ້ gcc 6.3, ເຊິ່ງຮອງຮັບ C++14 ຢ່າງເຕັມສ່ວນ. ຕາມທໍາມະຊາດ, ໃນກໍລະນີນີ້, ໃນ Red Hat 6 ທ່ານຕ້ອງປະຕິບັດ libstdc ++ ແລະເພີ່ມຫ້ອງສະຫມຸດກັບທ່ານ. ວິທີທີ່ງ່າຍທີ່ສຸດແມ່ນການເຊື່ອມໂຍງກັບພວກມັນແບບຄົງທີ່.

ແຕ່ອະນິຈາ, ບໍ່ແມ່ນຫ້ອງສະຫມຸດທັງຫມົດສາມາດເຊື່ອມຕໍ່ແບບຄົງທີ່.

ກ່ອນອື່ນ ໝົດ, ຫ້ອງສະຫມຸດລະບົບເຊັ່ນ libfuse, libblkid ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະເຊື່ອມຕໍ່ແບບເຄື່ອນໄຫວເພື່ອຮັບປະກັນຄວາມເຂົ້າກັນໄດ້ກັບແກ່ນແລະໂມດູນຂອງມັນ.

ອັນທີສອງ, ມີ subtlety ກັບໃບອະນຸຍາດ.

ໃບອະນຸຍາດ GPL ໂດຍພື້ນຖານແລ້ວອະນຸຍາດໃຫ້ທ່ານເຊື່ອມຕໍ່ຫ້ອງສະຫມຸດດ້ວຍລະຫັດ opensource ເທົ່ານັ້ນ. MIT ແລະ BSD ອະນຸຍາດໃຫ້ເຊື່ອມຕໍ່ແບບຄົງທີ່ແລະອະນຸຍາດໃຫ້ຫ້ອງສະຫມຸດຖືກລວມເຂົ້າໃນໂຄງການ. ແຕ່ LGPL ເບິ່ງຄືວ່າບໍ່ຂັດແຍ້ງກັບການເຊື່ອມໂຍງແບບຄົງທີ່, ແຕ່ຮຽກຮ້ອງໃຫ້ແບ່ງປັນໄຟລ໌ທີ່ຈໍາເປັນສໍາລັບການເຊື່ອມໂຍງ.

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

ການສ້າງແອັບພລິເຄຊັນ C/C++

ເພື່ອສ້າງຄໍາຮ້ອງສະຫມັກ C / C ++ ສໍາລັບແພລະຕະຟອມແລະການແຈກຢາຍທີ່ແຕກຕ່າງກັນ, ມັນພຽງພໍທີ່ຈະເລືອກຫຼືສ້າງ gcc ຮຸ່ນທີ່ເຫມາະສົມແລະໃຊ້ cross-compilers ສໍາລັບສະຖາປັດຕະຍະກໍາສະເພາະແລະປະກອບຊຸດຫ້ອງສະຫມຸດທັງຫມົດ. ວຽກງານນີ້ແມ່ນຂ້ອນຂ້າງເປັນໄປໄດ້, ແຕ່ຂ້ອນຂ້າງມີບັນຫາ. ແລະບໍ່ມີການຮັບປະກັນວ່າ compiler ແລະຫ້ອງສະຫມຸດທີ່ເລືອກຈະສະຫນອງສະບັບທີ່ສາມາດເຮັດວຽກໄດ້.

ປະໂຫຍດທີ່ຊັດເຈນ: ໂຄງສ້າງພື້ນຖານແມ່ນງ່າຍດາຍຫຼາຍ, ເນື່ອງຈາກວ່າຂະບວນການກໍ່ສ້າງທັງຫມົດສາມາດສໍາເລັດດ້ວຍເຄື່ອງຈັກດຽວ. ນອກຈາກນັ້ນ, ມັນພຽງພໍທີ່ຈະເກັບກໍາຊຸດຂອງຖານສອງສໍາລັບຫນຶ່ງສະຖາປັດຕະຍະກໍາແລະທ່ານສາມາດຫຸ້ມຫໍ່ໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນຊຸດສໍາລັບການແຈກຢາຍທີ່ແຕກຕ່າງກັນ. ນີ້ແມ່ນວິທີການຫຸ້ມຫໍ່ veeam ສໍາລັບ Veeam Agent ສໍາລັບ Linux.

ກົງກັນຂ້າມກັບທາງເລືອກນີ້, ທ່ານພຽງແຕ່ສາມາດກະກຽມກະສິກໍາກໍ່ສ້າງ, ນັ້ນແມ່ນ, ເຄື່ອງຈັກຈໍານວນຫນຶ່ງສໍາລັບການປະກອບ. ແຕ່ລະເຄື່ອງດັ່ງກ່າວຈະສະຫນອງການລວບລວມຄໍາຮ້ອງສະຫມັກແລະການປະກອບຊຸດສໍາລັບການແຈກຢາຍສະເພາະແລະສະຖາປັດຕະຍະກໍາສະເພາະ. ໃນກໍລະນີນີ້, ການລວບລວມແມ່ນດໍາເນີນໂດຍໃຊ້ວິທີການກະກຽມໂດຍຜູ້ຈັດຈໍາຫນ່າຍ. ນັ້ນແມ່ນ, ຂັ້ນຕອນຂອງການກະກຽມ compiler ແລະເລືອກຫ້ອງສະຫມຸດໄດ້ຖືກລົບລ້າງ. ນອກຈາກນັ້ນ, ຂະບວນການກໍ່ສ້າງສາມາດຂະຫນານໄດ້ງ່າຍ.

ຢ່າງໃດກໍຕາມ, ມີຂໍ້ເສຍຂອງວິທີການນີ້: ສໍາລັບການແຈກຢາຍແຕ່ລະພາຍໃນສະຖາປັດຕະຍະດຽວກັນ, ທ່ານຈະຕ້ອງເກັບກໍາຊຸດຂອງໄຟລ໌ຄູ່ຂອງຕົນເອງ. ຂໍ້ເສຍອີກອັນຫນຶ່ງແມ່ນວ່າເຄື່ອງຈໍານວນຫຼວງຫຼາຍຕ້ອງໄດ້ຮັບການຮັກສາໄວ້ແລະຈໍານວນຂະຫນາດໃຫຍ່ຂອງພື້ນທີ່ດິດແລະ RAM ຕ້ອງໄດ້ຮັບການຈັດສັນ.

ນີ້ແມ່ນວິທີການຫຸ້ມຫໍ່ KMOD ຂອງໂມດູນ veeamsnap kernel ຖືກລວບລວມສໍາລັບການແຈກຢາຍ Red Hat.

ເປີດບໍລິການສ້າງ

ເພື່ອນຮ່ວມງານຈາກ SUSE ພະຍາຍາມປະຕິບັດບາງພື້ນທີ່ກາງໃນຮູບແບບການບໍລິການພິເສດສໍາລັບການລວບລວມຄໍາຮ້ອງສະຫມັກແລະການປະກອບຊຸດ - openbuildservice.

ໂດຍພື້ນຖານແລ້ວ, ມັນແມ່ນ hypervisor ທີ່ສ້າງເຄື່ອງ virtual, ຕິດຕັ້ງຊຸດທີ່ຈໍາເປັນທັງຫມົດໃນມັນ, ລວບລວມຄໍາຮ້ອງສະຫມັກແລະສ້າງຊຸດໃນສະພາບແວດລ້ອມທີ່ໂດດດ່ຽວນີ້, ຫຼັງຈາກນັ້ນເຄື່ອງ virtual ໄດ້ຖືກປ່ອຍອອກມາ.

ຕົວກໍານົດເວລາທີ່ຖືກປະຕິບັດໃນ OpenBuildService ຈະກໍານົດຈໍານວນເຄື່ອງ virtual ທີ່ມັນສາມາດເປີດຕົວສໍາລັບຄວາມໄວການສ້າງແພັກເກັດທີ່ດີທີ່ສຸດ. ກົນໄກການລົງນາມໃນຕົວຈະລົງນາມໃນຊຸດຕ່າງໆແລະອັບໂຫລດພວກມັນໃສ່ບ່ອນເກັບມ້ຽນໃນຕົວ. ລະບົບການຄວບຄຸມສະບັບທີ່ສ້າງຂຶ້ນຈະຊ່ວຍປະຢັດປະຫວັດສາດຂອງການປ່ຽນແປງແລະການກໍ່ສ້າງ. ສິ່ງທີ່ຍັງເຫຼືອແມ່ນພຽງແຕ່ເພີ່ມແຫຼ່ງຂອງທ່ານເຂົ້າໃນລະບົບນີ້. ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງຕັ້ງຄ່າເຊີບເວີດ້ວຍຕົວເອງ; ທ່ານສາມາດໃຊ້ເປີດໄດ້.

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

ນອກຈາກນັ້ນ, ການສະຫນັບສະຫນູນການແຈກຢາຍອື່ນໆ - ຕົວຢ່າງ, Red Hat - ຖືກປະຕິບັດແທນທີ່ຈະບໍ່ດີ, ເຊິ່ງເຂົ້າໃຈໄດ້.

ຄວາມໄດ້ປຽບຂອງການບໍລິການດັ່ງກ່າວແມ່ນການສະຫນັບສະຫນຸນໄວສໍາລັບການແຈກຢາຍ SUSE ຮຸ່ນຕໍ່ໄປ. ກ່ອນທີ່ຈະປະກາດຢ່າງເປັນທາງການຂອງການປ່ອຍ, ຊຸດທີ່ຈໍາເປັນສໍາລັບການປະກອບໄດ້ຖືກຈັດພີມມາຢູ່ໃນ repository ສາທາລະນະ. ອັນໃໝ່ປະກົດຢູ່ໃນລາຍຊື່ການແຈກຢາຍທີ່ມີຢູ່ໃນ OpenBuildService. ພວກເຮົາກວດເບິ່ງກ່ອງແລະມັນຖືກເພີ່ມເຂົ້າໃນແຜນການກໍ່ສ້າງ. ດັ່ງນັ້ນ, ການເພີ່ມສະບັບໃຫມ່ຂອງການແຈກຢາຍແມ່ນເຮັດໃນເກືອບຫນຶ່ງຄລິກ.

ໃນໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາ, ໂດຍໃຊ້ OpenBuildService, ຊຸດ KMP ຫຼາກຫຼາຍຊະນິດຂອງໂມດູນແກ່ນ veeamsnap ສໍາລັບການແຈກຢາຍ SUSE ແມ່ນປະກອບເຂົ້າກັນ.

ຕໍ່ໄປ, ຂ້າພະເຈົ້າຢາກຈະຢູ່ໃນບັນຫາສະເພາະກັບໂມດູນ kernel.

kernel ABI

ໂມດູນ kernel Linux ໄດ້ຖືກແຈກຢາຍໃນປະຫວັດສາດໃນຮູບແບບແຫຼ່ງ. ຄວາມຈິງແລ້ວແມ່ນວ່າຜູ້ສ້າງ kernel ບໍ່ໄດ້ພາລະຕົວເອງກັບຄວາມກັງວົນຂອງການສະຫນັບສະຫນູນ API ທີ່ຫມັ້ນຄົງສໍາລັບໂມດູນ kernel, ແລະໂດຍສະເພາະໃນລະດັບສອງ, ເອີ້ນວ່າ kABI.

ເພື່ອສ້າງໂມດູນສໍາລັບ kernel vanilla, ແນ່ນອນທ່ານຕ້ອງການ headers ຂອງ kernel ໂດຍສະເພາະນີ້, ແລະມັນຈະເຮັດວຽກພຽງແຕ່ໃນແກ່ນນີ້.

DKMS ຊ່ວຍໃຫ້ທ່ານສາມາດອັດຕະໂນມັດຂະບວນການສ້າງໂມດູນໃນເວລາທີ່ການປັບປຸງ kernel. ດັ່ງນັ້ນ, ຜູ້ໃຊ້ຂອງ Debian repository (ແລະພີ່ນ້ອງຈໍານວນຫຼາຍຂອງມັນ) ໃຊ້ kernel modules ບໍ່ວ່າຈະຈາກ repository ຂອງຜູ້ຈັດຈໍາຫນ່າຍຫຼືລວບລວມຈາກແຫຼ່ງໂດຍໃຊ້ DKMS.

ຢ່າງໃດກໍ່ຕາມ, ສະຖານະການນີ້ບໍ່ເຫມາະສົມກັບພາກສ່ວນວິສາຫະກິດໂດຍສະເພາະ. ຜູ້ຈັດຈໍາຫນ່າຍລະຫັດເປັນເຈົ້າຂອງຕ້ອງການແຈກຢາຍຜະລິດຕະພັນເປັນຄູ່ທີ່ລວບລວມ.

ຜູ້ເບິ່ງແຍງລະບົບບໍ່ຕ້ອງການຮັກສາເຄື່ອງມືພັດທະນາໃນເຄື່ອງແມ່ຂ່າຍການຜະລິດສໍາລັບເຫດຜົນດ້ານຄວາມປອດໄພ. ຜູ້ຈັດຈໍາຫນ່າຍ Linux Enterprise ເຊັ່ນ Red Hat ແລະ SUSE ຕັດສິນໃຈວ່າພວກເຂົາສາມາດສະຫນັບສະຫນູນ kABI ທີ່ຫມັ້ນຄົງສໍາລັບຜູ້ໃຊ້ຂອງພວກເຂົາ. ຜົນໄດ້ຮັບແມ່ນຊຸດ KMOD ສໍາລັບ Red Hat ແລະຊຸດ KMP ສໍາລັບ SUSE.

ໂດຍເນື້ອແທ້ແລ້ວຂອງການແກ້ໄຂນີ້ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ. ສໍາລັບສະບັບສະເພາະຂອງການແຈກຢາຍ, kernel API ແມ່ນ frozen. ຜູ້ຈັດຈໍາຫນ່າຍກ່າວວ່າລາວໃຊ້ kernel, ສໍາລັບການຍົກຕົວຢ່າງ, 3.10, ແລະເຮັດພຽງແຕ່ການແກ້ໄຂແລະການປັບປຸງທີ່ບໍ່ມີຜົນກະທົບຕໍ່ການໂຕ້ຕອບຂອງແກ່ນ, ແລະໂມດູນທີ່ເກັບກໍາສໍາລັບ kernel ທໍາອິດສາມາດຖືກນໍາໃຊ້ສໍາລັບທຸກອັນຕໍ່ມາໂດຍບໍ່ມີການ recompilation.

Red Hat ອ້າງເຖິງຄວາມເຂົ້າກັນໄດ້ຂອງ kABI ສໍາລັບການແຈກຢາຍໃນທົ່ວວົງຈອນຊີວິດທັງຫມົດຂອງມັນ. ນັ້ນແມ່ນ, ໂມດູນທີ່ປະກອບສໍາລັບ rhel 6.0 (ປ່ອຍເດືອນພະຈິກ 2010) ຄວນເຮັດວຽກຢູ່ໃນຮຸ່ນ 6.10 (ປ່ອຍເດືອນມິຖຸນາ 2018). ແລະນີ້ແມ່ນເກືອບ 8 ປີ. ຕາມທໍາມະຊາດ, ວຽກງານນີ້ແມ່ນຂ້ອນຂ້າງຍາກ.
ພວກເຮົາໄດ້ບັນທຶກຫຼາຍໆກໍລະນີທີ່ໂມດູນ veeamsnap ຢຸດເຮັດວຽກເນື່ອງຈາກບັນຫາຄວາມເຂົ້າກັນໄດ້ຂອງ kABI.

ຫຼັງຈາກໂມດູນ veeamsnap, ລວບລວມສໍາລັບ RHEL 7.0, ເບິ່ງຄືວ່າບໍ່ເຂົ້າກັນໄດ້ກັບ kernel ຈາກ RHEL 7.5, ແຕ່ມັນໂຫລດແລະຮັບປະກັນວ່າເຄື່ອງແມ່ຂ່າຍຈະ crash, ພວກເຮົາປະຖິ້ມການໃຊ້ຄວາມເຂົ້າກັນໄດ້ຂອງ kABI ສໍາລັບ RHEL 7 ທັງຫມົດ.

ໃນປັດຈຸບັນ, ຊຸດ KMOD ສໍາລັບ RHEL 7 ປະກອບດ້ວຍການປະກອບສໍາລັບແຕ່ລະລຸ້ນລຸ້ນແລະສະຄິບທີ່ໂຫລດໂມດູນ.

SUSE ໄດ້ເຂົ້າຫາວຽກງານຂອງຄວາມເຂົ້າກັນໄດ້ຂອງ kABI ຢ່າງລະມັດລະວັງຫຼາຍຂຶ້ນ. ພວກເຂົາສະຫນອງຄວາມເຂົ້າກັນໄດ້ຂອງ kABI ພາຍໃນຊຸດບໍລິການດຽວເທົ່ານັ້ນ.

ຕົວຢ່າງ, ການປ່ອຍ SLES 12 ເກີດຂຶ້ນໃນເດືອນກັນຍາ 2014. ແລະ SLES 12 SP1 ແມ່ນແລ້ວໃນເດືອນທັນວາ 2015, ນັ້ນແມ່ນ, ຫຼາຍກວ່າຫນຶ່ງປີໄດ້ຜ່ານໄປ. ເຖິງແມ່ນວ່າທັງສອງລຸ້ນໃຊ້ 3.12 kernel, ພວກມັນບໍ່ເຂົ້າກັນໄດ້ kABI. ແນ່ນອນ, ການຮັກສາຄວາມເຂົ້າກັນໄດ້ຂອງ kABI ພຽງແຕ່ຫນຶ່ງປີແມ່ນງ່າຍຂຶ້ນຫຼາຍ. ຮອບວຽນການປັບປຸງໂມດູນ kernel ປະຈໍາປີບໍ່ຄວນເຮັດໃຫ້ເກີດບັນຫາສໍາລັບຜູ້ສ້າງໂມດູນ.

ເປັນຜົນມາຈາກນະໂຍບາຍ SUSE ນີ້, ພວກເຮົາບໍ່ໄດ້ບັນທຶກບັນຫາດຽວກັບຄວາມເຂົ້າກັນໄດ້ຂອງ kABI ໃນໂມດູນ veeamsnap ຂອງພວກເຮົາ. ແທ້ຈິງແລ້ວ, ຈໍານວນແພັກເກັດສໍາລັບ SUSE ແມ່ນເກືອບເປັນຄໍາສັ່ງທີ່ມີຂະຫນາດໃຫຍ່ກວ່າ.

Patches ແລະ backports

ເຖິງແມ່ນວ່າຜູ້ຈັດຈໍາຫນ່າຍພະຍາຍາມຮັບປະກັນຄວາມເຂົ້າກັນໄດ້ຂອງ kABI ແລະຄວາມຫມັ້ນຄົງຂອງແກ່ນ, ພວກເຂົາຍັງພະຍາຍາມປັບປຸງປະສິດທິພາບແລະລົບລ້າງຂໍ້ບົກພ່ອງຂອງແກ່ນທີ່ຫມັ້ນຄົງນີ້.

ໃນຂະນະດຽວກັນ, ນອກເຫນືອໄປຈາກ "ເຮັດວຽກກ່ຽວກັບຄວາມຜິດພາດ" ຂອງຕົນເອງ, ນັກພັດທະນາຂອງວິສາຫະກິດ Linux kernel ຕິດຕາມກວດກາການປ່ຽນແປງຂອງ vanilla kernel ແລະໂອນໃຫ້ເຂົາເຈົ້າ "ຫມັ້ນຄົງ" ຫນຶ່ງຂອງເຂົາເຈົ້າ.

ບາງຄັ້ງນີ້ນໍາໄປສູ່ການໃຫມ່ ຄວາມຜິດພາດ.

ໃນການປ່ອຍຫລ້າສຸດຂອງ Red Hat 6, ຄວາມຜິດພາດໄດ້ເກີດຂຶ້ນໃນຫນຶ່ງໃນການປັບປຸງເລັກນ້ອຍ. ມັນໄດ້ນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າໂມດູນ veeamsnap ໄດ້ຮັບການຮັບປະກັນທີ່ຈະ crash ລະບົບໃນເວລາທີ່ snapshot ໄດ້ຖືກປ່ອຍອອກມາ. ມີການປຽບທຽບແຫຼ່ງຂໍ້ມູນ kernel ກ່ອນແລະຫຼັງຈາກການປັບປຸງ, ພວກເຮົາພົບເຫັນວ່າ backport ແມ່ນເພື່ອຕໍານິ. ການ​ແກ້​ໄຂ​ທີ່​ຄ້າຍ​ຄື​ກັນ​ໄດ້​ຖືກ​ເຮັດ​ໃຫ້​ຢູ່​ໃນ​ເວີ​ຊັນ vanilla kernel 4.19​. ມັນເປັນພຽງແຕ່ວ່າການແກ້ໄຂນີ້ເຮັດວຽກໄດ້ດີໃນແກ່ນ vanilla, ແຕ່ເມື່ອໂອນມັນໄປຫາ "ຄວາມຫມັ້ນຄົງ" 2.6.32, ບັນຫາເກີດຂື້ນກັບ spinlock.

ແນ່ນອນ, ທຸກຄົນມັກຈະມີຂໍ້ຜິດພາດ, ແຕ່ມັນຄຸ້ມຄ່າທີ່ຈະລາກລະຫັດຈາກ 4.19 ຫາ 2.6.32, ມີຄວາມສ່ຽງຕໍ່ຄວາມຫມັ້ນຄົງບໍ?.. ຂ້ອຍບໍ່ແນ່ໃຈວ່າ ...

ສິ່ງທີ່ຮ້າຍແຮງທີ່ສຸດແມ່ນເວລາທີ່ການຕະຫຼາດມີສ່ວນຮ່ວມໃນສົງຄາມລະຫວ່າງ "ຄວາມຫມັ້ນຄົງ" ແລະ "ຄວາມທັນສະໄຫມ". ພະແນກການຕະຫລາດຕ້ອງການຫຼັກຂອງການແຈກຢາຍທີ່ຖືກປັບປຸງໃຫ້ມີຄວາມຫມັ້ນຄົງ, ໃນດ້ານຫນຶ່ງ, ແລະໃນເວລາດຽວກັນຈະດີກວ່າໃນການປະຕິບັດແລະມີຄຸນສົມບັດໃຫມ່. ນີ້ນໍາໄປສູ່ການປະນີປະນອມທີ່ແປກປະຫຼາດ.

ເມື່ອຂ້ອຍພະຍາຍາມສ້າງໂມດູນໃນ kernel 4.4 ຈາກ SLES 12 SP3, ຂ້ອຍແປກໃຈທີ່ຊອກຫາຫນ້າທີ່ເຮັດວຽກຈາກ vanilla 4.8 ໃນມັນ. ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ການປະຕິບັດ block I/O ຂອງ 4.4 kernel ຈາກ SLES 12 SP3 ແມ່ນຄ້າຍຄືກັນກັບ 4.8 kernel ຫຼາຍກ່ວາການປ່ອຍ 4.4 kernel ທີ່ຜ່ານມາທີ່ຫມັ້ນຄົງຈາກ SLES12 SP2. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ສາ​ມາດ​ຕັດ​ສິນ​ວ່າ​ອັດ​ຕາ​ສ່ວນ​ຂອງ​ລະ​ຫັດ​ທີ່​ໄດ້​ຮັບ​ການ​ຍົກ​ຍ້າຍ​ຈາກ kernel 4.8 ກັບ SLES 4.4 ສໍາ​ລັບ SP3​, ແຕ່​ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ສາ​ມາດ​ເອີ້ນ​ວ່າ kernel ເປັນ 4.4 ຄົງ​ທີ່​ດຽວ​ກັນ​.

ສິ່ງທີ່ບໍ່ພໍໃຈທີ່ສຸດກ່ຽວກັບເລື່ອງນີ້ແມ່ນວ່າເມື່ອຂຽນໂມດູນທີ່ຈະເຮັດວຽກໄດ້ດີເທົ່າທຽມກັນໃນ kernel ທີ່ແຕກຕ່າງກັນ, ທ່ານບໍ່ສາມາດອີງໃສ່ສະບັບ kernel ໄດ້. ນອກນັ້ນທ່ານຍັງຕ້ອງຄໍານຶງເຖິງການແຈກຢາຍ. ມັນເປັນການດີທີ່ບາງຄັ້ງທ່ານສາມາດມີສ່ວນຮ່ວມໃນຄໍານິຍາມທີ່ປາກົດພ້ອມກັບຫນ້າທີ່ໃຫມ່, ແຕ່ໂອກາດນີ້ບໍ່ໄດ້ປາກົດຢູ່ສະເຫມີ.

ດັ່ງນັ້ນ, ລະຫັດກາຍເປັນ overgrown ດ້ວຍຄໍາແນະນໍາການລວບລວມເງື່ອນໄຂທີ່ແປກປະຫຼາດ.

ນອກນັ້ນຍັງມີ patches ທີ່ປ່ຽນແປງ kernel API ທີ່ເປັນເອກະສານ.
ຂ້າພະເຈົ້າໄດ້ມາໃນທົ່ວການແຈກຢາຍ KDE neon 5.16 ແລະຮູ້ສຶກແປກໃຈຫຼາຍທີ່ເຫັນວ່າການໂທ lookup_bdev ໃນລຸ້ນ kernel ນີ້ປ່ຽນລາຍຊື່ພາລາມິເຕີການປ້ອນຂໍ້ມູນ.

ເພື່ອໃຫ້ມັນຮ່ວມກັນ, ຂ້ອຍຕ້ອງເພີ່ມສະຄິບໃສ່ makefile ທີ່ກວດເບິ່ງວ່າຟັງຊັນ lookup_bdev ມີພາລາມິເຕີຫນ້າກາກ.

ເຊັນຊື່ໂມດູນ kernel

ແຕ່ໃຫ້ກັບຄືນໄປຫາບັນຫາການແຈກຢາຍຊຸດ.

ຫນຶ່ງໃນຂໍ້ໄດ້ປຽບຂອງ kABI ທີ່ຫມັ້ນຄົງແມ່ນວ່າໂມດູນແກ່ນສາມາດຖືກເຊັນເປັນໄຟລ໌ຄູ່. ໃນກໍລະນີນີ້, ນັກພັດທະນາສາມາດແນ່ໃຈວ່າໂມດູນບໍ່ໄດ້ເສຍຫາຍໂດຍບັງເອີນຫຼືຖືກດັດແປງໂດຍເຈດຕະນາ. ທ່ານສາມາດກວດສອບນີ້ດ້ວຍຄໍາສັ່ງ modinfo.

ການແຈກຢາຍຂອງ Red Hat ແລະ SUSE ຊ່ວຍໃຫ້ທ່ານສາມາດກວດເບິ່ງລາຍເຊັນຂອງໂມດູນແລະໂຫຼດມັນພຽງແຕ່ຖ້າໃບຢັ້ງຢືນທີ່ສອດຄ້ອງກັນຖືກລົງທະບຽນຢູ່ໃນລະບົບ. ໃບຢັ້ງຢືນແມ່ນລະຫັດສາທາລະນະທີ່ໂມດູນຖືກເຊັນ. ພວກເຮົາແຈກຢາຍມັນເປັນຊຸດແຍກຕ່າງຫາກ.

ບັນຫາຢູ່ທີ່ນີ້ແມ່ນວ່າໃບຢັ້ງຢືນສາມາດຖືກສ້າງຢູ່ໃນແກ່ນ (ຜູ້ຈັດຈໍາຫນ່າຍໃຊ້ພວກມັນ) ຫຼືຕ້ອງຖືກຂຽນໃສ່ EFI ຫນ່ວຍຄວາມຈໍາທີ່ບໍ່ມີການລະເຫີຍໂດຍໃຊ້ປະໂຫຍດ. ໂມກຸຕິລ. ປະໂຫຍດ ໂມກຸຕິລ ເມື່ອຕິດຕັ້ງໃບຢັ້ງຢືນ, ມັນຮຽກຮ້ອງໃຫ້ທ່ານ reboot ລະບົບແລະ, ເຖິງແມ່ນວ່າກ່ອນທີ່ຈະໂຫລດ kernel ລະບົບປະຕິບັດການ, ກະຕຸ້ນໃຫ້ຜູ້ບໍລິຫານອະນຸຍາດໃຫ້ໂຫລດໃບຢັ້ງຢືນໃຫມ່.

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

EFI ໃນເຄື່ອງ virtual

ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າ EFI ໄດ້ຮັບການສະຫນັບສະຫນູນຈາກຜູ້ຜະລິດ motherboard ເກືອບທັງຫມົດ, ເມື່ອຕິດຕັ້ງລະບົບ, ຜູ້ບໍລິຫານອາດຈະບໍ່ຄິດກ່ຽວກັບຄວາມຕ້ອງການຂອງ EFI, ແລະມັນອາດຈະຖືກປິດໃຊ້ງານ.

ບໍ່ແມ່ນທຸກ hypervisors ສະຫນັບສະຫນູນ EFI. VMWare vSphere ຮອງຮັບ EFI ເລີ່ມຈາກລຸ້ນ 5.
Microsoft Hyper-V ຍັງໄດ້ຮັບການສະຫນັບສະຫນູນ EFI ເລີ່ມຕົ້ນດ້ວຍ Hyper-V ສໍາລັບ Windows Server 2012R2.

ຢ່າງໃດກໍຕາມ, ໃນການຕັ້ງຄ່າເລີ່ມຕົ້ນ, ຟັງຊັນນີ້ຖືກປິດໃຊ້ງານສໍາລັບເຄື່ອງ Linux, ຊຶ່ງຫມາຍຄວາມວ່າໃບຢັ້ງຢືນບໍ່ສາມາດຕິດຕັ້ງໄດ້.

ໃນ vSphere 6.5, ກໍານົດທາງເລືອກ Secure Boot ເປັນໄປໄດ້ພຽງແຕ່ໃນສະບັບເກົ່າຂອງການໂຕ້ຕອບເວັບໄຊຕ໌, ເຊິ່ງດໍາເນີນການຜ່ານ Flash. Web UI ໃນ HTML-5 ແມ່ນຍັງຢູ່ໄກກວ່າ.

ການແຈກຢາຍແບບທົດລອງ

ແລະສຸດທ້າຍ, ໃຫ້ພິຈາລະນາບັນຫາການທົດລອງແລະການແຈກຢາຍໂດຍບໍ່ມີການສະຫນັບສະຫນູນຢ່າງເປັນທາງການ. ໃນທາງກົງກັນຂ້າມ, ການແຈກຢາຍດັ່ງກ່າວບໍ່ຫນ້າຈະພົບເຫັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງອົງການຈັດຕັ້ງທີ່ຮ້າຍແຮງ. ບໍ່ມີການສະຫນັບສະຫນູນຢ່າງເປັນທາງການສໍາລັບການແຈກຢາຍດັ່ງກ່າວ. ເພາະສະນັ້ນ, ສະຫນອງເຫຼົ່ານັ້ນ. ຜະລິດຕະພັນດັ່ງກ່າວບໍ່ສາມາດຮອງຮັບການແຈກຢາຍດັ່ງກ່າວໄດ້.

ຢ່າງໃດກໍ່ຕາມ, ການແຈກຢາຍດັ່ງກ່າວກາຍເປັນເວທີທີ່ສະດວກສໍາລັບການພະຍາຍາມແກ້ໄຂບັນຫາທົດລອງໃຫມ່. ຕົວຢ່າງເຊັ່ນ Fedora, OpenSUSE Tumbleweed ຫຼືສະບັບທີ່ບໍ່ສະຖຽນຂອງ Debian. ພວກເຂົາເຈົ້າແມ່ນຂ້ອນຂ້າງຫມັ້ນຄົງ. ພວກມັນມີໂປຣແກມເວີຊັ່ນໃໝ່ສະເໝີ ແລະເປັນແກ່ນໃໝ່ສະເໝີ. ໃນປີຫນຶ່ງ, ຫນ້າທີ່ທົດລອງນີ້ອາດຈະສິ້ນສຸດໃນ RHEL, SLES ຫຼື Ubuntu ທີ່ຖືກປັບປຸງ.

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

ທ່ານ​ສາ​ມາດ​ສຶກ​ສາ​ບັນ​ຊີ​ລາຍ​ຊື່​ຂອງ​ການ​ແຜ່​ກະ​ຈາຍ​ສະ​ຫນັບ​ສະ​ຫນູນ​ຢ່າງ​ເປັນ​ທາງ​ການ​ສໍາ​ລັບ​ການ​ສະ​ບັບ 3.0 ທີ່ນີ້. ແຕ່ບັນຊີລາຍຊື່ທີ່ແທ້ຈິງຂອງການແຈກຢາຍທີ່ຜະລິດຕະພັນຂອງພວກເຮົາສາມາດເຮັດວຽກແມ່ນກວ້າງກວ່າ.

ສ່ວນບຸກຄົນ, ຂ້າພະເຈົ້າມີຄວາມສົນໃຈໃນການທົດລອງກັບ Elbrus OS. ຫຼັງຈາກສໍາເລັດຊຸດ veeam, ຜະລິດຕະພັນຂອງພວກເຮົາໄດ້ຖືກຕິດຕັ້ງແລະເຮັດວຽກ. ຂ້າພະເຈົ້າໄດ້ຂຽນກ່ຽວກັບການທົດລອງນີ້ກ່ຽວກັບ Habre in ບົດຄວາມ.

ດີ, ການສະຫນັບສະຫນູນການແຈກຢາຍໃຫມ່ຍັງສືບຕໍ່. ພວກເຮົາກຳລັງລໍຖ້າລຸ້ນ 4.0 ອອກມາ. ເບຕ້າກຳລັງຈະປະກົດຂຶ້ນ, ສະນັ້ນຈົ່ງເຝົ້າລະວັງ ມີ​ຫຍັງ​ໃຫມ່!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com