Re: Why is 7.x still stuck at 7.4?

[Nico Kadel-Garcia]

On Tue, May 15, 2018 at 7:09 PM jdow  wrote:

> After actually getting "yum-conf-sl7x" to work it appears it is an
abbreviation
> for "yum-conf-sl7x-7.5-2.sl7.noarch". It appears this loaded the
slreleasever
> with 7.5, which is the current 7x. Until there is an update for
"yum-conf-sl7x",
> meaning something like "yum-conf-sl7x-7.6-?.sl7.noarch", fill in the ?
later, it
> reads from 7.5.

> It appears that this may not really work until the "yum clean all" is
run. I

"yum clean all" clears, among things, the locally cached metadata.That data
expires eventually, even without the "yum clean all". But if you've changed
where your repos are synced from, *which I'll bet happened when did this,
even if you didn't notice at the time*, then it would talk to the new
upstream host for metadata. Also, if they
/etc/yum.repos.d/[whatever-sl7x].repo file had been manually disabled at
some point or pointed to an out of date local mirror, then deleting the
yum-conf-slx package and re-installing it manually could clear that
somewhat disabled state.

I've come to really suspect that you wound up, by hook or by crook, with a
mangled sl7x yum configuration that was not pointing to current repos, or
was disabled. What you describe above would clear that state.

> don't know if that can be run from inside the update to "yum-conf-7x" or
not.
> The symptoms I had after installing yum-conf-7x agree with the "proper"
command
> sequence mentioned in Takashi Ichihara's post (remove,install,clean all,
update)
> suggest that it cannot, which more or less makes the 7x concept not work
right.
> However, there may be an initial pump priming needed after the 7x conf
install
> with everything working as desired thereafter. I honestly don't know if I
did

Yes, but this would have occurred automatically: the timeout of
"metadata_expire" is typically set at 6 hours, in yum/__init__.py .

> the "clean all" step when installing 7x on the two machines that seemed to
> behave oddly. At any rate, I think I have it solved for now.

> {^_^}

Re: Why is 7.x still stuck at 7.4?

[jdow]

On 20180515 15:15, Orion Poplawski wrote:

On 05/13/2018 12:50 PM, Gilles Detillieux wrote:

On 2018-05-12 04:29, jdow wrote:

On 20180511 21:26, jdow wrote:
I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum update 
still leaves the system declaring it is 7.4.


{o.o}   Joanne


At least that's what I get on one system. The other is still declaring 7.3:

[... /etc]$ cat /etc/yum/vars/slreleasever
7.3

Shouldn't that read 7.x or something else if it's really following 7x?


I've found that sometimes yum-conf-sl7x doesn't properly update 
/etc/yum/vars/slreleasever. I suspect it might be because that file is 
shared/co-owned by yum-conf-sl7x and sl-release packages, and yum seems 
sometimes to get confused as to whether the config file should be updated or 
not. That happened on a few of my systems going from 7.3 to 7.4, but not with 
the recent 7.4 to 7.5 update. My fix was to copy the updated slreleasever file 
from an updated system to one that wasn't updating. Someone else has suggested 
removing and reinstalling the yum-conf-sl7x package: 
https://www.mail-archive.com/scientific-linux-users@fnal.gov/msg04927.html


If all else fails, you could try manually updating the slreleasever file:  
echo 7.5 > /etc/yum/vars/slreleasever


Yeah this system just isn't robust.  Which ever of sl-release or yum-conf-sl7x 
is installed last "wins".  So currently after every new point release you'll 
need to reinstall sl-conf-sl7x or echo 7x > /etc/yum/vars/slreleasever.


It might be possible with the use of rpm triggers to have yum-conf-sl7x "fix" 
slreleasever after every update of sl-release.


Perhaps:

%triggerin -- sl-release
echo 7x > /etc/yum/vars/slreleasever


After actually getting "yum-conf-sl7x" to work it appears it is an abbreviation 
for "yum-conf-sl7x-7.5-2.sl7.noarch". It appears this loaded the slreleasever 
with 7.5, which is the current 7x. Until there is an update for "yum-conf-sl7x", 
meaning something like "yum-conf-sl7x-7.6-?.sl7.noarch", fill in the ? later, it 
reads from 7.5.


It appears that this may not really work until the "yum clean all" is run. I 
don't know if that can be run from inside the update to "yum-conf-7x" or not. 
The symptoms I had after installing yum-conf-7x agree with the "proper" command 
sequence mentioned in Takashi Ichihara's post (remove,install,clean all, update) 
suggest that it cannot, which more or less makes the 7x concept not work right. 
However, there may be an initial pump priming needed after the 7x conf install 
with everything working as desired thereafter. I honestly don't know if I did 
the "clean all" step when installing 7x on the two machines that seemed to 
behave oddly. At any rate, I think I have it solved for now.


{^_^}

Re: Why is 7.x still stuck at 7.4?

[Orion Poplawski]

On 05/13/2018 12:50 PM, Gilles Detillieux wrote:

On 2018-05-12 04:29, jdow wrote:

On 20180511 21:26, jdow wrote:
I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum 
update still leaves the system declaring it is 7.4.


{o.o}   Joanne

At least that's what I get on one system. The other is still declaring 
7.3:


[... /etc]$ cat /etc/yum/vars/slreleasever
7.3

Shouldn't that read 7.x or something else if it's really following 7x?


I've found that sometimes yum-conf-sl7x doesn't properly update 
/etc/yum/vars/slreleasever. I suspect it might be because that file is 
shared/co-owned by yum-conf-sl7x and sl-release packages, and yum seems 
sometimes to get confused as to whether the config file should be 
updated or not. That happened on a few of my systems going from 7.3 to 
7.4, but not with the recent 7.4 to 7.5 update. My fix was to copy the 
updated slreleasever file from an updated system to one that wasn't 
updating. Someone else has suggested removing and reinstalling the 
yum-conf-sl7x package: 
https://www.mail-archive.com/scientific-linux-users@fnal.gov/msg04927.html


If all else fails, you could try manually updating the slreleasever 
file:  echo 7.5 > /etc/yum/vars/slreleasever


