Ontwikkelaar krijgt bootable Linux-installatie werkend op Google Drive

Een ontwikkelaar heeft een Arch Linux-installatie opgestart op een laptop zonder ssd, hdd of andere vorm van lokale opslag. De developer installeerde het OS in plaats daarvan op Google Drive met behulp van verschillende tools en bugfixes.

Het bootable Linux-systeem werd op Google Drive geïnstalleerd door Ersei, een student computerwetenschappen aan de Purdue University. Naar eigen zeggen deed de ontwikkelaar dat om een medestudent te overtreffen die Linux installeerde op een nfs, oftewel network file system.

Voor het installatieproces werden twee systemen gebruikt. In de eerste plaats gaat dat om FUSE, waarmee gebruikers een bestandssysteem kunnen maken in de userspace. Dat werd gecombineerd met initramfs, een stap in het Linux-bootproces waarbij een tijdelijk bestandsysteem door de Linux-kernel wordt uitgepakt naar het werkgeheugen, om vervolgens het daadwerkelijke bestandssysteem in te laden.

Voor de Google Drive-installatie moest initramfs ondersteuning bieden voor internetverbindingen en de FUSE-tool. Normaal gesproken kunnen gebruikers initramfs echter niet aanpassen, maar via een tool genaamd Dracut kunnen ze een eigen initramfs ontwerpen om aan de eisen te voldoen. Ersei kreeg de installatie in eerste instantie werkend in een container. De student gebruikte daarvoor een bestaand project, genaamd google-drive-ocamlfuse, om FUSE te draaien op Google Cloud. Ersei moest daarop enkele problemen oplossen rondom niet-werkende symlinks, roottoegang en meer.

Nadat dat alles werkte, werd het systeem overgezet naar een laptop zonder lokale opslag, zodat het cloudopslag-OS op echte hardware getest kon worden. Alles lijkt te werken, hoewel het OS vrij traag functioneert. De ontwikkelaar noemt het project dan ook 'maf', maar stelt dat er ook usecases voor dergelijke Linux-installaties zijn.

Arch Linux op Google Drive. Bron: Ersei
Arch Linux op Google Drive. Bron: Ersei

Door Daan van Monsjou

Nieuwsredacteur

03-07-2024 • 15:35

49

Reacties (49)

49
49
16
2
0
32
Wijzig sortering
Je kan in legacy BIOS mode of UEFI via bijvoorbeeld iPXE HTTPS-verbindingen (inclusief de nodige controles op communicatiebeveiliging d.m.v. TLS) maken om de kernel en initramfs op te halen om te booten. Vanuit daar kan je elk (kernel/FUSE) filesystem gebruiken die je in het initramfs voorbereid hebt. Zo zou je ook bijvoorbeeld WebDAV of git kunnen gebruiken, je Android-apparaat via USB of zelfs een torrent als read-only filesystem. :+ Het zou ook kunnen bij de tegenhanger van Amazon.
Normaal gesproken kunnen gebruikers initramfs echter niet aanpassen, maar via een tool genaamd Dracut kunnen ze een eigen initramfs ontwerpen om aan de eisen te voldoen.
Een initramfs pas je niet aan. Die bouw je op. Dracut is één manier om dat te doen. Arch Linux gebruikt normaliter mkinitcpio, waar dit ook mee zou kunnen.

[edit]
Volgens een reactie hieronder zou een bootable drive gebruikt worden. Dat is natuurlijk een beetje valsspelen. Betere voorstellen:

• Via standaard PXE kan je over een netwerk via TFTP iPXE inladen, waarna je alles verder via HTTP(S) kan doen.
• Je kan op bepaalde systemen EFI drivers toevoegen aan de firmware. iPXE is te compileren als EFI driver, waardoor het na het kiezen als optie in het boot menu direct vanuit onboard flash wordt geladen. Dan is het echt onderdeel van het systeem zelf, en heb je geen TFTP server (en speciale DHCP-configuratie) nodig.

Verdere verbetervoorstellen:

• Secure Boot-ondersteuning toevoegen, zodat de integriteit van bootbestanden opgehaald vanaf het internet wordt gewaarborgd.
• Een encrypted filesystem gebruiken voor overige bestanden, optioneel afhankelijk van sleutelmateriaal gebonden aan het gebruikte platform.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:20]

