<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Iso on Morfitronik</title>
    <link>https://morfikov.github.io/tags/iso/</link>
    <description>Recent content in Iso on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Mon, 23 Mar 2020 21:50:00 +0000</lastBuildDate><atom:link href="https://morfikov.github.io/tags/iso/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Pendrive multiboot dla EFI/UEFI z Secure Boot</title>
      <link>https://morfikov.github.io/post/pendrive-multiboot-dla-efi-uefi-z-secure-boot/</link>
      <pubDate>Mon, 23 Mar 2020 21:50:00 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/pendrive-multiboot-dla-efi-uefi-z-secure-boot/</guid>
      <description>&lt;p&gt;Przeniesienie mojego Debiana z laptopa mającego konfigurację BIOS i tablicę partycji MBR/MS-DOS do
maszyny wyposażonej w firmware EFI/UEFI nie było jakoś stosunkowo trudnym zadaniem. Nawet &lt;a href=&#34;https://morfikov.github.io/post/jak-dodac-wlasne-klucze-dla-secure-boot-do-firmware-efi-uefi-pod-linux/&#34;&gt;kwestia
włączenia Secure Boot&lt;/a&gt; okazała się o wiele mniej skomplikowana niż w rzeczywistości mogłoby się
człowiekowi wydawać. Problem jednak pojawił się w przypadku płytek czy pendrive z systemami live.
Nie chodzi przy tym o uruchamianie nośników z dopiero co wypalonymi obrazami ISO/IMG, bo te również
nie sprawiają kłopotów. Chodzi bardziej o rozwiązanie multiboot, które oferuje wgranie wielu
obrazów live na jedno urządzenie i odpalanie tego systemu, który sobie użytkownik w danym momencie
zażyczy. Do tej pory korzystałem z &lt;a href=&#34;https://github.com/thias/glim&#34;&gt;projektu GLIM&lt;/a&gt; i może on posiada wsparcie dla EFI/UEFI ale
już wsparcia dla Secure Boot mu zabrakło. W efekcie w konfiguracji EFI/UEFI + Secure Boot, GLIM stał
się bezużyteczny i trzeba było rozejrzeć się za nieco innym rozwiązaniem. Okazało się, że nie
trzeba daleko szukać, bo &lt;a href=&#34;https://www.rodsbooks.com/refind/&#34;&gt;rEFInd&lt;/a&gt; jest w stanie natywnie uruchomić system z obrazu ISO
praktycznie każdej dystrybucji linux&#39;a (Ubuntu/Debian/Mint/GParted/CloneZilla) i w zasadzie trzeba
tylko nieco inaczej przygotować nośnik, by móc na nowo cieszyć się korzyściami jakie oferuje
pendrive multiboot.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Pendrive multiboot z GRUB2 i obrazami ISO różnych dystrybucji Linux</title>
      <link>https://morfikov.github.io/post/pendrive-multiboot-z-grub2-i-obrazami-iso-roznych-dystrybucji-linux/</link>
      <pubDate>Fri, 08 Nov 2019 18:02:33 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/pendrive-multiboot-z-grub2-i-obrazami-iso-roznych-dystrybucji-linux/</guid>
      <description>&lt;p&gt;Obrazy ISO różnych dystrybucji Linux, szczególnie te live, bywają niezastąpione w sytuacjach