Yeah this system just isn't robust.  Which ever of sl-release or 
yum-conf-sl7x is installed last "wins".  So currently after every new 
point release you'll need to reinstall sl-conf-sl7x or echo 7x > 
/etc/yum/vars/slreleasever.


It might be possible with the use of rpm triggers to have yum-conf-sl7x 
"fix" slreleasever after every update of sl-release.


Perhaps:

%triggerin -- sl-release
echo 7x > /etc/yum/vars/slreleasever



--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/

Re: Why is 7.x still stuck at 7.4?

[Takashi ichihara]

Hi,

We have already installed yum-conf-sl7x.noarch to our SL7.4,
yum update did not update to SL7.5 on several nodes. In these cases,

yum remove yum-conf-sl7x
yum install yum-conf-sl7x
yum clean all
yum update

did work for us.


On 2018/05/12 18:29, jdow wrote:

On 20180511 21:26, jdow wrote:

I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum update 
still leaves the system declaring it is 7.4.

{o.o}   Joanne


At least that's what I get on one system. The other is still declaring 7.3:

[... /etc]$ cat /etc/yum/vars/slreleasever
7.3

Shouldn't that read 7.x or something else if it's really following 7x?

{^_^}

Re: Why is 7.x still stuck at 7.4?

[jdow]

FWIW uninstalling the 7x conf and reinstalling it with the cleanup led to 702 
files to be downloaded. Being paranoid I am taking a couple good backups before 
I load that many new things on my machine. So apparently the previous 7x install 
didn't take completely.


{^_-}

On 20180514 01:04, David Sommerseth wrote:

On 14/05/18 02:13, jdow wrote:

I notice that the system which declares 7.3 has been supposedly running 7x for
a very long time now, before 7.4 went public. I also notice some of the
installed repos, such as elrepo, explicitly say 7x. Other's use $slreleasever.

I figure there must be some good reason for this. I'm wondering what that good
reason might be.


$ rpm -q sl-release

This should be a good indication.  If this package is not updated, then the
whole system announces itself as an older release - plus the base sl7-*
repositories point at an older release as well.

Re: Why is 7.x still stuck at 7.4?

[David Sommerseth]

On 14/05/18 02:13, jdow wrote:
> I notice that the system which declares 7.3 has been supposedly running 7x for
> a very long time now, before 7.4 went public. I also notice some of the
> installed repos, such as elrepo, explicitly say 7x. Other's use $slreleasever.
> 
> I figure there must be some good reason for this. I'm wondering what that good
> reason might be.

$ rpm -q sl-release

This should be a good indication.  If this package is not updated, then the
whole system announces itself as an older release - plus the base sl7-*
repositories point at an older release as well.


-- 
kind regards,

David Sommerseth


> On 20180512 06:15, Steven C Timm wrote:
>> Two things could be happening--
>>
>> (1) yum typically has a delay built into it of a couple days before it
>> refreshes the repo cache when the repo has been changed, and thus may not
>> have detected the new repo is there.
>> (2) yum update could be failing for some reason--if you have a stock system
>> there will be e-mail in your root account saying why.
>>
>> My systems got the 7.5 updates yesterday May 11.
>>
>> Steve Timm
>>
>> 
>>
>> *From:* owner-scientific-linux-us...@listserv.fnal.gov
>> <owner-scientific-linux-us...@listserv.fnal.gov> on behalf of jdow
>> <j...@earthlink.net>
>> *Sent:* Saturday, May 12, 2018 4:29:35 AM
>> *To:* scientific-linux-users
>> *Subject:* Re: Why is 7.x still stuck at 7.4?
>> On 20180511 21:26, jdow wrote:
>>> I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum update
>>> still
>>> leaves the system declaring it is 7.4.
>>>
>>> {o.o}   Joanne
>>>
>> At least that's what I get on one system. The other is still declaring 7.3:
>>
>> [... /etc]$ cat /etc/yum/vars/slreleasever
>> 7.3
>>
>> Shouldn't that read 7.x or something else if it's really following 7x?
>>
>> {^_^}

Re: Why is 7.x still stuck at 7.4?

[jdow]

I notice that the system which declares 7.3 has been supposedly running 7x for a 
very long time now, before 7.4 went public. I also notice some of the installed 
repos, such as elrepo, explicitly say 7x. Other's use $slreleasever.


I figure there must be some good reason for this. I'm wondering what that good 
reason might be.


{o.o}

On 20180512 06:15, Steven C Timm wrote:

Two things could be happening--

(1) yum typically has a delay built into it of a couple days before it refreshes 
the repo cache when the repo has been changed, and thus may not have detected 
the new repo is there.
(2) yum update could be failing for some reason--if you have a stock system 
there will be e-mail in your root account saying why.


My systems got the 7.5 updates yesterday May 11.

Steve Timm


*From:* owner-scientific-linux-us...@listserv.fnal.gov 
<owner-scientific-linux-us...@listserv.fnal.gov> on behalf of jdow 
<j...@earthlink.net>

*Sent:* Saturday, May 12, 2018 4:29:35 AM
*To:* scientific-linux-users
*Subject:* Re: Why is 7.x still stuck at 7.4?
On 20180511 21:26, jdow wrote:

I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum update still
leaves the system declaring it is 7.4.

{o.o}   Joanne


At least that's what I get on one system. The other is still declaring 7.3:

[... /etc]$ cat /etc/yum/vars/slreleasever
7.3

Shouldn't that read 7.x or something else if it's really following 7x?

{^_^}

Re: Why is 7.x still stuck at 7.4?

[Gilles Detillieux]

On 2018-05-12 04:29, jdow wrote:

On 20180511 21:26, jdow wrote:
I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum 
update still leaves the system declaring it is 7.4.


{o.o}   Joanne

At least that's what I get on one system. The other is still declaring 
7.3:


[... /etc]$ cat /etc/yum/vars/slreleasever
7.3

Shouldn't that read 7.x or something else if it's really following 7x?


