Re: Boot order use the oldest kernel

[Tim via users]

On Mon, 2019-10-07 at 23:02 +,   sixpack13 wrote:
> /etc/default/grub 
> is used during kernel updates
> 
> there GRUB_DEFAULT= should be 0 or saved (I guess it's the default
> after fresh OS install)
> 
> GRUB_DEFAULT=saved 
> reads /boot/grub2/grubenv
> 
> - if I get that right - 

The default = saved option would make the next boot use the last kernel
that you selected.  However, it depends on each stanza saving itself as
the one to be used.  Zero means to boot from the topmost stanza
(usually new kernels are written to the top of the list, so zero picks
the latest).

i.e. You have three kernels to choose from, each grub entry for that
kernel saves its choice when selected, then boots up.  Next boot up,
grub looks to see what grub entry number was saved, and boots it.

Taking part of grub.conf from very old system of mine as an example:

default saved

title Fedora Core (2.6.17-1.2142_FC4)
root (hd0,0)
kernel /vmlinuz-2.6.17-1.2142_FC4 ro root=LABEL=/ acpi=force
initrd /initrd-2.6.17-1.2142_FC4.img
savedefault

title Fedora Core (2.6.17-1.2139_FC4)
root (hd0,0)
kernel /vmlinuz-2.6.17-1.2139_FC4 ro root=LABEL=/ acpi=force
initrd /initrd-2.6.17-1.2139_FC4.img
savedefault

title Fedora Core (2.6.16-1.2111_FC4)
root (hd0,0)
kernel /vmlinuz-2.6.16-1.2111_FC4 ro root=LABEL=/ acpi=force
initrd /initrd-2.6.16-1.2111_FC4.img

At the beginning is the "default saved" command that tells grub to boot
using the same kernel as last time.  However, only the first two
entries save themselves as the default.  If I elect to boot from the
third kernel (last on the list), I'm not sure what would happen next
boot.  I'm guessing that whichever out of the first two I last used
would be booted, because one of them set themselves as default, and
nothing else unsets that.

NB: I'm not sure if "savedefault" has to be last, or can be typed
anywhere in the stanzas.  And I'd be very surprised if the modern grub
didn't behave in the same way (having to deliberately save the chosen
entry as the default), but it installed no man file, nor a useful info
file on the PC that I'm looking at.

-- 
 
uname -rsvp
Linux 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon Sep 30 14:19:46 UTC 2019 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
 
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Boot order use the oldest kernel

[sixpack13]

s/reads/is related to/
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: SSH after upgrade

[Marko Vojinovic]

On Mon, 07 Oct 2019 15:25:28 +0200
Jakub Jelen  wrote:
> On Mon, 2019-10-07 at 14:13 +0200, Marko Vojinovic wrote:
> > On Mon, 07 Oct 2019 10:38:32 +0200
> > Can you please elaborate what were the "many practical reasons" that
> > prevented this from being changed for the last 5 years? And why are
> > they not equally practical now?
> 
> Mostly the unwillingness of people who were used to use root accounts
> in Fedora and not enough alternatives how to override or set up
> alternative during installation.
> 
> The initial change was half-baked proposed 5 years ago:
> 
> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no

Yes, that's what I remember being proposed, and eventually rejected.
There were long discussions of this on various mailing lists. I mostly
remember this one:

 https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html

but there were others as well...
 
> but never accepted by FeSCO (note sure if it was even proposed) and
> started long discussions on mailing lists as linked from there.
> 
> Since then, we did not change the value to "no", but we disabled only
> the password logins, we added a simple way how to override this in
> anaconda installer and there are simple ways how to override it in
> kickstarts or add a public ssh keys to authorized_keys files.

I see, so there indeed were some technical improvements, to anaconda and
kickstart, that circumvented the issues people had back then. That is
what I was looking for --- the technical upgrades that made changing
the default a viable proposal. I'll read up on those in more detail.
 
