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

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