Where i can find old kernels from fc19 updates?
Last 5-6 kernels are totally unstable and unusable.
For example, when i boot machines with many ethernet devices I got random
number ethX. Once eth0 is eth0, after reboot eth0 is eth1. After again boot
eth1 is eth1 and so on. After 1-2 hours machines totally hangs.
After many years of use Fedora (from fc1 and redhat 4.2) i have to switch
بسم الله الرّحمن الرّحيم
The result of updating Fedora by yum is fail !!
When any package have "proxy" word marked to (install or update) , error message will appear with http 403 error forbidden.
In my country Syria (maybe others) all URLs have "proxy" word are forbidden and couldn't open by default way.
In Fedora there are two common packages and have many updates:
libproxy - sssd-proxy .
Can to rename to :
libproxies - sssd-proxies
Or something else.
Then do new rule to write "proxies" instead of proxy, at Fedora packaging guidlines.
Senior of Linux Arab Community http://linuxac.org
Member of Ojuba Project http://ojuba.org
Member of Arab Eyes project http://arabeyes.org
Maintainer of Almasa project
Maintainer of Arabic Translations in : Wine - VLC - KDE .... etc
Also member of Fedora Arabic translations team
The bottom line question is, would it be useful to have an fsck_gpt run by systemd at either startup or shutdown time? This wasn't needed for MBR, so it seems kinda silly to suggest it, but there are some cases of one or the other GPT being stepped on in a way that probably never happened to MBR for the obvious reason that if it did, the computer would be busted.
A recent bug came up in QA that made me go down a bit of a rabbit hole, corrupting one or the other GPT to see how different things behave, starting with the various partition tools. This is a summary:
parted does the right thing, identifies which GPT is corrupt and says it's using the other one, and fixes the problem on the next write to disk.
gdisk does the right thing also.
fdisk sees a disk with corrupt primary GPT as being an MBR disk, RHBZ 1022217, fix now available although I haven't tested it yet.
anaconda sees such a disk as totally blank, RHBZ 1020974 is in progress.
grub2 only uses the primary GPT table, it doesn't check to see if it's valid, RHBZ 1022743. So a bit flip probably won't cause a computer to not boot. It'd have to be something that alters just the start LBA of /boot or / (or both), or stomps on the whole table data. In either case the result is an unbootable system. It's an open question if a bootloader should be able to determine the validity of the primary GPT since that means it needs CRC32 code. And then whether it should know to use the backup GPT. I've raised this on grub-devel@.
And just now, I found the kernel nose dives if the primary GPT table is altered by even one byte. kernel.org bug 63591.
Anyway, as rare as this is, it might be nice if the system can self-heal from such problems, because it's pretty much guaranteed the user will never know about it until the other GPT is toast. And the UEFI spec amusingly requires the user be asked for confirmation before restoring a primary GPT, which is probably not in either the kernel nor systemd's job description.
So that's why I ask if it makes sense to have an fsck for GPT disks.
Hi Fedora folks,
Hopefully some of you know me, possibly as a previous Fedora Project
Leader at Red Hat. If you don't, then salutations, and please feel
free to check out my Fedora wiki page for my background. :-)
As of next Monday, I'll be the reporting manager for Fedora
Engineering team members -- those folks who work on Fedora full time
in the Engineering department of Red Hat, other than the Fedora
Project Leader, Robyn Bergeron. This doesn't really affect anything
in the community, but I want to ensure that change is transparent to
These folks previously reported to Tom 'spot' Callaway, who remains at
Red Hat, and has kindly given me his good wishes in the new job. Of
course, we fully expect to continue working together around the Fedora
community. I'm lucky to be coming on board with an awesome team full
of great people, and I'm excited about working with all of them!
Of course there will be some transition time while I manage the
backfill for my other work at Red Hat, but you'll start seeing more of
me around here in the near future.
Sorry for the interruption -- now back to the normal Fedora stuff.
= = =
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
It's taking a bit of time, but I plan to start packaging a couple of
packages that are not currently available for either Red Hat nor Fedora.
The main reason for it taking a bit longer really has to do with
personal infrastructure and setting up my build host, etc.
However, that doesn't really pertain to the question at hand. I come
from a Debian centric environment, and have "come back" to Red Hat and
Fedora after more than a decade. As such, I have quite a bit more
experience building my packages with fakeroot, than I do with mock, and
I'm wondering what the differences between the two packages/processes are.
Will using mock in this environment be more beneficial to using
fakeroot? Will it be "harder" for lack of a better word, to build from
within the build system using fakeroot , once I get to that point or, is
Koji flexible enough so that it really wouldn't matter from an
infrastructure point of view as to whether or not I use one or the other?
As I am more familiar with fakeroot, I'd like to keep using that, but
at the same time, I'd like to do it the "Red Hat way" to ensure that the
package conforms to both Red Hat and Fedora packaging standards.
Thanks in advance for your guidance.