I've found that sometimes yum-conf-sl7x doesn't properly update 
/etc/yum/vars/slreleasever. I suspect it might be because that file is 
shared/co-owned by yum-conf-sl7x and sl-release packages, and yum seems 
sometimes to get confused as to whether the config file should be 
updated or not. That happened on a few of my systems going from 7.3 to 
7.4, but not with the recent 7.4 to 7.5 update. My fix was to copy the 
updated slreleasever file from an updated system to one that wasn't 
updating. Someone else has suggested removing and reinstalling the 
yum-conf-sl7x package: 
https://www.mail-archive.com/scientific-linux-users@fnal.gov/msg04927.html


If all else fails, you could try manually updating the slreleasever 
file:  echo 7.5 > /etc/yum/vars/slreleasever


--
Gilles R. Detillieux  E-mail: <grde...@scrc.umanitoba.ca>
Spinal Cord Research Centre   WWW:http://www.scrc.umanitoba.ca/
Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
Univ. of Manitoba  Winnipeg, MB  R3E 0J9  (Canada)

Re: Why is 7.x still stuck at 7.4?

[Nico Kadel-Garcia]

On Sat, May 12, 2018 at 9:16 AM Steven C Timm  wrote:

> Two things could be happening--

> (1) yum typically has a delay built into it of a couple days before it
refreshes the repo cache when the repo has been changed, and thus may not
have detected the new repo is there.
> (2) yum update could be failing for some reason--if you have a stock
system there will be e-mail in your root account saying why.

> My systems got the 7.5 updates yesterday May 11.

> Steve Timm

One delay is the time for the mirrors to get the updates. Depending on how
cleverly they're set up, and how much material they need to pull from the
reference repository, this can take significant time after the release time
at the primary distribution sites. This problem occurs for almost all
mirrored software distributions of any size. And whatever the local mirror
for you is, it may have fallen behind.

Re: Why is 7.x still stuck at 7.4?

[Steven C Timm]

Two things could be happening--

(1) yum typically has a delay built into it of a couple days before it 
refreshes the repo cache when the repo has been changed, and thus may not have 
detected the new repo is there.
(2) yum update could be failing for some reason--if you have a stock system 
there will be e-mail in your root account saying why.

My systems got the 7.5 updates yesterday May 11.

Steve Timm


From: owner-scientific-linux-us...@listserv.fnal.gov 
<owner-scientific-linux-us...@listserv.fnal.gov> on behalf of jdow 
<j...@earthlink.net>
Sent: Saturday, May 12, 2018 4:29:35 AM
To: scientific-linux-users
Subject: Re: Why is 7.x still stuck at 7.4?

On 20180511 21:26, jdow wrote:
> I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum update 
> still
> leaves the system declaring it is 7.4.
>
> {o.o}   Joanne
>
At least that's what I get on one system. The other is still declaring 7.3:

[... /etc]$ cat /etc/yum/vars/slreleasever
7.3

Shouldn't that read 7.x or something else if it's really following 7x?

{^_^}

Re: Why is 7.x still stuck at 7.4?

[jdow]

On 20180511 21:26, jdow wrote:
I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum update still 
leaves the system declaring it is 7.4.


{o.o}   Joanne


At least that's what I get on one system. The other is still declaring 7.3:

[... /etc]$ cat /etc/yum/vars/slreleasever
7.3

Shouldn't that read 7.x or something else if it's really following 7x?

{^_^}

Why is 7.x still stuck at 7.4?

[jdow]

I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum update still 
leaves the system declaring it is 7.4.


{o.o}   Joanne

Re: How to download SL 7.4

[Nico Kadel-Garcia]

On Mon, Apr 16, 2018 at 11:01 AM, Elio Fabri  wrote:
> On 04/16/2018 04:55 PM, Nico Kadel-Garcia wrote:
>>
>> Did you copy directly to the first block of the USB device? For
>> example, for a device reported at /dev/sda:
>>
>> dd if=dvdfile.iso of=/dev/sda
>
> I don't remember.
> Maybe I copied into /dev/sda1
>
> Does it make some difference?

Yes. /dev/sda1 is a partition, not the beginning of the disk. Finding
a boot loader on a partition is sometimes workable, but it's iffy
at best.

Re: How to download SL 7.4

[Elio Fabri]

On 04/16/2018 04:55 PM, Nico Kadel-Garcia wrote:

Did you copy directly to the first block of the USB device? For
example, for a device reported at /dev/sda:

dd if=dvdfile.iso of=/dev/sda

I don't remember.
Maybe I copied into /dev/sda1

Does it make some difference?
--
Elio Fabri

Re: How to download SL 7.4

[Nico Kadel-Garcia]