Zet de inhoud van een RHEL8 DVD op je google drive, maak het openbaar.
Pas je dhcpd(6) aan (deze heb je toch nodig voor het verkrijgen van een IP, met
class "httpclients" {
match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient";
option vendor-class-identifier "HTTPClient";
filename "https:/URL/shimx64.efi";
}
En boot op in UEFI en gaan met die banaan :) Je zou bijna denken, dat ik it al eens gedaan heb ;p

Overigens, kan je dit ook oen met een Ubuntu live DVD :)

[Reactie gewijzigd door wica op 22 juli 2024 15:20]

En boot op in UEFI en gaan met die banaan :)
Hoe haal jij iets op bij Google via HTTP zonder TLS?
Heb de s toegevoegd :)
Nee, zonder https kom je niet bij google, hier gebruiken we http voor het inspoelen van servers vanaf onze eigen repo's. Nog een puntje ter verbetering :)
Dank, ik miste de bios https stap in het artikel en vroeg me al af hoe je een laptop ging instrueren iets op te halen bij Google Drive zonder OS of bootloader (oid). :)
Ik begrijp hier werkelijk niks van, want geen achtergrond in, dus kan iemand een eli5 geven:
Hoe wordt de verbinding naar de drive gelegd zodra je het systeem aanzet?
Gebeurt dit direct in de bios en is de serverlocatie als bootable opgegeven? Kan dat zomaar?
In het artikel waar naar gelinkt word zegt de student dat hij alles op een bootable usb drive zet. Technisch gezien gebruikt hij dus geen hdd of ssd, maar hij heeft wel iets van storage nodig om van te booten en om initramfs op op te slaan.
en een usb-stick is echt wel lokale opslag, en het artikel zegt:
zonder ssd, hdd of andere vorm van lokale opslag.
Wat mij betref weer super slecht en ongenuanceerd voor een tech-site.
Als we echt gaan muggenziften, staan de bios settings natuurlijk ook ergens lokaal opgeslagen.
Zo muggenziften vind ik het niet. Ik wist na de lezen van het artikel niet waar de initramfs vandaan moest komen als je helemaal geen lokale opslag hebt. Die initramfs moet toch ergens staan. Dat kan met tftp, maar daarover werd niks gezegd. Als je inderdaad een usb stick nodig hebt is het hele project eigenlijk zinloos. Dan kun je net zo goed al je bestanden op de stick zetten en het internetgebeuren overslaan. Oftewel een standaard live distro.
De bios settings staan niet in iets wat we normaal als (mass) storage zouden omschrijven. Hdd, Sdd, stick etc. Dus enig verschil is er wel.

Als die persoon nou netboot had gebruikt of zo, dan had het anders geweest, netboot is onderdeel van de bios set van die machine. En werkt zonder lokale mass storage, maar dat is niet wat hier gedaan is. Hier is een stick gebruikt en dat is volgens alle definities lokale mass storage.

Fuse achtige dingen doen met een google drive is een leuk experiment. Maar het moet wel correct omschreven worden. Iets dat de media niet doet.
Net zoiets als een thin client (ica cliënt)zegmaar?
Over het algemeen zet je netwerk boot en DHCP aan op je netwerk kaart en in de DHCP server zet je TFTP aan (of je zet ergens een locatie van een tftp server erin) , via die TFTP server haalt hij dan een bootloader binnen die de rest gaat doen - is al een jaar of 20 geleden eer ik dit gebruikt heb dus mogelijk is het ondertussen iets praktischer geworden...; als ik dit verhaal verder goed begrijp is die bootloader lichtelijk aangepast zodat die z'n hele meuk daarna van google drive trekt. Leuk...echt praktische usecases zijn dan weer een andere discussie.
Je kan met PXE booten, als je een DHCP server en TFTP server in je netwerk hebt hangen, daar op een bootimage zetten die daarna de kernel van Google drive laadt
Sinds wanneer is het aanpassen van het initramfs niet mogelijk, daar is gewoon mkinitrd voor?
Sinds wanneer is het aanpassen van het initramfs niet mogelijk, daar is gewoon mkinitrd voor?
Exact, hier slaat het artikel de plank finaal mis.
Iedereen kan in principe zijn eigen initramfs bouwen en aanpassen is uiteraard ook mogelijk.

