Bericht

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  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      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

Geplaatst op

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

Geplaatst op

Yunohost SSH toegang

Normaliter hebben Yunohost-gebruikers geen SSH-toegang. Zodoende is het lastig om de bestanden via SSHFS te benaderen. Om de bestanden via SSHFS te benaderen, zijn er twee dingen aan te passen.

  1. SSH toegang beschikbaar maken voor de gebruiker
  2. Toegang op bestandsniveau regelen voor die gebruiker via ACL

1 – SSH toegang

Via het Yunohost forum werd ik gewezen op de SSH-toegang die vanaf (ongeveer) versie 4.2 van Yunohost uitgedeeld kan worden. Ik gebruik voor SSH toegang een afzonderlijke gebruiker, die naast SSH-toegang, geen applicaties toegewezen krijgt.

Gebruiker voor SSH toegang

Via ‘Manage groups and permissions’ kun je SSH-toegang toewijzen:

Maak een nieuwe groep (hier sshfsnc), en geef die SSH-permissie
Voeg de gebruiker die je net gemaakt hebt toe aan de SSH-groep

2 – ACL’s

Via access control lists kun je extra rechten toekennen aan bestanden, naast de reguliere eigenaar/groep/iedereen rechten op bestandsniveau.

De toegangsrechten van Yunohost zijn erg nauw gedefinieerd. Via het bestandssysteem kun je als gebruiker niet bij je eigen bestanden die in Nextcloud staan, en Nexctloud kan niet bij je bestanden in je home-directory. De admin-gebruiker kan ook maar beperkt bij verschillende bestanden komen, alleen root kan overal bij.

Om via de gebruiker met SSH toegang de bestanden uit Nextcloud te benaderen, moeten die vrijgegeven worden via ACL. Hoe dat gaat, heb ik in dezelfde forumthread gepost:

# cd /home/yunohost.app/nexctloud/data/
# setfacl -Rm u:boudewijn_ssh:rx boudewijn/
# setfacl -dRm u:boudewijn_ssh:rx boudewijn/
# setfacl -m u:boudewijn_ssh:rx .
# setfacl -dm u:boudewijn_ssh:rx .

Er is telkens een regel voor de nieuwe default (met -d), en dezelfde voor de rechten op de bestaande bestanden. Daarnaast telkens een recursieve regel (-R) voor de data-directory van gebruiker boudewijn, en een niet-recursieve op de huidige directory (/home/yunohost.app/nextcloud/data/). Setfacl heeft -m nodig, daarmee geef je aan dat het een wijziging/modificatie is.

Synchronisatie

Zolang je via SSHFS enkel bestanden leest, blijft alles werken zoals vanouds. Als je ook bestanden wegschrijft via SSHFS, loopt die actie buiten Nextcloud om. Het bestand wordt daardoor niet in Nextcloud geregistreerd, en is daarvandaan niet zichtbaar. Er is een OCC-opdracht om de opslagruimte te scannen op wijzigingen en de database bij te werken.

WebDAV

Om het toevoegen van bestanden, en alle wijzigingen aan bestanden, meteen in Nextcloud beschikbaar te maken, moet de verbinding via WebDAV gemaakt worden. Het werkt minder snel, maar wordt op meer platformen ondersteund dan SSHFS.

Print this entry

Geplaatst op

LVM thin pool extension

De foto-LV zit bijna vol, nog 32 GB te gaan. Er is meer ruimte nodig: om Nextcloud op online te kunnen upgraden naar de laatste versie, heb ik daar ruimte voor een backup nodig, en dat lukt niet met het huidige aantal (en grootte van) bestanden. De foto’s gaan daarom voor een groot deel naar de andere machine, maar 32 GB is niet voldoende.

De foto’s staan op een samengesteld volume:

  • cache_fotos , een caching-LV op twee SSD’s:
    • cache_fotos_cmeta
    • cache_fotos_sdata
  • data-LV, bestaand uit
    • fotosRO , een read-only LV op langzame SMR schijf
    • fotosRW, een thin LV met ‘external origin’ fotosRO, zelf een beschrijfbaar LV in LV datatlvpool. Die datatlvpool heeft twee onderliggende LV’s
      • datatlvpool_tmeta
      • datatlvpool_tdata

