Berichten

Geplaatst op

IPv6 – nogmaals

Vorige week heb ik – eindelijk – een laadpaal geinstalleerd ter vervanging van de kabel die al ruim 6 jaar uit het zolderraam hing te bungelen. Voordat de stroom er af ging, heb ik alle apparatuur in het zicht netjes uitgeschakeld, maar de server staat niet in het zicht en kwam niet meer online toen er weer stroom was.

Zodra ik dat door had, kon ik met een handmatige ingrepen het gros weer draaiend krijgen, voor het moment, maar na een blikseminslag vandaag was de stroom er opnieuw vanaf met hetzelfde resultaat: website en webservices off-line.

Iets wat zowiezo nog niet goed werkte, en nu dus zeker niet, was het betrouwbaar uitdelen van IPv6-adressen in het netwerk. Daarbij kwam nu dat IPv4 niet goed terechtkwam.

In de logging van OPNsense viel me op dat er regelmatig no route to host gemeld werd:

<187>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="5"] send_packet6: No route to host

Daar had ik eerder nog niet naar gezocht, of niet op de juiste zoekresultaten geklikt. Deze keer klikte ik een link naar het Netgate forum, waar met name een post er uitsprong. Het relevante deel:

I added to the bridge a link local IPv6 address … Soon after the DHCP log started indicating the DHCP response completed successfully

wallabybob

Ik controleerde de configuratie van de bridge op de router; er was wel een IPv6-adres aan toegekend, maar geen local link adres. Bovenstaand citaat is uit 2011, ruim 12 jaar geleden. Ik kon bijna niet geloven dat ik nu nog steeds tegen dat probleem aan kon lopen, maar na lezen (en leren) van de rest van de thread heb ik het toch geprobeerd: 

# ifconfig bridge0 inet6 add fe80::5a9c:fcff:fe10:ff91/64

Geloof het of niet, maar direct daarna verdwenen de no route to host‘s , en verschenen daarvoor in de plaats Reply NA‘s; zie de stukjes log, als eerste de fouten:

<190>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="1"] Solicit message from fe80::dab6:b7ff:feb7:981a port 546, transaction ID 0x577C2900
<191>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="2"] Picking pool address 2a10:3781:2d49:172:26:90:0:f525
<190>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="3"] Advertise NA: address 2a10:3781:2d49:172:26:90:0:f525 to client with duid 00:03:00:01:d8:b6:b7:b7:98:1a iaid = -1212704742 valid for 7200 seconds
<190>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="4"] Sending Advertise to fe80::dab6:b7ff:feb7:981a port 546
<187>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="5"] send_packet6: No route to host
<187>1 2023-07-09T20:39:33+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="6"] dhcpv6: send_packet6() sent -1 of 104 bytes
<190>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="7"] Solicit message from fe80::225:61ff:fee3:1ee0 port 546, transaction ID 0xFB62AD00
<191>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="8"] Picking pool address 2a10:3781:2d49:172:26:90:0:f79c
<190>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="9"] Advertise NA: address 2a10:3781:2d49:172:26:90:0:f79c to client with duid 00:03:00:01:00:25:61:e3:1e:e0 iaid = 2424874 valid for 7200 seconds
<190>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="10"] Sending Advertise to fe80::225:61ff:fee3:1ee0 port 546
<187>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="11"] send_packet6: No route to host
<187>1 2023-07-09T20:39:44+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="12"] dhcpv6: send_packet6() sent -1 of 100 bytes
<190>1 2023-07-09T20:39:46+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="13"] Information-request message from fe80::ec4:7aff:fec1:25e4 port 546, transaction ID 0x7A418D00
<190>1 2023-07-09T20:39:46+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="14"] Sending Reply to fe80::ec4:7aff:fec1:25e4 port 546
<187>1 2023-07-09T20:39:46+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="15"] send_packet6: No route to host
<187>1 2023-07-09T20:39:46+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="16"] dhcpv6: send_packet6() sent -1 of 73 bytes

… daarna de correcte verwerking: 

<190>1 2023-07-09T21:55:09+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="19"] Solicit message from fe80::dab6:b7ff:feb7:981a port 546, transaction ID 0x577C2900
<191>1 2023-07-09T21:55:09+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="20"] Picking pool address 2a10:3781:2d49:172:26:90:0:f525
<190>1 2023-07-09T21:55:09+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="21"] Advertise NA: address 2a10:3781:2d49:172:26:90:0:f525 to client with duid 00:03:00:01:d8:b6:b7:b7:98:1a iaid = -1212704742 valid for 7200 seconds
<190>1 2023-07-09T21:55:09+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="22"] Sending Advertise to fe80::dab6:b7ff:feb7:981a port 546
<190>1 2023-07-09T21:57:08+02:00 vpoort.osba.nl dhcpd 54250 - [meta sequenceId="133"] Reply NA: address 2a10:3781:2d49:172:26:90:0:f525 to client with duid 00:03:00:01:d8:b6:b7:b7:98:1a iaid = -1212704742 valid for 7200 seconds