> I think it was mostly testing and scratch boxes that needed root
> logins (specific use cases), making sure that there is some other
> account that is allowed to login after installation (installation
> problems). But I think I did not manage to read that thread this year
> again.

I just re-read the discussion on the devel list from 2014. And yes, the
main complaint was that some people were deploying headless VM/test
systems where they didn't want to create a non-root user. Changing the
default would break a bunch of their existing kickstart scripts...
Another scenario that was mentioned by someone was that if /home were
network-mounted, and the network would fail, it would leave the system
inaccessible via ssh.

> 5 years ago, there were no simple workarounds for the installation.
> Even this year, the agreement was not really smooth and updating
> installer was one of the requirements for the change to be approved:
> 
> https://pagure.io/fesco/issue/2133

I see, so it was an uphill battle even this time around. But this
time it was finally won! Congratulations! :-)

> This change request is in Fedora actually for more than 15 years:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=89216
> 
> Back in that time, this was not default even in upstream and many
> people were using root accounts.

Oh, wow, unbelievable, reported on 2003-04-21 !!! So this issue is even
older than Fedora itself --- from the days of Red Hat 9 (Shrike) all
the way to Fedora 31... I thought this was first raised in 2015, had no
idea it is as old as 2003...

> I think that over the years, the security practices shifted to better
> solutions, people learned to use normal users, sudo and ssh keys,
> which allowed us to do this finally. Originally the change would be a
> surprise for users, but recently, people were surprised by the root
> login allowed in Fedora, which also started to be dangerous.

So essentially it was a psychological thing --- it took all this time
just to change people's minds about this, re-educate them, and wait
until they change their practices of remotely logging in as root. With a
couple of technical modifications to anaconda and kickstart.

This is the info I was looking for, thanks a lot! :-)

But I'm still amazed... A security bug/rfe from 2003, closed in 2019...
Just wow...

Thanks, :-)
Marko


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Boot order use the oldest kernel

[sixpack13]

/etc/default/grub 
is used during kernel updates

there GRUB_DEFAULT= should be 0 or saved (I guess it's the default after fresh 
OS install)

GRUB_DEFAULT=saved 
reads /boot/grub2/grubenv

- if I get that right - 
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Can't boot from the harddive

[George N. White III]

On Mon, 7 Oct 2019 at 17:59, Jon Ingason  wrote:

> Thanks Samuel and George
>
> Den 2019-10-07 kl. 19:50, skrev Samuel Sieb:
> > On 10/7/19 9:42 AM, Jon Ingason wrote:
> >> I accidentally turn off my computer with the power button. That resulted
> >> in corruption of "BIOS start". The motherboard has legacy BIOS.
> >
> > Can you explain what's happening?  Unless you were in the middle of
> > updating grub, it's unlikely that you've corrupted any of the actual
> > boot process.  But maybe the filesystem needs checking.
>
>
> Den 2019-10-07 kl. 19:59, skrev George N. White III:
> > On Mon, 7 Oct 2019 at 13:43, Jon Ingason  > > wrote:
> >
> > Hi,
> > I accidentally turn off my computer with the power button. That
> resulted
> > in corruption of "BIOS start". The motherboard has legacy BIOS.
> >
> >
> > For most systems, BIOS settings are stored in battery backed memory and
> > will not be affected by a power failure until the battery dies.   There
> > are,
> > however, some systems that have "power fail" actions that may update
> > the BIOS settings so the system responds differently after an intentional
> > shutdown versus a power failure.
> >
> > If the battery dies, the BIOS should revert to "default" settings, which
> > might
> > mean UEFI boot.   You should enter the BIOS configuration utility (which
> > usually requires pressing a vendor-specific key when booting) and
> check the
> > boot settings.   If the system is several years old or has been without
> > power
> > for long periods you should check the battery (generally a small
> "coin" cell
> > on the motherboard).
> >
> >
>
> I found the problem. The things are the computer has to hard drives and
> the boot order of the hard drives where switched in the BIOS. I fix it
> in the BIOS and could boot normally.
>