Er kan dus op vijf punten te weinig ruimte ontstaan:

  • fotosRW
  • datatlvpool_tmeta
  • datatlvpool_tdata
  • cache_fotos_cmeta
  • cache_fotos_cdata

Om te controleren op beschikbare ruimte:

  • df -h | grep fotos RW voor LV fotosRW
    df -h | grep fotosRW
    /dev/mapper/data-fotosRW 2.9T 2.8T 32G 99% /home/wbk/photos
    • de 32G zou meer mogen zijn
    • de 99% zou minder mogen zijn
  • lvs -a data |grep twi voor de thin pool
    lvs -a data |grep twi
    datatlvpool data twi-aot— 409.60g 85.25 37.98
    • 85.25 is het percentage tdata in gebruik, er is dus nog ~60 GB (15% van 400 GB) beschikbaar voor alle thin LV’s in deze pool
    • 37.98 is het percentag tmeta in gebruik, er is nog ~150 MB (60% van 250 MB) beschikbaar voor het beheer van de thin LV’s in deze pool
  • lvs -a data |grep Cwi—C voor de cache-LV:
    lvs -a data |grep Cwi—C
    [cache_fotos] data Cwi—C— 48.00g 81.11 9.16 0.00
    • 81.11 is het percentage cdata in gebruik, er is ~10 GB (20% van 48 GB) beschikbaar voor aanvullende caching voor de fotos. Het lijkt dat enkel fotosRO caching heeft, lvs -a |grep C— geeft alleen de -RO LV’s terug
    • 9.16 is het percentage cmeta in gebruik, er is nog 90 MB (90% van 100 MB) beschikbaar voor beheer van het cache

Het belangrijkste is de ruimte op datatlvpool. Als er geen tdata of tmeta meer beschikbaar is, kan het bestandssysteem op fotosRW kapotgaan. Het lijkt of er nog gewoon naar het bestandssysteem geschreven kan worden, er lijkt in dat geval immers nog ruimte beschikbaar. Normaliter wordt de pool automatisch verruimd op het moment en met de percentages vermeld in /etc/lvm/lvm.conf

  • thin_pool_autoextend_threshold = 95
  • thin_pool_autoextend_percent = 10

Het verantwoordelijke proces daarvoor is dmeventd. Controleer of de pool gemonitord wordt door dmeventd met lvs -o+seg_monitor | grep monitored
Met de huidige instellingen wordt dmevendt pas over 40 GB getriggerd de pool te verruimen met 30 GB. Dat kan doorgaan zolang er voldoende ruimte in de bovenliggende VG is. VG data heeft 2 van 7 TB beschikbaar.

Het makkelijkst valt ruimtegebrek op fotosRW op: er kunnen geen bestanden meer naar het bestandsysteem geschreven worden, ‘disk full’. Zolang er nog ruimte in de datatlvpool beschikbaar is, kan het vergroot worden met een simpele lvextend -rL+100G /dev/mapper/data-fotosRW

Geen ruimte op caching-LV’s geeft geen directe problemen: er wordt minder optimaal gecached, maar bestaande cache blijft werken (of misschien wordt de data aangepast om nieuwe/andere bestanden te cachen). Ook het volledig wegvallen van cache geeft enkel een snelheidsvermindering en heeft geen dataverlies tot gevolg.

Afwachten

Deze keer ga ik enkel fotosRW meer ruimte geven, en in de gaten houden wat datatlvpool doet. Met de kennis van nu, verwacht ik dat er nog niets gebeurt op het moment dat fotosRW meer ruimte toegewezen krijgt, maar dat tijdens het verplaatsen van foto’s van Nextcloud naar fotosRW er meermaals een dynamische toewijzing van ruimte aan datatlvpool plaatsvindt.

Terugzoeken van details: zie man 7 lvmthin

Proef op de som

Om de boel in de gaten te houden, heb ik eerst fotosRW groter gemaakt het het bestandssysteem mee laten groeien:

lvextend -rL+100G /dev/mapper/data-fotosRW

Beschikbare vrije ruimte de fotopartitie is toegenomen, terwijl er van VG data geen vrije ruimte afgesnoept is:

