September 2022 - Talk - lists.gtalug.org

Tonight's meeting announcement?
by Stewart Russell 15 Nov '22

15 Nov '22

Did it go out? As far as I understand, Colin McGregor will be introducing Linux on Boats.

8 9

Linux on Chromebook
by Michael Galea 14 Nov '22

14 Nov '22

I am hoping to tap the wisdom of the list. I'm going traveling and I don't want to lug around my 5.2 pound T420. Not on this trip. If I buy a cheap refurb Chromebook from Best Buy or Canada Computers: - Will I have luck wiping ChromeOS and installing Debian? Can I still encrypt the disk? - If instead I just run Linux on Chromebook, can I run a wireguard VPN? - Can anyone recommend a minimum spec level for the machine? -- Thanks, Michael Galea

10 17

GPG key signing
by Stef Dunlap 13 Nov '22

13 Nov '22

Hello! This is my first post to this mailing list. :) With the pandemic, what have folks been doing for key signing? Have folks tried doing it remotely, are people meeting 1:1, or are folks just not getting their keys signed? Thanks, Stef D (she/her)

3 3

war story: power failure makes CentOS system unbootable
by D. Hugh Redelmeier 30 Sep '22

30 Sep '22

tl;dr / spoiler: change fstab so that /boot/efi is not automatically mounted. See the recommendation at the end of this message. My gateway computer is a little PC running CentOS. It does not come back after a power failure. The reason (as best I can tell) is interesting and I think that I have a fix. My system is UEFI. It boots from a UEFI system partition, known as /boot/efi to Linux. If this gets corrupted, it won't boot. It is a VFAT partition. On my gateway (a Zotac Zbox RI321, a cute little box with two ethernet ports), the UEFI firmware apparently won't boot if the dirty bit is set in the system partition. CentOS normally runs with /boot/efi mounted. So when the system isn't shut down cleanly, the dirty bit will be on. Consequence: the system is not going to boot after a power failure. Odd observation 1: if I put a live Fedora 25 USB stick in the system and try to boot in this otherwise-unbootable state, CentOS boots from the main disk. So this really looks like a firmware bug/quirk. Odd observation 2: fsck doesn't seem to automatically fix the system partition. Once CentOS 7 booted, I dismounted /boot/efi and did an fsck on it. $ sudo fsck /dev/sda1 fsck from util-linux 2.23.2 fsck.fat 3.0.20 (12 Jun 2013) 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. 1) Remove dirty bit 2) No action ? 1 Leaving filesystem unchanged. /dev/sda1: 16 files, 2420/51145 clusters Googling got me to <https://www.centos.org/forums/viewtopic.php?t=50917> In particular, this advice seemed quite good: ==== recommendation ==== Two other changes I recommend for UEFI systems, to each OS's /etc/fstab. - For the /boot/efi mountpoint, add the mount options x-systemd.automount,noauto - Change fs_passno (last column) to a 1 or 2; the canonical fstab instructions suggest 2, but systemd treats 1 and 2 as the same. The first change means the EFI System partition will not be automatically read-write mounted at boot time; it's a bad idea this is the default because it puts the ESP at risk especially if ther are crashes, FAT has no journal and will therefore always be marked dirty in such a case; no other UEFI OS mounts the ESP by default. Second, if anything tries to access /boot/efi (read or write), systemd will automatically mount it, and because of the fs_passno 1 or 2, it will fsck it first and that fixes and clears the dirty bit in case it's set. Right now without these changes, it's just a matter of having the right number and bad timing of crashes to render the EFI System partition corrupt.

3 9

[GTALUG-Announce] October meeting: Notice Of AGM
by Alan Heighway 29 Sep '22

29 Sep '22