On Mon, Apr 16, 2018 at 10:26 AM, Elio Fabri  wrote:
> Thank you Mark.
> I opted for USB install of the Everything iso.
> Downloaded the 8.4 GB file to a fresh partition.
> Copied with dd to a 16 GB pen.
> Up to here, all looks fine.
>
> But when I attempt to boot from USB, I get the message
>> No DEFAULT or UI configuration directive found!
>> boot:
> and I don't know what to answer...
> Unfortunately, my last install was several years ago (SL 6.2) and I have
> forgotten almost everything :-(
> --
> Elio Fabri

Did you copy directly to the first block of the USB device? For
example, for a device reported at /dev/sda:

dd if=dvdfile.iso of=/dev/sda

Re: How to download SL 7.4

[Elio Fabri]

Thank you Mark.
I opted for USB install of the Everything iso.
Downloaded the 8.4 GB file to a fresh partition.
Copied with dd to a 16 GB pen.
Up to here, all looks fine.

But when I attempt to boot from USB, I get the message
> No DEFAULT or UI configuration directive found!
> boot:
and I don't know what to answer...
Unfortunately, my last install was several years ago (SL 6.2) and I have 
forgotten almost everything :-(

--
Elio Fabri

Re: How to download SL 7.4

[Mark Stodola]

On 04/02/2018 07:02 AM, Elio Fabri wrote:

Hi all,
I want to switch from SL 6.2 to SL 7.4 (fresh install, not upgrade).
In http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/iso/
I see several iso files, but cannot understand which one fits my needs.
I would like to keep a bootable DVD (not dual layer) copy and a live disk.
Which are the right files to download?

Thanks


If you want an offline install, you will have to either use a dual-layer 
DVD or USB drive.  They don't package for single layer DVD anymore.  The 
SL-7-DVD is usually adequate for this.  If you have access to a 
repository (internet or LAN), the netinst iso will work fine for 
installs.  It can also be used for rescue boot if I am not mistaken.


Any of the Live images will work, just pick your flavor.  The Live media 
can also be booted and installed to disk, although you are initially 
limited to the packages included on the image.


Last, you can roll-your-own as I do here.  I grab the netinstall image 
and have a local repository.  From there I have a set of scripts/tools 
that builds a custom image that fits on a DVD and includes my kickstarts 
and additional packages I have made or from other repositories such as 
ELrepo and EPEL.  It results in a built-to-need offline installer.


-Mark

How to download SL 7.4

[Elio Fabri]

Hi all,
I want to switch from SL 6.2 to SL 7.4 (fresh install, not upgrade).
In http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/iso/
I see several iso files, but cannot understand which one fits my needs.
I would like to keep a bootable DVD (not dual layer) copy and a live disk.
Which are the right files to download?

Thanks
--
Elio Fabri

RE: EFI installation of SL 7.4

[Bill Maidment]

A bit more Googling provided the answer.
There is a magic touch in Acer laptops. You have to set an administrator 
password in the bios before you are allowed to disable secure boot.
I can now dual boot (using the windows boot manager). The rest should be plain 
sailing now.
Cheers
Bill
 
-Original message-
> From:Eero Volotinen <eero.voloti...@iki.fi>
> Sent: Tuesday 2nd January 2018 15:21
> To: Bill Maidment <b...@maidment.me>
> Cc: SCIENTIFIC-LINUX-USERS@FNAL.GOV <SCIENTIFIC-LINUX-USERS@fnal.gov>
> Subject: RE: EFI installation of SL 7.4
> 
> I have never seen hardware without possibility to disable secureboot.   
> 
> UBuntu works with secureboot. try it first?
> 
> Eero 
> 
> 2.1.2018 5.20 "Bill Maidment" <b...@maidment.me <mailto:b...@maidment.me>> 
> kirjoitti:Thanks. I thought that might be the answer.
 
> Unfortunately, the bios (version 1.10) will not let me disable secure boot.
 
> Maybe an older bios will?
 
> 
 
> 
 
> -Original message-
 
> > From:Eero Volotinen <eero.voloti...@iki.fi <mailto:eero.voloti...@iki.fi>>
 
> > Sent: Tuesday 2nd January 2018 13:33
 
> > To: Bill Maidment <b...@maidment.me <mailto:b...@maidment.me>>
 
> > Cc: SCIENTIFIC-LINUX-USERS@FNAL.GOV 
> > <mailto:SCIENTIFIC-LINUX-USERS@FNAL.GOV> <SCIENTIFIC-LINUX-USERS@fnal.gov 
> > <mailto:SCIENTIFIC-LINUX-USERS@fnal.gov>>
 
> > Subject: Re: EFI installation of SL 7.4
 
> >
 
> > enable uefi on bios and disable secure boot.
 
> >
 
> > Eero
 
> >
 
> > 2.1.2018 4.25 "Bill Maidment" <b...@maidment.me <mailto:b...@maidment.me> 
> > <mailto:b...@maidment.me <mailto:b...@maidment.me>>> kirjoitti: > type="attribution" />Happy New Year everyone.
 
> 
 
> > I am now an owner of an Acer A515-51G laptop and Im trying to install SL 
> > 7.4 in EFI mode dual boot with Win 10.
 
> 
 
> > After lots of experiments I was only able to install in legacy mode, but 
> > that locked me out of Win 10.
 
> 
 
> > I am trying to run mokutil, but I get an error as follows:
 
> 
 
> > mokutil --import 
> > /etc/pki/secure-boot/SECURE-BOOT-KEY-fnal-sl7-exp-2020-08-26
 
> 
 
> > EFI variables are not supported on this system
 
> 
 
> > Elsewhere, it was suggested to do modprobe efivars, but efivars does not 
> > appear to be available.
 
> 
 
> > Any suggestions as to what to do next?
 
> 
 
> >
 
> 
 
> > Cheers
 
> 
 
> > Bill Maidment
 
> 
 
> 

RE: EFI installation of SL 7.4

[Eero Volotinen]

I have never seen hardware without possibility to disable secureboot.

UBuntu works with secureboot. try it first?

Eero

2.1.2018 5.20 "Bill Maidment" <b...@maidment.me> kirjoitti:

Thanks. I thought that might be the answer.
Unfortunately, the bios (version 1.10) will not let me disable secure boot.
Maybe an older bios will?


-Original message-
> From:Eero Volotinen <eero.voloti...@iki.fi>
> Sent: Tuesday 2nd January 2018 13:33
> To: Bill Maidment <b...@maidment.me>
> Cc: SCIENTIFIC-LINUX-USERS@FNAL.GOV <SCIENTIFIC-LINUX-USERS@fnal.gov>
> Subject: Re: EFI installation of SL 7.4
>
> enable uefi on bios and disable secure boot.
>
> Eero
>
> 2.1.2018 4.25 "Bill Maidment" <b...@maidment.me <mailto:b...@maidment.me>>
kirjoitti:Happy New Year everyone.

> I am now an owner of an Acer A515-51G laptop and Im trying to install SL
7.4 in EFI mode dual boot with Win 10.

> After lots of experiments I was only able to install in legacy mode, but
that locked me out of Win 10.

> I am trying to run mokutil, but I get an error as follows:

> mokutil --import /etc/pki/secure-boot/SECURE-
BOOT-KEY-fnal-sl7-exp-2020-08-26

> EFI variables are not supported on this system

> Elsewhere, it was suggested to do modprobe efivars, but efivars does not
appear to be available.

> Any suggestions as to what to do next?

>

> Cheers

> Bill Maidment

Re: EFI installation of SL 7.4

[Eero Volotinen]

enable uefi on bios and disable secure boot.

Eero

2.1.2018 4.25 "Bill Maidment" <b...@maidment.me> kirjoitti:

> Happy New Year everyone.
> I am now an owner of an Acer A515-51G laptop and I'm trying to install SL
> 7.4 in EFI mode dual boot with Win 10.
> After lots of experiments I was only able to install in legacy mode, but
> that locked me out of Win 10.
> I am trying to run mokutil, but I get an error as follows:
> mokutil --import /etc/pki/secure-boot/SECURE-
> BOOT-KEY-fnal-sl7-exp-2020-08-26
> EFI variables are not supported on this system
> Elsewhere, it was suggested to do modprobe efivars, but efivars does not
> appear to be available.
> Any suggestions as to what to do next?
>
> Cheers
> Bill Maidment
>

EFI installation of SL 7.4

[Bill Maidment]

Happy New Year everyone.
I am now an owner of an Acer A515-51G laptop and I'm trying to install SL 7.4 
in EFI mode dual boot with Win 10.
After lots of experiments I was only able to install in legacy mode, but that 
locked me out of Win 10.
I am trying to run mokutil, but I get an error as follows:
mokutil --import /etc/pki/secure-boot/SECURE-BOOT-KEY-fnal-sl7-exp-2020-08-26
EFI variables are not supported on this system
Elsewhere, it was suggested to do modprobe efivars, but efivars does not appear 
to be available.
Any suggestions as to what to do next?

Cheers
Bill Maidment

Re: Upgrading to SL 7.4 not working

[Miguel A. Lerma]

The way I upgraded to 7.4 was as follows.

First make sure that /etc/yum/vars contains the files releasever and 
slreleasever.  The former should have the major version number, i.e., 7:

# cat /etc/yum/vars/releasever 
7

The later may have the latest minor version, e.g.:

# cat /etc/yum/vars/slreleasever 
7.3

Edit /etc/yum/vars/slreleasever and change it to 7.4:

# cat /etc/yum/vars/slreleasever 
7.4

If you want to have always the latest version then replace 7.4 with 7x above:

# cat /etc/yum/vars/slreleasever 
7x

Then you can do the usual upgrade:

# yum clean all

# yum update

etc.

Then check that the upgrade was sucessful:

# cat /etc/redhat-release 
Scientific Linux release 7.4 (Nitrogen)

That worked for me.


-  Miguel A. Lerma
  

From: owner-scientific-linux-us...@listserv.fnal.gov 
<owner-scientific-linux-us...@listserv.fnal.gov> on behalf of Mark Stodola 
<stod...@pelletron.com>
Sent: Tuesday, November 28, 2017 7:44 AM
To: scientific-linux-us...@listserv.fnal.gov
Subject: Re: Upgrading to SL 7.4 not working

On 11/27/2017 09:51 PM, stephen sefick wrote:
> Hello,
>
> I have yum-conf-7x installed, but I am unable to upgrade to 7.4. I can
> provide anything that may be needed to help. I could change all of the
> repos to point to 7.4, but I feel like there is a better way to this
> than that.
>
> kindest regards,
>
> Stephen Sefick, PhD

Any more detailed would be helpful.  What command are you running to
upgrade, what is the output/error you are getting, etc?  Just to
clarify, it is yum-conf-sl7x, correct?

Re: Upgrading to SL 7.4 not working

[Mark Stodola]

On 11/27/2017 09:51 PM, stephen sefick wrote:

Hello,

I have yum-conf-7x installed, but I am unable to upgrade to 7.4. I can 
provide anything that may be needed to help. I could change all of the 
repos to point to 7.4, but I feel like there is a better way to this 
than that.


kindest regards,

Stephen Sefick, PhD


Any more detailed would be helpful.  What command are you running to 
upgrade, what is the output/error you are getting, etc?  Just to 
clarify, it is yum-conf-sl7x, correct?

Upgrading to SL 7.4 not working

[stephen sefick]

Hello,

I have yum-conf-7x installed, but I am unable to upgrade to 7.4. I can
provide anything that may be needed to help. I could change all of the
repos to point to 7.4, but I feel like there is a better way to this than
that.

kindest regards,

Stephen Sefick, PhD

Let's not spend our time and resources thinking about things that are so
little or so large that all they really do for us is puff us up and make us
feel like gods.  We are mammals, and have not exhausted the annoying little
problems of being mammals.

-K. Mullis

"A big computer, a complex algorithm and a long time does not equal
science."

  -Robert Gentleman

Re: not recovering session after locking SL 7.4

[Stefano Vergani]

Hi all,


to David Sommerseth:


graphic card: Intel HD Graphics 4600 in processor and NVIDIA GeForce® GT 730M

drivers: for Intel HD -> i915 for NVIDIA -> nouveau


to James M. Pulver: I am using gnome-classic

thank you for the help, still not working.

Cheers,
Stefano


Da: David Sommerseth <sl+us...@lists.topphemmelig.net>
Inviato: venerdì 3 novembre 2017 20:09
A: Stefano Vergani; scientific-linux-us...@listserv.fnal.gov
Oggetto: Re: not recovering session after locking SL 7.4

On 26/10/17 16:23, Stefano Vergani wrote:
> Hi all,
>
>
> I have just upgraded Scientific Linux to version 7.4 and I have found an
> issue I cannot fix. Anytime I lock my PC (ThinkPad Lenovo T440p)
> pressing the lock icon or simply I close the PC without locking it or
> shutting it down, I am not able anymore to return in my session. The
> screen remains black and I have to press the on/off button for some
> seconds until it reboots.
>
> How can I fix this? Anyone else with the same issue?

Which graphic card do you have?  Which drivers do you use?


--
kind regards,

David Sommerseth

Re: not recovering session after locking SL 7.4

[David Sommerseth]

On 26/10/17 16:23, Stefano Vergani wrote:
> Hi all,
> 
> 
> I have just upgraded Scientific Linux to version 7.4 and I have found an
> issue I cannot fix. Anytime I lock my PC (ThinkPad Lenovo T440p)
> pressing the lock icon or simply I close the PC without locking it or
> shutting it down, I am not able anymore to return in my session. The
> screen remains black and I have to press the on/off button for some
> seconds until it reboots. 
> 
> How can I fix this? Anyone else with the same issue?

Which graphic card do you have?  Which drivers do you use?


-- 
kind regards,

David Sommerseth

Re: not recovering session after locking SL 7.4

[~Stack~]

Greetings,

I have to preface this because so many like to hate on it just to hate
on it...but I am _not_ trying to start a fight. Just point in a
potentially helpful direction. It has it's pros and it has its pains.

With that said, take a look at your journald logs. Crank up the
verbosity and take note of what is there before putting the laptop to
sleep / closing the lid / hibernate / whatever.

100% of the time, without fail, every single problem I've had with my
Ubuntu 16.04 laptop and my SL7.4 laptop not sleeping, waking, or
crashing when I close the lid has gone back to systemd doing something
it shouldn't. The vast majority of the old ways of fixing these problems
don't work, you *must* fix it the systemd way. I've fixed almost* all of
my issues. It is a new tougher-challenge road for me, but it's the one
I'm on. :-)

* The only one remaining is that I can manually lock the screen and wake
the laptop up just fine. However, if I have an external monitor plugged
int and I manually lock the screen for some weird reason systemd puts
the laptop to sleep and won't wake up unless I open/close the lid. YET!
If I just let the screensaver timeout hit, it works perfectly. That one
has stumped me for the last couple of months. *shrug*

If you can figure out what systemd trigger is being tripped, you can
either disable that from running or potentially tweak it to work for you.

Unfortunately, I don't have good resources for you. Of all the times
I've asked the systemd IRC/mailing list, I have yet to get help that
didn't blame me or my hardware (even when I've proved it's neither). The
Ubuntu systemd group has helped several times and having a proper Up
Stream Vendor license that I can install on a spare drive, boot the
laptop, and use their support has helped me with several issues that I
was able to take back to SL7.4 (or wait for the patch to filter down).

It's primarily just been a ton of digging around on the Internet and in
the log files.

Good luck!
~Stack~


On 10/26/2017 09:23 AM, Stefano Vergani wrote:
> Hi all,
> 
> 
> I have just upgraded Scientific Linux to version 7.4 and I have found an
> issue I cannot fix. Anytime I lock my PC (ThinkPad Lenovo T440p)
> pressing the lock icon or simply I close the PC without locking it or
> shutting it down, I am not able anymore to return in my session. The
> screen remains black and I have to press the on/off button for some
> seconds until it reboots. 
> 
> How can I fix this? Anyone else with the same issue?
> 
> 
> thanks,
> 
> Stefano
> 
> 
> p.s. before this upgrade everything worked just fine
> 




signature.asc
Description: OpenPGP digital signature

Re: not recovering session after locking SL 7.4

[Andrew Komornicki]

Hi,

  I understand your frustration.  You should know that power management
and the ability to put your laptop to sleep, or perchance to put it into
hibernation mode, has been a major problem under Linux.  For many years
many of us just gave up.  I go back about a dozen years, when I fist
started with Fedora.  At that time it was not possible to put your
laptop to sleep, so many just gave up.  Over the years, things improved
and it was possible.  i still run under SL 6.9 and my laptop will sleep
without any problems.  Let's face it, this is not rocket science.  The
Apple people have figured out how to do this some years ago.

  If you can undo your changes, you just might be able to put your
laptop to sleep, and recover your session.  Just my two cents worth.

regards,
Andrew


On 10/26/2017 7:23 AM, Stefano Vergani wrote:
> Hi all, 
> 
> I have just upgraded Scientific Linux to version 7.4 and I have found an
> issue I cannot fix. Anytime I lock my PC (ThinkPad Lenovo T440p)
> pressing the lock icon or simply I close the PC without locking it or
> shutting it down, I am not able anymore to return in my session. The
> screen remains black and I have to press the on/off button for some
> seconds until it reboots. 
> 
> How can I fix this? Anyone else with the same issue? 
> 
> thanks, 
> Stefano  
> p.s. before this upgrade everything worked just fine 

not recovering session after locking SL 7.4

[Stefano Vergani]

Hi all,


I have just upgraded Scientific Linux to version 7.4 and I have found an issue 
I cannot fix. Anytime I lock my PC (ThinkPad Lenovo T440p) pressing the lock 
icon or simply I close the PC without locking it or shutting it down, I am not 
able anymore to return in my session. The screen remains black and I have to 
press the on/off button for some seconds until it reboots.

How can I fix this? Anyone else with the same issue?


thanks,

Stefano


p.s. before this upgrade everything worked just fine

SL-7.4 Netinst ok

[Heraldo Filho]

Good morning to everyone,

I installed SL-7.4 via netinst and everything is ok.
I used it as source: ftp1.scientificlinux.org/linux/scientific/7.4/x86_64/os/
and the gnome desktop group

I performed:
yum update and everything ok ...
Thank you!
Heraldo Barros

Re: RHEL 7.4 Beta as a Security Update?

[Alec Habig]

Sean writes:
> All of our desktops with NVIDIA cards are now about as good as boat
> anchors under the 3.10.0-693 kernel.

In my case, it was because whenever you update the X libs, some of the X
libs the proprietary driver replaced when it was installed got
re-replaced with the standard ones from the X rpms.  The last batch of
updates included a lot of xorg-x11 packages along with that kernel.
Re-installing the proprietary nvidia library fixed this.  If your
problem is with the opensource xorg-x11-nouveau driver though, this
wasn't your problem.  This happens whenever an X-windows patch comes
through in rpm form, and is a feature of using 3rd party binary blob
drivers.

TUV also changed the kernel source api, causing vmware to fail on its
rebuild of the vmnet drivers.  Fixed following this recipe here:

  https://communities.vmware.com/message/2686431#2686431

Note that this post does talk about the build 663 "7.4 beta" kernel, but
the one we just got is build 693.  Looks like TUV backported their
7.4beta kernel to 7.3 security updates.  Not much either SL or CentOS
can do about that: both distros simply follow along with security
updates.

-- 
   Alec Habig
 University of Minnesota Duluth
 Dept. of Physics and Astronomy
ha...@neutrino.d.umn.edu
   http://neutrino.d.umn.edu/~habig/

Re: RHEL 7.4 Beta as a Security Update?

[Bonnie King]

On 08/25/2017 01:25 PM, Sean wrote:

If the purpose of this distribution is to provide stable platforms for 
scientific research how do you marry that with releasing back-ported 
beta versions of the future release as a security patch?  Seriously, 
what is going on with dropping RHEL 7.4 beta kernel, gnome-3.22, etc. 
packages into SL7.3 as security updates?


The packages released on Monday are security updates. They are not beta.
They are packages associated with 7.4 that fix security problems.

Scientific Linux always pushes security updates to older "point
releases" for a major version's life cycle:

http://scientificlinux.org/documentation/faq/faq-updates/#older-releases

There are a lot of security updates included in a new release. So rather
than publish them immediately, we push them (and dependencies if needed)
to testing and allow a 2-week testing period before publishing. This
testing window is announced on the scientific-linux-devel mailing list.



All of our desktops with NVIDIA cards are now about as good as boat 
anchors under the 3.10.0-693 kernel.  Sudo segfaults when using it with 
pam_ssh_agent_auth, luckily pam_pkcs11.so works so at least I can use my 
CAC to escalate privilege if I am at the console.  I'm sure the list 
could go on, but these are of my immediate concern.


Suggestions?


Detailed bug reports are always appreciated.



If this is the SOP for this Distro, which until this week didn't seem to 
be the case, I'm left to recommend that we migrate to something more 
stable like CentOS.  Is anyone else feeling the pain?




Nothing has changed. This is standard operating procedure for Scientific 
Linux.



--Sean


--
Bonnie King

RHEL 7.4 Beta as a Security Update?

[Sean]

Greetings,

I've been running on SL7 for about 2 years, having come from CentOS and
RHEL background.  I manage about 15 SL7 desktops, and a handful of
servers.  I work with the Air Force Research Laboratory, so even on a DoD
research network we are required to run yum-cron to be compliant with the
DISA STIG.

If the purpose of this distribution is to provide stable platforms for
scientific research how do you marry that with releasing back-ported beta
versions of the future release as a security patch?  Seriously, what is
going on with dropping RHEL 7.4 beta kernel, gnome-3.22, etc. packages into
SL7.3 as security updates?

All of our desktops with NVIDIA cards are now about as good as boat anchors
under the 3.10.0-693 kernel.  Sudo segfaults when using it with
pam_ssh_agent_auth, luckily pam_pkcs11.so works so at least I can use my
CAC to escalate privilege if I am at the console.  I'm sure the list could
go on, but these are of my immediate concern.

Suggestions?

If this is the SOP for this Distro, which until this week didn't seem to be
the case, I'm left to recommend that we migrate to something more stable
like CentOS.  Is anyone else feeling the pain?

--Sean

Re: 7.4

[Tom H]

On Mon, Jun 19, 2017 at 6:18 PM, ToddAndMargo <toddandma...@zoho.com> wrote:
> On 06/19/2017 05:12 AM, Tom H wrote:
>> On Mon, Jun 19, 2017 at 12:16 AM, ToddAndMargo <toddandma...@zoho.com>
>> wrote:
>>>
>>> Any rumors on when 7.4 will hit SL?
>>
>> Why are you always so keen about dot-releases?
>
> Because when Red Hat fixed my bug reports, they always fix
> it in the next release. They don't care about the one I
> am using. It is appreciated that they fix them, although
> somewhat frustrations that I have to wait forever to see them.

Yes, non-critical bug fixes are published at dot-release time :(

You can enable the "fastbugs" repo to try to get them earlier; but
only closer to release time. RHEL 7.3 was released in Nov and SL 7.3
was released in Jan so it's going to take a few months.

Re: 7.4

[ToddAndMargo]

On 06/24/2017 01:51 AM, David Sommerseth wrote:

On 24/06/17 02:23, Todd Chester wrote:

On 06/23/2017 03:04 PM, Steven Haigh wrote:

On Saturday, 24 June 2017 3:32:02 AM AEST ToddAndMargo wrote:

On 06/23/2017 07:28 AM, Sean A wrote:

Are you all referring to RHEL 7.4 Beta?

Given recent history on the past 2 releases, I would put my money on
7.4
GA in Nov. 2017.  Scientific probably not until Jan 2018.

Just 7.4.  When Red Hat Bugzilla notifies me they
have fixed something, they say they fixed it in 7.4.

The way RH sounds, RHEL is already on 7.4, but I
haven't checked.


Nope:

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)



Sounds to me like RH has lost interest in fixing anything in 7.3


A clarification on how the Red Hat releases and updates work is probably
in order.

Red Hat have a few Errata categories - depending on how critical and
sever an issue is.

Important and critical bug fixes are fixed in erratas during the life
time of the point releases (7.0, 7.1...7.3).

Trivial and minor bug fixes, which does not impact stability, security
and such will most commonly be postponed to the next point release.
That also includes new features.

If something is targeted for the next point release or is put in an
errata for the current release is most commonly evaluated and decided on
a case-by-case scenario by Red Hat's product manager and the package
manager.

You may want to enable the fastbugs repository, which will update all
packages not been considered important enough for the current main
repositories, but still important enough to ship to those who might care.

A bit more info:
<https://www.scientificlinux.org/documentation/faq/faq-updates/#updates-how>

What you typically will notice when enabling fastbugs, is that the
packages required to update from a 7.x with fastbugs to the next point
release will be noticeably smaller compared to not having fastbugs enabled.

But, you will notice that the updates will often be a bit fewer when the
next point release is talking shape and especially after the public
betas have been released.  That said, important fixes will still flow to
the current stable releases where it is needed and supported.


Hope this clarified more than added more confusion.




Hi David,

Thank you for the tutorial!

I checked out sl7-fastbugs.repo

[sl-fastbugs]
...
enabled=1

So I do have it.  I haven't seen any of the bugs I
reported show up.  Then again, RH specifically stated
that they release them in 7.4.  So, I will have to wait.
Aw shucks.

-T

--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: 7.4

[David Sommerseth]

On 24/06/17 02:23, Todd Chester wrote:
> On 06/23/2017 03:04 PM, Steven Haigh wrote:
>> On Saturday, 24 June 2017 3:32:02 AM AEST ToddAndMargo wrote:
>>> On 06/23/2017 07:28 AM, Sean A wrote:
>>>> Are you all referring to RHEL 7.4 Beta?
>>>>
>>>> Given recent history on the past 2 releases, I would put my money on
>>>> 7.4
>>>> GA in Nov. 2017.  Scientific probably not until Jan 2018.
>>> Just 7.4.  When Red Hat Bugzilla notifies me they
>>> have fixed something, they say they fixed it in 7.4.
>>>
>>> The way RH sounds, RHEL is already on 7.4, but I
>>> haven't checked.
>>
>> Nope:
>>
>> $ cat /etc/redhat-release
>> Red Hat Enterprise Linux Server release 7.3 (Maipo)
>>
> 
> Sounds to me like RH has lost interest in fixing anything in 7.3

A clarification on how the Red Hat releases and updates work is probably
in order.

Red Hat have a few Errata categories - depending on how critical and
sever an issue is.

Important and critical bug fixes are fixed in erratas during the life
time of the point releases (7.0, 7.1...7.3).

Trivial and minor bug fixes, which does not impact stability, security
and such will most commonly be postponed to the next point release.
That also includes new features.

If something is targeted for the next point release or is put in an
errata for the current release is most commonly evaluated and decided on
a case-by-case scenario by Red Hat's product manager and the package
manager.

You may want to enable the fastbugs repository, which will update all
packages not been considered important enough for the current main
repositories, but still important enough to ship to those who might care.

A bit more info:
<https://www.scientificlinux.org/documentation/faq/faq-updates/#updates-how>

What you typically will notice when enabling fastbugs, is that the
packages required to update from a 7.x with fastbugs to the next point
release will be noticeably smaller compared to not having fastbugs enabled.

But, you will notice that the updates will often be a bit fewer when the
next point release is talking shape and especially after the public
betas have been released.  That said, important fixes will still flow to
the current stable releases where it is needed and supported.


Hope this clarified more than added more confusion.


-- 
mvh.

David Sommerseth

Re: 7.4

[Todd Chester]

On 06/23/2017 03:04 PM, Steven Haigh wrote:

On Saturday, 24 June 2017 3:32:02 AM AEST ToddAndMargo wrote:

On 06/23/2017 07:28 AM, Sean A wrote:

Are you all referring to RHEL 7.4 Beta?

Given recent history on the past 2 releases, I would put my money on 7.4
GA in Nov. 2017.  Scientific probably not until Jan 2018.

Just 7.4.  When Red Hat Bugzilla notifies me they
have fixed something, they say they fixed it in 7.4.

The way RH sounds, RHEL is already on 7.4, but I
haven't checked.


Nope:

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)



Sounds to me like RH has lost interest in fixing anything in 7.3

Re: 7.4

[Steven Haigh]

On Saturday, 24 June 2017 3:32:02 AM AEST ToddAndMargo wrote:
> On 06/23/2017 07:28 AM, Sean A wrote:
> > Are you all referring to RHEL 7.4 Beta?
> > 
> > Given recent history on the past 2 releases, I would put my money on 7.4
> > GA in Nov. 2017.  Scientific probably not until Jan 2018.
> Just 7.4.  When Red Hat Bugzilla notifies me they
> have fixed something, they say they fixed it in 7.4.
> 
> The way RH sounds, RHEL is already on 7.4, but I
> haven't checked.

Nope:

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)