root@fractal:~# df -h | grep  -E 'fotosRW|Use'
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW        3.0T  2.8T  128G  96% /home/wbk/photos

root@fractal:~# vgs data            
  /dev/sdd: open failed: No medium found
  VG      Attr   VSize VFree 
  data   7  14   0 wz--n- 7.31t <2.02t

Daarna foto’s kopieren in groepjes van zo’n 5 GB. Net bij het laatste groepje is de 95% aangetikt. De toewijzing van extends uit VG data aan thin LV pool datatlvpool lijkt niet onmiddelijk te zijn, je kan de toewijzing zien groeien door met enige tussenpoos opnieuw de status van VG’s en LV’s op te vragen: 


# Bij afronden laatste batch van de initiele set foto's: 
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 409.60g                               94.73  41.80
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         7.48   
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

# Even later is te zien dat onder 'Data%' de waarde van 94.73 teruggelopen is naar 89.91...
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 450.56g                               89.91  43.48  
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         8.05       
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

# ...en nog weer 
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 495.62g                               87.38  46.21                           
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         8.96  
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

Beschikbare vrije ruimte in VG data is afgenomen: 

                             
root@fractal:~# vgs data
  /dev/sdd: open failed: No medium found
  VG      Attr   VSize VFree
  data   7  14   0 wz--n- 7.31t 1.93t

Conclusie: het systeem werkt. Ik weet niet of het nadelig is om meermaals kleine brokjes toe te kennen, in plaats van in een keer een veel groter stuk. Nu staat met 87% bezetting de volgende verruiming van datatlvpool alweer voor de deur.

Print this entry

Geplaatst op

Vakantie 2021

Nuttige links

Geen vakantie

Op de Deitse FAQ over inreizen, is er een regeltje tussengefrot over de NL-situatie:

Laadpunten onderweg

Vakantie-adressen

Activiteiten

  • Om te bezoeken:
    • Langs de Donau
      • Stroomopwaarts, naar het Westen
      • Rondom Sankt Nikola
        • Grein
        • Struden
        • Sankt Nikola
        • Sarmenstein
        • Ybbs an der Donaf
      • Stroomafwaarts, naar het Oosten
        • Wachau
          • Melk
          • tussenliggend gebied
          • Krems an der Donau
        • Wenen
          • alleen wat rondlopen
          • eten: japans bij Catch, Marc-Aurel strasse (looproute vanaf dierentuin)
          • museumbezoek
          • dierentuin, dagelijks geopend van 9u-18.30
            • p&r huetteldorf, hackinger strasse (kaart)
            • met lijn U4 naar Station Hietzing
            • vordeelticket 2x volwassene, 3x kind: 65 euro (ipv 22/volwassene en 11/kind = 6)
            • ontbijt kopen en opladen bij Lidl in Sankt Polten: Hermann-Gmeiner-Gasse 1, 3100 St. Pölten (kaart)
            • adres: Tiergarten Schönbrunn, 13/B, Maxingstraße, Hietzing, KG Hietzing, Hietzing, Vienna, 1130, Austria
    • Verder naar het Westen
      • Hallstatt
  1. Reis en aankomst
  2. ’s Ochtends wandelen, ’s middags verhuizen
  3. Zwemmen en wandelen
  4. Wenen
  5. Dag thuis
  6. ’s Ochtends naar Wallsee, ’s middags wandelen bij de Giessenbach
  7. Vroeg op, naar Hallstatt
  8. Dag thuis, zwemmen? Er is een groter bad in Perg, ongeveer een half uur rijden.
  9. Wenen – dierentuin en museum; eten in Krems?
  10. zwemmen en donautour retour, eten in Sptiz
  11. boot gemist, alsnog donautour Melk <> Spitz, eten in Melk
  12. Plannen maken, zwemmen, eten bij de brug
  13. Kano op de Steyr
    1. route naar Agonitz
    2. Eventueel laden in Sierning, naast Pichlern :

