Hello Bruno, hello Guillermo!
Are you still alive and well? What's up with dhcp_probe in Fedora?
Apparently, it has been unmaintained since its approval:
* Review Request: dhcp_probe - Tool for discover DHCP and BootP servers
CLOSED ERRATA (2010-10-19)
* dhcp_probe dependency requires NetworkManager to run
* dhcp_probe fails to get ip address for interface on 64-bit platform
It shouldn't become a daily routine to have to actively search for
package maintainers to find out why they are unresponsive. :-(
Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64
loadavg: 0.41 0.57 0.56
You know what was the painless part of this re-install? After firing up google
chrome, I didn't need to reinstall anything for it. It's all synced with gmail.
I find myself wishing that all my fedora packages could be restored just like
Oh sure, there's a few methods for automaticing installs. But none are so
brain-dead easy. Imagine, just 1 click (or command) to sync all the packages
(and maybe /etc?) to some server, and 1 step to reinstall back to the last
What's that? Wouldn't work over upgrades? Somehow it does for chrome. And for
-----BEGIN PGP SIGNED MESSAGE-----
We have added file trans by name rules to policy to fix a lot of
files/directories being created with the correct label.
We have problems on Distribution updates (F16-F17) though, where there is a
files/directories in the homedir that are mislabeled.
We have "restorecond -u" which we run in F15/F16 which examines the homedir
and fixes any files directories it finds mislabeled in ~. If it finds a dir
which is mislabeled, it will relabel the directory and all of its children.
We have turned this tool off by default on the desktop in F17, because
filename transition rules are doing a pretty good job of maintaining the
labels in the homedir. But this tool never did a great job of fixing
mislabeled subdirs, if the top level directory in the homedir was labeled
You can enable this tool with /etc/xdg/autostart/restorecond.desktop
One possible fix to this would be to force a system relabel on everything on
upgrades, while this would fix the labels, it is considered to time consuming.
(restorecon -R -v / or touch /.autorelabel)
Another option would be to just relabel /home (# restorecon -R -v /home) at
upgrade time. But this would also be time consuming. And would not catch the
cases where the homedir is not in /home.
A third option would be to run "restorecon -R -v $HOME" in background in an
profile script the first time you login on a new OS Version. This would seem
to be the least time consuming, but could be subject to race conditions, you
hit the mislabeled file before the restorecon fixes it. This would be better
then what we have now, in that everyone can hit the mislabeled file directory.
Final option would be to do nothing, which is what we are doing in F17, until
we get a bug reported and tell the user to run "restorecon -R -v /home"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
On Fri, 2012-06-01 at 14:57 -0400, Steve Clark wrote:
> On 06/01/2012 12:02 PM, Cosimo Cecchi wrote:
> > The point I'm trying to make is the default setting might actually be
> > the most important thing that matters when it comes to new users that
> > want to install Fedora.
> > - "You need to disable SecureBoot in the BIOS settings in order to
> > install Fedora"
> > - "BIOS settings? What's that? Oh a blueish DOS-like command-line thing?
> > Freaky. Disable SecureBoot? Why on earth would I want to make my system
> > less secure? *screw this Linux thing*"
> > Cosimo
> How many people that aren't somewhat technical are even going to think
> about installing another OS?
> No many I would guess.
I don't think we can have a definite answer to this question.
I'm pretty confident the intersection of people afraid of touching their
BIOS settings and those who want to use another OS is not empty though.
Normally top reports CPU line, sy at 0.4% when idle. If I format an external Firewire disk as btrfs and mount it, it remains at 0.4%. If I reformat as XFS and mount it, again top reports sy at 0.4%. However, if I reformat as ext4 and mount it, sy runs at 3.5%. These two processes are now at the top of top's results:
Each uses on average 1.9% CPU. The light on the external drive flashes 4x per second. There are no processes using the disk at all while this is going on. If I umount it, the pulsing stops. If I remount it, the pulsing resumes as does the slightly higher CPU consumption.
This doesn't happen with the same hardware mounted XFS or btrfs or HFS+.
These reveal nothing related to the disk:
lsof | grep sdb
lsof | mapper
If I sift through it unfiltered with the volume mounted and not, I don't really see anything obvious standing out.
I've upgraded a few machines to Fedora 17.
One of them does not boot anymore. No device ever becomes plugged, thus
systemd eventually times out waiting for the disk device
(dev-sda1.device) and drops into the emergency shell.
The device is there and accessible;
udevadm trigger --type=devices --action==add does generate add events
(as seen by udevmonitor)
Strangely, though, none of the devices have a sysfs path; also, I only
have the two disk devices mentioned in fstab, while on working machines
I have many more.
Can somebody give me a hint on what goes wrong, or on how to debug this
About a week ago I did a scratch build of one of my packages that includes <sys/sysctl.h> and it built successfully.
Today I did another scratch build and it broke with:
Making all in src
In file included from fuse-helpers.c:24:0:
/usr/include/sys/sysctl.h:63:25: fatal error: bits/sysctl.h: No such file or directory
Is this a known problem? Some new package I need to add as a BuildRequires?
I'm trying to find out the changes in the kernel relating the 3.2 to 3.3 changes in relation to the vfsmount structure change as we use an application that uses the mnt_parent element that no longer exists in the source. I looked at the Documentation directory for the kernel in Fedora 16 but it has references to mnt_parent still (linux-3.3.7/Documentation/filesystems). I saw a bug reference that has this being moved to the mount structure however I don't get any results with grep on the entire source tree for mnt_parent.
Can anyone point me to a document that has the structure change so that I can modify this source accordingly?
I have been reading about secure boot. I understand that we are going to
pay Microsoft to get our keys signed. Will this change affect people
creating remixes? What about kernel modules from third party repositories
like rpmfusion? Will it be affected?
Arun S A G