-- 
Steven Haigh

 net...@crc.id.au   http://www.crc.id.au
 +61 (3) 9001 6090  0412 935 897

signature.asc
Description: This is a digitally signed message part.

Re: 7.4

[Jos Vos]

On Fri, Jun 23, 2017 at 10:32:02AM -0700, ToddAndMargo wrote:

> The way RH sounds, RHEL is already on 7.4, but I
> haven't checked.

Only 7.4 *beta* is out for a month now.  So the final 7.4 might still
take a few months from now.

-- 
--Jos Vos <j...@xos.nl>
--X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
--Amsterdam, The Netherlands|   Mobile: +31 6 26216181

Re: 7.4

[ToddAndMargo]

On 06/23/2017 07:28 AM, Sean A wrote:

Are you all referring to RHEL 7.4 Beta?

Given recent history on the past 2 releases, I would put my money on 7.4 GA in 
Nov. 2017.  Scientific probably not until Jan 2018.



Just 7.4.  When Red Hat Bugzilla notifies me they
have fixed something, they say they fixed it in 7.4.

The way RH sounds, RHEL is already on 7.4, but I
haven't checked.

Re: 7.4

[Sean A]

Are you all referring to RHEL 7.4 Beta?  

Given recent history on the past 2 releases, I would put my money on 7.4 GA in 
Nov. 2017.  Scientific probably not until Jan 2018.

