Installing amd64 mini.iso on dell 2840
Hi i try to instal the mini.iso from here (ftp://ftp2.de.debian.org/debian-amd64/debian-installer/2006-01-29/netboot) on my dell 2850. The Server boots with the CD an i am able to configure the disks (hw raid 10). When it comes to the installing of the base system it starts downloading all needed packages but than it crashes because some packes are not found. I tryed with stable, testing and unstable (everytime form the scratch) but allways some packages are not found. Can someone tell me how to fix this problem? Thanks Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unable to eject cdrom???
Hi, Intermittently I am unable to eject my dvd/cdrom. Is there a way to determine whether Linux is refusing to eject the dvd/cdrom or if it is a hardware related problem? -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: [EMAIL PROTECTED] web: www.askesis.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unable to eject cdrom???
On Tue, 07 Feb 2006 14:15:36 +0100 Joost Kraaijeveld [EMAIL PROTECTED] wrote: Intermittently I am unable to eject my dvd/cdrom. Is there a way to determine whether Linux is refusing to eject the dvd/cdrom or if it is a hardware related problem? I would check to see if there are any files open on the drive. In particular, Konqueror was bad for leaving files open, preventing you from un-mounting or ejecting CDs/DVDs. If your CD is mounted on /media/cdrom then try lsof | grep /media/cdrom Regards, Ozz. pgpBuwam54cPM.pgp Description: PGP signature
Re: Unable to eject cdrom???
Intermittently I am unable to eject my dvd/cdrom. Is there a way to determine whether Linux is refusing to eject the dvd/cdrom or if it is a hardware related problem? If cd/dvd is mounted you cannot eject it. First you must unmount it. If it's not mounted you can eject it directly.
Re: Unable to eject cdrom???
On Tue, 2006-02-07 at 14:15 +0100, Joost Kraaijeveld wrote: Hi, Intermittently I am unable to eject my dvd/cdrom. Is there a way to determine whether Linux is refusing to eject the dvd/cdrom or if it is a hardware related problem? In addition: if I run eject -v it reports that the command was success full. Mounting the disc again and umount it immediately again seems to solve the problem? -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: [EMAIL PROTECTED] web: www.askesis.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Unable to eject cdrom???
Usually it means that something is still accessing the mount point, you could try Bash#lsof | grep /cdrom/mountpoint To see what is still accessing the cd/dvd Thank you, Mark Adrian Coetser [EMAIL PROTECTED] http://www.tux-edo.co.za, http://www.thummb.com cel: +27 76 527 8789 tel: +27 11 805 2076 fax: +27 11 805 2330 -Original Message- From: Joost Kraaijeveld [mailto:[EMAIL PROTECTED] Sent: 07 February 2006 03:16 PM To: Debian-Amd64 Subject: Unable to eject cdrom??? Hi, Intermittently I am unable to eject my dvd/cdrom. Is there a way to determine whether Linux is refusing to eject the dvd/cdrom or if it is a hardware related problem? -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: [EMAIL PROTECTED] web: www.askesis.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tyan K8WE, kernel, PCI Firewire
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I got a dual-opteron K8WE board here. In this board there are 3 PCI 64bit FW800 cards with chips linux should recognize. But a lspci doesn't show anything. I assume while building a 2.6.15 I missed something for hte 64bit PCI bus. Anyone know, ehich option I should check for 64bit PCI bus for this board? MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: [EMAIL PROTECTED] Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD6KX1mWhuE0qbFyMRApcnAJ0Vr1yTa/O+YXH2M9C5ng0ADWyJogCeN3uh vB67rW4r5C8yOR7d7oZ8DPw= =fooi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
initrd race conditions
I'm running the backports.org 2.6.15 kernel on an otherwise sarge amd64 box with a couple of Opteron 275s. It seems that modules are being loaded by the initrd at startup in parallel. This seems to lead to serious race conditions with the following symptoms: 1. Failure to boot at all and being dumped at a shell prompt inside the ramdisk if the onboard SATA driver is loaded prior to the megaraid driver. This is despite the fact that nothing is connected to SATA. I've worked around this one by disabling the onboard SATA. 2. Almost random ordering of ethernet devices between boots. The machine has a single e100 and two tg3 ports. Although I can believe that the two tg3s always appear in the same order I've had the e100 detected either first, last or inbetween the two tg3s! Statically configuring IP addresses is very hard if you don't know which will be eth0 next time. I've not fathomed a workaround for this one. This makes bug #342498 entered against the installer even worse. Does anyone else see this problem? Is it likely to be amd64 specific? I haven't really used initrds, udev or 2.6 kernels on the dual processor x86 boxes we have so I don't know if they suffer similary. -- Mike Crowe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
Mike Crowe wrote:
1. Failure to boot at all and being dumped at a shell prompt inside
the ramdisk if the onboard SATA driver is loaded prior to the megaraid
driver. This is despite the fact that nothing is connected to
SATA. I've worked around this one by disabling the onboard SATA.
I actually had this exact problem myself for the first time this morning
with my X2 system, with an initrd built by initramfs-tools.
Using yaird may help because AIUI it will only load the modules required
to mount the root filesystem during the initramfs stage, or at least
will load those first.
2. Almost random ordering of ethernet devices between boots. The
machine has a single e100 and two tg3 ports. Although I can believe
that the two tg3s always appear in the same order I've had the e100
detected either first, last or inbetween the two tg3s! Statically
configuring IP addresses is very hard if you don't know which will be
eth0 next time. I've not fathomed a workaround for this one. This
makes bug #342498 entered against the installer even worse.
You can fix the names of network interfaces using udev-- istr that's
available in sarge, even though a kernel that supports it isn't (fun).
e.g. I have:
bash$ cat /etc/udev/rules.d/010_local.rules
# Local rules
# eth0: dl2k (gigabit adaptor)
SUBSYSTEM=net, SYSFS{address} = 00:05:5d:9a:a3:a8, NAME=eth0
# ethX: e100 (onboard)
SUBSYSTEM=net, SYSFS{address} = 00:02:a5:cf:bb:d4, NAME=ethX
This renames my onboard ethernet adaptor to ethX to keep it out of the
way because the BIOS doesn't permit disabling it (grumble).
HTH
SRH
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unable to eject cdrom???
On Tuesday 07 Feb 2006 13:15, Joost Kraaijeveld wrote:
Hi,
Intermittently I am unable to eject my dvd/cdrom. Is there a way to
determine whether Linux is refusing to eject the dvd/cdrom or if it is a
hardware related problem?
Most probably some process still has a file open on there. Use something like
# lsof |grep cdrom
to determine what process this is, then deal with it appropriately. If it's a
daemon {famd is a likely culprit} try sending SIGHUP first.
--
AJS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
Mike Crowe wrote: 1. Failure to boot at all and being dumped at a shell prompt inside the ramdisk if the onboard SATA driver is loaded prior to the megaraid driver. This is despite the fact that nothing is connected to SATA. I've worked around this one by disabling the onboard SATA. On Tue, Feb 07, 2006 at 02:26:54PM +, Steven Haslam wrote: I actually had this exact problem myself for the first time this morning with my X2 system, with an initrd built by initramfs-tools. Using yaird may help because AIUI it will only load the modules required to mount the root filesystem during the initramfs stage, or at least will load those first. Assuming I can persuade the stock 2.6.15 kernel to use yaird rather than initramfs then I'll give that a go. If I have to compile the kernel myself I might as well just compile in the drivers I need which will also solve the problem for me. 2. Almost random ordering of ethernet devices between boots. The machine has a single e100 and two tg3 ports. Although I can believe that the two tg3s always appear in the same order I've had the e100 detected either first, last or inbetween the two tg3s! Statically configuring IP addresses is very hard if you don't know which will be eth0 next time. I've not fathomed a workaround for this one. This makes bug #342498 entered against the installer even worse. You can fix the names of network interfaces using udev-- istr that's available in sarge, even though a kernel that supports it isn't (fun). e.g. I have: bash$ cat /etc/udev/rules.d/010_local.rules [snip] But surely that's too late? The ramdisk will load the drivers before my root filesystem and therefore that rules file can be seen. -- Mike Crowe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Kernel 2.6.15-4 freeze
Hi
There seems to be some problem with kernel version 2.6.15-4. My computer
froze a few minutes ago. It may not be an amd64 specific problem since I have
had problem with loading the gpib module with the same kernel version on a
686 machine.
A lot of things where nicely documented in the syslog so if anyone can make
use of the information I would be glad. The computer did not fully freeze but
I had to do a hard reboot.
The other 2.6.15 versions seemed to be stable, and the computer is very
stable with the 2.6.12 version.
Regards
Gudjon
Feb 7 17:39:01 mve035 /USR/SBIN/CRON[3368]: (root) CMD
( [ -d /var/lib/php5 ] find /var/lib/php5/ -type f -cmin
+$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
Feb 7 17:47:17 mve035 kernel: VFS: Busy inodes after unmount. Self-destruct
in 5 seconds. Have a nice day...
Feb 7 17:47:19 mve035 kernel: Unable to handle kernel NULL pointer
dereference at 0008 RIP:
Feb 7 17:47:19 mve035 kernel: 882c2d4f{:shfs:shfs_lookup+126}
Feb 7 17:47:19 mve035 kernel: PGD 175384067 PUD 110c38067 PMD 0
Feb 7 17:47:19 mve035 kernel: Oops: [1] SMP
Feb 7 17:47:19 mve035 kernel: CPU 0
Feb 7 17:47:19 mve035 kernel: Modules linked in: eeprom i2c_sis96x i2c_dev
nls_iso8859_1 nls_cp437 vfat fat usb_storage ipv6 nvidia shfs sr_mod sbp2
ide_generic eth1394 pl2303 usbserial snd_emu10k1_synth snd_emux_synth
snd_seq_virmidi snd_seq_midi_emul snd_seq_dummy snd_seq_oss snd_seq_midi
snd_seq_midi_event snd_seq ide_cd cdrom ide_disk snd_emu10k1 emu10k1_gp
gameport snd_rawmidi snd_seq_device tg3 snd_util_mem ohci1394 ohci_hcd
ieee1394 snd_hwdep snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm psmouse snd_timer amd74xx serio_raw snd joydev generic
pcspkr ide_core soundcore i2c_amd756 hw_random floppy i2c_amd8111 i2c_core
snd_page_alloc ext3 jbd mbcache sd_mod sata_sil libata scsi_mod shpchp
pci_hotplug evdev
Feb 7 17:47:19 mve035 kernel: Pid: 3383, comm: kdesvn Tainted: P
2.6.15-1-amd64-k8-smp #2
Feb 7 17:47:19 mve035 kernel: RIP: 0010:[_end+132775247/2132660224]
882c2d4f{:shfs:shfs_lookup+126}
Feb 7 17:47:19 mve035 kernel: RSP: 0018:810023241a18 EFLAGS: 00010202
Feb 7 17:47:19 mve035 kernel: RAX: 0001 RBX: 810023d825b8
RCX:
Feb 7 17:47:19 mve035 kernel: RDX: 810023241c18 RSI: 810023241a18
RDI:
Feb 7 17:47:19 mve035 kernel: RBP: 810010b2a910 R08: 8100378a5014
R09: 0002
Feb 7 17:47:19 mve035 kernel: R10: 0002 R11: 801b907c
R12:
Feb 7 17:47:19 mve035 kernel: R13: 810023241c18 R14: 810010b2a850
R15: 810023241d18
Feb 7 17:47:19 mve035 kernel: FS: 2ef44770() GS:803e3800
() knlGS:55efdbb0
Feb 7 17:47:19 mve035 kernel: CS: 0010 DS: ES: CR0:
80050033
Feb 7 17:47:19 mve035 kernel: CR2: 0008 CR3: 306e2000
CR4: 06e0
Feb 7 17:47:19 mve035 kernel: Process kdesvn (pid: 3383, threadinfo
81002324, task 810002ec6340)
Feb 7 17:47:19 mve035 kernel: Stack: 2a006e76732f
81007599bd78 8101113870a8
Feb 7 17:47:19 mve035 kernel:0212 80161c83
0001340ea7f0 810002e7b480
Feb 7 17:47:19 mve035 kernel:00a8 810162a26c98
Feb 7 17:47:19 mve035 kernel: Call
Trace:80161c83{__handle_mm_fault+679}
801516d9{find_get_page+30}
Feb 7 17:47:19 mve035 kernel:8012ab0a{activate_task+140}
8012ba65{try_to_wake_up+933}
Feb 7 17:47:19 mve035 kernel:8012ab0a{activate_task+140}
8012ba65{try_to_wake_up+933}
Feb 7 17:47:19 mve035 kernel:8012906c{__wake_up_common+60}
80186a0b{d_alloc+358}
Feb 7 17:47:19 mve035 kernel:8017e5dd{do_lookup+204}
8017ea30{__link_path_walk+918}
Feb 7 17:47:19 mve035 kernel:8017f538{link_path_walk+89}
8017fbc9{__user_walk+62}
Feb 7 17:47:19 mve035 kernel:801701d9{sys_access+225}
8017fa98{path_lookup+430}
Feb 7 17:47:19 mve035 kernel:8017fbb8{__user_walk+45}
80179b28{vfs_stat+24}
Feb 7 17:47:19 mve035 kernel:8017fbc9{__user_walk+62}
801701d9{sys_access+225}
Feb 7 17:47:19 mve035 kernel:8017a08f{sys_newstat+17}
8010d792{system_call+126}
Feb 7 17:47:19 mve035 kernel:
Feb 7 17:47:19 mve035 kernel:
Feb 7 17:47:19 mve035 kernel: Code: 41 ff 54 24 08 85 c0 89 c5 79 75 83 3d 77
c5 00 00 02 7e 25
Feb 7 17:47:19 mve035 kernel: RIP 882c2d4f{:shfs:shfs_lookup+126}
RSP 810023241a18
Feb 7 17:47:19 mve035 kernel: CR2: 0008
Feb 7 17:48:33 mve035 kernel: 1Unable to handle kernel paging request at
0167edaf RIP:
Feb 7 17:48:33 mve035 kernel: 8018c8cf{show_vfsmnt+113}
Feb 7 17:48:33 mve035
Re: Kernel 2.6.15-4 freeze
On Tue, Feb 07, 2006 at 06:07:14PM +0100, Gudjon I. Gudjonsson wrote:
There seems to be some problem with kernel version 2.6.15-4. My computer
froze a few minutes ago. It may not be an amd64 specific problem since I have
had problem with loading the gpib module with the same kernel version on a
686 machine.
A lot of things where nicely documented in the syslog so if anyone can
make
use of the information I would be glad. The computer did not fully freeze but
I had to do a hard reboot.
The other 2.6.15 versions seemed to be stable, and the computer is very
stable with the 2.6.12 version.
Regards
Gudjon
Feb 7 17:39:01 mve035 /USR/SBIN/CRON[3368]: (root) CMD
( [ -d /var/lib/php5 ] find /var/lib/php5/ -type f -cmin
+$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
Feb 7 17:47:17 mve035 kernel: VFS: Busy inodes after unmount. Self-destruct
in 5 seconds. Have a nice day...
Feb 7 17:47:19 mve035 kernel: Unable to handle kernel NULL pointer
dereference at 0008 RIP:
Feb 7 17:47:19 mve035 kernel: 882c2d4f{:shfs:shfs_lookup+126}
Feb 7 17:47:19 mve035 kernel: PGD 175384067 PUD 110c38067 PMD 0
Feb 7 17:47:19 mve035 kernel: Oops: [1] SMP
Feb 7 17:47:19 mve035 kernel: CPU 0
Feb 7 17:47:19 mve035 kernel: Modules linked in: eeprom i2c_sis96x i2c_dev
nls_iso8859_1 nls_cp437 vfat fat usb_storage ipv6 nvidia shfs sr_mod sbp2
ide_generic eth1394 pl2303 usbserial snd_emu10k1_synth snd_emux_synth
snd_seq_virmidi snd_seq_midi_emul snd_seq_dummy snd_seq_oss snd_seq_midi
snd_seq_midi_event snd_seq ide_cd cdrom ide_disk snd_emu10k1 emu10k1_gp
gameport snd_rawmidi snd_seq_device tg3 snd_util_mem ohci1394 ohci_hcd
ieee1394 snd_hwdep snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm psmouse snd_timer amd74xx serio_raw snd joydev generic
pcspkr ide_core soundcore i2c_amd756 hw_random floppy i2c_amd8111 i2c_core
snd_page_alloc ext3 jbd mbcache sd_mod sata_sil libata scsi_mod shpchp
pci_hotplug evdev
Feb 7 17:47:19 mve035 kernel: Pid: 3383, comm: kdesvn Tainted: P
Kernel tainted by a proprietary module, so backtrace might be
unreliable. Try to recreate the problem without the Nvidia and shfs
modules and see if it persists.
BTW: you might want to use FUSE with sshfs instead of shfs. FUSE is
part of the mainline kernel so should be in sync with the current
in-kernel API. See http://fuse.sourceforge.net/sshfs.html .
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
Mike Crowe wrote: Mike Crowe wrote: On Tue, Feb 07, 2006 at 02:26:54PM +, Steven Haslam wrote: I actually had this exact problem myself for the first time this morning with my X2 system, with an initrd built by initramfs-tools. Using yaird may help because AIUI it will only load the modules required to mount the root filesystem during the initramfs stage, or at least will load those first. Assuming I can persuade the stock 2.6.15 kernel to use yaird rather than initramfs then I'll give that a go. If I have to compile the kernel myself I might as well just compile in the drivers I need which will also solve the problem for me. There shouldn't be any kernel changes required. Just use mkinitrd.yaird to build a new initrd.img. You can fix the names of network interfaces using udev-- istr that's available in sarge, even though a kernel that supports it isn't (fun). e.g. I have: bash$ cat /etc/udev/rules.d/010_local.rules [snip] But surely that's too late? The ramdisk will load the drivers before my root filesystem and therefore that rules file can be seen. I presume that unless you're mounting the root filesystem over nfs, then the ramdisk doesn't try to load net drivers. There's a certain amount of "it works for me" in play here. Hmm. You could well be right-- the machine I'm using that udev tinkering on is using a yaird-built ramdisk, so it definitely *doesn't* load the net drivers. tinkers OTOH, building an initramfs using initramfs-tools takes a copy of your /etc/udev and /etc/modprobe.d at the time it was built, so you just have to update /etc/udev/rules.d and rebuild the initrd. SRH
Re: initrd race conditions
Mike Crowe wrote: I'm running the backports.org 2.6.15 kernel on an otherwise sarge amd64 box with a couple of Opteron 275s. It seems that modules are being loaded by the initrd at startup in parallel. This seems to lead to serious race conditions with the following symptoms: BTW you can also add modules explicitly to /etc/mkinitramfs/modules and they will be individually (and presumably sequentially, assuming modprobe only exist when the module has finished probing) loaded before udev is started. That may be the easiest option of all for sorting out your drive hardware ordering. I'm fairly sure it's udev that is setting off module loads in the background. SRH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fglrx and linux-image-2.6.15-1-amd64-k8
Marcin D?bicki wrote: Did anyone installed successfully 8.21.7 driver for ATI on 2.6.15 kernel? I am using kernel image from repo (linux-image-2.6.15-1-amd64-k8). Compilation goes ok, ko module is generated. Many warnings obviously are whown but module is generated. While trying to modprobe it seems that module cannot be inserted because of some reason. I've tried compilation woth and without patch from this site: http://www.thinkwiki.org/wiki/Problems_with_fglrx#fglrx_8.21.7 Hi, I'm running Sid 2.6.15-amd64 with an ATI Radeon 9550 card. I've had some help from the fglrx list and have managed to get the 8.21.7 driver working. Everything is Ok: 3D acceleration etc. xv video. The only problem I have is that the system freezes every time I shut down the X server. FWIW, here's the advice I received from Flavio. Maybe you won't have the freezup problem on your systems. The fglrx driver for X.Org 6.9 is not available in RPM format, so you're out of luck with my packages. The ATI installer, however, *does* contain binaries for 6.9 and you can build packages with it: http://www.stanchina.net/~flavio/debian/fglrx-archive/msg01034.html Besides, if you want to use it with 2.6.15 you'll need this patch: http://lkml.org/lkml/2005/12/11/26 Good luck, Jonathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
On Tue, Feb 07, 2006 at 05:36:51PM +, Steven Haslam wrote: There shouldn't be any kernel changes required. Just use mkinitrd.yaird to build a new initrd.img. I installed the sarge-backports yaird and modified /etc/kernel-pkg.conf to say ramdisk=mkinitrd.yaird and then ran dpkg-reconfigure linux-image-2.6.15-1-amd64-k8-smp which seemed to cause the ramdisk to be rebuilt using yaird. As you explained this meant that the network drivers were not loaded by the initrd. I still couldn't get my local udev rules to rename the interfaces on startup though. In the end I just disabled the e100 in the BIOS - I hope that the two tg3s will always be discovered in the same order... :-) Thanks for all your help. I think I'd like to log a bug report about this though. Is udev the best package to do that against? -- Mike Crowe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
Mike Crowe wrote: I still couldn't get my local udev rules to rename the interfaces on startup though. In the end I just disabled the e100 in the BIOS - I hope that the two tg3s will always be discovered in the same order... :-) Well, presumably the ordering of the tg3s is based on their PCI bus positions, so it should be better defined. I think I'd like to log a bug report about this though. Is udev the best package to do that against? Not sure. It could be argued that udev is simply doing its thing, which is loading modules in response to hotplug events: and processing them serially is possibly going to cause other problems. Mmmm. dunno. Raise it anyway and see what happens, I guess :) The issue with not being able to rename your net interfaces is certainly a udev issue, although whether it's a bug or misconfiguration is hard to determine. Maybe double-check the sysfs attributes using, for example, udevinfo -a -p /sys/class/net/eth0. The first block of values (for the /class/net/eth0 node) are what can be used to rename the device. Also if udev isn't running when the module gets loaded, the renaming won't happen. I remember it took me a few attempts to get it right, but it was a while ago and I can't remember too many details. And just for kicks, the machine I'm using it on is i386 not amd64, so you never know but I'd be surprised if the arch made a difference. SRH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd race conditions
On Tue, Feb 07, 2006 at 02:26:54PM +, Steven Haslam wrote:
Mike Crowe wrote:
2. Almost random ordering of ethernet devices between boots. The
You can fix the names of network interfaces using udev-- istr that's
available in sarge, even though a kernel that supports it isn't (fun).
e.g. I have:
bash$ cat /etc/udev/rules.d/010_local.rules
# Local rules
# eth0: dl2k (gigabit adaptor)
SUBSYSTEM=net, SYSFS{address} = 00:05:5d:9a:a3:a8, NAME=eth0
Another option is to use ifrename. Then you just create an /etc/iftab
which lists the MAC addresses and desired names. I'm using it on my laptop,
where the wired and wifi interfaces come up in random order.
This problem isn't particular to dual-processor machines at all; the
modules do load in parallel or random order.
# ethX: e100 (onboard)
SUBSYSTEM=net, SYSFS{address} = 00:02:a5:cf:bb:d4, NAME=ethX
This renames my onboard ethernet adaptor to ethX to keep it out of the
way because the BIOS doesn't permit disabling it (grumble).
You could blacklist the module, if it's the only e100 you have.
I blacklisted the eth1394 module here since I don't want ethernet over
firewire.
Hamish
--
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.6.15-4 freeze
Erik Mouw wrote:
On Tue, Feb 07, 2006 at 06:07:14PM +0100, Gudjon I. Gudjonsson wrote:
There seems to be some problem with kernel version 2.6.15-4. My computer
froze a few minutes ago. It may not be an amd64 specific problem since I have
had problem with loading the gpib module with the same kernel version on a
686 machine.
A lot of things where nicely documented in the syslog so if anyone can
make
use of the information I would be glad. The computer did not fully freeze but
I had to do a hard reboot.
The other 2.6.15 versions seemed to be stable, and the computer is very
stable with the 2.6.12 version.
Regards
Gudjon
Feb 7 17:39:01 mve035 /USR/SBIN/CRON[3368]: (root) CMD
( [ -d /var/lib/php5 ] find /var/lib/php5/ -type f -cmin
+$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
Feb 7 17:47:17 mve035 kernel: VFS: Busy inodes after unmount. Self-destruct
in 5 seconds. Have a nice day...
Feb 7 17:47:19 mve035 kernel: Unable to handle kernel NULL pointer
dereference at 0008 RIP:
Feb 7 17:47:19 mve035 kernel: 882c2d4f{:shfs:shfs_lookup+126}
Feb 7 17:47:19 mve035 kernel: PGD 175384067 PUD 110c38067 PMD 0
Feb 7 17:47:19 mve035 kernel: Oops: [1] SMP
Feb 7 17:47:19 mve035 kernel: CPU 0
Feb 7 17:47:19 mve035 kernel: Modules linked in: eeprom i2c_sis96x i2c_dev
nls_iso8859_1 nls_cp437 vfat fat usb_storage ipv6 nvidia shfs sr_mod sbp2
ide_generic eth1394 pl2303 usbserial snd_emu10k1_synth snd_emux_synth
snd_seq_virmidi snd_seq_midi_emul snd_seq_dummy snd_seq_oss snd_seq_midi
snd_seq_midi_event snd_seq ide_cd cdrom ide_disk snd_emu10k1 emu10k1_gp
gameport snd_rawmidi snd_seq_device tg3 snd_util_mem ohci1394 ohci_hcd
ieee1394 snd_hwdep snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm psmouse snd_timer amd74xx serio_raw snd joydev generic
pcspkr ide_core soundcore i2c_amd756 hw_random floppy i2c_amd8111 i2c_core
snd_page_alloc ext3 jbd mbcache sd_mod sata_sil libata scsi_mod shpchp
pci_hotplug evdev
Feb 7 17:47:19 mve035 kernel: Pid: 3383, comm: kdesvn Tainted: P
Kernel tainted by a proprietary module, so backtrace might be
unreliable. Try to recreate the problem without the Nvidia and shfs
modules and see if it persists.
BTW: you might want to use FUSE with sshfs instead of shfs. FUSE is
part of the mainline kernel so should be in sync with the current
in-kernel API. See http://fuse.sourceforge.net/sshfs.html .
Did you reboot after upgrading to 2.6.15-4? That upgrade happened for me
this morning, and the upgrade warned that I would need to reboot, so I did.
Also, I noticed a problem with shfs on AMD64 with a 2.6.14 kernel last
week or the week before, whereby normal everyday commands like ls
started segfaulting. It might be a related problem -- I didn't take the
time to debug it.
--Ken
--
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