Glad you got the system going.

The change could indicate a failing battery for the BIOS parameter storage.
If so, you could see other changes to BIOS settings next time the power is
cycled.  You can check the battery with a multimeter.  The battery
is usually easy to replace.

-- 
George N. White III
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Can't boot from the harddive

[Jon Ingason]

Thanks Samuel and George

Den 2019-10-07 kl. 19:50, skrev Samuel Sieb:
> On 10/7/19 9:42 AM, Jon Ingason wrote:
>> I accidentally turn off my computer with the power button. That resulted
>> in corruption of "BIOS start". The motherboard has legacy BIOS.
> 
> Can you explain what's happening?  Unless you were in the middle of
> updating grub, it's unlikely that you've corrupted any of the actual
> boot process.  But maybe the filesystem needs checking.


Den 2019-10-07 kl. 19:59, skrev George N. White III:
> On Mon, 7 Oct 2019 at 13:43, Jon Ingason  > wrote:
>
> Hi,
> I accidentally turn off my computer with the power button. That
resulted
> in corruption of "BIOS start". The motherboard has legacy BIOS.
>
>
> For most systems, BIOS settings are stored in battery backed memory and
> will not be affected by a power failure until the battery dies.   There
> are,
> however, some systems that have "power fail" actions that may update
> the BIOS settings so the system responds differently after an intentional
> shutdown versus a power failure.
>
> If the battery dies, the BIOS should revert to "default" settings, which
> might
> mean UEFI boot.   You should enter the BIOS configuration utility (which
> usually requires pressing a vendor-specific key when booting) and
check the
> boot settings.   If the system is several years old or has been without
> power
> for long periods you should check the battery (generally a small
"coin" cell
> on the motherboard).
>
>

I found the problem. The things are the computer has to hard drives and
the boot order of the hard drives where switched in the BIOS. I fix it
in the BIOS and could boot normally.
-- 
Regards

Jon Ingason
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Can't boot from the harddive

[George N. White III]

On Mon, 7 Oct 2019 at 13:43, Jon Ingason  wrote:

> Hi,
> I accidentally turn off my computer with the power button. That resulted
> in corruption of "BIOS start". The motherboard has legacy BIOS.
>

For most systems, BIOS settings are stored in battery backed memory and
will not be affected by a power failure until the battery dies.   There
are,
however, some systems that have "power fail" actions that may update
the BIOS settings so the system responds differently after an intentional
shutdown versus a power failure.

If the battery dies, the BIOS should revert to "default" settings, which
might
mean UEFI boot.   You should enter the BIOS configuration utility (which
usually requires pressing a vendor-specific key when booting) and check the
boot settings.   If the system is several years old or has been without
power
for long periods you should check the battery (generally a small "coin" cell
on the motherboard).


>
> $ sudo fdisk -l /dev/sda
> [sudo] lösenord för jonsi:
> Disk /dev/sda: 2,7 TiB, 3000592982016 byte, 5860533168 sektorer
> Disk-modell: WDC WD30EZRX-22D
> Enheter: sektorer av 1 * 512 = 512 byte
> Sektorstorlek (logisk/fysisk): 512 byte / 4096 byte
> I/O-storlek (minsta/optimal): 4096 byte / 4096 byte
> Disketikettstyp: gpt
> Diskidentifierare: 0A859753-6B39-4C92-BD5C-9754F2056E45
>
> Enhet   Början Slutet   Sektorer Storlek Typ
> /dev/sda1 2048   4095   2048  1M BIOS start
> /dev/sda2 409610280951024000500M Linux-filsystem
> /dev/sda3  1028096 5860532223 58595041282,7T Linux LVM
>
> I can start the OS from the hard drive with SystemRescueCD. How can I
> repair BIOS start so I can start directly from the hard drive?
>





> --
> Regards
>
> Jon Ingason
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>


