October 2019 - Talk - lists.gtalug.org

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] Meeting on Tuesday, November 12 at 07:30 PM
by hi＠gtalug.org 12 Nov '19

12 Nov '19

<https://gtalug.org/meeting/2019-11/> # taskwarrior with Tomas Babej Tomas will give a tutorial on taskwarrior -- an open-source, command-line cross platform time and task management tool ## Location George Vari Engineering and Computing Centre 245 Church Street, Room 203 Ryerson University <https://goo.gl/maps/16oJ2> <https://www.openstreetmap.org/way/23447525> ## Schedule * 6:00 pm - Please discuss on the general mailing list (i.e. <talk(a)gtalug.org>) where you want to go for dinner. * 7:30 pm - Meeting and presentation. * 9:00 pm - After each meeting, a group of GTALUGers move to The Imperial Pub (54 Dundas St East) for refreshments and more socialising. # Code of Conduct We want a productive happy community that can welcome new ideas, improve every process every year, and foster collaboration between individuals with differing needs, interests and skills. We gain strength from diversity, and actively seek participation from those who enhance it. This code of conduct exists to ensure that diverse groups collaborate to mutual advantage and enjoyment. We will challenge prejudice that could jeopardise the participation of any person in the community. The Code of Conduct governs how we behave in public or in private whenever the Linux community will be judged by our actions. We expect it to be honoured by everyone who represents the community officially or informally, claims affiliation or participates directly. It applies to activities online or offline. We invite anybody to participate. Our community is open. Please read more about the GTALUG Code of Conduct here: <https://gtalug.org/about/code-of-conduct/>. If you have any questions, comments, or concerns about the GTALUG Code of Conduct please contact the GTALUG Board @ <board(a)gtalug.org>. --- GTALUG Announce mailing list announce(a)gtalug.org https://gtalug.org/mailman/listinfo/announce

2 1

Problem with /dev/ttyUSB* serial port
by Jim Ruxton 31 Oct '19

31 Oct '19

I have a device plugged into an active USB extender that usually shows up as /dev/ttyUSB0 when I first plug it in (occasionally it will show up as /dev/ttyUSB1 when first plugging it in) . If it is /dev/ttyUSB0 when I unplug it and plug it back in it occasionally changes to /dev/ttyUSB1 . Is there a way that I can always have it show up as /dev/ttyUSB0 . I'm not sure why /dev/ttyUSB0 isn't being released and restarted after unplugging and replugging it. If I look in /dev it does disappear as /dev/ttyUSB0 from there when I unplug it but like I said it reappears as /dev/ttyUSB1? I am on Ubuntu 18.04.3 LTS . Thanks for any pointers. Jim

8 14

Benchtop power supply
by William Park 30 Oct '19

30 Oct '19

