Bug#567468: domainname
Hi, IMHO you are confused: /proc/sys/kernel/domainname is the NIS domain name and has nothing to do with DNS; in fact, the NIS domain can be different from the DNS domain. Thus your script is doubly wrong: on a NIS system hostnames are normally not qualified so you cannot obtain the NIS domain from the host name, and on a non-NIS system the NIS domainname should remain unset even if the hostname is qualified. Also, mdadm currently works fine with custom-built kernels having no initramfs at all. Why break that? It would be much nicer to patch mdadm to try to read /etc/hostname directly if gethostname() returns an empty string. Regarding to the issue Marco raised: in fact it is quite common to install a machine on an internal network where it gets some random name from DHCP, and rename it when it is ready to be put at it's intended location. When you do not have physical access to the final location then finding out that the machine no longer boots with the new name may be painful. Gabor -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Xen support on Squeeze
On Sun, Jan 03, 2010 at 06:31:20PM +0200, Pasi Kärkkäinen wrote: So the change has happened, lthough it took painfully long to get the upstream Linux pv_ops framework in shape and all that.. and obviously the pv_ops dom0 patches still need to get merged upstream. That was opposed quite strongly by the kernel folks last time it was attempted. Were there any fundamental changes in the Xen dom0 patches since then? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535008: configure_networking: support BOOTIF variable set by pxelinux
Hi, aolMee too!/aol It'd be really nice to have this integrated. To add something constructive, mdadm, and lvm2 scripts already use sed without checking for it or making sure that it is available, so the use of sed should not be a problem. cryptsetup also uses sed but it at least forces BUSYBOX=y. IMHO it should be enough to document that BOOT=nfs requires BUSYBOX=y. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC
On Fri, Dec 26, 2008 at 06:49:05PM +0100, Moritz Muehlenhoff wrote: Does this error still occur with more recent kernel versions? I've tried once during the christmas holidays with 2.6.26 and it worked, so the bug can be closed. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#488273: linux-image-2.6.25-2-amd64: Hangs on a Dell Poweredge 850
On Sat, Dec 27, 2008 at 02:44:21PM +0100, Moritz Muehlenhoff wrote: Does this error still occur with more recent kernel versions? No idea, all our Dells are now running Mandriva with a 2.6.18-based Xen kernel, and there is no chance in the near future to try Debian on them again. I've had other affected machines but they were/are running vanilla kernels, not Debian provided ones. On these other machines, the bug has been fixed in 2.6.27 upstream. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496967: general: System completely blocks any input
On Mon, Sep 01, 2008 at 09:04:35PM +0200, Frank Küster wrote: Although I personally feal the bug is super-duper-hyper-grave, I leave the judgement to the linux maintainers. FYI: I've tried 2.6.27-rc5 and it is up for more than 15 hours now. That's far more than 2.6.25/26 ever managed on this box (2.6.24 is rock solid). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC
On Tue, Dec 25, 2007 at 11:30:32PM +0100, maximilian attems wrote: please report back if aboves fixes it. Ok, but it may take 1-2 weeks when I'm next near that machine. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC
On Fri, Dec 07, 2007 at 11:15:00AM +0100, maximilian attems wrote: please try newer, unstalbe has 2.6.23-1 that installs just fine in testing. I've tested now 2.6.23-2 and the bug is still present, but only when powering on the machine. After a reboot (or when booting Windows before Linux) the network card is visible again. The reason seems to be the same as before: after power-on, the PCI bridge at 00:1e.0 is disabled, but after a reboot it gets enabled. 2.6.20 still works fine even right after a power-on. dmesg of both after a cold start and after reboot are below. dmesg after cold start: === Linux version 2.6.23-1-686 (Debian 2.6.23-2) ([EMAIL PROTECTED]) (gcc version 4.1.3 20071209 (prerelease) (Debian 4.1.2-18)) #1 SMP Fri Dec 21 13:57:07 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 1ff3 (usable) BIOS-e820: 1ff3 - 1ff4 (ACPI data) BIOS-e820: 1ff4 - 1fff (ACPI NVS) BIOS-e820: 1fff - 2000 (reserved) BIOS-e820: ffba - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. found SMP MP-table at 000ff780 Entering add_active_range(0, 0, 130864) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 130864 HighMem130864 - 130864 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 130864 On node 0 totalpages: 130864 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 990 pages used for memmap Normal zone: 125778 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000F9E70, 0014 (r0 ACPIAM) ACPI: RSDT 1FF3, 0030 (r1 A M I OEMRSDT 2000424 MSFT 97) ACPI: FACP 1FF30200, 0081 (r2 A M I OEMFACP 2000424 MSFT 97) ACPI: DSDT 1FF303F0, 3779 (r1 P4PSS P4PSS023 23 INTL 2002026) ACPI: FACS 1FF4, 0040 ACPI: APIC 1FF30390, 005C (r1 A M I OEMAPIC 2000424 MSFT 97) ACPI: OEMB 1FF40040, 003F (r1 A M I OEMBIOS 2000424 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:2 APIC version 20 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dfba) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e8000 swsusp: Registered nosave memory region: 000e8000 - 0010 Built 1 zonelists in Zone order. Total pages: 129842 Kernel command line: root=/dev/hda7 ro mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 2793.185 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 508652k/523456k available (1721k kernel code, 14244k reserved, 672k data, 240k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfff4c000 - 0xf000 ( 716 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xe080 - 0xff7fe000 ( 495 MB) lowmem : 0xc000 - 0xdff3 ( 511 MB) .init : 0xc035d000 - 0xc0399000 ( 240 kB) .data : 0xc02ae7cd - 0xc03568c4 ( 672 kB) .text : 0xc010 - 0xc02ae7cd (1721 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 5590.68 BogoMIPS (lpj=11181368) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff b080 4400 Intel machine check architecture supported.
Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC
On Fri, Dec 07, 2007 at 11:15:00AM +0100, maximilian attems wrote: please try newer, unstalbe has 2.6.23-1 that installs just fine in testing. Well, I'm actually using unstable, but linux-image-2.6-686 still pulled 2.6.22. Next time I'll try 2.6.23 but I'll not be near that machine for approx. 2 weeks. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454718: linux-image-2.6.22-3-686: Does not see the NIC
Package: linux-image-2.6.22-3-686 Version: 2.6.22-6 Severity: normal Hi, After upgrading to linux-image-2.6.22-3, networking no longer works. In fact, lspci does no longer show the network card at all. linux-image-2.6.20-1 (version 2.6.20-3) works fine. dmesg and lspci for both versions are below; I think the most significant part is this change in dmesg: PCI: Bridge: :00:1e.0 - IO window: d000-dfff - MEM window: fea0-feaf + IO window: disabled. + MEM window: disabled. PREFETCH window: disabled. The network card (driven by 8139too) is behind that bridge... The MB is an Asus P4P800S/SE. Gabor lspci -vvnn with 2.6.20-3: == 00:00.0 Host bridge [0600]: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface [8086:2570] (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device [1043:8110] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 3.0 Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP- GART64- 64bit- FW- Rate=none 00:01.0 PCI bridge [0604]: Intel Corporation 82865G/PE/P PCI to AGP Controller [8086:2571] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: fc90-fe9f Prefetchable memory behind bridge: e7f0-f7ef Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- 00:1d.0 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 [8086:24d2] (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard [1043:80a6] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 17 Region 4: I/O ports at ef00 [size=32] 00:1d.1 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 [8086:24d4] (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard [1043:80a6] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 18 Region 4: I/O ports at ef20 [size=32] 00:1d.2 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 [8086:24d7] (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard [1043:80a6] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin C routed to IRQ 19 Region 4: I/O ports at ef40 [size=32] 00:1d.3 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 [8086:24de] (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard [1043:80a6] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 17 Region 4: I/O ports at ef80 [size=32] 00:1d.7 USB Controller [0c03]: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller [8086:24dd] (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard [1043:80a6] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin D routed to IRQ 20 Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bug#425050: initramfs-tools: Ask if we should update all initramfses
On Fri, May 18, 2007 at 09:26:25PM +0200, Tim Dijkstra wrote: Come on. `useless debconf proliferation'? The question has medium priority. I can also make it an configration option somewhere and use that, but it was just a convenient why to get info from a user. I'd also say a debconf question is overkill. People who understand what the option means can edit a config file by hand. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sysctl syscall removed in 2.6.18+ kernels
On Tue, Aug 15, 2006 at 06:11:18PM +0200, Aurelien Jarno wrote: It already started to annoy some people having their log filled with such messages. IMHO if the message is not rate-limited you should bug the kernel developers (preferably upstream on linux-kernel). Printing the message 1-2 times per boot is OK but after that it is meaningless. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) Different distros have different target audiences so this may not be easy. Often fixing a driver bug for one class of users breaks it for an other class of users so it is quite possible that different distros want different bugs to be fixed/left alone. Also, other distros (e.g. RedHat) already found out the hard way that diverging too much from upstream costs a lot. So unless you find someone to pay the maintainers of such a forked kernel, it will not work out in the long term. If you give it a quick look (and a quick try), we will have more users testing the same kernel, which means more feedback, we will have more developers working to get it stable and working to get it secure. Probably even upstream get benefits from this model and sounds like a very good way to work together, even to try to integrate outside patches and backporting things. =) Dave Jones (Fedora) and Greg KH (Gentoo) already posted a much better idea on l-k: make packages from daily -git snapshots available for distro testers, so bugs like the past udev breakages are found _before_ the next official kernel version is released. Packaging at least -rc kernels for unstable might be a good idea for Debian too. That would provide more testing coverage for -rc releases, and this is what upstream needs the most. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 02:26:51PM +0100, Maximilian Attems wrote: the -rc kernels are build in experimental, staging area for unstable and without any potential d-i breakage. Ah, nice, I did not notice it. Perhaps it should get some more publicity to attract more testers :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:10:49AM +0100, Sven Luther wrote: But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev and it works. AFAIK it should work with the default ruleset. It breaks only with certain custom rules due to a bug in the libsysfs version used by udev. So, if you did not create any udev rules yourself you should be fine. With old udev and new kernel my rules that map my USB disks to persistent names under /dev were definitely broken. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