-- 
George N. White III
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Can't boot from the harddive

[Samuel Sieb]

On 10/7/19 9:42 AM, Jon Ingason wrote:

I accidentally turn off my computer with the power button. That resulted
in corruption of "BIOS start". The motherboard has legacy BIOS.


Can you explain what's happening?  Unless you were in the middle of 
updating grub, it's unlikely that you've corrupted any of the actual 
boot process.  But maybe the filesystem needs checking.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Boot order use the oldest kernel

[Jon Ingason]

Hi,
With one of my computers I have problem to set permanent default start
order of the kernel. I can change it with "sudo grub2-set-default 0" but
when I update the kernel I get oldest kernel as default boot order.
How do I make the start order so the latest kernel is default?
-- 
Regards

Jon Ingason
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Can't boot from the harddive

[Jon Ingason]

Hi,
I accidentally turn off my computer with the power button. That resulted
in corruption of "BIOS start". The motherboard has legacy BIOS.

$ sudo fdisk -l /dev/sda
[sudo] lösenord för jonsi:
Disk /dev/sda: 2,7 TiB, 3000592982016 byte, 5860533168 sektorer
Disk-modell: WDC WD30EZRX-22D
Enheter: sektorer av 1 * 512 = 512 byte
Sektorstorlek (logisk/fysisk): 512 byte / 4096 byte
I/O-storlek (minsta/optimal): 4096 byte / 4096 byte
Disketikettstyp: gpt
Diskidentifierare: 0A859753-6B39-4C92-BD5C-9754F2056E45

Enhet   Början Slutet   Sektorer Storlek Typ
/dev/sda1 2048   4095   2048  1M BIOS start
/dev/sda2 409610280951024000500M Linux-filsystem
/dev/sda3  1028096 5860532223 58595041282,7T Linux LVM

I can start the OS from the hard drive with SystemRescueCD. How can I
repair BIOS start so I can start directly from the hard drive?
-- 
Regards

Jon Ingason
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: strange behavior: it slows down and then recovers

[Samuel Sieb]

On 10/7/19 1:29 AM, Andras Simon wrote:

2019-10-07 3:08 GMT+02:00, Eddie G. O'Connor Jr. :

Been noticing the same thing on my F30 system as wellI don't think
its FedoraI think its Mozilla's Firefox, this behavior also has hit
my OpenSuSE and my CEntOS laptopssomething is eating up the RAM on
them when Firefox is running...and it seems to go back to being snappy
and fast once I close and then reopen FF, but after a few
minutes?.it slows down again.


It's not necessarily a problem with FF: it may be due to an addon, or
a website that is doing some heavy computations locally.  If you have
lots of tabs open, you have lots of potential culprits.


And the nice about multi-process firefox is that if you kill the "Web 
Content" process that is too big, then you can narrow down which site 
was causing you the problem.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: /dev/null is full ???

[Ed Greshko]

On 10/7/19 8:22 PM, j.witvl...@mindef.nl wrote:

There seems to be missing a /dev/one.
Could it be obtained by exoring /dev/zero?


Does this satisfy your need?

[egreshko@meimei ~]$ dd if=/dev/zero count=1 bs=512 | tr '\000' '\377' > file
1+0 records in
1+0 records out
512 bytes copied, 6.6966e-05 s, 7.6 MB/s

[egreshko@meimei ~]$ hexdump -v file
000        
010        
020        
030        
040        
050        
060        
070        
080        
090        
0a0        
0b0        
0c0        
0d0        
0e0        
0f0        
100        
110        
120        
130        
140        
150        
160        
170        
180        
190        
1a0        
1b0        
1c0        
1d0        
1e0        
1f0        

--
If simple questions can be answered with a simple google query then why are 
there so many of them?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: /dev/null is full ???

[George N. White III]

On Mon, 7 Oct 2019 at 07:59, Ed Greshko  wrote:

