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

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

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/vda1 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 (resize2fis -M)
  • Nogmaals kopieren, nu van /dev/vda1 naar /dev/vda1
  • 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

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

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

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

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

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

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

Zomervakantie 2022

Stranden zoeken: beachsearcher.com

1e etappe: Zwolle – Zwarte Woud (26)

Langs de Rijn omhoog naar het Zuiden; eerst naar Arnhem (via A50 en A12 richting Oberhausen), grens over bij Zevenaar, over de A3 langs Oberhausen, Duisburg, Dusseldorf, Keulen, (op een afstandje langs) Koblenz, tussen Frankfurt, Wiesbaden en Mainz door richting Darmstadt. Daar wordt het A5, langs Mannheim en Heidelberg tot Karlsruhe. Daar naar het Oosten afbuigen over de A8. Voor Waldbronn afslag 42 nemen, anders bij Pforzheim van de snelweg af (afslag 43) naar het Zuiden. Het is dan nog ongeveer 40 kilometer naar Oberhaugstett.I will check my

Vaste priks:

2e etappe: Zwarte Woud – Bodensee (27)

Indien nodig, eerst van Waldbron ongeveer naar Oberhaugstett; vanaf Oberhaugstett een kort stukje naar Wildberg, dan naar het Zuiden over de A81 langs Horb-, Sulz- en Obendorf am Neckar, langs Rottweil, Trossingen en Geisingen, Engen en Singen naar Schaffhausen

  • route naar laadplein bij de waterval, Lauferstrasse, Uhwiesen, Laufen-Uhwiesen, Bezirk Andelfingen, Zurich, 8248, Switzerland
  • batterijplanner vanaf Oberhaugstett (150 km); vanaf Waldbronn 210 km

Met een korte omweg komen we door Freudenstadt (waar we vanuit Bad Rippoldsau een paar keer geweest zijn); als we de dag van tevoren bellen kunnen we kijken of we bij het Vietnamese restaurant daar kunnen ontbijten.

  • route naar Freudenstadt (45 km, drie kwartier), en
  • route van Fruedenstadt naar het laadplein in Schaffhausen (140 km, een kleine twee uur)
  • aangepaste batterijplanner vanaf Oberhaugstett over Fruedenstadt (170 km); vanaf Waldbronn 200 km