kryzysowych. Dzięki takiej płytce CD/DVD czy pendrive (może być też i karta SD) można wybrnąć nawet
z najgorszych opresji bez potrzeby rezygnowania przy tym z graficznego środowiska pracy
podłączonego do internetu. Zwykle jednak użytkownicy są stawiani przed wyborem systemu, który mogą
sobie wgrać na zewnętrzny nośnik, by w późniejszym czasie przeprowadzać ewentualne prace naprawcze.
Chodzi generalnie o fakt, że taki obraz ISO czy IMG przy wgrywaniu konsumuje całe urządzenie bez
względu na jego rozmiar, i tak mając 32G pamięci na flash możemy wgrać w zasadzie tylko jeden
obraz, np. Debiana, a by wgrać obraz Ubuntu, to już trzeba albo osobnego pendrive albo nadpisać ten
poprzednio wgrany obraz. Takie rozwiązanie jest mało praktyczne i też generuje koszty. Na szczęście
można stworzyć boot&#39;owalny pendrive (w oparciu o GRUB/GRUB2), na którym można umieścić dowolną
ilość obrazów ISO i w fazie rozruchu wybrać sobie ten system, który nas interesuje, a wszystko
dzięki &lt;a href=&#34;https://github.com/thias/glim&#34;&gt;projektowi GLIM&lt;/a&gt; (GRUB Live ISO Multiboot).&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Montowanie obrazów ISO (urządzenia loop)</title>
      <link>https://morfikov.github.io/post/montowanie-obrazow-iso-urzadzenia-loop/</link>
      <pubDate>Thu, 19 Nov 2015 14:17:20 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/montowanie-obrazow-iso-urzadzenia-loop/</guid>
      <description>&lt;p&gt;Użytkownicy Debiana (i innych dystrybucji linux&#39;a) mają czasem poważne problemy z zamontowaniem
&lt;a href=&#34;https://pl.wikipedia.org/wiki/ISO_%28obraz%29&#34;&gt;obrazu ISO&lt;/a&gt; pozyskanego czy to z internetu, czy też
od swoich znajomych. Na windowsach zwykliśmy korzystać z takich rozwiązań jak Daemon Tools, Alcohol
120%, czy też &lt;a href=&#34;http://wincdemu.sysprogs.org/&#34;&gt;WinCDEmu&lt;/a&gt;. Na linux&#39;ach z narzędzi, które mają GUI,
można chyba wyróżnić &lt;a href=&#34;https://launchpad.net/furiusisomount&#34;&gt;furiusisomount&lt;/a&gt; oraz
&lt;a href=&#34;http://sourceforge.net/projects/acetoneiso/&#34;&gt;acetoneiso&lt;/a&gt; ale nie będziemy się nimi zajmować w tym
wpisie. Na dobrą sprawę, to nie potrzebujemy żadnego zewnętrznego oprogramowania, by sprawnie i
szybko zamontować dowolny obraz ISO w swoim systemie. W tym wpisie zostanie przedstawiony sposób
montownia tychże obrazów, który zakłada wykorzystanie urządzeń &lt;code&gt;loop&lt;/code&gt; .&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Suma kontrolna nagranego obrazu .iso</title>
      <link>https://morfikov.github.io/post/suma-kontrolna-nagranego-obrazu-iso/</link>
      <pubDate>Mon, 15 Jun 2015 15:20:52 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/suma-kontrolna-nagranego-obrazu-iso/</guid>
      <description>&lt;p&gt;Suma kontrolna daje możliwość sprawdzenia czy dane zawarte w pliku nie zostały zmienione podczas
transferu z jednego medium informacyjnego na inne. Jeśli weźmiemy przykład pakietów sieciowych, to
pliki przesyłane między dwoma punktami są dzielone na mniejsze kawałki. W każdym z nich są zawarte
sumy kontrole danych, które zawierają. Komputer odbierający taki pakiet generuje własną sumę
kontrolą i porównuje ją z tą otrzymaną w pakiecie. W przypadku gdy suma kontrolna się nie zgadza,
mamy do czynienia z błędami przesyłu, tj. pakiet został uszkodzony gdzieś po drodze. W tej sytuacji
maszyna odbierająca dane prosi o ponowne przesłanie uszkodzonego segmentu. Ta sytuacja może się
zdarzyć ale błędy są automatycznie naprawiane. Problem jest taki, że przy pobieraniu plików z
internetu nie zawsze korzystamy z bezpiecznych połączeń, poza tym, zawsze ktoś może uzyskać dostęp
do serwera i podmienić pliki. Czy możemy zatem mieć pewność, że dany plik trafił do nas w formie
takiej jak powinien?&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