> On 10/7/19 6:30 PM, George N. White III wrote:
> > Not "nothing"
>

Oops -- I was thing of "/dev/zero"

Really?
>
> [egreshko@meimei ~]$ sudo dd if=/dev/null of=/dev/sdg status=progress
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 0.000189575 s, 0.0 kB/s
>
> [egreshko@meimei ~]$ sudo mount /dev/sdg1 /mnt
> [egreshko@meimei ~]$ ls /mnt
> lost+found  x
>
>
> --
> If simple questions can be answered with a simple google query then why
> are there so many of them?
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>


-- 
George N. White III
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: SSH after upgrade

[Jakub Jelen]

On Mon, 2019-10-07 at 14:13 +0200, Marko Vojinovic wrote:
> On Mon, 07 Oct 2019 10:38:32 +0200
> Jakub Jelen  wrote:
> 
> > On Mon, 2019-10-07 at 02:53 +0200, Marko Vojinovic wrote:
> > > On Mon, 7 Oct 2019 10:21:03 +1100
> > > Cameron Simpson  wrote:
> > > > On 07Oct2019 01:00, Marko Vojinovic  wrote:
> > > > > On Sun, 06 Oct 2019 18:05:02 +0200
> > > > > alcir...@gmail.com wrote:
> > > > > > It could it be related to this change:
> > > > > > https://fedoraproject.org/wiki/Releases/31/ChangeSet#Disable_Root_Password_Login_in_SSH
> > > > > 
> > > > > As a side question --- I remember that this was the default
> > > > > for
> > > > > upstream OpenSSH since 2015, but was not adopted in Fedora
> > > > > because
> > > > > people who install Fedora on headless machines (or remotely)
> > > > > would
> > > > > have no other way of logging in after initial installation.
> > > > > So
> > > > > why
> > > > > the change of heart now, what happened to the headless login
> > > > > issue?
> > > > 
> > > > Because one can generally set up a normal user, log in as them,
> > > > then
> > > > su or sudo.
> > > 
> > > Was this not possible back in 2015?
> > > 
> > > I guess I am asking what technically changed between then and
> > > now,
> > > so that we didn't block root back then and we are doing it now?
> > 
> > Please, read the whole fedora change page. It answers all your
> > questions.
> 
> Well, the relevant sentence from the change page says:
> 
> "Fedora was for many practical reasons keeping the old configuration
> since then, but the difference is no longer bearable"
> 
> Can you please elaborate what were the "many practical reasons" that
> prevented this from being changed for the last 5 years? And why are
> they not equally practical now?

Mostly the unwillingness of people who were used to use root accounts
in Fedora and not enough alternatives how to override or set up
alternative during installation.

The initial change was half-baked proposed 5 years ago:

https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no

but never accepted by FeSCO (note sure if it was even proposed) and
started long discussions on mailing lists as linked from there.

Since then, we did not change the value to "no", but we disabled only
the password logins, we added a simple way how to override this in
anaconda installer and there are simple ways how to override it in
kickstarts or add a public ssh keys to authorized_keys files.

> Don't get me wrong, I fully support this change, disabling ssh root
> login is the very first thing I do every time I install a new system.
> And each time I ask myself why on earth isn't this the default, but I
> sort-of remember (from various discussions on this mailing list back
> in
> 2015 or so) that people had good reasons to keep it that way.

I think it was mostly testing and scratch boxes that needed root logins
(specific use cases), making sure that there is some other account that
is allowed to login after installation (installation problems). But I
think I did not manage to read that thread this year again.

> And now
> that I see the default is going to be changed, I'm curious what were
> those reasons and what happened to them --- how come they were
> good enough for the last five years, and are not good enough now? 

5 years ago, there were no simple workarounds for the installation.
Even this year, the agreement was not really smooth and updating
installer was one of the requirements for the change to be approved:

https://pagure.io/fesco/issue/2133

This change request is in Fedora actually for more than 15 years:

https://bugzilla.redhat.com/show_bug.cgi?id=89216

Back in that time, this was not default even in upstream and many
people were using root accounts.

> What
> changed? Or else, why wasn't this done already back in 2015?

I think that over the years, the security practices shifted to better
solutions, people learned to use normal users, sudo and ssh keys, which
allowed us to do this finally. Originally the change would be a
surprise for users, but recently, people were surprised by the root
login allowed in Fedora, which also started to be dangerous.

Regards,
Jakub

> Best, :-)
> Marko
> 
> 
> 
> 
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

RE: /dev/null is full ???

[J.Witvliet]

Like wise...

There seems to be missing a /dev/one.
Could it be obtained by exoring /dev/zero?


Met vriendelijke groet,
Hans Witvliet, J, Ing., DMO/OPS/I&S/APH, Kennis Team Opensource
Coldenhovelaan 1 Maasland 3531RC Coldehovelaan 1, kamer B213


-Original Message-
From: Roberto Ragusa [mailto:m...@robertoragusa.it]
Sent: maandag 7 oktober 2019 14:04
To: users@lists.fedoraproject.org
Subject: Re: /dev/null is full ???

On 10/6/19 9:05 AM, ToddAndMargo via users wrote:

> /dev/null is full ???  Huh ???

Yeah, it always happens, nobody takes care of cleaning up
/dev/null, so it becomes full of stuff.
But, you know, there are people providing cloud-based
dev-null-as-a-service at affordable prices.
For example you can send them 100GB per month for just $25.
https://devnull-as-a-service.com/pricing/

(I hope everybody in this mailing list is able to detect
the above is said as a joke...)

Anyway, of course mistyping /dev/null can fill the disk containing
the "dev" directory, but if you really want to see sudden random
failures in any software, you should try replacing
/dev/null with a normal file. This happened to me
once because of a stupid installer of a very well known
commercial product. Then, if the permissions are not open to "others",
somebody using /dev/null will fail at reading or writing. And if
the permissions are instead open, the process reading
from /dev/null will actually read something that another process
was intending to discard. Spectacular confusion.

Regards.

--
Roberto Ragusamail at robertoragusa.it
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: SSH after upgrade

[Marko Vojinovic]

On Mon, 07 Oct 2019 10:38:32 +0200
Jakub Jelen  wrote:

> On Mon, 2019-10-07 at 02:53 +0200, Marko Vojinovic wrote:
> > On Mon, 7 Oct 2019 10:21:03 +1100
> > Cameron Simpson  wrote:
> > > On 07Oct2019 01:00, Marko Vojinovic  wrote:
> > > > On Sun, 06 Oct 2019 18:05:02 +0200
> > > > alcir...@gmail.com wrote:
> > > > > It could it be related to this change:
> > > > > https://fedoraproject.org/wiki/Releases/31/ChangeSet#Disable_Root_Password_Login_in_SSH
> > > > 
> > > > As a side question --- I remember that this was the default for
> > > > upstream OpenSSH since 2015, but was not adopted in Fedora
> > > > because
> > > > people who install Fedora on headless machines (or remotely)
> > > > would
> > > > have no other way of logging in after initial installation. So
> > > > why
> > > > the change of heart now, what happened to the headless login
> > > > issue?
> > > 
> > > Because one can generally set up a normal user, log in as them,
> > > then
> > > su or sudo.
> > 
> > Was this not possible back in 2015?
> > 
> > I guess I am asking what technically changed between then and now,
> > so that we didn't block root back then and we are doing it now?
> 
> Please, read the whole fedora change page. It answers all your
> questions.

Well, the relevant sentence from the change page says:

"Fedora was for many practical reasons keeping the old configuration
since then, but the difference is no longer bearable"

Can you please elaborate what were the "many practical reasons" that
prevented this from being changed for the last 5 years? And why are
they not equally practical now?