Re: 7.4

[Nico Kadel-Garcia]

They're notably larger than weekly updates, they tend to restart
daemons (not always successfully), and the local yum metadata ideally
needs to be cleared before updating from it to avoid obsolete
repodata.

On Mon, Jun 19, 2017 at 8:12 AM, Tom H <tomh0...@gmail.com> wrote:
> On Mon, Jun 19, 2017 at 12:16 AM, ToddAndMargo <toddandma...@zoho.com> wrote:
>>
>> Any rumors on when 7.4 will hit SL?
>
> Why are you always so keen about dot-releases?
>
> Do you perform installs for every dot-release or are you using
> versioned yum repos (the latter doesn't make sense if you always
> switch to the latest dot-release)?

Re: 7.4

[Tom H]

On Mon, Jun 19, 2017 at 12:16 AM, ToddAndMargo <toddandma...@zoho.com> wrote:
>
> Any rumors on when 7.4 will hit SL?

Why are you always so keen about dot-releases?

Do you perform installs for every dot-release or are you using
versioned yum repos (the latter doesn't make sense if you always
switch to the latest dot-release)?

Re: 7.4

[jdow]

On 2017-06-18 21:16, ToddAndMargo wrote:

Hi All,

Any rumors on when 7.4 will hit SL?

-T


Well, WiseOldCrow remarked it was just around the corner, "second Tuesday this 
week."


{O,o}  Ack! Plbbltptpbbb! (Fed that straight line I cannot resist.)

7.4

[ToddAndMargo]

Hi All,

   Any rumors on when 7.4 will hit SL?

-T


--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~