To All GTALUG Members, October's meeting will be our AGM, if you are interested in running for the board please send a message to 'operations(a)gtalug.org'. Annual General meeting & Mike Hoye - Mozilla Update <https://gtalug.org/meeting/2022-10/> with Mike Hoye <https://gtalug.org/> 11 October, 2022 at 07:30 PM Our annual general meeting will take place this month followed by a Mozilla update by Mike Hoye We're going to use Big Blue Button for this meeting: *Time:* October 11, 2022 07:30 PM Eastern Time *Join Big Blue Button:* https://blue.lpi.org/b/eva-zjc-gjy-kgl *A*lan *H*eighway <http://heighway.ca/> heighway.ca VA3WAH / VA3YKZ [image: Please consider the environment before printing] --- GTALUG Announce mailing list announce(a)gtalug.org https://gtalug.org/mailman/listinfo/announce

1 0

Data archaeology: archive KDE distortion from 2004ish
by Stewart Russell 28 Sep '22

28 Sep '22

A friend has a data problem. Her father used to use Linux, and left copious art notes in pictures stored in DigiKam, KDE’s photo management tool. This was in 2004 or so. Now my friend is trying to recover the notes. Current DigiKam won’t read the database. Given her very-tech background, we can assume she’s tried everything reasonable with modern software. I’m wondering: is there a LiveCD from around 2004 that used KDE that might have a ready-to-go matching version of DigiKam? I’ve never been a KDE user, but maybe trying an old OS in a VM might be a way to go. Any suggestions for which ancient distro and where it might still live gratefully received. thanks Stewart

4 4

Linux word processing like it's 1997!
by Stewart C. Russell 26 Sep '22

26 Sep '22

In an act of bravery/recklessness/genius (pick any combination), Tavis Ormandy has managed to package Corel WordPerfect for Unix for modern (x86ish) Linux distributions: https://github.com/taviso/wpunix I'm not quite sure what to make of this, but Liam Proven gives a fair rundown: Tavis Ormandy ports WordPerfect for UNIX to Linux — https://www.theregister.com/2022/07/20/wordperfect_for_unix_for_linux/ Stewart

4 5

speaking of iOS device recovery
by D. Hugh Redelmeier 25 Sep '22

25 Sep '22