Don't get me wrong, I fully support this change, disabling ssh root
login is the very first thing I do every time I install a new system.
And each time I ask myself why on earth isn't this the default, but I
sort-of remember (from various discussions on this mailing list back in
2015 or so) that people had good reasons to keep it that way. And now
that I see the default is going to be changed, I'm curious what were
those reasons and what happened to them --- how come they were
good enough for the last five years, and are not good enough now? What
changed? Or else, why wasn't this done already back in 2015?

Best, :-)
Marko




___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: /dev/null is full ???

[Roberto Ragusa]

On 10/6/19 9:05 AM, ToddAndMargo via users wrote:


/dev/null is full ???  Huh ???


Yeah, it always happens, nobody takes care of cleaning up
/dev/null, so it becomes full of stuff.
But, you know, there are people providing cloud-based
dev-null-as-a-service at affordable prices.
For example you can send them 100GB per month for just $25.
https://devnull-as-a-service.com/pricing/

(I hope everybody in this mailing list is able to detect
the above is said as a joke...)

Anyway, of course mistyping /dev/null can fill the disk containing
the "dev" directory, but if you really want to see sudden random
failures in any software, you should try replacing
/dev/null with a normal file. This happened to me
once because of a stupid installer of a very well known
commercial product. Then, if the permissions are not open to "others",
somebody using /dev/null will fail at reading or writing. And if
the permissions are instead open, the process reading
from /dev/null will actually read something that another process
was intending to discard. Spectacular confusion.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: /dev/null is full ???

[Ed Greshko]

On 10/7/19 6:30 PM, George N. White III wrote:

Not "nothing"


Really?

[egreshko@meimei ~]$ sudo dd if=/dev/null of=/dev/sdg status=progress
0+0 records in
0+0 records out
0 bytes copied, 0.000189575 s, 0.0 kB/s

[egreshko@meimei ~]$ sudo mount /dev/sdg1 /mnt
[egreshko@meimei ~]$ ls /mnt
lost+found  x


--
If simple questions can be answered with a simple google query then why are 
there so many of them?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: /dev/null is full ???

[George N. White III]

On Mon, 7 Oct 2019 at 02:48, Samuel Sieb  wrote:

> On 10/6/19 8:50 PM, jdow wrote:
> > On 20191006 01:34:45, Tom H wrote:
> >> On Sun, Oct 6, 2019 at 9:05 AM ToddAndMargo via users
> >>  wrote:
> >>>
> >>> Fedora 30 x64
> >>>
> >>> # dd bs=4096 if=/dev/sdb of=/dev/dull status=progress
> >>> 8301694976 bytes (8.3 GB, 7.7 GiB) copied, 38 s, 218 MB/s
> >>> dd: error writing '/dev/dull': No space left on device
> >>> 2034754+0 records in
> >>> 2034753+0 records out
> >>> 8334348288 bytes (8.3 GB, 7.8 GiB) copied, 38.4257 s, 217 MB/s
> >>>
> >>> /dev/null is full ???  Huh ???
> >>
> >> 1) "/dev/null" not "/dev/dull"
> >>
> >> 2) "if=/dev/null of=/dev/sdb" not "if=/dev/sdb of=/dev/null"
> >
> > Don't you hate it when you do that (item 2), Tom?
>
> He did have them in the right order.
> "if=/dev/null of=/dev/sdb" would do nothing at all.
>

Not "nothing", Flash memory cells have a limited number of writes.
Devices based on flash memory use several strategies,
including wear leveling and spare capacity so failed regions
can be replaced with fresh cells.Flash devices that get a lot
of writes will last longer if they are kept well below the maximum
capacity, and should have a command to "delete" all the data
that doesn't actually overwrite the existing data.Using
 "count=N if=/dev/null of=/dev/sdb" to zero out the partion table and
boot "sector" is easy and shouldn't cause a lot of wear since those
areas shouldn't change often.