Ik ben er nog niet uit hoe het met de volgordelijkheid zit: eerder liepen de meta sequence id’s slechts tot ergens in de 20, nu ver voorbij 100. Nummers <190> en <191> lijken OK, de eerdere fouten vallen onder <187>.

Het resultaat is nu dat opeens heel veel apparaten een IPv6 toegewezen hebben gekregen. Waar ik er eerst met hangen en wuren twee of drie kreeg, instabiel (telkens andere IP’s, telkens andere apparaten), is er nu opeens een hele lijst.

Nog te doen: herkenbare statische leases aanmaken voor vaste apparatuur, en natuurlijk waar het om begon: zorgen dat de webserver een IP krijgt tijdens boot.

Print this entry

Geplaatst op

Printer troubleshoot: HP Photosmart 3310 all-in-one – 0x18a0206 (Inktsysteem-fout)

Deze printer heb ik een keer gekregen als ‘alleen om te scannen, printen werkt niet’. De printer lijkt dezelde als de photosmart C7180.

to clear a fault for the HP c8180, press both “Red Eye Removal” and “Print Photos,” and it will ask for a special key combo. Press “Red Eye Removal,” then “Print Photos,” then “Red Eye Removal” again and the menu will open. Use the right arrow on the menu to scroll to “System Configuration Menu” and click OK. Scroll to “Hardware failure status” and press “OK” to clear.