Dagindeling

  1. Reis en aankomst
  2. ’s Ochtends wandelen, ’s middags verhuizen
  3. Zwemmen en wandelen
  4. Wenen
  5. Dag thuis
  6. ’s Ochtends naar Wallsee, ’s middags wandelen bij de Giessenbach
  7. Vroeg op, naar Hallstatt
  8. Dag thuis, zwemmen? Er is een groter bad in Perg, ongeveer een half uur rijden.
  9. Wenen – dierentuin en museum; eten in Krems?
  10. zwemmen en donautour retour, eten in Sptiz
  11. boot gemist, alsnog donautour Melk <> Spitz, eten in Melk
  12. Plannen maken, zwemmen, eten bij de brug
  13. Kano op de Steyr
    1. route naar Agonitz
    2. Eventueel laden in Sierning, naast Pichlern : Lagerhausstraße 19, 4522 Sierning
    3. Terug via Steyr, eventueel laden in Eisenstraße 44, onderweg naar Spitz
    4. Bij Ybbs an der Donau eventueel van de snelweg en laden: Bahnhofstraße 1
    5. Spitz: eten bij Haus Prinkl, Hinterhaus 16.
  14. Wandelen
    1. Lunch bij Jaunsenstation Kleinleitner , +43 7268 8135
    2. Eventueel grotbezoek
    3. Naar Abtenau rijden, route naar 215 Markt, 5441 Abtenau
  15. Activiteiten rondom Abtenau
    1. Bevriezen tijdens het beekwandelen
    2. Horrorrestaurant bezoeken
    3. Informatieve rondleiding in het openluchtmuseum (1 boerderij groot)
    4. Eten bij K2 in St. Maarten in het dennenbos
  16. Richting Salzburg
    1. Kasteel Hohenwerfen
    2. Salzburg bezoeken
  17. Geologische dag
    1. Fossielen zoeken in de Russbeek
      1. Halverwege Abtenau en Hallstatt links afslaan naar Russbachsaag, route gaat net niet ver genoeg)
      2. Daarna lopend naar de Schneckenwand, route
    2. Gletchers Dachstein (oa Dachstein en Niederer Dachstein ) : vallen voor nu af, lange wandeling of lift (voor 150 euro voor 4 personen)
    3. Bij regenachtig weer: grotbezoek in Dachstein
      1. Mammoetgrot kan voordelig gecombineerd worden met de ijsgrotten (96 euro voor familiekaart voor de een, 112 euro voor combinatie, 128 euro voor 3 liften, vanaf daar 6 km wandeltocht naar Hallstatter gletcher)
      2. Zoutmijnen zitten aan de andere kant van het meer, boven Hallstat, 88 euro voor gezin minus een paar euro uit het foldertje van Hohenwerfen
    4. Bij goed weer: zeilen op de Attersee
      1. Zeilschool Attersee, in Attersee am Attersee, verhuurt een V-Star voor 120 euro/dag; via Telefon: +43 7662 4024 oder +43 699 111 66 99 1
      2. Aan de andere kant van het meer zit zeilschool Steinwand, met verschillende boten vanaf 150/dag; Steinwand 2,4852 Weyregg am Attersee , Mobil: 0043 664 1242849
  18. Terugweg dag 1
    1. Sneltest om 7.30: Schnellteststation Gemeinde Abtenau – Pfarrzentrum , Markt 79, 5441 Abtenau
    2. Ondertussen auto bijladen
    3. Daarna kijken of er in Abtenau ontbeten kan worden
    4. Vanuit Oostenrijk geeft https://www.einreiseanmeldung.de/#/4 geen registratiesplicht voor het inrijden van Duitsland
    5. overnachten in Frankfurt, Crowne Plaza Frankfurt Congress Hotel Lyoner Strasse 44 -48, Frankfurt | 60528 | Germany | 49-69-66330, via booking.com 117 voor 4 personen + ontbijt; route , ongeveer 600 km, 2-3 keer laden
  19. Terugweg dag 2
    1. Ontbijt en zwemmen in het hotel
    2. Sight-seeing in Frankfurt, rond 1600 vertrekken
    3. Kennis bezoeken in Lorchhausen, ~30 km, rond 1900 vertrekken
    4. Lorchhausen –> Zwolle, ~400 km: halverwege eten en laden

Naschrift

