I'm running FC4, and last night I was reading about NetworkManager,
and I realized I never tried it. So I do:
# /etc/init.d/NetworkManager start
It started alright, but everything (network) stopped working!
BTW, this is happening on a desktop with only a wired eth0.
I say 'F@#% it!' and I stop it quickly, but the network is still
down. I bounce eth0 once:
# ifdown eth0
# ifup eth0
Still no go. After a while I figure out that pings are working, but DNS
is foo-bared. Sure enough, NetworkManager completely erased my
/etc/resolv.conf! Needless to say, my resolv.conf was 100% hand-edited
with search and nameserver entries that NetworkManager can not possibly
guess. Why did it feel the need to mess with it?
Now, apart from the very frustrating experience, is this intended
behavior? If so, does it really have to be this way?
Dimi Paun <dimi(a)lattica.com>
in our office setup, the only available printer is
shared by a server running cups.
Is seems that clients still need to run cupsd just
to print through this printer. cupsd takes a few
seconds to start and is generally a resource hog.
Is it possible to access the remote printer without
using a local cupsd? If not, how could I turn off
unneeded cups components such as the web server at
port 632 and local printer discovery?
// Bernardo Innocenti - Develer S.r.l., R&D dept.
Beginning tomorrow, the following changes will be in rawhide:
- pcmcia-cs will be replaced with the new pcmciautils
- udev will be upgraded to 062
What does this mean for you, the user?
- PCMCIA support should be better. Notably, 16-bit PCMCIA support will be
going through the same hotplug, etc. mechanisms as Cardbus, PCI, and other
- Certain operations should be faster. The new udev internalizes some of
the mechanisms that were farmed out to scripts before (such as
loading of modules for PCI, PCMCIA/Cardbus, and USB), so things should
What does this mean for you, the developer?
- The use of /etc/hotplug.d and /etc/dev.d for the running of programs on
hotplug and udev events is officially deprecated.
All programs that have been run in this way need to be converted to
RUN targets in udev rule files; these can be dropped in /etc/udev/rules.d.
Old dev.d and hotplug.d events will still be run in a compatibility mode
for now... I'm not yet sure how long we will continue to do so.
What sort of problems could arise, and where should they be filed?
- All matching of of PCMCIA devices to drivers is done via standard module
aliases. /etc/pcmcia/config is no longer used.
If your driver isn't loaded properly, bugs should be filed against 'kernel';
ids will need to be added to the drivers.
- Not everything may be converted to new udev rules yet. For things that aren't,
please file bugs against the relevant packages.
And, of course, there could be something that's just plain broken. :)
This isn't going to be the last device handling change; these changes
allow further tweaks to udev, hotplug, and related packages. Hopefully
nothing will break too badly along the way.
I ran into som troubles with stateless-linux today.
I have a protosystem, and I chroot:ed into it, mounted /proc and
did a 'yum -y update'. That ran fine and installed a new kernel
among other things. But upon running stateless-snapshooter I ran
into some troubles:
# stateless-snapshooter -n -p minimal
Traceback (most recent call last):
File "/usr/share/stateless/snapshooter.py", line 177, in transfer_finished
File "/usr/share/stateless/snapshooter.py", line 263, in prepare_destination
File "/usr/share/stateless/snapshooter.py", line 251, in copy_pxeboot_files
copy_from_snapshot ("diskless-initrd-%s.img" % latest_kernel, 'initrd.img')
File "/usr/share/stateless/snapshooter.py", line 246, in copy_from_snapshot
shutil.copy (src_path, dest_path)
File "/usr/lib/python2.3/shutil.py", line 71, in copy
File "/usr/lib/python2.3/shutil.py", line 37, in copyfile
fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: '/srv/stateless/snapshots/minimal/minimal-2/boot/diskless-initrd-2.6.11-1.35_FC3.img'
Which script creates the diskless-initrd? And why doesn't it generate
a new one for the new kernel? I have an old one but I wanna use
the new one.
And does it generate one for the SMP kernel as well cause I wanna use that
kernel for my P4?
begin 644 carljohan_at_kjellander_dot_com.gif
I have been working on porting my wallpaper tray program to the gnome panel
(from the notification area), and I have hit a snag with Fedora.
I have to configure my program as follows:
The default is /usr/local, and this results in my panel applet not being
available from the menu. Now, I am trying to add a gconf schema (I think not
having one was causing bugs), and the schema is ending up getting installed
to /usr/etc which is clearly wrong.
Apparently I don't have to configure like this on other distros, so what can
I do to get around the problem?
* http://www.mozilla.org/products/firefox/ *
just got this kernel panic right after updating Fedora core 3 to
2.6.11-1.35_FC3. I am running Fedora Core 3 for x86 on an AMD64 machine
- if this helps?. Since i have no serial console i could not copy and
paste the panic message, so i have made a photo which you can see at:
The following package is what i am talking about:
Please tell me how i could debug such things better in the future. I
really want to understand the way developers are handling this.
I hope this helps.