Bug 21225

I tried to upload the output of 
`journalctl -a --since=2017-06-26 --until=2017-06-27`
but it was 4.3MB ..(300Kb compressed with tar.gz)

any way, here is the file: https://ufile.io/465zf


as well as a picture of the enabled & disabled mirrors: https://ibb.co/fvW3LF

thanks

Created attachment 9486 [details]
Mubarak's journalctl log



(In reply to Mubarak Alrashidi from comment #1)
> I tried to upload the output of 
> `journalctl -a --since=2017-06-26 --until=2017-06-27`
> but it was 4.3MB ..(300Kb compressed with tar.gz)
> 
> any way, here is the file: https://ufile.io/465zf
> 

I should have asked you to compress with xz :-)

It's 184Kb after compressing with xz and only 151Kb after compressing like this:
xz -9 --text journalctl-2017-06-26_27.log

CC: (none) => marja11

(In reply to Mubarak Alrashidi from comment #0)
> Description of problem:
> This is the second time. it happened once before..  about a year ago or so.
> It was a long time since I found any available updates. and with the help of
> #Mageia-Dev channel on FreeNode. I found some mirrors (sources) were
> disabled. I also discovered the last modified time for /etc/urpmi/urpmi.cfg
> was the same time of the latest updated packages (2017/06/26 21:48)
> 

> 
> 
> 0 ✓ root@workstation ~ $ ls -lah /etc/urpmi/urpmi.cfg 
> -rw-rw-r-- 1 root root 6.0K Jun 26 21:48 /etc/urpmi/urpmi.cfg

The only thing that happened at that time was:
 
Jun 26 21:48:41 workstation.local mgaapplet[10907]: trying distributions list from https://releases.mageia.org/api/b/x86_64?product=Default&version=5&mgaonline_version=3.15
etc. etc.

However, something was already wrong with the updates you received since a month earlier.

The last kernel you had installed, was kernel-4.4.65-1.mga5, from May 11, but on May 26 kernel-4.4.68-1.mga5 was released.

@ Thierry

Does mgaapplet disable repositories if there's something wrong with the media_info files?

Assignee: bugsquad => mageiatools
Source RPM: (none) => mgaonline, urpmi
CC: (none) => thierry.vignaud

@Marja van Waes, @Thierry

Hi again... any good reason why did that happen?

(In reply to Mubarak Alrashidi from comment #4)
> @Marja van Waes, @Thierry
> 
> Hi again... any good reason why did that happen?

Thierry might be too busy to read this bug report.

I don't have a clue, except that whatever happened probably already happened in May, somewhere in between the release of kernel-4.4.65-1.mga5 and of kernel-4.4.68-1.mga5

Can you run, again as root:
 
   journalctl -a --since=2017-05-11 --until=2017-06-01 > May.txt

and then:

   xz -9 --text May.txt



I hope May.txt.xz won't be too large to attach.

(In reply to Marja van Waes from comment #5)
> (In reply to Mubarak Alrashidi from comment #4)
> > @Marja van Waes, @Thierry
> > 
> > Hi again... any good reason why did that happen?
> 
> Thierry might be too busy to read this bug report.
> 
> I don't have a clue, except that whatever happened probably already happened
> in May, somewhere in between the release of kernel-4.4.65-1.mga5 and of
> kernel-4.4.68-1.mga5
> 
> Can you run, again as root:
>  
>    journalctl -a --since=2017-05-11 --until=2017-06-01 > May.txt
> 
> and then:
> 
>    xz -9 --text May.txt
> 
> 
> 
> I hope May.txt.xz won't be too large to attach.

Thanks for replying, Yeah I understand.
The file size is 680M and after compressing became 8.1M. again, I could not attach it here.
anyway, here is the like: https://files.fm/u/56vdk3gu

regards

(In reply to Mubarak Alrashidi from comment #6)

> 
> Thanks for replying, Yeah I understand.
> The file size is 680M and after compressing became 8.1M. again, I could not
> attach it here.
> anyway, here is the like: https://files.fm/u/56vdk3gu
> 
> regards

Unfortunately the logs are not complete "Logs begin at Wed 2017-05-17 13:06:53 AST" and there is nothing you can do to retrieve the older logs. When the logs exceed the set vacuum-size, the oldest part is deleted.

I did not manage to find anything in the logs you uploaded that reveals that one of our applications disabled a repository.

However, your system seems to be much too hot to function properly, there are many such lines in your logs:

May 20 23:24:01 workstation.local smartd[1828]: Device: /dev/sdg [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 123 to 124

(for sda, sdb and sdh temperatures above 100°C are reported, too)

May 21 00:28:41 workstation.local sensord[2476]: Sensor alarm: Chip nct6779-isa-0290: CPUTIN: 96.0 C (limit = 80.0 C, hysteresis = 75.0 C) [ALARM]

May 21 01:22:41 workstation.local sensord[2476]: Sensor alarm: Chip nct6779-isa-0290: SYSTIN: 105.0 C (limit = 0.0 C, hysteresis = 0.0 C) [ALARM]

Created attachment 9494 [details]
source automatically disabled


As this screenshot shows there seem to be circumstances in which media may be automatically disabled.

I was able to trigger that message by disconnecting the USB drive on which my local mirror is stored and then attempting to use drakrpm-editmedia - File - Update to update the source.

However, the source was NOT in fact disabled and so I'm not sure precisely what condition (or combination of conditions) would lead to the source actually  being disabled.

I remember seeing that message (and sources actually being disabled) a long time ago but I can't recall the conditions which led to it happening.

CC: (none) => jim

(In reply to James Kerr from comment #8)
> Created attachment 9494 [details]
> source automatically disabled
> 
> 
> As this screenshot shows there seem to be circumstances in which media may
> be automatically disabled.
> 
> I was able to trigger that message by disconnecting the USB drive on which
> my local mirror is stored and then attempting to use drakrpm-editmedia -
> File - Update to update the source.
> 
> However, the source was NOT in fact disabled and so I'm not sure precisely
> what condition (or combination of conditions) would lead to the source
> actually  being disabled.

Thanks, that string comes from http://gitweb.mageia.org/software/rpmdrake/tree/rpmdrake.pm#n880

sub update_sources_noninteractive {
    my ($urpm, $media, %options) = @_;

        urpm::media::select_media($urpm, @$media);
        update_sources_check(
	    $urpm,
	    {},
	    N_("Unable to update medium; it will be automatically disabled.\n\nErrors:\n%s"),
	    @$media,
	);
	return 1;
}

Mubarak did not run drakrpm-edit-media, but in his case a medium did really get disabled without prominent notification. However, the message you found gives the impression that disabling a medium that cannot be updated, is standard practice.

I cannot find the matching code (which I think cannot be in rpmdrake since, afaics, rpmdrake doesn't get called when mgaapplet or "urpmi --auto-update" runs. 

Maybe I'm reading the wrong file http://gitweb.mageia.org/software/rpm/urpmi/tree/urpm/media.pm or I look over it. Not knowing Perl doesn't help, of course.

Created attachment 9495 [details]
some temp outputs

(In reply to Marja van Waes from comment #7)
> (In reply to Mubarak Alrashidi from comment #6)
> 
> > 
> > Thanks for replying, Yeah I understand.
> > The file size is 680M and after compressing became 8.1M. again, I could not
> > attach it here.
> > anyway, here is the like: https://files.fm/u/56vdk3gu
> > 
> > regards
> 
> Unfortunately the logs are not complete "Logs begin at Wed 2017-05-17
> 13:06:53 AST" and there is nothing you can do to retrieve the older logs.
> When the logs exceed the set vacuum-size, the oldest part is deleted.
> 
> I did not manage to find anything in the logs you uploaded that reveals that
> one of our applications disabled a repository.
> 
> However, your system seems to be much too hot to function properly, there
> are many such lines in your logs:
> 
> May 20 23:24:01 workstation.local smartd[1828]: Device: /dev/sdg [SAT],
> SMART Usage Attribute: 194 Temperature_Celsius changed from 123 to 124
> 
> (for sda, sdb and sdh temperatures above 100°C are reported, too)
> 
> May 21 00:28:41 workstation.local sensord[2476]: Sensor alarm: Chip
> nct6779-isa-0290: CPUTIN: 96.0 C (limit = 80.0 C, hysteresis = 75.0 C)
> [ALARM]
> 
> May 21 01:22:41 workstation.local sensord[2476]: Sensor alarm: Chip
> nct6779-isa-0290: SYSTIN: 105.0 C (limit = 0.0 C, hysteresis = 0.0 C) [ALARM]

Thanks for pointing out the hot temps.. about 5 or 6 months ago, I noticed those "SYSTIN", "CPUTIN", "AUXTIN2" and "AUXTIN3" were higher than the maximum values, and when I googled it, I found there has been some kind of a bug with some ASUS workstation/server motherboards. So, I called it a day since there was nothing I could have done.

And about the HDDs temps, I noticed the smartd was reporting the "VALUE" without/or instead of the "RAW VALUE". while `sensors` and `hddtemp` were reporting the "RAW VALUE". although the "VALUE" looks like a value in fahrenheit. But I'm not sure.

based on smartctl manual page:
"So to summarize: the Raw Attribute values are the ones that might have a real physical interpretation, such as "Temperature Celsius", "Hours", or "Start-Stop Cycles".  Each manufacturer converts these, using their detailed knowledge of the disk´s operations and failure modes, to Normalized Attribute values in the range 1-254.  The current and worst (lowest measured) of these Normalized Attribute values are stored on the disk,  along  with  a Threshold value that the manufacturer has determined will indicate that the disk is going to fail, or that it has exceeded its design age or aging limit.  smartctl does not calculate any of the Attribute values, thresholds, or types, it merely reports them from the SMART data on the device."

I've attached the output of `smartctl -A /dev/sdX`, `sensors` and `hddtemp`
please note: 
"sda" and "sdb" are samsung ssd 850 pro
"sdc" and "sdd" are WD Red 6TB Network HDD
"sde" is Samsung XP941 AHCI M.2 SSD - MZHPU512HCGL
"sdf" is an external usb WD Elements
"sdg" is an external usb WD My Passport

Hi Mubarak,

Thank you for having taken the needed time to report this issue! Sorry that I never replied to your information about the given temperatures, I didn't understand what was going on (except that there's a problem with some ASUS motherboards) :-(

This bug was filed against Mageia 5. Did it get fixed? If so, please change its status to RESOLVED - FIXED.

If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/
It continued to get limited extended support since then, but that support has now ended, too.
As a result we are closing this bug report as OLD.

If you still see this issue in a newer Mageia version, and the medium stays disabled even after a reboot, then please reopen this report and say so.

==> If you didn't reset your password after February 2018, then you'll need to reset it here https://identity.mageia.org/forgot_password to be able to log in and comment in this report. <==

Note that we are a community distribution, which means that we, the Mageia users, make Mageia together in our free time. If you'd like to help maintain our packages, then please consider becoming a Mageia packager https://wiki.mageia.org/en/Becoming_a_Mageia_Packager

(Really closing)

Status: NEW => RESOLVED
Resolution: (none) => OLD

This issue is still in Cauldron (MGA7) (and presumably also in MGA6).

Steps to Reproduce:
1. Find a mirror that does not have a correct synthesis.hdlist.cz (ftp.acc.umu.se is a good candidate)
2. Add a local media source
3. Update system using rpmdrake --mode=update

Note: urpmi --auto-update does not disable mirror sources.

Note: when invoking the update from MCC, there is no indication to the user that sources were disabled (not even in the journal)

Status: RESOLVED => UNCONFIRMED
Resolution: OLD => (none)
Ever confirmed: 1 => 0
CC: (none) => gm2.asp

Created attachment 10382 [details]
output from urpmi --auto-update and rpmdrake --mode=update

including listing of active sources before and after

(In reply to Arne Spiegelhauer from comment #14)
> This issue is still in Cauldron (MGA7) (and presumably also in MGA6).
> 
> Steps to Reproduce:
> 1. Find a mirror that does not have a correct synthesis.hdlist.cz
> (ftp.acc.umu.se is a good candidate)
when umeabot is pushing thousands of packages, most mirrors will do.
> 2. Add a local media source
I hope someone will try some more options (no local, but extra online mirror, no extra media, only changed media)
> 3. Update system using rpmdrake --mode=update
> 
> Note: urpmi --auto-update does not disable mirror sources.
> 
> Note: when invoking the update from MCC, there is no indication to the user
> that sources were disabled (not even in the journal)

(In reply to Arne Spiegelhauer from comment #15)
> Created attachment 10382 [details]
> output from urpmi --auto-update and rpmdrake --mode=update
> 
> including listing of active sources before and after

Thanks Arne, for having figured out this only happens with rpmdrake.

Increasing severity and adjusting the summary.

Version: 5 => Cauldron
Whiteboard: (none) => MGA6TOO
Source RPM: mgaonline, urpmi => rpmdrake
Severity: normal => major
Summary: Some mirrors (sources) were disabled by something (itself/packages?) => rpmdrake permanently disables repositories when it has a problem reading the synthesis file of that medium (urpmi luckily doesn't do that)

It also happens with the mgaapplet-update-checker,

What happens (at least in my case) is the following:

The failing to get a synthesis file causes the ignore option to be set in memory for the corresponding media (/usr/share/perl5/vendor_perl/urpm/media.pm).

The existence of a local media without configured key-ids causes a config modified flag ($urpm->{modified}) to be set, resulting in the changed ignore options being written back to /etc/urpmi/urpmi.cfg.
I am not sure if such a configuration is supposed to be supported, but it is easy to create from MCC.