KALF Computertechniek

arch / antergos bootloader / -manager

Zoals gezegd een stabiel besturingsysteem, mits het opstart!

arch logoArch kan de bootloader niet in een partitie plaatsen, en staat erop dat deze in het MBR geinstalleerd wordt,

Kan je dat geloven? In 2017? Met de multibootmogelijkheden van tegenwoordig?
Het is een truc die we van Microsoft kennen, maar bij een OpenSource systeem heb ik dat nog niet eerder meegemaakt.

Waarom is bij een multibootsysteem de plaatsing van de bootloader in een partitie te prefereren boven het die in het MBR?

Een bootloader (of zo je wil een "bootmanager" ) in het MBR zoals GRUB, start, indien gewenst, een keuzemenu met alle op de schijf aanwezige opstratbare besturingsystemen.
Nu bieden de verschillende besturingsystemen een verschillend uiterlijk van dit menu: van simpele zwart-wit tekst, tekst met mooie achtergronden, iconen van systemen, tot het grafische menu van BURG.

Ikzelf gebruik(te) deze laatstgenoemde BURG optie in mijn default (non-Arch) syteem: Linux Mint.
Bij installatie van besturingsytemen laat ik de bootloader in de partitie installeren zodat bij een systeem update van een specifiek systeem nimmer mijn BURG-bootloader gewist kan worden.
Het enige nadeel is dat ik in burg.cfg handmatig de eventueel geupdate kernelversienummers moet aanpassen,
(het kan automatisch, maar de kans bestaat dat mijn zorgvuldig opgebouwd custom menu beschadigs raakt)
En dat Linux Mint deze default niet overneemt en daarom bij een systeem upgrade altijd de GRUB-loader installeert.

Dus, na de geslaagde installatie van Antergos gebruik ik nu tijdelijk dat aangeboden menu.
Echter, de laatste kernelupgrade in Mint heeft de GRUB bootloader geinstalleerd waardoor Antergos niet meer opgestart kan worden.

Lees hier hoe d.m.v " chroot" de bootloader te herstellen..

mlocate werkt niet

Mlocate is een snelle file finder met een database backend.
Helaas wordt /usr/bin, waar o.a. locate en slocate zich bevinden niet in het terminal/shell PATH$ opgenomen. (???)
Om deze onmisbare functie toch bruikbaar te maken, voegen we /usr/bin aan het PATH toe in .bashrc

#set path for shell
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Sla het bestand op en maak een symlink van locate naar mlocate
sudo ln -s /usr/bin/locate /usr/bin/mlocate
Valideer de PATH$ aanpassing via:
source ~/.bashrc

automount networkdrive in arch

automount netdrivesAnders dan bij de Debian's, Ubuntu's en Mint distros, blijkt het netwerk door Arch pas in een laat bootstadium gestart te worden.
Als gevolg hiervan flitst er een foutmelding voorbij met betrekking tot de "failed". koppeling van de netwerkschijven.
Daarnaast is het niet vanzelfsprekend dat de gebruiker de baas wordt over deze schijven!

Om dat alles op te lossen heeft de /etc/fstab in Arch wat extra parameters nodig:

Debian / Ubuntu / Mint manier:

10.0.0.5:/media/data /media/data nfs defaults,auto,noatime,nofail,_netdev 0 0

Waarbij de parameters aangeven:

  • defaults = rw, suid, dev, exec, auto, nouser, and async. o.a. gebruikers permissie om evt zelf de schijf aan te koppelen
  • auto = automatisch aankoppelen bij opstarten (defaults heeft nl de "N0-USER" optie!)
  • noatime = toont geen update van de datum en tijdstempel bij gebruik of manipulatie van een bestand 
  • nofail = indien netwerk nog niet gereed is, dient het systeem geen foutnelding (failed mount) te geven en niet te wachten op userinput.
  • _netdev = schijf aankoppeling vindt alsnog plaats wanneer het netwerk "UP" is. (geldt alleen voor NFS)
  • Klik hier voor de expliciete uileg

De Arch manier:

Arch is meer gesloten en veiliger dan de eerder genoemde distro' s, wat af en toe complicaties geeft wanneer de gebruiker in " Debian's"  blijft denken :-) mede omdat ARCH " Systemd" helemaal geintegreerd heeft, waar de andere distributies nog weleens  het verouderde " Sysvinit" niet helemaal los kunnen laten ( lees de verschillen )

De mountregel voor dezelfde NFS netwerkschijf wordt nu:

10.0.0.5:/media/data /media/data  nfs  user,noauto,nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10  0  0

De parameters in dit geval:

  • user = de gebruikerheeft rechten om te (un-)mounten
  • auto = indien gebruikt, wordt de schijf automatisch aangekoppeld
  • noauto = indien gebruikt, wordt de schijf door de gebruiker aangekoppeld d.m.v. een muisklik
  • nofail = indien netwerk nog niet gereed is, dient het systeem geen foutnelding (failed mount) te geven en niet te wachten op userinput.
  • x-systemd.automount = laat het systeem via systemd de mount starten
  • x-systemd.requires=network-online.target = voor de koppeling is het netwerk nodig, geen netwerk: geen poging tot aankoppelen
  • x-systemd.device-timeout=10 = process wordt met vertraging van 10 seconden opgestart

Zowel "noauto" als " auto" zijn opgenomen. (kan dubbelop zijn, maar het werkt!)

  • noauto om een te vroege koppeling, zonder netwerk, te voorkomen
  • auto om aan te geven dat de schijven wel automatisch aangekoppeld worden, wat vervolgens door systemd wordt uitgevoerd. (zoals gezegd, in mijn geval vermoedelijk een overbodige optie. Kom ik later op terug))
Bij gebruik van de Debian notatie lukte het maar niet om de netwerkschijven bij het booten te koppelen, en om de gewenste gebruikers-permissies toe te kennen.

Schijven moesten bij elke boot handmatig gekoppeld worden met het commando:

sudo mount -av

Het heeft wel wat zoekwerkg gekost om tot deze oplossing te komen, maar het is gelukt met behulp van de archwiki !


Drucken