Er zijn 8 geschikte laadpalen beschikbaar naast de waterval, maar LET OP: laden via newmotion/shellrecharge of via een app van swisscharge (de palen staan niet vermeld op abetterrouteplanner.com, en niet op openchargemap.io, wel op https://shellrecharge.com/nl-nl/vind-een-laadpunt)

Daarna van Schaffhausen via Konstanz naar Dornbirn in Oostenrijk. De routeplanner wil het eerste stuk niet langs het meer rijden, misschien is dat twee minuten langzamer, of het is alleen voor fietsers.

3e etappe: Dornbirn – noord Italie (28)

We kunnen door een tunnel onder de hoogste Alpen rijden en een stuk afsnijden, maar we kunnen er ook overheen gaan. We zijn dan langer onderweg, maar er zijn ook leukere plaatsen om uit te stappen.

Davos is wel een bekende plaats in de Zwitserse Alpen, daar zouden we wat kunnen eten en opladen. (Davos valt af, we komen dan aan de verkeerde kant van de Stelviopas aan) De Stelviopas is een van de hoogste bergpassen in de Alpen, die is daar niet ver vandaan de weg over de Alpen naar Italie. We gaan grappig genoeg juist vanuit Italie naar Zwitserland de pas over!

Net ten Zuiden van de Alpen is een groot meer (Garda), daar in de buurt, in Gavardo, heb ik een B&B gevonden die net de dag dat we daar rijden, een vrije kamer heeft.

Een andere optie is om in de buurt van Verona te overnachten. Dat is iets verder rijden, 60 km ongeveer, maar het is ook een mooie plaats. We komen daar zowiezo langs als we naar Ancona (op weg naar het Zuiden) of naar Venetie (dat is nog een redelijk stuk naar het Oosten) gaan.

  • Naar Venetie? Dan overnachten in de buurt van Verona, en in de buurt van Venetie, voor we naar het Zuiden gaan
  • Niet naar Venetie? Dan overnachten in de buurt van het Gardameer, daar kijken, via Verona naar het Zuiden rijden.

Na wat advies, nalezen en overleg, geen Venetie: het is een redelijke omweg, en midden in de zomer op z’n drukst.

Vaste priks:

  • route: die is wat gefragmenteerd, omdat de routeplanner graag door de tunnel gaat in plaats van een toeristische route te nemen. Ik reken met effectief vertrekken om 10 uur ’s ochtends; met pauzes en laden komen we rond 19.30 aan.
    • Vorarlberg-Tirol: de Arlberg-tunnel ligt op de landsgrens, Arlbergpass aanhouden om bovenlangs te gaan. Op de pas zal vast een uitkijk/drinkpunt zijn.
      • 80 km
      • 1 uur rijden
      • niet laden (iets meer dan 50% gebruikt, daarna bergafwaarts)
      • 11 uur
    • Pauze 30 minuten
      • 11.30
    • Tirol-Trontino / Suedtirol:
      • 90 km
      • ruim 1 uur rijden
      • laden in Graun im Vinschgau (ca 90% gebruikt)
      • 12.45
    • Graun im Vinschgau: hapje eten, eindje wandelen langs het meer
      • batterij laden, in ieder geval een half uurtje@22kW
      • 1,5 uur lunch
      • 14.15
    • Trontino-Stelviopas /Passo dello Stelvia:
      • 50 km
      • 45 minuten
      • 15.00
    • Passo dello Stelvia: Op de pas lijkt er een uitkijkpunt te zijn, een paar hotels en parkeerplaatsen. Er is een punt dat ‘Dreisprachenspitz’ heet. Er zal vast iets te drinken en te wandelen zijn.
      • via Prad am Stilfser Joch (Prato allo Stelvio) en Trafoi (dan komen we de Italiaanse kant van de pas op, anders aan de andere kant van de ‘Rotelspitze’/’Punta Rosa’, in Zwitserland. Naar beneden gaan we in ieder geval aan de Zwitserse kant
      • 30 minuten pauze
      • niet laden, we gaan nu alleen maar naar beneden
      • 15.30
    • Stelviopas-PicNic Il Cantoniera: er lijkt een fotopunt te zijn bij deze picnicplaats, daarna gaat het stijl bergafwaarts
      • 13 km
      • 11 minuten
      • 15.40
    • PicNic: korte fotopauze
      • 15 minuten
      • 15.55
    • PicNic Il Cantoniera – Pisogne : Hier avondeten en laatste laadsessie. In Pisogne zijn twee laadlocaties met twee contacten; in zowel Gratacasolo als in Pian Camuno, telkens 5 km terug op de route, zijn er ook twee palen met twee contacten. Langs het meer zelf zijn de laadpalen dun gezaaid, een in Sulzano, een in Iseo. Voorbij het meer, in Brescia, zijn er wel vrij veel laadpalen. Als we hier rond vijven zijn, is het waarschijnlijk nog vroeg voor avondeten in Italie.
      • 120 km
      • ruim 2 uur
      • 17.00
    • Pisogne – avondeten
      • 1.5 uur
      • auto laden
      • 18.30
    • (misschien even kijken: Terme di Bormio , locatie: halverwege de pas en Bormio; bezoeken niet echt de moeite, 44 euro pp)
    • Pisogne-Gavardo : hier overnachten we. Als de rit volgens plan verloopt, is het nog licht. Het Gardameer ligt op ongeveer 10 kilometer afstand, we zouden nog even kunnen gaan kijken.
      • 70 km
      • 1 uur
      • 19.30
    • Gavardo: hier overnachten
  • Batterijplanner voor de hele rit (1x ruim een uur in Graun im Vinschgau, 1x een half uur in Pisogne, om met enkele procenten respijt in Gavardo aan te komen. Tijdens het eten volladen is wel handig, dan halen we het om langzaamladend de volgende ochtend met een volle accu te vertrekken. De dichtstbijzijnde laadpaal bij de Aldi (1,5 km lopen) lijkt gratis te gebruiken, dat zal de beschikbaarheid niet ten goede komen.

4e etappe: Noord Italie – San Marino (29)

Vanuit Gavardo via Verona en San Marino richting Ancona, daar een paar dagen bijkomen aan het strand.

Overnachtingsopties:

De stille vrede is ondertussen geboekt, het wordt de lieve vrede voor families in de heuvels.

  • route van Gavalto via Verona naar San Marino
    • 330 km
    • ruim drie uur, sightseeing niet meegerekend
  • route van San Marino naar Montefiori Conca (dorp, locatie moet nog bevestigd worden)
    • 25 km
    • 40 minuten door het binnenland

Geen etappe – Montefiori Conca (30)

Een dag naar het strand, omgeving bekijken. Er schijnen mooie dorpjes in de buurt te zijn.

5e etappe: San Marino – Marche (31)

Via een strand tussen Rimini en Ancona, of, gezien het uitzicht zoals in beachsearcher te zien, misschien een strand aan de voet van de berg/heuvel bij Ancona, bij Civitanova rechtsaf bij de zee vandaan rijden naar Petrolio.

  • route van Montefiori Conca naar Petriolo
    • 160 km zonder strandstops
    • 2 uur

Geen etappe: Petriolo

Hier een paar dagen blijven, strand bezoeken, omgeving bekijken, verdere plannen maken. In grote lijnen nog uit te werken:

  • Petriolo
    • 2 nachten: een dag bijkomen op het strand, ’s avonds plannen, daarna op pad
  • Napels
    • Pompei/Herculeum/Vesuvius – 1 dag
    • Er zal vast in de baai iets te zien zijn – 1 dag
    • Er is een zomerfestival verder naar het Zuiden, er is vast meer te doen; bootje varen? – 1 dag
    • het is een kleine 400 km rijden, een kleine 5 uur – 1 dag
    • waar slapen?
  • Rome
    • Nog helemaal geen plan; 2 dagen Rome is snel voorbij
    • Omgeving verkennen – 2 dagen
    • Het is 250 km rijden over de snelweg, een kleine drie uur. Misschien is een route (dichter) langs de kust mooier – 1 dag
  • Het is nu nog 1600 km (snelweg) naar Zwolle. Met etappes van 300 km per dag, nog 5 dagen; met een toeristische route al snel 7 dagen.

Rome en verder

  • dag 1 (09) : Rome – Piombino – Elba – Pisa ; overnachten in Pisa
    • Rome weg met volle accu
    • bijna leeg rond Piombino; dichtstbijzijnde laadpalen op ca 10 km;
    • Mikken op rond 12u in Piombino, boot naar Elba
    • 13u op Elba; Napoleon-iets bezoeken, strand
    • 17u boot terug naar Piombino
    • Bij Piombino evt Etruskisch-iets bezoeken en eten in Populonia
    • 100 km naar Pisa, 40-60 minuten laden, 1.5 uur rijden
    • aankomen in Pisa 21-22u
  • dag 2 (10): Pisa – Milaan; overnachten in Milaan
    • volgende ochtend op tijd weg om Zwitserland door te rijden
  • dag 3 (11): in Milaan
  • dag 4 (12): Milaan – Zwarte Woud rond Colmar
  • dag 5 (13): in Colmar
  • dag 6 (14): Colmar – Zwolle
    • kleine 700 km, 2x laden, laat thuis

uiteindelijke route

Ik heb de route bij benadering op Graphhopper uitgetekend.

Print this entry