Het is gewoon een kwestie van uitpakken, aanpassen en weer inpakken.

Het gebeurt wel met een compressieformaat dat bij velen niet bekend is.

Uiteraard is het wel zo dat het ding niet (gemakkelijk, want het kan wel) meer aan te passen is nadat het systeem reeds is opgestart.

[Reactie gewijzigd door vliegendekat op 22 juli 2024 15:20]

Bij mijn vorige baan als systeembeheerder had ik een compleet serverpark draaien met een automatische installer. Via PXE een kernel met initramfs booten en vanuit initramfs de lokale disk partitioneren, formatteren, image uitpakken en dan verder booten.
Server bijplaatsen was MAC, IP en image instellen in configfile, server in het rack hangen en binnen 2 minuten live meedraaien in het cluster.
Uiteraard is het wel zo dat het ding niet (gemakkelijk, want het kan wel) meer aan te passen is nadat het systeem reeds is opgestart.
Wat bedoel je daarmee? Het bestand zelf is prima aan te passen, dat staat gewoon op je schijf (meestal in /boot). Het bevat een bestandssysteem, wat gemount wordt op de root (/), en gemounte bestandssystemen zijn sowieso makkelijk aan te passen (cp, mv, rm, etc). En nadat het z’n opstart routine gedaan heeft, wordt het vervangen door het gewone fs, en heb je m niet meer nodig. Het is niet voor niks een tijdelijk fs dat alleen in het geheugen staat (initial ram filesystem). Dat geheugen kun je daarna weer voor andere dingen gebruiken wanneer je de “normale” schijf op / mount. Dus wat er niet aan te passen is mis ik hier volledig. Alles in Linux is aan te passen 8-)
Je mist het feit dat het initramfs meestal na de start gemount blijft.

Ja, je kan er een / overheen mounten, maar dat eerste FS staat meestal nog steeds ergens en kan zonder een herstart, kexec of andere truuks, niet meer eenvoudig worden aangepast nadat get de eerste keer is ingeladen. Mede daarom is het ook prettig om het zo klein mogelijk te hebben.
Dus eigenlijk wat we vroeger al met DOS/Windows/Novell deden.

Maar wel knap en veel doorzettingsvermogen _/-\o_
Ik zat dat net te denken, dit delen we al met Windows 95 en Linux, i ik ieder geval z’n 25 jaar geleden. Ook netwerk install. Het verschil wel ligt nu over http?
Ik deed dit 25 jaar geleden al met dhcp, tftp en nfs. Compleet diskloze systemen die alles op het netwerk opslaan. Het enige nieuwe hier is een afhankelijkheid op Google. Wie heeft daar nou nog meer van nodig…
Een ontwikkelaar heeft een Arch Linux-installatie opgestart op een laptop zonder ssd, hdd of andere vorm van lokale opslag
Volgens mij niet helemaal zonder lokale opslag: I build the unified EFI file, throw it on a USB drive under /BOOT/EFI, and stick it in my old server.
Logisch, de bootloader moet ergens staan.
Dit is gewoon de werking van werkelijk elke Linux live-cd gecombineerd met een mounted FUSE.
Zoals @The Zep Man voorsteld zou het booten van het geheel via old school PXE al een stuk nicer zijn. Nadeel is wel dat je dan minder flexibel bent met de inzetbaarheid op elke plek.

Feit dat dit een frontpage haalt van Tweakers is eigenlijk wel een beetje triestig. Je ziet aan de manier van schrijven dat de redacteur totaal geen idee heeft van de gebruikte techniek. Ik noem dat de Teletubificatie van de IT sector. Ik zie het op mijn werk ook. Vroeger werkten wij met 60 diehard IT'ers. Nu zijn er nog maar 20 over en de andere 40 zijn al blij als ze een Microsoft PowerAppje in elkaar geklikt hebben.
zonder ssd, hdd of andere vorm van lokale opslag.
Onzin, de initramfs image, de bootloader, al die dingen draaien gewoon op lokale storage. Stick, CD of wat dan ook.
Onzin, de initramfs image, de bootloader, al die dingen draaien gewoon op lokale storage. Stick, CD of wat dan ook.
Als je al zover bent, is het nog slechts 1 stap om het in te bouwen, over PXE te sturen, of misschien zelfs met een directe live-download te regelen.
Die iter reactor is helemaal klaar. Nog 1 stap om het aan te zetten.....