Volgende keer proberen meer uit te werken voor aanvang van de vakantie, in plaats van planning 1-2 dagen van tevoren opstellen. De meeste dingen hebben we nu via ’t Net opgezocht, en hadden we dus al in NL kunnen doen. Afstemming op het weer of aanpassingen vanwege nieuwe inzichten kunnen alsnog ter plaatse opgenomen worden maar dat kost minder tijd dan het programma helemaal opstellen.

Statistieken

Met vier personen:

  • 21 dagen van vertrek tot thuiskomst
  • 4440 km gereden
  • 80-100 km gewandeld
  • ~50 km gevaren (40 met de Donau-boot, 12 met de kano)
  • met de auto 550 kWh gebruikt (en 60 kWh teruggewonnen in de bergen)
  • ongveer 4000 euro besteed (ondanks voordelige familie-tickets), dus ~50 euro/persoon/dag

Print this entry

Geplaatst op

Home-lv in thin pool uitbreiden

Mijn /home/wbk zit vol en ik kan niets vinden om te verwijderen, dus: uitbreiden.

TL;DR: controleer of er voldoende ruimte in de VG en in de pool is, daarna: 

lvextend -rL +20G /dev/mapper/homes-wbkRW  /dev/sde2

Daarmee wordt de wbkRW-LV (in LV-pool homestlvpool) uitgebreid met 20 GB (-L +20G) op PV sde2, en wordt het bestandssysteem meteen uitgebreid (-r)

/home/wbk is een thin-LV, in de pool homestlvpool (’thin logical volume-pool voor home-directories’). Om de uitbreiding van de LV effectief te laten zijn, moet er nog ondersteunende ruimte in de ondersteunende LV-pool zijn.

Het spoor loopt van mijn homedirectory: 

root@fractal:~# mount | grep /home/wbk
/dev/mapper/homes-wbkRW on /home/wbk type ext4 (rw,noatime,stripe=256,data=ordered)
/dev/mapper/data-muziekRW on /home/wbk/music type ext4 (rw,noexec,noatime,data=ordered)
/dev/mapper/data-pubRW on /home/wbk/pubNR type ext4 (rw,noexec,noatime,data=ordered)
/dev/mapper/data-geluidRW on /home/wbk/sounds type ext4 (rw,noexec,noatime,stripe=256,data=ordered)
/dev/mapper/data-fotosRW on /home/wbk/photos type ext4 (rw,noexec,noatime,stripe=256,data=ordered)
/dev/mapper/data-videoRW on /home/wbk/movies type ext4 (rw,noexec,noatime,stripe=32750,data=ordered)

dus /home/wbk = /dev/mapper/homes-wbkRW. Gezien de naam: LV wbkRW bevindt zich in VG homes: 

root@fractal:~# lvs homes
LV       VG    Attr       LSize    Pool          Origin         Data%  Meta%  
homeRO       homes ori-a-C---  <27.94g [cache_homes] [homeRO_corig] 6.57   1.36            
homeRW       homes Vwi-aot---  <27.94g homestlvpool  homeRO         3.97                                   
homestlvpool homes twi-aot---  800.00g                              6.42   13.42                           
wbkRO        homes ori-a-C---  <95.13g [cache_wbk]   [wbkRO_corig]  75.98  3.46  
wbkRW        homes Vwi-aot--- <135.13g homestlvpool  wbkRO          37.20  
# welke PV`s zijn erbij betrokken? 
root@fractal:~# vgs homes -o+pv_name
  VG       Attr   VSize  VFree   PV        
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sda4 
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sda5 
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sdc3 
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sdb3 
  homes   5   5   0 wz--n- <1.20t 275.52g /dev/sde2

De nieuw toegewezen ruimte moet beschikbaar gesteld worden door de ‘snelle’ draaiende schijf, de CMR/PMR WD-disk, en niet de SMR Seagate. Welke van de PV’s is dat? 