I have an annoying problem with my first generation iPad. (The device is worth so little these days that I've not put a lot of effort into this. Without updates, an iDevice is mostly useless.) When I plug it in to the charger and power the device on, it goes into a boot loop. Apparently the battery is so flat that the device cannot boot, even when the charger is connected! There is no obvious way to say: calm down, just go to sleep for a while.

2 1

speaking of Ipod data recovery.
by Karen Lewellen 25 Sep '22

25 Sep '22

..okay perhaps we were not speaking of it yet, but why not start? smiles. Seriously, here is the situation. While I did indeed manage to properly charge this iPod, my visit to Irepair.ca, location around the corner on college, in a building I never plan to entre again..certainly not in heels, shared the following. while the IPod could be fixed, it would cost $175 which is about what I paid for it new. While the IPod data could be recovered, it would cost $60, given the hours and hours and hours of music I have not even heard yet, likely worth it. But, there might be a better way. I asked said Irepair.ca to send an email detailing the process, never hearing from them again. So, am opening up the question to the more technically imaginative. is there a reasonable way to transfer IPod data from an unhappy IPod? Thanks, Kare

4 5

DNS oddities
by D. Hugh Redelmeier 15 Sep '22

15 Sep '22

[This probably has nothing to do with gtalg.og problems.] I run a recursive DNS server on my Rogers cable internet connection. I has stopped working today. (It did this once on the weekend but healed after a few hours.) Symptom: nothing resolves. But I'm still able to use the internet via cached name server info. Refined symptom: $ dig gtalug.org + trace yields nothing but a timeout. Not even intermediat results. Hypothesis: Rogers is blocking accesss to the root name servers. Test: $ mtr i.root-servers.net. # this is a root name server ================================================================ My traceroute [v0.85] reddoor.mimosa.com (::) Thu Sep 15 14:32:38 2022 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 2607:f798:804:f4::1 0.0% 27 7012. 273.2 11.0 7012. 1346. 2. 2607:f798:10:4cf:0:241:5614:2189 0.0% 27 23.2 14.7 10.7 29.0 3.8 3. 2607:f798:10:4a5:0:2091:4823:2082 0.0% 27 13.3 14.1 10.7 22.7 2.7 4. 2607:f798:10:ea48:0:721:3913:6098 0.0% 27 15.6 13.9 10.5 20.7 2.1 5. 2607:f798:10:378:0:2091:4823:7021 0.0% 27 21.9 25.8 20.1 39.5 4.7 6. be812.ccr41.ord03.atlas.cogentco.com 80.8% 27 20.8 23.3 20.8 25.7 1.7 7. be2765.ccr41.ord01.atlas.cogentco.com 80.8% 27 36.4 28.4 21.7 36.4 5.3 8. be3180.rcr21.ind01.atlas.cogentco.com 19.2% 27 30.5 30.2 26.9 35.7 1.9 9. be3365.ccr42.atl01.atlas.cogentco.com 74.1% 27 38.9 45.1 38.9 52.9 5.5 10. be3483.ccr22.mia01.atlas.cogentco.com 80.8% 27 54.7 54.7 53.2 55.9 0.9 11. be3087.ccr41.mia03.atlas.cogentco.com 96.2% 27 55.1 55.1 55.1 55.1 0.0 12. 2001:550:2:4a::90:2 0.0% 27 116.4 116.8 113.7 122.9 2.0 13. 2800:68:ffff:1:: 0.0% 27 126.3 128.3 125.4 135.6 1.9 14. 2800:68:ffff:1::1 0.0% 26 127.3 128.2 124.7 137.0 2.1 15. i.root-servers.net 0.0% 25 7080. 406.6 125.8 7080. 1390. ================================================================ Notice all the lost packets on cogentoco nodes. Here's the same mtr command, this time run on my Vybe Networks VDSL line: ================================================================ redhop-mimosa-com (98.158.128.23) -> i.root-servers.net. (192.36.148.17) 2022-09-15T14:34:24-0400 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. _gateway 0.0% 82 17.2 17.6 16.8 25.1 0.9 2. 216.105.84.14 0.0% 82 17.7 17.6 17.0 18.2 0.3 3. 10.77.77.2 0.0% 82 17.5 17.4 16.9 18.2 0.3 4. te0-1-1-4.ccr32.yyz02.atlas.cogentco.com 0.0% 81 19.1 19.1 18.5 20.2 0.3 5. be2994.ccr22.cle04.atlas.cogentco.com 0.0% 81 25.2 25.7 25.1 26.4 0.3 6. be2718.ccr42.ord01.atlas.cogentco.com 0.0% 81 32.2 34.8 31.6 123.7 12.7 7. be2832.ccr22.mci01.atlas.cogentco.com 0.0% 81 43.7 44.2 43.4 65.5 2.4 8. be3036.ccr22.den01.atlas.cogentco.com 0.0% 81 55.2 55.2 54.6 55.9 0.3 9. be3038.ccr32.slc01.atlas.cogentco.com 0.0% 81 65.4 65.6 65.0 66.6 0.3 10. be2029.ccr22.sea02.atlas.cogentco.com 0.0% 81 85.7 85.6 85.0 89.3 0.5 11. be3705.rcr51.b042840-1.sea02.atlas.cogentco.com 0.0% 81 85.5 85.6 85.0 86.3 0.3 12. 38.88.252.178 0.0% 81 85.1 85.8 84.9 122.9 4.2 13. tky001bb00.IIJ.Net 0.0% 81 166.9 168.7 166.6 213.0 5.6 14. tky001ix11.IIJ.Net 0.0% 81 173.2 173.6 172.3 207.4 3.9 15. as8674.dix-ie.jp 0.0% 81 172.6 176.5 172.2 276.9 15.7 16. i.root-servers.net 1.2% 81 167.3 169.5 166.6 226.5 9.3 ================================================================ This has no lost packets. Is this relevant?

1 0