Ja, netboot zou het meer waar maken, maar dat is niet gebeurd en niet gedaan, dus de rapportage is gewoon fout. Je kan niet iets als gebeurd presenteren als het niet gebeurd is.

Anders heb ik nog een brug te koop en een eifeltoren. die heb ik gisteren van de Fransen overgenomen....
(dat is niet werkelijk gebeurd, maar het zou kunnen.... en dat is toch goed genoeg voor jou?)


Het was een grappig experiment voor komkommertijd nieuws, maar verder totaal niet noemenswaardig en heel verkeerd gerapporteerd.
In mijn ogen zijn ze al zo ver, dat ik ze die laatste stap door de vingers zie.
Je hebt pas bewezen dat je iets kan als je het ook werkelijk doet. Het is goed mogelijk dat deze persoon netboot opzetten nog niet geleerd heeft.
Je hebt pas bewezen dat je iets kan als je het ook werkelijk doet. Het is goed mogelijk dat deze persoon netboot opzetten nog niet geleerd heeft.
Als hij reeds zo ver is gekomen, dan lukt netboot opzetten hem ook wel, maar kan het wellicht niet in een universiteitslab omdat hij geen toegang tot de routers, of een tweede machine die als router/dhcp/tftp-server kan dienen.

Ik zie dat dus door de vingers.
Ik zat in eerste instantie te denken dat het systeem geboot werd vanaf, kort gezegd, een ISO die zich in Google Drive bevindt. Maar zoals ik het lees is het dus een compleet werkend systeem waar het OS is 'geïnstalleerd' op een Google Drive locatie op het internet.

Het enigste wat ik niet direct kan vinden is hoe het systeem start. Want wat je ook maakt, je moet altijd een bestand of iets dergelijks hebben om het hele proces te starten, zeker als je iets 'customs' als dit maakt. Het lijkt te starten met een zelfgemaakte EFI image. Maar daar heb je toch opslag voor nodig, niet? Zit er opslagruimte in het UEFI waar dit er dan bij geplaatst kan worden?
Nee, het systeem word gestart vanaf een USB stick. Compleet zonder lokale opslag is het dus niet, maar wel indrukwekkend.
Het is knap dat je het vanaf google drive kan doen, maar via nfs deden we (met Redhat) al 15 jaar gelden. Een blade vm booten via nfs, voor zover ik me kan herinneren geen lokale storage alleen via PXE een bootimage halen en de rest mounten van de SAN via nfs. Ik dat nog steeds eens thuis gaan doen vanaf mijn NAS, maar de kennis is enig sinds weggezakt....
Ik dat nog steeds eens thuis gaan doen vanaf mijn NAS, maar de kennis is enig sinds weggezakt....
Succes met het matchen/mappen van de uid's en gid's die op een nas vaak niet matchen met het linux-systeem dat u voor ogen heeft.

Met NFS en dan vanaf een nas is het dus een slecht idee. Andere protocollen zijn waarschijnlijk succesvoller.
Dat is een goed punt, niet aan gedacht. Dan "cheat" ik wel door een vm te maken met het zelfde OS en dan vanaf daar een nfs share aan te bieden, dan vermijd ik dat in eerste instantie
Dat gaat niet voor problemen zorgen, je kunt gewoon NFS gebruiken op de NAS en die shares mounten op de clients.
Dat gaat niet voor problemen zorgen, je kunt gewoon NFS gebruiken op de NAS en die shares mounten op de clients.
Uiteraard kan dat, maar ook dat gaat (tenzij je in een single-user omgeving zit) wel degelijk ergens voor problemen zorgen.