root@fractal:~# fdisk -l |grep Disk
Disk /dev/sdb: 101.3 GiB, 108711411200 bytes, 212326975 sectors
Disk model: INTEL SSDSA2CW12
Disklabel type: gpt
Disk identifier: CBAB7495-F3C7-4542-BC4F-9C3B5F99E30C
Disk /dev/sdc: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500MX500SSD1  
Disklabel type: gpt
Disk identifier: B480C1C9-E7CB-D04D-BDCD-C797ED5F0512
Disk /dev/sda: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: ST6000DM003-2CY1
Disklabel type: gpt
Disk identifier: 9E399DDA-DE30-694B-8440-EEFC55053188
Disk /dev/sde: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: WDC WD60EFRX-68M
Disklabel type: gpt
Disk identifier: 0517360C-9C7E-42AB-9CC0-B4ADC825DA36

De schijf op /dev/sde is de WD schijf.

Ter controle: er is 800 GB beschikbaar in homestlvpool. De data in de homes-VG bestaat voor een deel uit read-only data uit de homes-*RO LVs en voor een deel uit gewijzigde data in de homes-*RW LVs. De RO-data gaat niet ten koste van de beschikbare 800 GB in de pool, maar de gewijzigde/geschreven data in de RW LVs wel. De geschreven data kan inet meer zijn dan de som van de *RW LVs, dus nog geen 200 GB. Ruimte zat, dus aan de slag. 

root@fractal:~# lvextend -tvrL +20G /dev/mapper/homes-wbkRW  /dev/sde2
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
  /dev/sdd: open failed: No medium found
  /dev/sdf: open failed: No medium found
    Executing: /sbin/fsadm --dry-run --verbose check /dev/homes/wbkRW
fsadm: "ext4" filesystem found on "/dev/mapper/homes-wbkRW".
fsadm: Skipping filesystem check for device "/dev/mapper/homes-wbkRW" as the filesystem is mounted on /home/wbk
    /sbin/fsadm failed: 3
    Test mode: Skipping archiving of volume group.
    Extending logical volume homes/wbkRW to <155.13 GiB
  Size of logical volume homes/wbkRW changed from <135.13 GiB (34593 extents) to <155.13 GiB (39713 extents).
    Test mode: Skipping backup of volume group.
  Logical volume homes/wbkRW successfully resized.
    Executing: /sbin/fsadm --dry-run --verbose resize /dev/homes/wbkRW 162664448K
