have very recently upgraded from F19 to F21 and notice scary log entires
Watch your logs!
The hardware (in combination with F19) was rock solid all the time and
is fairly boring. I am still running 32 bit x86. No sign of any problems
when not hibernating. I have completely encrypted root/home/swap.
Is this a kernel problem or is there any chance that during boot
the filesystem was written before the resume was intiated?
Also - rather disturbing - despite potentially serious errors in the filesystem
- filesystem check is not forced after reboot
- tune2fs -C 1 dev is apparently ignored on all devices
Can not give all messages here - come of the more serious apparently have been
lost possibly due to fs corruption.
Those that were lost were of the kind
".... There's a risk of filesystem corruption in case of system crash."
Those that were preserved are of the kind
Jan 11 18:10:09 rz kernel: [ 4486.613583] EXT4-fs error (device dm-5): ext4_mb_generate_buddy:757: group 258, block bitmap and bg descriptor inconsistent: 4880 vs 4724 free clusters
Jan 11 18:10:09 rz kernel: [ 4486.648386] EXT4-fs error (device dm-5): ext4_free_inode:340: comm tcptrack: bit already cleared for inode 2127171
Jan 11 18:10:09 rz kernel: EXT4-fs error (device dm-5): ext4_mb_generate_buddy:757: group 258, block bitmap and bg descriptor inconsistent: 4880 vs 4724 free clusters
Jan 11 18:10:12 rz kernel: EXT4-fs error (device dm-5): ext4_free_inode:340: comm tcptrack: bit already cleared for inode 2127171
Jan 11 18:10:20 rz kernel: [ 4497.917092] EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm xkbcomp: failed to insert inode 656088: doubly allocated?
Jan 11 18:10:20 rz kernel: EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm xkbcomp: failed to insert inode 656088: doubly allocated?
Jan 11 18:10:25 rz kernel: [ 4502.692300] EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm xkbcomp: failed to insert inode 656095: doubly allocated?
Jan 11 18:10:25 rz kernel: EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm xkbcomp: failed to insert inode 656095: doubly allocated?
Jan 11 18:10:31 rz kernel: [ 4508.156434] EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm baloo_file: failed to insert inode 656626: doubly allocated?
Jan 11 18:10:31 rz kernel: EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm baloo_file: failed to insert inode 656626: doubly allocated?
Jan 11 18:11:41 rz kernel: [ 4579.069411] EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm baloo_file: failed to insert inode 656820: doubly allocated?
Jan 11 18:11:41 rz kernel: EXT4-fs error (device dm-5): __ext4_new_inode:1010: comm baloo_file: failed to insert inode 656820: doubly allocated?
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 01)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
Name and OpenPGP keys available from pgp key servers
Hi, I know how to manually configure the zram, but what's the best way
to do it?
I've seen the unit zram.service of anaconda-core, and it gets activated
when booting with inst.zram=on, but it looks like very anaconda-centric.
Should something like  be packaged and included in the distro? or
maybe we should spin off the anaconda zram.service and do it more
I think this is a very interesting feature for memory constrained VMs
and other devices.
Reposted from <http://fedoramagazine.org/5tftw-2014-12-17/>.
Fedora is a big project, and it’s hard to keep up with everything that
goes on. This series highlights interesting happenings in five
different areas every week. It isn’t comprehensive news coverage — just
quick summaries with links to each. Here are the five things for
December 17th, 2014:
Fedora 21 Retrospective: What was awesome? What wasn’t?
While Fedora 22 is already rolling into the target zone, we do want to
make sure we look back at this previous cycle and identify things we
can improve — ideally, specific and actionable changes. In the end, we
came out with (another!) great release, but there is always something
to learn. In particular, we ended _yet again_ in a last minute scramble
to get a release we could feel good about signing off on out before the
holidays, and next time around it would be nice to put less stress on
all of our contributors (including the quality assurance team and the
developers needed to make those late fixes.)
There will be more to it than this, but to get started, we have a F21
Retrospective wiki page, to help collect comments and ideas.
Fedora 22: Coming up fast!
FESCo (the Fedora Engineering Steering Committee, the elected
organization which oversees technical decisions in the project) has
indicated that we’re back to aiming for the traditional May/October
Fedora release cycle, and although the F22 schedule isn’t finalized yet,
we have a tentative plan calling for a release about 6 months from
now. When you work back from that, it means that there’s really not much
time to think about change proposals for F22, especially if we
subtract out holiday time. So, if you’re thinking of working on
something big, please start getting your proposal formalized — the
tentative deadline is January 20th, 2015.
Fedora 19: End of Life
And on the other end of the cycle: it’s time to say farewell to Fedora
19. If you’re running this release, please plan to update before January
6th, 2015, when the last updates will go out. After that, there will be
no further security fixes. The good news is that Fedora 20 was a great
release, and Fedora 21 is *even better*, and I think you’ll be happy
with the upgrade.
Fedora Workstation firewall discussion
This week’s big devel-list thread concerned the default firewall
settings in Fedora Workstation. The Fedora Workstation Working Group was
not happy with the user experience offered by blocking incoming “high
ports” by default. Out of the box, nothing is listening on these, but if
one installs software that expects to, it won’t work, and because we
don’t have a good way yet to tie *attempts* to access ports to listening
applications and communicate that to the user, the resulting failure is
On the other hand, if you install something and it starts listening and
you didn’t know that, that’s *also* invisible. So, pretty much everyone
recognizes this as a not ideal situation. Everyone involved in the
discussion also is concerned with enhancing user security in practice —
the question is just how to best get there from an imperfect state.
Originally, the Workstation WG asked to disable the firewall entirely.
FESCo asked instead that it be left available, possibly with a
less-restrictive out-of-the-box configuration — the path taken for F21.
If you’re not running Workstation, this doesn’t affect you. If you are,
and would like a different configuration, run the firewall configuration
tool and either edit the Fedora Workstation zone or change the default
zone. (There’s a long list of options, but “public” is a
You can also change the per-network zone. Unfortunately currently wired
networks are all considered as one per interface, but wireless networks
are distinguished individually. This can be done in a number of ways,
but the easiest is to run the network configuration tool (in GNOME
control center — press the overview key and start typing “network”),
select the wifi network in question, press the little gear icon next to
it, go down to Identity (?!), and choose the appropriate firewall zone.
(Again, there’s a long list — go back to the firewall config tool to see
exactly what they all do.)
This is clearly, not the most friendly approach; it’s my understanding
that the desktop designers, network tools team, and security team are
going to work together to develop a better overall solution for Fedora
22 and beyond.
Overall, the mailing list thread stayed relatively positive and
constructive and avoided personal attacks, although there were some
accusations of bad faith actions which do not seem warranted based on
the actual history. It is, however, a case where more transparent
discussion and communication could have helped; that’s something we’re
continually working at making better and might make for a good component
of the F21 retrospective mentioned above.
Of course things in Fedora never really stop, but it’s vacation time for
many of us. Before I was a Red Hat employee, I was used to seeing
extended days off as ideal for getting in some serious work on Fedora.
Now, things are strangely inverted, and I’m going to use the time to
unplug a bit. I’ll be back in January all recharged, and will catch up
with everything that’s happened in the meantime — FtFTW will resume the
week of January 15th — or possibly the week before, but let’s save the
hard-to-keep resolutions for New Year’s Day. :)
Check out the Fedora vacation calendar to see who else will be away,
and make sure to add yourself if you will be too. (There's even a
Fedora badge for doing so!)
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Fedora Project Leader mattdm(a)fedoraproject.org <http://fedoraproject.org/>
On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
> Does this proposal apply to native non-C/C++ programs?
I would like to see this proposal apply to native non-C/C++ programs,
but I am not sure on how that would be done?
Do the other compilers understand what needs to be done when they are
passed '-fPIC -pie' flags?
I am Zamir SUN from China. I have been promoting Open Source for some
time and been an ambassador last year. Now I want to help some more bit
Recently I find some bugs that can be fixed by fixing the spec. So I'd
like to help with the packager in my spare time.
Although I did not have much experience in packaging, I will learn by
zsun in #fedora-zh #openshift on freenode.net
> Sshd(8) daemon by default allows remote users to login as root.
> 1. Is that really necessary?
> 2. Lot of users use their systems as root, without even creating a
> Such practices need to be discouraged, not allowing remote root
login could be
> useful in that.
> Does it make sense to disable remote root login by default? If so, do
> we need to just report it to the maintainer or it would be treated as
> a feature?
This is generally a very bad idea, because this is NOT SECURE AT ALL.
1) If the problem is brute force attack (BF) against root account, this
solution will not prevent BF at all, because BF could be used against
other accounts too (it may not so easy, but BF means to try all possible
solutions to find the correct one so no change to BF here)
2) You have to fight BF attack in general, which means to use some kind
of wrapper to block unsuccesfull logins, but this will raise the
security problem, because this wrapper could be vulnerable, ie. may
contain some bug which could be security disaster.
3) Previous solution with wrapper could be solved by some kind of script
and touching iptables/tcp_wrapper and this will not be security problem,
so this is better than 2)
4) Blocking root access means forcing admins to log as normal user and
then do su/sudo and providing root password, which is far less secure
than disable root password authentication and allow login to root with
SSH key only, because password could be easily stolen (private key is
never send to the net so is more safe).
5) When a user provides login/password through ssh, the ssh know whats
going on, so there is a padding (with nothing) included in the initial
network communication to prevent spoofing on how the password "sounds
like" (ie sniffing on password typing), but when the user is logged-in,
the ssh has no clue what is going on so no padding could be inserted to
the network communication and this is why there is possibility to attack
(spoof) on password the user provides when doing su/sudo after
succesfull login. See SSH protocol explanation and a lot of very good
articles about this.
6) Because all I wrote above, disabling root login is "Security through
obscurity" and THIS NOT IMPROVE SECURITY! See
https://cs.wikipedia.org/wiki/Security_through_obscurity and 5) above
There are possible solutions for this problem:
A) do not allow any SSH connection (the user should enable SSH on its own)
B) provide good blocking script as of 3) above by default [there are
many out there]
C) do not allow user to set weak root password at all
As Fedora is focused as desktop, I wonder why SSH is enabled by default.
RHEL/CentOS/SLES/whatever is focused as server and this sounds me
reasonable to allow SSH by default.
Yes, Debian/Ubuntu etc. disable root login by default but as I wrote,
this is not security feature, it only provides false security feeling
and by nature it lower security (see above). Don't do the same please
only because others do too. Don't think about to make the computer more
secure and allow administrator to be stupid on the same time!
Hi folks! So I don't think we have anything particular to discuss at a
meeting tomorrow, thus according to the policy of not wasting people's
time with unnecessary meetings, I propose we cancel it. If anyone did
have something to discuss, please do reply to this mail!
We could possibly move blocker review up by one hour to help out
European folks, but it may be a bit late for that.
test-announce mailing list