En als je single-user bezig bent, vraag ik me af waarom je dit over NFS zou draaien...
En waarom zou dat voor problemen zorgen met meerdere gebruikers als deze standaarden bedoeld zijn om meerdere gebruikers te kunnen onderhouden... Je kunt hele user folders exporteren en dit werkt zonder problemen op schaal ook binnen bedrijven die terminal sessies gebruiken voor customer support waar tientallen agents op dezelfde server aan het werk zijn!

Ik had jaren lang een LTSP server, als ik dan thuis kwam van school/werk boot ik via het netwerk en kon zo vrij simpel in een nieuwe omgeving mijn werk doen.
Omdat een NAS zijn eigen uid/gid administratie heeft en je bij het gebruik van NFS erop vertrouwt dat de client-machines exact hetzelfde schema gebruiken als de NAS-box.

Er zijn systemen die iets aan mapping doen, maar dan wordt alles weer gedwongen gemapt, met als gevolg dat je soms bepaalde permissies expliciet verkeerd gaat mappen.
Stiekem is een initialramdisk (geen initramfs, die term is al jaren uit de gratie) een mini Linux omgeving, waar alles uitgesloopt is wat niet nodig is. Op een systeem met een dracut initrd (zoals Fedora) moet je voor de grap maar eens `sudo lsinitrd` doen en kijken wat er allemaal in je initrd zit. Je kunt daar met dracut (via `/etc/dracut.conf.d/*.conf`) vrij makkelijk zaken aan toevoegen.
Stiekem is een initialramdisk (geen initramfs, die term is al jaren uit de gratie)
Dat is nieuws voor mij. :P Het is beter om te zeggen dat `initramfs` een specifieke implementatie van een ramdisk is. Het is dubbel ironisch dat je zegt dat deze term "uit de gratie" is en je het daarna doodleuk hebt over `initrd`, want `initrd` is nu net wat in de meeste distro's niet meer gebruikt wordt. De tools verwijzen vaak nog naar `initrd` in de bestandsnaam als legacy (net als `vmlinuz`), maar ze werken stiekem bijna allemaal op `initramfs`, dat alweer bijna 20 jaar oud is.

Als je iets met cpio in elkaar aan het bastelen bent kun je er van uit gaan dat je te maken hebt met een `initramfs`, waaronder dus ook dracut.
Sorry, after dinner dip, draai initrd en initramfs om in mn reactie
(geen initramfs, die term is al jaren uit de gratie)
Uit interesse, waar is de term uit de gratie? AFAIK is het een afkorting voor Initial Ram File System wat nog overal gebruikt word.

Om het een mini Linux omgeving te noemen is een beetje kort door de bocht, het is namelijk verantwoordelijk voor het voorbereiden en het starten van de Linux kernel (het doet namelijk zaken als belangrijke mountpoints als /usr mounten, maar ook een aantal kernel modules laden). Er draait zelf eigenlijk geen process om het Linux te noemen. Zodra het init process draait is dan ook zijn taak volbracht en zitten we echt in Linux.
Sorry, dat was een after dinner dip momentje, vervang initrd door initramfs in mijn reactie..
Om het een mini Linux omgeving te noemen is een beetje kort door de bocht, het is namelijk verantwoordelijk voor het voorbereiden en het starten van de Linux kernel (het doet namelijk zaken als belangrijke mountpoints als /usr mounten, maar ook een aantal kernel modules laden). Er draait zelf eigenlijk geen process om het Linux te noemen. Zodra het init process draait is dan ook zijn taak volbracht en zitten we echt in Linux.
Nou, dat ben ik toch niet echt met je eens. Start een dracut initramfs maar eens op in rescue mode, het is écht een zelfstandig (mini) linux installatie. Het doet ook wel wat meer dan alleen je /usr mounten, dat is zeker met btrfs bestandssystemen je root subvol en je home subvol (/ en /home).

Als je met `sudo lsinitrd` ook kijkt zie je een complete kernel installatie, met als kernel `usr/lib/modules/6.9.6-200.fc40.x86_64/vmlinuz`. Pas als dit geladen is en z'n ding gedaan heeft start je "echte" installatie door en word de controle overgedragen.

Op dit item kan niet meer gereageerd worden.