fsadm: "ext4" filesystem found on "/dev/mapper/homes-wbkRW".
fsadm: Device "/dev/mapper/homes-wbkRW" size is 145093558272 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/homes-wbkRW"
fsadm: Resizing filesystem on device "/dev/mapper/homes-wbkRW" to 166568394752 bytes (35423232 -> 40666112 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/homes-wbkRW 40666112

Lijkt OK; volume is aangekoppeld, dus check van bestandssysteem gaat niet door. Nu zonder -tv: 

root@fractal:~# lvextend -rL +20G /dev/mapper/homes-wbkRW  /dev/sde2
  /dev/sdd: open failed: No medium found
  /dev/sdf: open failed: No medium found
  Size of logical volume homes/wbkRW changed from <135.13 GiB (34593 extents) to <155.13 GiB (39713 extents).
  Logical volume homes/wbkRW successfully resized.
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mapper/homes-wbkRW is mounted on /home/wbk; on-line resizing required
old_desc_blocks = 9, new_desc_blocks = 10
The filesystem on /dev/mapper/homes-wbkRW is now 40666112 (4k) blocks long.

root@fractal:~# df -h /home/wbk
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/homes-wbkRW  153G  127G   19G  87% /home/wbk
root@fractal:~#

Print this entry

Geplaatst op

Printer – HP D7160

Deze printer geeft eigenlijk nooit problemen zolang er nog inkt in zit. Er zitten zes stationaire patronen in, en een vaste printkop. De patronen zijn de HP 363-serie, met een groot zwart patroon en kleine kleurenpatronen voor geel/magenta/cyaan/licht magenta/licht cyaan.

De patronen worden al jaren niet meer geproduceerd door HP. Alle patronen in de printer zijn dus

  • origineel en nieuw, maar over de datum (met ‘correcte’ restinkt-aanduiding)
  • origineel en bijgevuld door mezelf (zonder restinkt-aanduiding, alleen een uitroepteken)
  • origineel en bijgevuld door een cartridge-navulbedrijf (afhankelijk van de chip met of zonder restinkt-aanduiding
  • helemaal nagemaakte cardridge (al dan niet met restinkt-aanduiding)

Als een cartridge leegraakt, heeft dat twee nadelige gevolgen:

  1. Bij lang printen met lucht kan de printkop beschadigd raken door oververhitting
  2. Zodra er geen inkt meer uit een cartridge komt, wordt de hoeveelheid restinkt op de chip door de printer bijgewerkt van ‘let op, bijna leeg’ naar ‘leeg, niet meer printen’. Bijvullen heeft nu geen zin meer.

Nagaan hoeveel inkt er nog over is, gaat door de variatie aan cartridges wat omslachtig: met een weegschaal.

De lege kleurencartridges wegen volgens opgave 14 gram, hoewel ik hier en daar heb gelezen dat het specifieke leeg- en vulgewicht kleurafhankelijk is. HP geeft de leeggewichten voor zover ik gevonden heb niet vrij, maar een vrij uitgebreide lijst is te vinden op de site van Octopus-office, hoewel daar weer 13 gram aangegeven wordt, en 16 gram voor zwart. Omdat het alweer een tijdje geleden is dat ik de inkt gecontroleerd en bijgevuld heb, heb ik de cartridges vandaag gewogen. De status is:

  • geel C8773EE – 19 gram: 5 gram beschikbaar
  • licht magenta C8775EE – 18 gram: 4 gram beschikbaar
  • magenta C8772EE – 19 gram: 5 gram beschikbaar
  • licht cyaan C8774EE – 18 gram: 4 gram beschikbaar
  • cyaan C8771EE – 17 gram: 3 gram beschikbaar
  • zwart C8719EE (XL) / C8721EE – 26 gram: 10 gram beschikbaar?

Van de zwarte cartridge ben ik niet zeker wat het leeggewicht is, maar de cartridge klotst nog van de inkt. In de cyaan-cartridge hoor ik het ook nog klotsen, dat zou 3 gram (dus ruim 3 ml) beschikbare inkt zijn.

Volgens specificaties kunnen er 500 pagina’s geprint worden met de 6-ml cartridges, dat zal A4 bij 5% dekking zijn. Bij 100% dekking zijn dat er 500/20, dus zo’n 25. Ik weet niet of de 5% dekking geldt voor een print met *enkel* die kleur, maar als dat het geval is: de tekeningen en foto’s zijn niet volledig cyaan of magenta, maar een mengsel van meerdere kleuren. Aan de andere kant, het zal vast 5% in draft-modus zijn, niet in fotokwaliteit.

Hier zijn het meestal tekeningen en foto’s op A5 of A6. Vijftig prints moeten er in ieder geval gemaakt kunnen worden.

Voorlopig kunnen we dus nog printen.

Print this entry

Geplaatst op

Apt key van sury.org ongeldig

Bij het ophalen van pakketlijsten met apt update treedt er een fout op, 

root@akashaduocyen:~# apt update
Hit:1 http://ftp.debian.org/debian buster InRelease
Get:2 http://security.debian.org buster/updates InRelease [65.4 kB]                                                         
Get:3 http://ftp.debian.org/debian buster-updates InRelease [51.9 kB]                                                       
Get:4 https://packages.sury.org/php buster InRelease [6,823 B]                                                              
Hit:5 http://forge.yunohost.org/debian buster InRelease                       
Err:4 https://packages.sury.org/php buster InRelease
  The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
Fetched 124 kB in 1s (122 kB/s)
Reading package lists... Done
Building dependency tree       
Reading state information... Done
110 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php buster InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
W: Failed to fetch https://packages.sury.org/php/dists/buster/InRelease  The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
W: Some index files failed to download. They have been ignored, or old ones used instead.

Zoeken op apt key sury.org of apt signatures were invalid: EXPKEYSIG B188E2B695BD4743 geeft voldoende resultaten, maar alleen 

apt-key adv --keyserver keys.gnupg.net --recv-keys B188E2B695BD4743

of 

curl -sSL -o /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

lost het probleem niet altijd op.

Soms bleek het nodig om eerst de bestaande sleutel te verwijderen:

apt-key del B188E2B695BD4743

gevolgd door toevoegen van de nieuwe sleutel.

Print this entry