Arch Linux User Repository

@eta-carinae thanks

zerophase,

There's an error in this command called by configure to test gcc:

gcc -march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2, D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now conftest.c

The problem is with this section:

-Wp,-D_FORTIFY_SOURCE=2, D_GLIBCXX_ASSERTIONS

This should read:

-Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS

This is probably coming from your /etc/makepkg.conf. The -D_GLIBCXX_ASSERTIONS portion was moved in the latest pacman upgrade, so maybe there was a problem when you merged the new version of makepkg.conf?

https://pastebin.com/7iyDqdeF

zerophase,

Can you post the config.log from your build directory? configure spits out that error message anytime gcc fails, and the log should have the underlying error message. Often it's a missing library or header file, but it could be a lot of things.

I'm getting configure: error: in /tmp/makepkg/rasdaemon/src/rasdaemon-0.6.7: configure: error: C compiler cannot create executables with the 0.6.7-2 update.

0.6.7-2 fixes the location of the rasdaemon config file. It's now back at /etc/sysconfig/rasdaemon. It briefly moved to /rasdaemon in version 0.6.7-1!

How is this package in the aur?

How else is someone supposed to explore mce issues?

@Kodehawa, I remember encountering this error, too. I meant to file a bug report upstream but must have forgotten.

I believe the mc_event table is where rasdaemon records memory-corrected error data, which is new in 0.6.6. If you've been using rasdaemon for a while, you already have a database which doesn't have this table, and the new version fails to create it if it doesn't exist, hence the error.

You could stop rasdaemon, rename the existing database in /var/lib/rasdaemon to something else, then restart rasdaemon. It should create a new database with the correct tables. You'd lose all your history, however.

The other option is to use a sqlite tool to add the missing table manually to your existing database. The SQL statement is:

CREATE TABLE mc_event (id INTEGER PRIMARY KEY, timestamp TEXT, err_count INTEGER, err_type TEXT, err_msg TEXT, label TEXT, mc INTEGER, top_layer INTEGER, middle_layer INTEGER, lower_layer INTEGER, address INTEGER, grain INTEGER, syndrome INTEGER, driver_detail TEXT);

I'll file this upstream when I have a chance to downgrade and verify the problem with a fresh database.

Hello. I keep getting

DBD::SQLite::db prepare failed: no such table: mc_event at /usr/bin/ras-mc-ctl line 1243.
ras-mc-ctl: Error: mc_event table missing from /var/lib/rasdaemon/ras-mc_event.db. Run 'rasdaemon --record'.

I've ran rasdaemon --record at least 10 times. I'll attach an image: https://i.imgur.com/gIFyRLT.png

Pretty lost really. Can't find much on the internet. Any ideas?

rasdaemon 0.6.6 adds support for memory corrected error PFA, and I enabled it in the PKGBUILD. If it causes any problems for anyone, let me know and I'll disable it until it's had more testing.

The url() should be https://pagure.io/rasdaemon

@eta-carinae : Just built it for a new machine - smooth... THANKS!!!!!

If anybody is having problems with the periodic block_rq_complete 'errors' that aren't errors, there was a thread on GitHub in the last couple days:

https://github.com/mchehab/rasdaemon/issues/17#issuecomment-646455597

At least for some machines, it's each empty slot in a card reader (SD, etc.) and the 7th message down has the command to make it STFU.

-----Burton

Removed --enable-abrt-report as requested. Got a little too aggressive with experimental flags I guess. :)

Why is this package being built with

--enable-abrt-report

There is no abrt daemon for Arch, so this generates an "error" about 5 per minute. I've built it with this removed and we're down to a heartbeat every 3 seconds or so.

-----Burton

Stellar! ;-)

pancho,

Thanks for the heads-up. I added your workaround and will report the problem upstream.

Hi there.

It seems that we've been hit by a change¹ in GCC 10. See the topic² for more details. It also affects pam_ssh, so I've managed to easily workaround it² by adding:

CFLAGS="$CFLAGS -fcommon" ./configure ...

This just reverts GCC to the pre-10 behavior.

Hope that it helps.

¹: https://gcc.gnu.org/gcc-10/porting_to.html

²: https://bbs.archlinux.org/viewtopic.php?id=255727

³: https://aur.archlinux.org/cgit/aur.git/commit/?h=pam_ssh&id=cb4ed823ece6b3316a7b4103135dec8d1711473c

I get some of those disk errors, though not nearly as many. Also don't see any corresponding problems or errors outside of rasdaemon, so I'm not sure what to make of them. If they're causing people problems, I can disable the disk error feature in the PKGBUILD, but I think reporting this upstream is the best answer.

Those new "experimental features" don't seem to be working right for me here. On certain boots, I get hundreds of the following errors recorded in ras-mc-ctl --errors:

Disk errors
1 2019-09-30 12:19:31 +0200 error: dev=0:2080, sector=192357784, nr_sector=256, error='unknown block error', rwbs='RA', cmd='', 
...
504 2019-10-11 21:02:08 +0200 error: dev=0:2048, sector=12986960, nr_sector=8, error='unknown block error', rwbs='R', cmd='', 

This does not happen on every boot, it only happens every three days or so.

While those errors are getting recorded by rasdaemon, I can't find any strange messages in journalctl or dmesg. The log messages there look fine with no errors or warnings.

Because this was an orphaned package I took over and I didn't notice the change because I was using my own custom unit :). Fixed.

Why are you removing "-r" from ExecStart in rasdaemon.service? Without "-r" it doesn't record anything, journalctl -u rasdaemon output is nearly useless when MCE occurs:

сен 02 19:37:55 X299 rasdaemon[552]: overriding event (1081) ras:mc_event with new print handler
сен 02 19:37:55 X299 rasdaemon[552]: overriding event (1078) ras:aer_event with new print handler
сен 02 19:37:55 X299 rasdaemon[552]: overriding event (1079) ras:non_standard_event with new print handler
сен 02 19:37:55 X299 rasdaemon[552]: overriding event (1080) ras:arm_event with new print handler
сен 02 19:37:55 X299 rasdaemon[552]: overriding event (109) mce:mce_record with new print handler
сен 02 19:37:55 X299 rasdaemon[552]: overriding event (1082) ras:extlog_mem_event with new print handler

automake and autoconf are in base-devel.

automake and autoconf are needed to build this package.