High-end flash memory sticks should have self-monitoring and
testing (SMART) capabilities.   See:
https://superuser.com/questions/1064119/usb-flash-drives-or-sd-cards-with-s-m-a-r-t


Many vendors provide utilities (often on a freeDOS CD) to manage their USB
sticks.

-- 
George N. White III
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: SSH after upgrade

[Jakub Jelen]

On Mon, 2019-10-07 at 02:53 +0200, Marko Vojinovic wrote:
> On Mon, 7 Oct 2019 10:21:03 +1100
> Cameron Simpson  wrote:
> 
> > On 07Oct2019 01:00, Marko Vojinovic  wrote:
> > > On Sun, 06 Oct 2019 18:05:02 +0200
> > > alcir...@gmail.com wrote:
> > > > It could it be related to this change:
> > > > https://fedoraproject.org/wiki/Releases/31/ChangeSet#Disable_Root_Password_Login_in_SSH
> > > 
> > > As a side question --- I remember that this was the default for
> > > upstream OpenSSH since 2015, but was not adopted in Fedora
> > > because
> > > people who install Fedora on headless machines (or remotely)
> > > would
> > > have no other way of logging in after initial installation. So
> > > why
> > > the change of heart now, what happened to the headless login
> > > issue?
> > 
> > Because one can generally set up a normal user, log in as them,
> > then
> > su or sudo.
> 
> Was this not possible back in 2015?
> 
> I guess I am asking what technically changed between then and now, so
> that we didn't block root back then and we are doing it now?

Please, read the whole fedora change page. It answers all your
questions.

You can always install public keys for root during kickstart (it might
not have been that easy before) or allow password root logins from
Anaconda (which is new feature in F31).

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: strange behavior: it slows down and then recovers

[Andras Simon]

2019-10-07 3:08 GMT+02:00, Eddie G. O'Connor Jr. :
> Been noticing the same thing on my F30 system as wellI don't think
> its FedoraI think its Mozilla's Firefox, this behavior also has hit
> my OpenSuSE and my CEntOS laptopssomething is eating up the RAM on
> them when Firefox is running...and it seems to go back to being snappy
> and fast once I close and then reopen FF, but after a few
> minutes?.it slows down again.

It's not necessarily a problem with FF: it may be due to an addon, or
a website that is doing some heavy computations locally.  If you have
lots of tabs open, you have lots of potential culprits.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: [SOLVED] SSH after upgrade

[Earl A Ramirez]

>
> Please, do not advise this as a general solution. The correct solution
> is to setup public key authentication or use different user
>
Isn't cockpit installed by default on servers since that is the future
directive?

>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: [SOLVED] SSH after upgrade

[Jakub Jelen]

On Sun, 2019-10-06 at 11:15 -0500, Mike Chambers wrote:
> On Sun, 2019-10-06 at 18:05 +0200, alcir...@gmail.com wrote:
> > On Sun, 2019-10-06 at 10:46 -0500, Mike Chambers wrote:
> > > Upgraded server from Fedora 30 to 31 (updated to present), and
> > > ssh
> > > into
> > > that server works fine as normal user, but no longer lets me
> > > login
> > > as
> > > root.  I can login as root from the server machine itself, and
> > > can
> > > login via su - but just cant' from ssh.
> > > 
> > > Any ideas what changed or got replaced so revert it back?
> > 
> > It could it be related to this change: 
> > https://fedoraproject.org/wiki/Releases/31/ChangeSet#Disable_Root_Password_Login_in_SSH
> 
> Had to add the below line to my sshd.conf file and works now.
> 
> PermitRootLogin yes
> 
> Guess it changed or got removed when I did the upgrade (upgraded via
> dnf, not a clean install), but added that line and it works now.

No, this IS intentional change of Fedora 31 to disable password root
logins. This account is very frequent target of brute-force attacks
(and this change was made by upstream OpenSSH years ago).

Please, do not advise this as a general solution. The correct solution
is to setup public key authentication or use different user and sudo
for the administrative tasks.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org