Er is geen ‘Rode ogen’- of ‘Red eye’-knop, of ‘Print foto`s’.

HP C5180 All-In-One Printer HARD RESET:Hold down HELP + OK button and unplug printer (…) Hold down HELP + OK button again as you plug the printer back in. Then power it on, if it doesn’t power on automatically. Be Safe: keep holding the buttons until the printer turns itself off. (It took mine less than a minute.)Now you can release the buttons and simply power it back on. After I clicked “OK” the printer was just fine and didn’t mind anymore. And now I can print.

Dit werkt niet bij deze fout op de Photosmart 3310

hp c6180 to fix error 0xc18a0101 : You can do deep power cycle by removing the power cord for 1 minute and then pressing and holding the power button and plugin in to the power at the same time.

Dit werkt niet bij deze fout op de Photosmart 3310

error 0xc18a0101 occurs typically in HP Photosmart printers when printer head is clogged, in particular it happened in my Photosmart 3310. The following action solved my problem: push simultaneously OK, Cancel, Black and Color buttons (i.e. these 4 buttons at once). This rest printer program and you can print again but, this action does not clean the printer head (you can see a little improvement, though), so after of this follow the any procedure about how to clean the printer head.

Deze optie was het! OK en Cancel samen met Zwart en Kleur. Ik weet niet zeker of ik het samen met inschakelen, uitschakelen, of op zich deed. In ieder geval niet met de stekker. De printer ging terug naar blanco instellingen, en vroeg als eerste om de gewenste taal.

Na basisinstellingen is de printer een kwartier bezig geweest met rommelen en inkt tanken. De inktsysteem-fout was weg!

Een andere tip, via Youtube, is om de power en cancel buttons tegelijk ingedrukt te houden terwijl de printer aan staat. Kan ik de volgende keer proberen, ik ben blij dat deze nu werkt en ga de (mogelijk fragiele) situatie niet resetten zonder dat het nodig is.

Na de testprint die volgt op een koppenspoelprogramma, deden enkel blauw en geel het, met een paar sporen zwart. Na een test met een zwart/wit kopie om de zwarte inkt verder uit te spuiten, gaf het papier-oppakmechanisme er de brui aan. Wat printen betreft wilde ik het daarbij laten, en eerst de film-scan-functie uitproberen.

Daarvan wilde ik een ‘contactafdruk’ op fotopapier maken, omdat fotopapier in een andere lade zit en misschien geen probleem met oppakken heeft. Toen ik daarmee eenmaal zover was dat ik een print kon maken, leek het initieel of de overige kleuren ook weer werkten: er zit in ieder geval veel rood in de foto.

Next: papier-roller schoonmaken. Bij het schoonmaken van de papier-roller kwam meteen het probleem aan het licht: een stuk play-dough, of opgedroogde inkt, had een stuk papier vastgeplakt aan de uitgang van de papierbak, net uit het zicht aan de voorkant, en onopvallend aan de achterkant. Na het verwijderen van dat vel was er geen probleem meer met de papiertoevoer.

Terug naar de print zelf. Cyaan, licht cyaan en geel komen er goed uit, zwart half. Magenta en licht magenta, in het statusrapport, totaal niet.

Na een A4’tje vol kleine lettertjes (negen willekeurige pagina’s uit een ebook, met 3×3 pagina’s per vel A4) komt zwart er perfect uit.

Ik weet niet hoe ik een epub in magenta kan printen, daarom copy/paste naar een teksteditor, in een 6-punts-lettergrootte en 100% magenta. Via formatting/columns op twee kolommen ingesteld, en find/replace met $ gebruikt om de ¶’s te vervangen omdat er elke anderhalve regel een harde newline in de tekst zat.

Tot mijn verbazing komt er met het eerste A4’tje leesbare tekst uit. Het lijkt niet volledig magenta, maar zeker niet geel, cyaan of groen. Dat was met de instelling ‘kleur, beste kwaliteit, op fotopapier’. Een tweede poging, nu met ‘kleur, fotokwaliteit, op fotopapier’ brengt aan het licht wat er gebeurt: cyaan en magenta worden gemengd. Magenta komt er wel door, maar met wat moeite. Na de eerste A4 lijkt het wat uitgeput, en de tweede A4 komt voor driekwart in volledig cyaan, om dan in een gradient over te gaan naar paarsig.

Een derde test, met gradienten wit –> magenta komt er ‘perfect’ uit: de tekst is weer paarsig, maar de gradienten gaan zonder witlijnen van wit naar lichtroze, magenta zou je zeggen.

Eerder had ik een alignment-print gedaan, die mislukte omdat, gok ik, zwart toen half werkte. Nu ik nogmaals een alignment-print maak, slaagt die wel. Het toont dat naast zwart, geel en (licht) cyaan, nu ook magenta volledig kleurt. Licht magenta blijft volledig leeg.

Nog een test: dezelfde pagina met de magenta gradienten, maar nu echt op fotopapier, uit de fotolade. De instellingen zijn ‘kleur, fotokwaliteit op fotopapier’. De tekst wordt cyaan geprint, magenta ontbreekt volledig. Misschien wordt voor fotokwaliteit licht magenta aangesproken, daarom dezelfde test nogmaals, maar dan met als instellingen ‘kleur, beste kwaliteit, op fotopapier’. Zelfde resultaat 🙁

Ik verwachtte oorspronkelijk, voor ik van het weekeind aan de slag ging en eerst de foutcode weg wilde krijgen, dat ik lucht uit de leidingen moest halen. “Prime” de printer. Dat bleek dus niet het geval, althans, ik denk dat de printer dat in het kwartier rommelen na de reset gedaan heeft.

Magenta en met name licht magenta waren misschien verder leeg / meer met lucht gevuld dan de rest. Magenta heeft het ‘soort van’ opgepakt: in ‘beste’ en ‘fotokwaliteit’ komt er kleur uit, maar in de stand die de printer gebruikt voor rapportages (normaal? concept?) blijven de magenta varianten blanco.

Op ‘t Net zag ik een filmpje over het verwijderen van lucht uit een CISS-opstelling voor een cartridge met geintegreerde printkop: met een halfvolle injectiespuit de boel vacuum zuigen (lucht + inktresten uit de container). De restjes inkt en de lucht komen in de injectiespuit met inkt terecht; de lucht gaat naar boven. Laat de injectiespuit daarna rustig terugkomen in de startpositie: de inkt wordt naar binnen gezogen, de lucht blijft in de spuit.

Datzelfde heb ik toegepast op de licht magenta aansluiting; voor extra effect in plaats van inkt een milliliter mengsel van 2 delen spiritus en 1 deel ammoniaoplossing. Inktpatroon eruit genomen, spuit aangesloten op de inktpoort met een centimetertje flexibele slang. Eerst naar buiten trekken, luchtbellen naar boven laten borrelen, langzaam laten vieren, en dat een paar maal herhalen, telkens iets verder vacuum zuigen. Op die manier is er enkele milliliter lucht en evenveel inkt uit de leiding gekomen.

Terug om te testen: het is niet meteen optimaal, maar de eerste testfoto heeft al een flink magentazweem op de plaatsen waar dat zou moeten.

Een paars A4’tje verder komt er een overtuigende hoeveelheid (licht) magenta uit de printer – zolang ik maar op ‘beste’- of ‘foto’-kwaliteit print.

Aanvulling voor een volgende keer: de zogenaamde ‘Tap n’ codes/tests: power ingedrukt houden, en n maal op resume (1-increment) of cancel (10-increment) drukken, dan power loslaten.

Een ander document geeft op pagina 40 hints voor problemen photosmart printers.

Print this entry

Geplaatst op

Ardennen 2023

In 2023 gaan we naar de Ardennen! Meer specifiek, naar een “Camping SY“, in Sy (Wikipedia).

Hoe komen we er?

Het is ruim 300 kilometer, een beetje bergopwaarts, dus een keer laden zit er wel in. ABRP stelt voor om bij Nijmegen richting Venlo te rijden en een half uur te laden (van 25% naar 60%) rond Roermond. Daarna via Maastricht en Luik; na Luik is het nog krap een uur voor 50 kilometer.

Waar ligt Sy?

Sy (Openstreetmap) ligt tussen een paar meanders van de Ourthe, en de camping ligt tussen het station van Sy en de Ourthe.

Het is een beetje op de Noord-Westrand van de Ardennen.

Wat is er te doen?

Op de Ourthe kun je, als het meezit, kanovaren. Er zijn (zie kaartje hierboven) grotten in buurt, maar voor echte grotten moeten we 50 kilometer naar het Zuidwesten, naar de Grotten van Han. Die grotten liggen in een natuurpark waar je een combiticket voor kunt krijgen.

Stroomopwaarts aan de Ourthe ligt La Roche-en-Ardenne, in vallei met in het midden van het stadje een heuvel met een kasteel. Dichterbij, ook aan de Ourthe, ligt Durbuy. Durbuy is niet alleen een pittoresk stadje, er is ook een klimbos in de buurt.

Sites met touristeninfo

Print this entry

Geplaatst op

VPS-migratie

Een van de VPS’en zit vol. Uitbreiden van de opslagruimte is niet (goedkoop) mogelijk, maar omdat het er al een tijdje aan zat te komen, heb ik een ruimere VPS beschikbaar.

Bij een eerdere migratie, van thuis naar VPS, heb ik een howto op lowendspirit gevolgd waarmee het disk-image goed te versturen was. Ik had nu moeite hem weer terug te vinden, dus voor de volgende keer leg ik het hier ook vast.

Het idee is in grote lijnen:

  • Sluit de draaiende server af, om een statische situatie te hebben zodat het bestandssysteem consistent blijft.
  • Start een rescue-mode op de VPS-omgeving. In de rescue-mode zijn de diskpartities van de VPS beschikbaar.
  • Kopieer de partitie van de ene machine naar de andere machine met dd over SSH

In dit geval is het resultaat: 

rescue # dd if=/dev/vda bs=32M status=progress | ssh -C root@185.193.158.65 "dd of=/dev/vda"
The authenticity of host '185.193.158.65 (185.193.158.65)' can't be established.
RSA key fingerprint is SHA256:+EhOiwW9GjD4wv2S/0eRveRdoxV8Mlf1x8sICc9JxUY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '185.193.158.65' (RSA) to the list of known hosts.
root@185.193.158.65's password: 
973078528 bytes (973 MB, 928 MiB) copied, 35.8094 s, 27.2 MB/s

De partitie gaat van een datacenter in Frankfurt naar eentje in Amsterdam. De doorvoersnelheid stabiliseert zich op iets boven 33 MB/s, waarmee de partitie van 20 GB in ongeveer 10 minuten gekopieerd is.

De partitie is meteen al 40 GB, maar het bestandssysteem is nog 20 GB. Met resize2fs kan de grootte van het ext4-bestandssysteem aangepast worden: 

# e2fsck -f /dev/vda
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
....
# resize@fs /dev/vda
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/vda to 10485760 (4k) blocks.
The filesystem on /dev/vda is now 10485760 (4k) blocks long. 
#

Het enige probleem is dat het doelsysteem niet boot. Als ik de schijf boot in rescue-modus, staat alle data er op, inclusief de bootdirectory.

Wat blijkt? Bij het kopieren heb ik uit gewoonte de eerste partitie van de schijf (/dev/vda1) gepakt, terwijl er op de doelserver geen partitie is de schijf zit: het had /dev/vda1 ipv /dev/vda moeten zijn, of allebei /dev/vda.

Opgelost vanuit een system-rescue door:

  • Bestandssysteem krimpen tot minimum, de grootte van de bezette ruimte (resize2fs -M)
  • Nogmaals kopieren, nu van /dev/vda1 naar /dev/vda
  • Bestandssysteem laten groeien tot partitiegrootte

Het systeem bootte toen wel, maar de netwerkconfiguratie was nog die van de oude server. Toen het eenmaal half-en-half werkte, vond ik de ‘reconfigure networking’ knop in de Solus-management-omgeving.

Daarmee werkte routing voor IPv6 weer; DNS was al gecorrigeerd.

Nu lijkt alles weer naar behoren te werken, met ruim het dubbele aan beschikbare ruimte.

Print this entry

Geplaatst op

Firefox sync server

Omdat de sync server afhankelijk is van Python 2, is het al een tijdje lastig de boel bij te werken. De syncserver op online.osba.nl houdt daarmee de volledige server in z’n grip, omdat daardoor Debian niet van 10 naar 11 geupgrade kan worden. Daarmee zijn recente PHP-versies niet goed beschikbaar, waardoor andere pakketten weer niet bijgewerkt kunnen worden.

De sync server krijgt daarom een eigen machine toegewezen. Het adres veranderd helaas een klein beetje, wat weer gevolgen heeft voor alle verbonden Firefox instanties. Op desktopversies is dat nog wel makkelijk aangepast via about:config, maar op Android is die pagina sinds een paar versies niet meer beschikbaar.

Er is een wat spijtige workaround voor Firefox op Android nodig:

  • ga naar settings –> about Firefox –> klik 5x op het Firefox-logo.
  • er volgt een popupje dat debug-settings beschikbaar zijn
  • in settings is nu onder het kopje ‘Account’ een menu-optie ‘Custom Sync Server’ beschikbaar gekomen.
    • Zolang er een reeds verbonden Firefox-account actief is, is de optie uitgegrijsd
  • vul als custom sync server in: https://ffs.osba.nl/ffsync/token/1.0/sync/1.5
  • Als je het veld leegmaakt, wordt de hele optie op nul gezet en moet je opnieuw op het logo kloppen.

Op dezelfde pagina is te lezen dat voor desktop-versies van Firefox de custom-synchronisatie-optie ook moeilijker gemaakt is, naast het invullen van de URL van de synchronisatieserver, was het ook nodig twee andere instellingen op nee te zetten:

  • identity.fxaccounts.useSessionTokensForOAuth = false
  • identity.sync.useOAuthForSyncToken = false
  • de tokenserver zelf nog steeds corrigeren naar de eigen server:
    • identity.sync.tokenserver.uri = https://ffs.osba.nl/ffsync/token/1.0/sync/1.5

Print this entry

Geplaatst op

Wireguard VPN

Met dank aan Nyr op lowendspirit.com makkelijk te installeren en configureren op een NAT-VPS.

Het script wordt onderhouden op github, de huidige kopie heb ik lokaal staan. Nieuwe versie ophalen met wget https://git.io/wireguard -O wireguard-install.sh

Edit eind 2023: ik heb een kopie in de lokale forge gemaakt. Die zal gaan achterlopen in geval van wijzigingen. Voor de lol: wget https://forge.osba.nl/wbk/wireguard-install/raw/branch/master/wireguard-install.sh

Gebruik:

  • De eerste keer is de daadwerkelijke installatie/configuratie:
    • geef het externe IP/hostname waarop de server bereikbaar is
    • geef een poort die Wireguard mag gebruiken
    • voor de eerste gebruiker:
      • geef de DNS-resolver die gebruikt moet worden
      • geef de gebruikersnaam
    • Wireguard wordt nu geinstalleerd
    • er wordt een QR-code getoond met de configuratie, direct te scannen met een Wireguard-programmaatje op je telefoon
  • De volgende keer uitvoeren kun je nieuwe gebruikers toevoegen

Klaar!

Print this entry

Geplaatst op

UEFI BIOS boot en GRUB

Voor de zoveelste keer tijdens een installatie: wat zijn ook alweer de benodigde partities sinds UEFI?

In ieder geval /boot , groot genoeg voor een stuk of drie Linux-images; met 50-70 MB per stuk is 200 MB ruim voldoende.

Dan is er de BIOS-boot-partitie, waar de UEFI-bestanden terechtkomen. Volgens specificaties tot zo’n 500 MB, maar mag ook minder zijn. Gok ook op 200 MB.

Uiteindelijk: een kleine partitie (1-2 MB is meer dan genoeg) voor de het deel van de bootloader wat voorheen in de loze ruimte in de partitietabel weggeschreven werd. In tegenstelling tot een DOS-partitieschema, heeft GPT geen loze ruimte.

Het is wel nodig om GRUB over te halen gebruik te maken van die loze ruimte, anders meldt grub-install dat use of blocklists ‘discouraged’ is:

# grub-install /dev/sda1 --force

… vooropgesteld natuurlijk dat de mini-partitie te vinden is op /dev/sda1.

Print this entry

Geplaatst op

reMarkable BRICK

Waarschuwingen, wat kun je er anders mee doen dan ze in de wind slaan? Even een alternatieve packagemanager proberen kan geen kwaad toch?

Dat ssh-copy-id niet het gewenste resultaat had, ach… Dan verander ik tijdelijk het wachtwoord naar iets wat ik zeker niet vergeet. Om dan ook nog een reservekopie te maken van je de configuratiebestanden en een backup van kladjes: daar ga ik nu toch niets mee doen. Alleen maar een paar programma’tjes proberen.

Alleen: de programmastarter is niet geintegreerd in het reguliere OS. Het is of stock reMarkable-OS, of iets anders. Jammer, niet het toppunt van handig. Ander programma proberen, mijn favoriete ereader: koreader.

Yep, dat is koreader. Fijn, volgende programmaatje proberen. SSH: timeout. Lichte paniek. WiFi? WiFi staat uit, gelukkig. Netwerk over USB dan; in een keer raak, ssh root@10.11.99.1, maar inloggen? Nee hoor: incorrect wachtwoord. Meer paniek.

Rust. Ik kan niet de eerste zijn die dit verprutst. Na wat zoeken blijken ook niet hele volksstammen er met open ogen ingerend te zijn, maar er zijn howto’s die – na een introductie over ‘bricking beyond repair’ – je weer op pad helpen.

Ik kwam uit bij remarkable-uuuflash. Ik zag er een beetje tegenop om de procedure uit te zoeken, tegen problemen aan te lopen en zonder resultaat de avond af te sluiten, maar die vrees was ongegrond: het werkt precies zoals voorgesteld.

Unbrick

Veel meer dan copy/paste van de bron-site is dit niet. Samengevat:

  • Sluit de reMarkable per USB op je PC; let op dat het een datakabel is, niet eentje die enkel kan opladen.
  • Schakel de reMarkable, mocht hij aanstaan. Dat is nodig om de USB poort van modus te kunnen laten switchen.
  • Houdt de middelste knop onderaan ingedrukt terwijl je de aan-/uitknop een seconde of 3-5 ingedrukt houdt. Op het scherm is niets te zien: het OS dat het scherm aanstuurt, wordt niet gestart.
  • Op je PC zie je met dmesg|tail onderaan de USB poort in flash modus genoemd worden, of met tail -f /var/log/messages komt hij voorbij:
    [111357.268334] hid-generic 0003:15A2:0063.0005: hiddev1,hidraw4: USB HID v1.10 Device [Freescale SemiConductor Inc  SE Blank MEGREZ] on usb-0000:00:1a.0-1.3/input0
  • Gebruik uuu (op je PC) om een recovery-image in RAM (van de reMarkable) te laden :
    # ./uuu recover.uuu
  • De reMarkable boot nu in het recovery-image; als tail -f /var/log/messages aan staat, zie je de seriele poort voorbij komen, anders lezen op de laatste regels van dmesg|tail. Het zal waarschijnlijk een /dev/ttyACMx-apparaat zijn.
  • Open nu een seriele verbinding vanaf je PC naar de reMarkable:
    # screen /dev/ttyACM1
  • Log in als root
  • Je zit nu in het recovery-image, er is dus nog niets beschikbaar van de flash opslag op de reMarkable. Die kun je wel aankoppelen:
    # mount /dev/mmcblk1p2 /mnt/
    # mount /dev/mmcblk1p7 /mnt/home
    # mount /dev/mmcblk1p1 /mnt/var/lib/uboot
  • chroot naar het aangekoppelde bestandssysteem:
    # chroot /mnt
  • Voer nu uit waar je voor gekomen was. In mijn geval: het wachtwoord van root verwijderen. passwd werkte niet, misschien dat dat ook in de chroot-omgeving het /etc/shadow-file buiten chroot probeert aan te passen, of misschien is er iets ingebouwd in het reMarkable-OS dat voorkomt dat het wachtwoord aangepast wordt (zou verklaren waarom ik er eerder niet inkwam). In plaats daarvan, maak ik het root-password leeg door in /etc/passwd de verwijzing naar /etc/shadow te verwijderen:
    # vi /etc/passwd
  • de ‘x’ achter root geeft aan dat het gehashte wachtwoord opgeslagen is in /etc/shadow: root:x:0:0:root:/home/root:/bin/sh wordt root::0:0:root:/home/root:/bin/sh, dus zonder de ‘x’ tussen de ::’s

Met een reboot-commando wordt de reMarkable herstart. screen blijft nog even hangen, met de toetsenserie enter-tilde-punt-enter wordt de verbinding verbroken als het je te lang duurt.

Terug in koreader…

… maar nu met werkende SSH-toegang. Eerst maar terug naar reMarkable-OS:
systemctl disable --now koreader && systemctl enable --now xochitl

Op zoek naar een oplossing kwam ik tegen dat er de middelste knop als switch van reMarkable-OS naar koreader in te richten is, en bovendien dat launchers het leven eenvoudiger kunnen maken.

… en weer terug in reMarkable-OS

Installatie van ddvk-hacks had een reboot nodig om de functionaliteit beschikbaar te maken in xochitl, de reMarkable-reader-app.

Na de reboot was het wachtwoord weer actief: niet het lege wachtwoord, niet mijn zelfgekozen wachtwoord, maar h04ytCFiD zoals in de help (waar ik nu weer bij kan).

Task switcher to the rescue

Er zijn nu drie launchers in het opkg-repository, draft, oxide en remux. Van die drie lijkt alleen remux een multitasking-launcher te zijn. Die heb ik nu bereikbaar via lang indrukken van de middelste knop met
# systemctl enable --now remux

Dat werkt best aardig. Mooi voor vanavond!

Print this entry

Geplaatst op

LVM thin pool extension, v2

Het verhaal van vorige keer dat een van de data-LV’s bijna vol zat is wat lang van tekst en niet volledig van uitleg, nu een poging voor een puntsgewijze howto.

Het gaat deze keer om de video-LV. Een DV-tapes neemt ongeveer 15 GB in beslag, en er was niet meer voldoende ruimte voor de eerste vakantie-tape.

Gebruikte commando’s

# df-h /home/wbk/movies 
# lvs -a data/videoRW -o+thin_count,thin_id,devices
# vgs data -o+pv_name,pv_free
# pvs /dev/sde1 -a -o-vg_name -o+vg_name,vg_size,vg_free,lv_name,origin,pool_lv,data_lv
# lvextend -r -L+200G data/videoRW /dev/sde1

Huidige status afleiden

Eerst df -h om de juiste LV bij de volle directory/partitie te vinden. De movies-directory heeft nog 13 MB vrij in LV data-videoRW :

df -h /home/wbk/movies
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/data-videoRW  1.3T  1.3T   13M 100% /home/wbk/movies

Daarna de LVM-status erbijzoeken; /dev/mapper/data-videoRW is een van de vijf thin LV’s onder datatlvpool, namelijk nummer 4 (onderaan). videoRW heeft zelf geen (hardware-) device, omdat het een logisch volume in een logisch volume is.

Het feitelijke (hardware-) device waarop de data terecht komt, kan gevonden worden via de thin pool, hier datatlvpool.

Omdat videoRW een thin LV is, kan de in df -h gerapporteerde vrije ruimte groter zijn dan de daadwerkelijke beschikbare ruimte op de onderliggende fysieke volumes. Dat is voor videoRW (nog) niet aan de orde: datatlvpool heeft nog 8% van 800 GB, ~64 GB, vrije ruimte. 

root@fractal:~# lvs -a data -o+thin_count,thin_id,devices
  LV                  VG   Attr       LSize   Pool          Origin          Data%  Meta%  Move Log Cpy%Sync Convert #Thins ThId Devices             
  archief             data -wi-a----- 800.00g                                                                                   /dev/sda9(0)        
  [cache_fotos]       data Cwi---C---  48.00g                               99.99  9.16            0.00                         cache_fotos_cdata(0)
  [cache_fotos_cdata] data Cwi-ao----  48.00g                                                                                   /dev/sdd4(0)        
  [cache_fotos_cmeta] data ewi-ao---- 100.00m                                                                                   /dev/sdb4(0)        
  datatlvpool         data twi-aot--- 798.21g                               92.02  47.56                                 5      datatlvpool_tdata(0)
  [datatlvpool_tdata] data Twi-ao---- 798.21g                                                                                   /dev/sde1(0)        
  [datatlvpool_tmeta] data ewi-ao---- 400.00m                                                                                   /dev/sdb4(10265)    
  fotosRO             data ori-a-C---   2.68t [cache_fotos] [fotosRO_corig] 99.99  9.16            0.00                         fotosRO_corig(0)    
  [fotosRO_corig]     data owi-aoC---   2.68t                                                                                   /dev/sda1(1)        
  fotosRW             data Vwi-aot---  <3.27t datatlvpool   fotosRO         15.21                                             5                     
  geluidRO            data ori-a-----  16.56g                                                                                   /dev/sda1(703333)   
  geluidRW            data Vwi-aot---  16.56g datatlvpool   geluidRO        5.19                                              1                     
  [lvol0_pmspare]     data ewi------- 400.00m                                                                                   /dev/sda1(707573)   
  muziekRO            data ori-a----- 150.00g                                                                                   /dev/sda2(1)        
  muziekRW            data Vwi-aot--- 150.00g datatlvpool   muziekRO        26.97                                             2                     
  pubNR               data ori-a-----   8.00g                                                                                   /dev/sda2(323587)   
  pubRW               data Vwi-aot---   8.00g datatlvpool   pubNR           0.01                                              3                     
  romRO               data -wi-ao----  90.00g                                                                                   /dev/sda3(1)        
  ssdata              data -wi-ao----  40.00g                                                                                   /dev/sdb4(25)       
  videoRO             data ori-a-----  <1.09t                                                                                   /dev/sda2(38402)    
  videoRW             data Vwi-aot---   1.23t datatlvpool   videoRO         14.56                                             4

De conclusie is wel: om de vakantietapes van dit jaar over te zetten op schijf, moet naast het videoRW-volume, ook het datatlvpool-volume groter gemaakt worden. Voor metadata is nog voldoende ruimte: datatlvpool_tmeta heeft nog maar 200 MB van 400 MB gebruikt.

Hoeveel ruimte is er om datatlvpool groter te maken? Dat hangt van de vrije ruimte in de volumegroep data af, en uiteindelijk van de vrije ruimte van de onderliggende fysieke volumes. De data van datatlvpool zit in het data-component van het volume, datatlvpool_tdata, met als onderliggend (handmatig toegewezen) fysiek volume /dev/sde1. 

# vgs data -o+pv_name,pv_free
  VG   #PV #LV #SN Attr   VSize VFree  PV         PFree   
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda1    18.07g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda2     9.80g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda3   <60.00g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sdd4    <2.00g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sdb4    <7.51g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda9  <328.67g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sde1     1.22t

Het rapport voor PV /dev/sde1 laat zien dat sde1 deel uitmaakt van VG data. Die VG heeft (in totaal) 1.6 TB vrije ruimte, de (enige) toegewezen LV is datatlvpool_tdata

# pvs /dev/sde1 -a -o-vg_name -o+vg_name,vg_size,vg_free,lv_name,origin,pool_lv,data_lv
  PV         Fmt  Attr PSize  PFree VG   VSize VFree  LV                  Origin Pool Data
  /dev/sde1  lvm2 a--  <2.00t 1.22t data 7.31t <1.64t [datatlvpool_tdata]                 
  /dev/sde1  lvm2 a--  <2.00t 1.22t data 7.31t <1.64t

De grootte van pool datatlvpool kan automatisch bijgewerkt worden door LVM, zie Automatically extend thin pool LV in man 7 lvmthin, maar voor de thin volumes zelf zie ik het niet 1-2-3. Die moet dus handmatig vergroot worden. Controle van de gemonitorde pool:

# lvs data/datatlvpool -o+seg_monitor
  LV          VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Monitor  
  datatlvpool data twi-aot--- 798.21g             92.02  47.56                            monitored

Extend thin volume videoRW

Automatische uitbreiding van de thin volumes kan ook aangezet worden, zie man 7 lvmthin , Automatic extend settings.

Waarschijnlijk heb ik het, bang voor ongemerkt volschrijven van de VG, uitgezet. De standaardsetting is dat de thinLV bij 70% uitgebreid wordt, met 20%. Dat kun je uitzetten door in /ect/lvm/lvm.conf de optie thin_pool_autoextend_threshold op 100 te zetten. Dat staat hij op het moment, en met dezelfde overweging laat ik hem daar op staan. 

# lvextend -tvr -L+200G data/videoRW /dev/sde1
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
    Executing: /sbin/fsadm --dry-run --verbose check /dev/data/videoRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-videoRW".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Dry execution fsck -f -p /dev/mapper/data-videoRW
    Test mode: Skipping archiving of volume group.
    Extending logical volume data/videoRW to <1.43 TiB
  WARNING: Sum of all thin volume sizes (<4.87 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<1.64 TiB).
  Size of logical volume data/videoRW changed from 1.23 TiB (323584 extents) to <1.43 TiB (374784 extents).
    Test mode: Skipping backup of volume group.
  Logical volume data/videoRW successfully resized.
    Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/videoRW 1535115264K
fsadm: "ext4" filesystem found on "/dev/mapper/data-videoRW".
fsadm: Device "/dev/mapper/data-videoRW" size is 1357209665536 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-videoRW"
fsadm: Resizing filesystem on device "/dev/mapper/data-videoRW" to 1571958030336 bytes (331350016 -> 383778816 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-videoRW 383778816

dsadm: Skipping filesystem check : Het bestandssysteem is aangekoppeld; fsck kan geen kwaad dus ik unmount het.
WARNING: Sum of thin volumes exceeds thin pool: Ik vermoed dat in de 4.77 TB ook de RO-origins opgenomen zijn, anders zit ik volgens mij nooit tegen de 5 TB aan mediabestanden. Alhoewel… fotosRW geeft aan 3.27 TB, waarvan 15.21% bezet is. Dat zou redelijk passen in een totaal van ~5 TB waarvan minder dan 1.5 TB bezet is.

Nu voor ‘t echie:

# lvextend -r -L+200G data/videoRW /dev/sde1  
fsck from util-linux 2.36.1
...
filmNR: Inode 54001666 extent tree (at level 2) could be narrower.  IGNORED.
filmNR: Inode 55050243 extent tree (at level 1) could be shorter.  IGNORED.
...
filmNR: Inode 60030985 extent tree (at level 1) could be narrower.  IGNORED.
filmNR: 5000/82837504 files (23.6% non-contiguous), 328700572/331350016 blocks
  WARNING: Sum of all thin volume sizes (<4.87 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<1.64 TiB).
  Size of logical volume data/videoRW changed from 1.23 TiB (323584 extents) to <1.43 TiB (374784 extents).
  Logical volume data/videoRW successfully resized.
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/mapper/data-videoRW to 383778816 (4k) blocks.
The filesystem on /dev/mapper/data-videoRW is now 383778816 (4k) blocks long.

De beschikbare ruimte in de volumegroup data is nog steeds 1.64 TB, er is immers enkel beschikbare ruimte toegewezen aan de thin LV videoRW, maar nog niets gebruikt.

Het resultaat

Er is nu voldoende ruimte voor zo’n 12 uur aan DV-video: 

# df -h /home/wbk/movies/
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/data-videoRW  1.5T  1.3T  206G  86% /home/wbk/movies

Print this entry

Geplaatst op

Verlanglijstje

Deze keer:

  • Een nieuw kussen, of in ieder geval het luchtige schuimrubber aan de binnenkant, voor mijn fiets;
  • Een abonnement op Ars Technica, met een NFC-security-key;
  • Een prettige rugzak, met meerdere compartimenten en heup-riem;
  • Een stofzuigrobotje?

Print this entry