Hi all, (Cross-posted to both GTALUG and KWLUG, because I belong to both. Please reply to the list you're subscribed to. Otherwise, mail admin gets mad at me.) I need a benchtop power supply (0-30V, 0-5A, though 0-10A would be nice). Question: - What brand do you recommend? - Amazon.ca recommends "Sky Toppower" brand. Anyone have experience with these? -- William Park <opengeometry(a)yahoo.ca>

3 2

logrotate problem
by Giles Orr 29 Oct '19

29 Oct '19

We have a bunch of new(ish) Debian 10 VMs, and logrotate is failing to rotate our non-standard logs. Unfortunately we deleted all the old Debian 9 VMs before I noticed this problem, so they're not readily available for comparison. The logrotate config files worked fine on Debian 9 (provisioning is with Ansible, so it's consistent). The failures aren't detailed enough to help. Here's the config: # /etc/logrotate.d/ruby /opt/rubyapp/log/*.log { daily missingok rotate 28 compress delaycompress copytruncate } The parent configuration is standard Debian 10: # /etc/logrotate.conf # (system-supplied comments removed) weekly rotate 4 create include /etc/logrotate.d Unfortunately my paranoia is such that I'm redacting or modifying machine names and folder names ... I apologize for that. But I don't think the path involved is the problem. Here's one of the errors: # systemctl status logrotate.service ● logrotate.service - Rotate log files Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-10-17 00:00:17 EDT; 12h ago Docs: man:logrotate(8) man:logrotate.conf(5) Process: 29004 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE) Main PID: 29004 (code=exited, status=1/FAILURE) Oct 17 00:00:01 acctserver systemd[1]: Starting Rotate log files... Oct 17 00:00:14 acctserver logrotate[8621]: error: unable to open /opt/rubyapp/log/newrelic_agent.log.1 for compression Oct 17 00:00:14 acctserver logrotate[8621]: error: unable to open /opt/rubyapp/log/puma.stderr.log.1 for compression Oct 17 00:00:14 acctserver logrotate[8621]: error: unable to open /opt/rubyapp/log/puma.stdout.log.1 for compression Oct 17 00:00:14 acctserver logrotate[8621]: error: unable to open /opt/rubyapp/log/traffic.log.1 for compression Oct 17 00:00:17 acctserver systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE Oct 17 00:00:17 acctserver systemd[1]: logrotate.service: Failed with result 'exit-code'. Oct 17 00:00:17 acctserver systemd[1]: Failed to start Rotate log files. Here's the folder contents: # cd /opt/rubyapp/log # ls -l -rw-rw-r--+ 1 root root 1982 Oct 16 15:08 newrelic_agent.log -rw-rw-r--+ 1 root root 7194 Oct 16 13:37 newrelic_agent.log.1 -rw-rw-r--+ 1 root root 2549 Oct 10 17:45 newrelic_agent.log.2.gz -rw-rw-r--+ 1 root root 154290 Oct 17 12:34 puma.stderr.log -rw-rw-r--+ 1 root root 573253 Oct 16 13:37 puma.stderr.log.1 -rw-rw-r--+ 1 root root 512648 Oct 10 17:45 puma.stderr.log.2.gz -rw-rw-r--+ 1 root root 238 Oct 16 15:08 puma.stdout.log -rw-rw-r--+ 1 root root 722 Oct 16 13:37 puma.stdout.log.1 -rw-rw-r--+ 1 root root 701 Oct 10 17:45 puma.stdout.log.2.gz -rw-rw-r--+ 1 root root 4747006453 Oct 17 12:37 traffic.log -rw-rw-r--+ 1 root root 15668065757 Oct 10 17:55 traffic.log.1 -rw-rw-r--+ 1 root root 850646513 Sep 20 18:12 traffic.log.2.gz I note that in /var/log/ - where logrotate continues to work fine - that files are owned mostly root:adm (what is 'adm', and does it matter in this context?) and the permissions are 640 rather than 664. There are ACLs attached to the files/folder shown above ... does _that_ matter? Where this gets weirder is that if I run 'logrotate --force /etc/logrotate.d/ruby' it gets rotated fine. It runs fine if run by hand, it fails if run on a SystemD timer. Which suggests a difference in permissions, but don't timers run as root:root? Any thoughts appreciated. As you can see, these are damn big logs, and we have this problem across multiple machines so I'd really like to fix it ... Errors on other servers aren't always consistent with this: a fix for this may or may not help with them, so I may be coming back for more. Thanks all. -- Giles https://www.gilesorr.com/ gilesorr(a)gmail.com

3 5

Pycon Canada 2019
by Alex Volkov 29 Oct '19

29 Oct '19

Hey Everyone, I'm helping to organize Pycon Canada this year and tickets are now available. The conference is happening on November 16-17 at Carlu, with sprints on November 18-19 at Mozilla office. This year we're having a separate ML/Data Science track. http://pycon.ca Alex.

5 5

nice post on fixing performance bugs in Gnome Shell
by D. Hugh Redelmeier 27 Oct '19

27 Oct '19

>From a Ubuntu developer. I'm glad they are contributing. Longish. <https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-…>

1 0

October 2019 Meeting Video
by Alex Volkov 15 Oct '19

15 Oct '19

Hello Everyone, Here are the videos from our October 2019 meeting -- The state of Mozilla with Mike Hoye. The talk is split up in two videos: presentation and Q&A. Here is the playlist of both videos -- https://www.youtube.com/watch?v=RkvDnIGbv4w&list=PLUgE6dqIXiEtGpatcxP_rLdsb… Or here are the separate videos: * The state of Mozilla (fall 2019) with Mike Hoye-- https://youtu.be/RkvDnIGbv4w * The state of Mozilla (fall 2019) Q&A with Mike Hoye-- https://youtu.be/jHeNnSX6GcQ Alex.

1 0

Reproducible Build Project
by Nicholas Krause 12 Oct '19

12 Oct '19

Greetings, In case anyone is interested and there does seem to be a interest in the project: https://reproducible-builds.org/ That's the URL for the reproducible builds including the work that is ongoing with gcc and llvm related to compiler optimizations to my knowledge. Regards, NIck

1 0

(off topic) What do with old tools?
by William Park 11 Oct '19

11 Oct '19

Definitely off topic... I'm cleaning up my garage, and I have lots of old tools (pliers, screwdrivers, drills, etc) that I want to throw away. How do I dispose of metal tools? Is there recycling for them?--William Sent from Yahoo Mail on Android

5 4