Bug#266872: [i386] [20040816] [netinstall] hwconfig shows minor error
Package: installation-reports INSTALL REPORT Debian-installer-version: daily build netinstall 16.08.2004 uname -a: Linux hansi 2.4.26-1-686 #1 Thu Jul 22 13:00:49 JST 2004 i686 GNU/Linux Date: Tue Aug 17 16:18:30 CEST 2004 Method: network install not proxied, .at mirror, Machine: sony vaio pcg-nv105 Processor: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping: 4 cpu MHz : 1590.856 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 3171.94 Memory: total:used:free: shared: buffers: cached: Mem: 262254592 217079808 451747840 14950400 121671680 Swap: 5099192320 509919232 MemTotal: 256108 kB MemFree: 44116 kB MemShared: 0 kB Buffers: 14600 kB Cached: 118820 kB SwapCached: 0 kB Active: 94944 kB Inactive:90496 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 256108 kB LowFree: 44116 kB SwapTotal: 497968 kB SwapFree: 497968 kB Root Device: ide Root Size/partition table: rootfs / rootfs rw 0 0 /dev2/root2 / ext3 rw 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 /dev/hda8 /home ext3 rw 0 0 usbfs /proc/bus/usb usbfs rw 0 0 # /etc/fstab: static file system information. # # proc/proc procdefaults0 0 /dev/hda6 / ext3defaults,errors=remount-ro 0 1 /dev/hda8 /home ext3defaults0 2 /dev/hda7 noneswapsw 0 0 /dev/hdc/media/cdrom0 iso9660 ro,user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 Output of lspci and lspci -n: :00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04) :00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) :00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 42) :00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) :00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) :00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 02) :00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio Controller (rev 02) :00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem Controller (rev 02) :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] :02:05.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8) :02:05.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8) :02:05.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller :02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) :00:00.0 0600: 8086:1a30 (rev 04) :00:01.0 0604: 8086:1a31 (rev 04) :00:1d.0 0c03: 8086:2482 (rev 02) :00:1d.1 0c03: 8086:2484 (rev 02) :00:1d.2 0c03: 8086:2487 (rev 02) :00:1e.0 0604: 8086:2448 (rev 42) :00:1f.0 0601: 8086:248c (rev 02) :00:1f.1 0101: 8086:248a (rev 02) :00:1f.3 0c05: 8086:2483 (rev 02) :00:1f.5 0401: 8086:2485 (rev 02) :00:1f.6 0703: 8086:2486 (rev 02) :01:00.0 0300: 1002:4c57 :02:05.0 0607: 1180:0476 (rev a8) :02:05.1 0607: 1180:0476 (rev a8) :02:05.2 0c00: 1180:0552 :02:08.0 0200: 8086:1031 (rev 42) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[0] Configure network HW: [0] 1) Config network: [0] Detect CD: [0] Load installer modules: [0] Detect hard drives: [0] Partition hard drives: [0] Create file systems:[0] Mount partitions: [0] Install base system:[0] Install boot loader:[0] Reboot: [0] Comments/Problems: great work guys, minor comments: 1) error while modprobe -v ohci1394 probably already known signature.asc Description: Digital signature
Bug#222374: d-i melts screen on sis 630 laptop
Package: installation-reports Version: sarge-i386-netinst.iso 22-Nov-2003 Severity: grave installer is unusable because right away in the middle of kernel booting appears a "melting" white screen. xfree 4.1 and before the old sis driver showed this strange behaviour, thomas winischhofer cured it by programming good sis drivers: http://www.winischhofer.net/linuxsisvga.shtml here my mini-howto for installing woody on this laptop: http://debian.stro.at/webgine.htm don't know what causes the problem, but appears even with net video=vga16:off or net mono may test any enhanced version of d-i, this bug affects gericom webgine, webboy regards maks attems -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#222374: d-i melts screen on sis 630 laptop
Thank your for your helpfull email!! > It sounds to me like there is a problem when the installer enables the > frame buffer. Unfortunatly, the boot documentation is wrong, and there > is no way to disable the framebuffer with beta 1 of the installer. > > Could you please try downloading a current daily build of the debian > install (ISOs here: http://people.debian.org/~manty/testing/netinst/) > and boot it with "linux debian-installer/framebuffer=false", and let me > know if that solves your problem? you are completly right just tested aboves daily build and with aboves arguments, i got into d-i on this sis-630 laptop :)) strange parsing of the kernel commandline, tried with aboves image net video=sisfb:off which had no effect. cool work ! a++ maks ps cc at sisfb kernel mantainer as he was aware of this bug pgp0.pgp Description: PGP signature
Bug#222374: d-i melts screen on sis 630 laptop
On Sun, 21 Dec 2003, Thomas Winischhofer wrote: [..] > Sisfb should work on this hardware as of 2.4.18, but I am not sure. It's > been a while since that came out. 2.4.20 is the oldest one I positively > remember to contain a working sisfb. i can confirm that sisfb works for 2.4.2[0-3] so there is no kernel bug there, no need to reassign. > But is it really the sis framebuffer driver that is activated during > boot, and not eg vga16 or some other generic driver? AFAIK, there is no > such thing as "auto-config" for framebuffers; one has to positively > choose one by the kernel command line. Even if you compile all of them, > none will be activated if no video=xxx is given. So, appending > video=sisfb:off won't have any effect if another framebuffer driver is > started with another video= switch. the isolinux.cfg of the d-i iso image contains a "vga=normal" switch but no video, don't know if "vga=normal" already enables a framebuffer or if there is another place with some video switch? > Some old Debian installer (which I used about two years ago when I for > the last time yet installed Debian on a 630 based laptop) did start > vga16 - with the very same result that Maximilian experiences. I don't > recall exactly what I did to work around this problem, but I assume it > was appending "vga16:off" or something like this. unfortunately this doesn't work with d-i please do not close this bug until f6.txt shows the correct switch to really disable the chosen framebuffer take a look at this patch below (no idea which patchlevel d-i uses and about the controll characters): regards max --- a/isolinux/f5.txt 2003-12-17 15:34:18.0 +0100 +++ b/isolinux/f5.txt 2003-12-22 18:49:29.0 +0100 @@ -6,7 +6,7 @@ 0fHARDWARE PARAMETER TO SPECIFY07 Monochrome monitor 0fmono07 -Disable framebuffer for monitor0fvideo=vga16:off07 +Disable framebuffer for monitor0fdebian-installer/framebuffer=false07 IBM PS/1 or ValuePoint (IDE disk) 0fhd=0bcylinders0f,0bheads0f,0bsectors07 IBM ThinkPad 0ffloppy=thinkpad07 IBM Pentium Microchannel 0fmca-pentium no-hlt07 -- free software is not free at all, and "actually a different form of monopoly" ARLENE MCCARTHY member of the european parliament (labour party) -> http://swpat.ffii.org/#guardian-nhill030619 support real limits on patentability -> http://swpat.ffii.org/index.en.html pgp0.pgp Description: PGP signature
Bug#222374: d-i melts screen on sis 630 laptop
thx Joey for fixing CDROM boot txt! On Tue, 23 Dec 2003, Thomas Winischhofer wrote: > Max, if you have time, could you compile a kernel with vesafb enabled > and test this? plain vesafb works fine, just booted up, relevant config: -- config-2.4.23 snippet # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y # CONFIG_FB_RIVA is not set # CONFIG_FB_CLGEN is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CYBER2000 is not set CONFIG_FB_VESA=y # CONFIG_FB_VGA16 is not set # CONFIG_FB_HGA is not set CONFIG_VIDEO_SELECT=y -- no splash or melting sreen! so which fb is using d-i ? should take a look at cvs, but couldn't find my path to the config files of the boot kernels regards max pgp0.pgp Description: PGP signature
Bug#222374: d-i melts screen on sis 630 laptop
On Sun, 28 Dec 2003, Thomas Winischhofer wrote: > Max, could you please try connecting an external VGA monitor to your > box, go through the installer and see if you can find out what exactly > happens during boot (like syslog, dmesg, etc)? just in a bit of hurry checked on another vga monitor via dmesg that vga16 fb get loaded the bad one ;) i will try to provide full dmesg tomorrow regards max signature.asc Description: Digital signature
Bug#222374: d-i melts screen on sis 630 laptop
On Sun, 28 Dec 2003, Joey Hess wrote: > I think you're right, it all goes by very fast here, even in vmware, but > the code does a modprobe vesafb || modprobe vga16, and I see modprobe > failing to load the former, then presumably it loads the latter. thomas here the promised dmesg and syslog they show vga16fb to bee loaded -- dmesg snippet Linux version 2.4.22-1-386 ([EMAIL PROTECTED]) (gcc version 3.3.2 20030908 (Debian prerelease)) #9 Sat Oct 4 14:30:39 EST 2003 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 1f7f (usable) BIOS-e820: 1f7f - 1f7f8000 (ACPI data) BIOS-e820: 1f7f8000 - 1f80 (ACPI NVS) BIOS-e820: ffef - fff0 (reserved) BIOS-e820: - 0001 (reserved) 503MB LOWMEM available. ACPI: have wakeup address 0xc0001000 On node 0 totalpages: 129008 zone(0): 4096 pages. zone(1): 124912 pages. zone(2): 0 pages. ACPI disabled because your bios is from 97 and too old You can enable it with acpi=force Kernel command line: vga=normal initrd=/install/cdrom.gz ramdisk_size=8192 root=/dev/rd/0 init=/linuxrc devfs=mount,dall rw BOOT_IMAGE=/install Initializing CPU#0 Detected 1097.266 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2188.90 BogoMIPS Memory: 506632k/516032k available (1031k kernel code, 9012k reserved, 442k data, 76k init, 0k highmem) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode cache hash table entries: 32768 (order: 6, 262144 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After generic, caps: 0383f9ff CPU: Common caps: 0383f9ff CPU: Intel Pentium III (Coppermine) stepping 0a Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX ACPI: Subsystem revision 20030813 ACPI: Interpreter disabled. PCI: PCI BIOS revision 2.10 entry at 0xfdb31, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: ACPI tables contain no PCI IRQ routing entries PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router SIS [1039/0008] at 00:01.0 PCI: Found IRQ 11 for device 00:03.0 PCI: Sharing IRQ 11 with 00:01.4 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd VFS: Disk quotas vdquot_6.5.1 devfs: v1.12c (20020818) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x1 pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A PCI: Found IRQ 10 for device 00:01.6 PCI: Sharing IRQ 10 with 00:01.1 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Initializing Cryptographic API NET4: Linux TCP/IP 1.0 for NET4.0 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 65536) Linux IP multicast router 0.06 plus PIM-SM RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1631k freed VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev VFS: Mounted root (ext2 filesystem). Trying to move old root to /initrd ... okay Mounted devfs on /dev Freeing unused kernel memory: 76k freed NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. vga16fb: initializing vga16fb: mapped to 0xc00a Console: switching to colour frame buffer device 80x30 fb0: VGA16 VGA frame buffer device -- syslog snippet Dec 29 19:07:12 (none) syslog.info syslogd started: BusyBox v1.00-pre3 (2003.10.21-17:24+) Dec 29 19:07:12 (none) syslog.notice klogd: klogd started: BusyBox v1.00-pre3 (2003.10.21-17:24+) Dec 29 19:07:12 (none) syslog.warn klogd: Linux version 2.4.22-1-386 ([EMAIL PROTECTED]) (gcc version 3.3.2 20030908 (Debian prerelease)) #9 Sat Oct 4 14:30:39 EST 2003 Dec 29 19:07:12 (none) syslog.info klogd: BIOS-provided physical RAM map: Dec 29 19:07:12 (none) syslog.warn klogd: BIOS-e820: - 0009fc00 (usable) Dec 29 19:07:12 (none) syslog.warn klogd: BIOS-e820: 0009fc00 - 000a (reserved) Dec 29 19:07:12 (none) syslog.warn klogd: BIOS-e820: 000e8000 - 0010 (reserved) Dec 29 19:07:12 (none) syslog.warn klogd: BIOS-e820: 0010 - 1f7f (usable) Dec 29 19:07:12 (none) syslog.warn klogd: BIOS-e820: 1f7f - 1f7f8000
Bug#253032: alpha test rc1 installation failed on various reasons
Package: installation-reports INSTALL REPORT Debian-installer-version: alpha test rc1 from may 30 uname -a: Date: 6. june 2004 ~16h Method: sarge-alpha-businesscard.iso, boot from scsi cdrom, target ont scsi hard disc. Machine: Digital Server 4000 - family Rawhide Processor: 4 Memory: ~ 800 Mb Root Device: SCSI Maverick hard disc Root Size/partition table: 520mb from the end of a ~540 mb scsi drive Output of lspci and lspci -n: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [E] 1) Config network: [O/E] 2) Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[E] 3) Install boot loader:[E] 4) Reboot: [E] 5) Comments/Problems: this is the same machine as #242659 *) unfortunately ended again without a working os on it. 1) detecting network loads module DAC960 don't know how that raid controller helps for networking? anyway everything dead, last thing i could do was to change consoles without seeing any grave message, i assume kernel panic -> please blacklist that controller for network detection. rebooted with DEBCONF_PRIORITY=medium to not load that module 2) another error while installing the base system on a clean target: "couldn't download dpkg" the dhcpd daemon of that ass slow network is configured with "renewal in 150 seconds" so that may have interferred. on the next run i had more luck regarding network. 3) install the base system fails after 70% because of apt-utils vc3 shows: Errors were encountered while processing: apt-utils umount: /target/dev/pts: No such file or directory umount: /target/dev/shm: No such file or directory umount: /target/proc/bus/usb: Invalid argument changed to vc2, chrooted into /target, cd /var/cache/apt/archives, dpkg -i *deb apt-get install aboot libdb4.2 kernel-image-2.4.26-generic 4) boot loader menu entry jumps back to base-install instaed of calling swriteboot witch correct arguments: tried to install aboot from debian main-menu, that asked if i want to proceed on an unclean base install, which i thought to have cured above somehow, but arrrgh it brings me back to 3) redone aboves steps then outside of chroot: sbin/swriteboot -c1 dev/sda boot/bootlx (hmm it's a wild guess but seems to work somehow, stumbeled a bit but /dev/sda seemed not to exist only above /target) edited /etc/aboot.conf to reflect the root partition on 1 partition. 5) boot fails on kernel panic unable to mount root=/dev/sda1 when entering aboot, a quick 'l' lists aboot.conf entries choosing 1 boots up the kernel, but Please append a correct "root=" boot option kernel panic: vfs unable to mount root fs on 08.01 also treid with bootargs devfs=mount,dall root=/dev/scsi/host0/bus/0/target0/lun0/partition1 but same result. hope that helps for further alpha development. best regards maks *) i will close that bug report, as scsi disc were recognised after boot (no need to mount) those base system trouble were cured, and the menu entry of aboot showed up. signature.asc Description: Digital signature
Bug#253855: alpha 20040610 base install failed after choosing kernel
Package: installation-reports INSTALL REPORT Debian-installer-version: alpha daily build http://cdimage.debian.org/pub/cdimage-testing/daily/alpha/20040610/ uname -a: Date: 11. june 2004 ~13h Method: sarge-alpha-businesscard.iso, boot from scsi cdrom, target scsi hard disc. Machine: Digital Server 4000 - family Rawhide Processor: 4 Memory: ~ 800 Mb Root Device: SCSI Maverick hard disc Root Size/partition table: 520mb from the end of a 540 mb scsi drive Output of lspci and lspci -n: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Choose Keyboard:[E] 1) Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[E] 2) Install boot loader:[] Reboot: [] this is same machine as #253032 *) 1) the daily build didn't let me choose my keyboard at DEBCONF_PRIORITY=medium after the coutry selection. had an english keyboard (same as language) but needed german. 2) after choosing the kernel base-install fails after 81% initial choosen kernel-image-2.4.26-1-smp reproduced with kernel-image-2.6.6-1-smp on a clean base target vc1 gets the known error message "Installation step failed", initrd-tools were downloaded as well ash as a cramfs package but the kernel not, verified by a ls /target/boot the last thing that is done is "setting up initrd tools" syslog shows a main-menu with 100% a Connection to ftp.at.debian.org[ip]:80 (the mirror i chose) and then a user.warn main-menu WARNING **: Configuring "base-installer failed with error code 1 i retried with netinst.iso from aboves link, and a bit different paritioning scheme 470mb from the end for /, 40 mb in the middle for /boot and 30mb free at the beginning of the disc. always used ext2 fs. sorry that the error message is not more meanfull, hope vorlon that aboves still helps to nail that down. strange happened when passing "console=tty console=ttyS0" as bootargs from aboot, did get no serial console, but when doing "console=tty console=ttyS0,9600" i got the serial line, but no tty. a++ maks *) i will close that bug report as the failures from tc1 are corrected, inbetween thanks vorlon! signature.asc Description: Digital signature
Bug#242659: d-i errors on alpha
Package: installation-reports Severity: Normal an-installer-version: sarge-alpha-netinst.iso daily build from 5. April uname -a: (don't remember exactly but was 2.4.24) Date: 07. April 2004 Method: boot from scsi cdrom, target root partition on scsi hard-disc Machine: alpha rawhide Processor: 4 Memory: ~ 800 Mb Root Device: SCSI Maverick hard disc Base System Installation Checklist: Initial boot worked:[0] Configure network HW: [0] Config network: [0] Detect CD: [E] 1) Load installer modules: [0] Detect hard drives: [0] Partition hard drives: [0] Create file systems:[0] Mount partitions: [0] Install base system:[E] 2) Install boot loader:[E] 3) Reboot: [ ] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: 1) the cd from whom aboot booted the debian system was not recognised: cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 05 Lun: 00 Vendor: DEC Model: RRD47(C) DEC Rev: 1206 Type: CD-ROMANSI SCSI revision: 02 mount /dev/scsi/host0/bus0/target5/lun0/cd /cdrom 2) base system install aborted with following message on console 3: trying to overwrite /etc/default/devpts which is also in packages initscripts .. errors where encountered while processing .*libc6 also tried beta3, but this aborted even earlier in base-install with no error message while trying to install libgcrypt did a reinstall on clean partition and aboves error appeared again. manually installed all packages witch dpkg inside a chroot 3) at this stage i strongly missed a menu-entry for aboot at d-i!! from within the chroot one can't do much so i tried a recommendation from an srm howto (-> http://www.sgmltools.org/HOWTO/SRM-HOWTO/t182.html) did an # swriteboot /dev/sda bootlx vmlinux.gz (well different pathes .. but you got it) it asked for an -fi in order to overwrite the first empty partition, which was given. I eventually forgot to setup an /etc/aboot.conf the installation ended somehow miserably with a working debian install (had already an sshd inside) but without the possibility too boot inside this root partition :( i tried many possible root flags from within srm, but the kernel always failed to find the root partition (also tried boot root partition from cd). regards maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242659: d-i errors on alpha
On Fri, 09 Apr 2004, maximilian attems wrote: > the problem now was that the kernel panicked, because it couldn't find > it's root fs .. tried lots of bootargs from aboot forgot to mention that i used bsd disklabels to partition this harddisk .. had a first empty partition of 50 mb and the rest for root. regards maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242659: d-i errors on alpha
hey steve, thanks for your response and usefull bugs pointer! On Thu, 08 Apr 2004, Steve Langasek wrote: > > > 3) at this stage i strongly missed a menu-entry for aboot at d-i!! > > (!) I'll have to take a look at this; last I was able to test, aboot > showed up right where it was supposed to in the menu, you just can't get > it to run from the menu unless the base install has completed > successfully. 2 curious questions: * what is base install supposed to do .. beside dpkg -i the base deb? i had at this stage a working chroot with apt-get inside and could install sshd for example. * abootconf /dev/sda 2 showed some strange lseek error, (the machine is abootable .. had previously woody) swriteboot /dev/sda bootlx vmlinuz -f1 worked (modulo pathes for kernel and bootlx) at this stage i probably forgot to write a nice aboot.conf and the INSTALL file from aboot recommends to use swriteboot -c2 /dev/sda bootlx the problem now was that the kernel panicked, because it couldn't find it's root fs .. tried lots of bootargs from aboot root=/scsi/host0/bus0/target0/lun0/part2 .. or root=/dev/sda2 in combination with the initrd=/boot/initrd.gz arg. does a devfs=no help at that point ? tried also to boot via dka d-i cdrom or a woody rescue floppy disk .. regards maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242659: d-i errors on alpha
hello steve, thanks for the explanations. On Mon, 12 Apr 2004, Steve Langasek wrote: > If the base system has installed successfully (and it won't with current > images on alpha), the aboot installer should be run automatically. waiting for a bug closure for some more testing, on the mailinglist i saw an upload of a new kernel, so i hope the scsi bug is resolved. (allthough #237884 is still pending, marcelo added a stxcpy fix to 2.4.26-rc3 as did linus in current) > Can you be more specific regarding the "strange lseek error"? It sounds > below like aboot was successfully installed to your hard drive, so it > may not be a problem. the lseek error occurred while executing abootconf /dev/sda 2 after installing the debian packages out of /var/cache/apt/archives by hand inside the chroot and leaving it. (don't remember the exact wording .. but can retry nexttime) therefor used swriteboot to install aboot on the hard drive. > Did you specify an initrd option on your boot line? The kernels shipped > with Debian have only minimal filesystem support compiled in -- you will > need the initrd to be able to mount your root filesystem. used the initrd option but forgot to put a /etc/aboot.conf inside of this root filesystem perhaps thats fatal? regards maks signature.asc Description: Digital signature
RE: installation: apt-get fails for gcc-3.3 (trying to overwrite .../gcc-3.3-base/changelog.Debian.gz)
bug is resolved in todays gcc-3.3 see bug #268338. please report installation against package installation-reports. thanks. -- maks kernel janitor http://janitor.kernelnewbies.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Out-of-tree kernel module udeb
On Sun, May 17, 2015 at 01:36:53PM +0100, Ben Hutchings wrote: > On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote: > > > > At the moment only spl is available in the archive, using dkms, and > > > for zfs it's similar in the way of packaging though not uploaded yet. > > > What we have (code ready to go) is a mechanism that detects/gets > > > definition of a current KVERS and generate a source package with > > > dependencies and binary packages with names corresponding to it. > > > > > > What do you guys think? > > > > My personal stance on kernel related things would be “upstream first”. > > If it ain't going to be merged into mainline, or at least accepted as a > > patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure > > we want to support that. > > > > Cc-ing debian-kernel@ to see what they think. > > I strongly oppose adding OOT modules this way as a supposed workaround > for licence incompatibility. > this has been indeed our general conensus. we reject OOT modules or patchsets that have zero or near zero probability of getting merged upstream. -- maks signature.asc Description: Digital signature
Bug#242659: d-i errors on alpha
hello steve, thanks for your aboot infos. the changes to the debian alpha kernel i refer to is the announcment of linux-kernel-di-alpha_0.57_source+alpha.changes (linked that to a new kernel) http://lists.debian.org/debian-boot/2004/debian-boot-200404/msg01002.html from your wordings i assume that aboves probably is just another .config, but not new patches or source. > When you say "netboot cd", I think you mean net*inst* CD? Netboot means > to boot across the network, without a CD at all, and I'm pretty sure > this isn't working. :) uups yes, you are right of course ;) a++ maks signature.asc Description: Digital signature
Bug#251018: 20042525 install-report, minor glitches: serial console, lvm wishlist
Package: installation-reports INSTALL REPORT Debian-installer-version: daily i386 20040525 uname -a: Linux kourou 2.4.26-1-386 #2 Sat May 1 16:31:24 EST 2004 i686 GNU/Linux Date: 26. may 2004 ~11h Method: netboot.iso, not proxied via serial cable. Machine: AMD 800 with Via mainboard Processor: Memory: 128 mb Root Device: ide - Maxtor 81280A2 Root Size/partition table: root 90MB hda1, lvm2 1.1 GB hda5 (/home, /tmp, /usr, /var) Output of lspci and lspci -n: :00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) :00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) :00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 10) :00:07.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 10) :00:07.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 10) :00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) :00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 20) :00:09.0 Ethernet controller: 3Com Corporation 3c900B-TPO [Etherlink XL TPO] (rev 04) :00:0d.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02) :01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (rev 7a) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] 1) Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] 2) Comments/Problems: daily image very nice, seems quite close to a rc. some minor glitches or wishlists: 1) was my first time lvm usage on d-i: as shown above i wanted 2 partitions for the hard disc one for root and the other for lvm. * maybe i was to quick first, but i choose format the partion for both the partitions, had overseen the "use for lvm". when trying to configure lvm it let my do, but it had of course no physical volume! perhaps a check for a pv should be made before allowing volume groups to be made? * when deleting the lvm partition, the physical volume, all the already created volume/physical groups related to it won't be deleted. * a menu entry for "list volume/physical groups" would be very nice. at the moment you have to go to delete to see which you already created. 2) as my install was via serial cable i would appreciate that grub/lilo (used default grub) contain the boot args that were initially typed in: console=ttyS0,115200 on reboot they were lost thanks a lot for your work and good luck for rc1. a++ maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[PATCH] tasksel: add kerneloops to the 3 desktop tasks
From: maximilian attems <[EMAIL PROTECTED]> the debian kernel team enjoys feedback of the shipped quality. it has proven that kernelwise the desktop or laptop boxes are often problematic thus add kerneloops there. due to the size of kerneloops package it shouldn't be a problem. it defaults to not send info home, unless explicitly allowed. --- [ ooh i see bugreport already tagged as pending, so only sending in as doc, thanks -maks ] tasks/gnome-desktop |2 ++ tasks/kde-desktop |2 ++ tasks/xfce-desktop |2 ++ 3 files changed, 6 insertions(+), 0 deletions(-) diff --git a/tasks/gnome-desktop b/tasks/gnome-desktop index 0b4dfb5..188c419 100644 --- a/tasks/gnome-desktop +++ b/tasks/gnome-desktop @@ -69,3 +69,5 @@ Packages-list: # recommended by file-roller, useful for interop with windows arj p7zip +# feedback on linux-2.6 quality + kerneloops diff --git a/tasks/kde-desktop b/tasks/kde-desktop index a589d36..9e2e274 100644 --- a/tasks/kde-desktop +++ b/tasks/kde-desktop @@ -32,3 +32,5 @@ Packages-list: k3b-i18n # desktop network setup network-manager-kde +# feedback on linux-2.6 quality + kerneloops diff --git a/tasks/xfce-desktop b/tasks/xfce-desktop index e6be780..89d4877 100644 --- a/tasks/xfce-desktop +++ b/tasks/xfce-desktop @@ -30,3 +30,5 @@ Packages-list: xsane # gui for configuration of the print server foomatic-gui +# feedback on linux-2.6 quality + kerneloops -- 1.5.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
klibc 1.5.10
hello, please unblock klibc 1.5.10-1 was 10 days in unstable without trouble and fixes some utils. no lib changes itself. hpa just pushed out 1.5.11, i'd like to upload that tomorrow as several more nice to have fixes in nfsmount + sh4 support + ext4dev fstype. thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486815: tasksel: use brasero for cd burning
Package: tasksel Version: 2.74.2 Severity: normal Tags: patch both latest releases of fedora and ubuntu ship with brasero. it is much user friendlier then gnome-baker. it has active dev. althought not yet as feature complete as k3b it's main feature is the neat integration into the gnome desktop. also see this review -> http://www.linux.com/feature/126944 ps thanks for switching to git :) diff --git a/tasks/gnome-desktop b/tasks/gnome-desktop index 7ea013a..34d5b27 100644 --- a/tasks/gnome-desktop +++ b/tasks/gnome-desktop @@ -58,8 +58,8 @@ Packages-list: iceweasel-gnome-support # hardware browser, broader scope than hal hardinfo -# audio CD burning (data CDs handled by nautilus-cd-burner) - serpentine +# CD burning + brasero # desktop network setup network-manager-gnome # bluetooth applet for gnome -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-rc6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii aptitude 0.4.11.3-1 terminal-based package manager ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii liblocale-gettext-perl1.05-4 Using libc functions for internati ii tasksel-data 2.74.2 Official tasks used for installati tasksel recommends no packages. -- debconf information: tasksel/title: tasksel/desktop: gnome tasksel/first: tasksel/tasks: Print server -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switch to 2.6.25
On Mon, 23 Jun 2008, Otavio Salvador wrote: > Frans Pop <[EMAIL PROTECTED]> writes: > > > On Sunday 22 June 2008, Otavio Salvador wrote: > >> I've prepared a set of patches against current kernel-wedge to update > >> it. > > > > Thanks. > > > >> - ide-generic-pci > >> > >> I haven't add it since I found no reference about it being used by > >> other distros and then I prefer to still use ide-generic for now, > >> so near of release > > > > I'm still not sure about this one. Current support for ide-generic in D-I > > and initramfs-tools is far from perfect and could still be considered a > > regression from Etch. It could well be that ide-generic-pci fills an > > important gap here. We really should discuss this with the kernel team. > > Kernel Team, please give us some guidance on that. Should we use > ide-generic-pci or ide-generic? on my TODO, currently fjp has the best write up on the current situation. wanted to double check it and give it some thought ide-generic sucks^Wwins usually tooo often > >> cdrom-core-modules: add ide-cd_mod. > >> ide-modules: add ide-pnp. > > > > Some more explanation for these would be nice. Please remember that the > > changelog is not only _what_ you do, but also _why_ you do it. > > Looking again, I think we could skip ide-pnp. At least from the source > it looks to be ISA related and I think we doesn't need to include it > until we get complains about non-working systems. > > Kernel Team, any guidance here too? right yes forget isa for now. amicalement -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switch to 2.6.25
On Wed, Jun 25, 2008 at 11:16:23AM -0400, Lennart Sorensen wrote: > On Wed, Jun 25, 2008 at 03:42:55AM +0200, maximilian attems wrote: > > On Mon, 23 Jun 2008, Otavio Salvador wrote: > > > Kernel Team, please give us some guidance on that. Should we use > > > ide-generic-pci or ide-generic? > > > > on my TODO, currently fjp has the best write up on the current situation. > > wanted to double check it and give it some thought > > > > ide-generic sucks^Wwins usually tooo often > > But if you load it last, how can it win unless it finds something > nothing else supported? that there is *zero* point in having it loaded first. also win 95 killed ISA thankfully. gone dead. if someone really complains we can start wasting time there. sunny greetings -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switch to 2.6.25
this thread goes no where. loading a module on *all* boxes for 0.01% percent of the population is not the right thing to do. if you want some more informed statement read what fjp wrote down or come up with a fine patch. -- mask -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488238: tasksel: hotkey-setup draggs discover in
Package: tasksel Version: 2.74.2 Severity: normal Tags: patch hotkey-setup seems not ready for mass consumption, it recently added discover to it's dependency. [Julien Cristau] > Why do you care what X driver is going to be used? That sounds like > a bad hack??? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488095 please remove it from the corresponding tasks. Lenny should install fine everywhere and work *without* discover. diff --git a/tasks/desktop b/tasks/desktop index e463f8f..a268731 100644 --- a/tasks/desktop +++ b/tasks/desktop @@ -16,7 +16,6 @@ Key: iceweasel Packages: task-fields Packages-list: - hotkey-setup # the gimp is the best image editor, no matter the desktop gimp # openoffice.org is the best word processor / office suite at the moment diff --git a/tasks/laptop b/tasks/laptop index 9ce9498..931d805 100644 --- a/tasks/laptop +++ b/tasks/laptop @@ -25,7 +25,6 @@ Packages-list: cpufrequtils avahi-autoipd uswsusp - hotkey-setup bluetooth radeontool vbetool -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-rc6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii aptitude 0.4.11.4-1 terminal-based package manager ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii liblocale-gettext-perl1.05-4 Using libc functions for internati ii tasksel-data 2.74.2 Official tasks used for installati tasksel recommends no packages. -- debconf information: tasksel/title: tasksel/desktop: gnome tasksel/first: tasksel/tasks: Print server -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488238: tasksel: hotkey-setup draggs discover in
On Fri, 27 Jun 2008, Petter Reinholdtsen wrote: > [Maximilian Attems] > > hotkey-setup seems not ready for mass consumption, > > it recently added discover to it's dependency. > > Can you explain why adding a dependency on discover make it unfit for > mass consumption? afais the obnixious init script is gone. so i don't care too much, but there stems the strong arg against it. > > please remove it from the corresponding tasks. > > Lenny should install fine everywhere and work *without* discover. > > Why is it important to avoid discover in Lenny? > > The discover dependency was added to hotkey-setup to solve #483200, as > it was judged to be better than adding PCI ids directly in > hotkey-setup to work around the fact that /etc/X11/xorg.conf more and > more often will not include information about the X driver used. > > When this is said, there are rumors that the task done by hotkey-setup > now can be handled by hal/dbus instead. I have not verified that this > is true, but I have seen information under /usr/share/hal/fdi/ that > make me suspect it is correct. If hal/dbus do a better job of > handling the hotkeys, hotkey-setup should be removed from Debian. hotkeys are working just fine here with latest hal and without hotkey-setup on a x61s mostly running Lenny. best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2.6.25-2 testing sync
hello now that d-i released last beta that 2.6.25 state in unstable is fine, we'd want that backup option for the upcoming release in testing. please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2, linux-modules-extra-2.6 2.6.25-5 thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.25-2 testing sync
On Thu, Jul 03, 2008 at 02:20:58PM -0300, Otavio Salvador wrote: > maximilian attems <[EMAIL PROTECTED]> writes: > > > hello > > > > now that d-i released last beta that 2.6.25 state in unstable > > is fine, we'd want that backup option for the upcoming release > > in testing. > > > > please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2, > > linux-modules-extra-2.6 2.6.25-5 > > Please wait few more days until we get it properly done on sid (d-i > migrates to it). 2.6.26 is meant to come out soon. and it is about time to have 2.6.25 in testing. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Mon, Jul 07, 2008 at 05:30:09PM +0200, Frans Pop wrote: > (adding d-kernel and d-release) > > On Monday 07 July 2008, Otavio Salvador wrote: > > Frans Pop <[EMAIL PROTECTED]> writes: > > > On Thursday 03 July 2008, Otavio Salvador wrote: > > >> > please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2, > > >> > linux-modules-extra-2.6 2.6.25-5 > > >> > > >> Please wait few more days until we get it properly done on sid (d-i > > >> migrates to it). > > > > > > Why? We have never blocked migration of a new kernel when that wasn't > > > needed because of a D-I release. Uploading udebs and switching to a > > > kernel is not dependant on the migration. A new kernel can basically > > > migrate (from a D-I PoV) as soon as a release is out. > > > > Except that kernel team wants it to upload 2.6.26 to sid when it's > > released (probably this week) > > OK, then _that_ should be discussed, not the migration to testing. The two > are completely separate issues. > > In fact, having 2.6.25 in testing would possibly make it easier for the > kernel team to do a final (?) 2.6.25 upload with latest stable updates. > > There are valid arguments to be found for staying with 2.6.25 a bit > longer, but "D-I has not yet converted to it" is NOT one of them. testing users are currently on an unsupported kernel. > A much more important argument is that .25 has seen and will almost > certainly continue to get a lot more stabilization effort upstream than > is "normal" for upstream kernel releases because long term releases for > at least two important other distros are based on it. I doubt .26 will > get the same upstream attention. > Given the lack of capacity in Debian to do any real stabilization (cherry > picking/backporting of fixes from later releases) ourselves, that could > IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. > .26 also includes at least one change I know of that is somewhat risky: > PAT support for x86 (which could be disabled). disabled. > Se IMO we should take a real good look at .25 and .26 and check what's > new, what's important for Lenny and what's risky, and maybe check if some > things we do want could be backported. > > Delaying the upload of .26 to unstable could give us time, as a > distribution, to stay up to date with .25, see how things are going > with .26 and make a more informed decision. > > However, if the kernel team (together with maybe the release team) has > already decided on .26 for Lenny, then it would be better to get it into > unstable ASAP and for D-I to basically skip .25. .26 is the release kernel. so i'm happy with push on it. .25 is a possible backup. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: > * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: > > Changing kernel at this point of the release would be too destructive, > > so unless there is a big fat problem in the .25 that the .26 should fix > > and is unbackportable (does such a beast even exist ?) I'm rather > > opposed to it. Note that the asm/page.h mess is still not fixed thanks > > to hppa. > > > > Disclaimer: it's my own opinion, I did not check what other Release Team > > member think about this. > > I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. we have allways stated that .26 will be the release kernel. i don't understand why this would come as a surprise. .26 is to be released in a week, which is early enough to prepare all stuff including testing migration. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote:
> On Monday 07 July 2008, maximilian attems wrote:
> > > There are valid arguments to be found for staying with 2.6.25 a bit
> > > longer, but "D-I has not yet converted to it" is NOT one of them.
> >
> > testing users are currently on an unsupported kernel.
>
> Eh, how does that follow my last para which I assume you are commenting
> on, but which has nothing to do with testing?
>
> A side-note to your comment though...
>
> IMO testing kernel support is the weakest point in the current upload
> strategy by the kernel team. By uploading the next upstream release to
> unstable basically as soon as it's available upstream, Debian users (both
> unstable and testing) are frequently missing out on at least one or two
> upstream stable updates for the previous stable ("stable -1") release.
agreed on the week point, but not to your conclusions.
it often happens that d-i is blocking on older release.
like the beta that happened to want to stick to 2.6.22
which was a pure catastrophe, half a year too old, without
support for e1000e and newer intel boards..
> We worked around this for .24 by doing an upstream stable update through
> t-p-u.
dannf did and he is from the kernel team.
it was not a workaround, but again a stick to previous instead of
working forward.
> Upstream does seem to recognize the fact that a new release will need at
> least a few updates before it is actually "stable and usable", and will
> therefore do at least a few stable updates (for both "new stable"
> and "stable -1" in parallel). This basically happens in parallel to the
> new merge window (say the time to -rc2) and some upstream releases get
> "longer term" upstream stable support (.18, .22, .25).
.22 didn't stay long with us. this was said back then for .16 and
didn't matter on the long run.
> My personal opinion is that it would be better to delay the upload of new
> upstream releases to unstable until the .2 or maybe even .3 upstream
> stable update has become available. This would mean a bit more work for
> the kernel team, but I would expect that to be solvable.
don't see any point on that.
it wouldn't accelerate the meta package sort.
> That would also give more time for initial arch-specific and l-m-e issues
> for the new upstream to be worked out (e.g. in experimental) without
> breaking unstable too much. IMO a new kernel version should only be
> uploaded to unstable if kernel meta packages can be updated at roughly
> the same time.
this is a currently a week point, but unstable is the place to sort
such.
> It would also allow to upload a few more stable updates for "stable -1"
> and to migrate those to testing, giving testing users on average better
> support and it would give D-I some more "breathing space" to do releases.
>
> When a new stable *is* uploaded, D-I should be able to switch faster too
> (at least, if there's someone willing to do the initial kernel-wedge
> work) as the main criterium for D-I to switch to a new kernel version is:
> does the new version look about to be ready to migrate to testing, which
> current early uploads of the kernel to unstable effectively never are.
never seen that, d-i has always been dragging.
would wish that kmuto be an official d-i member. he even
tracks rc snapshot releases when necessary.
> > > A much more important argument is that .25 has seen and will almost
> > > certainly continue to get a lot more stabilization effort upstream
> > > than is "normal" for upstream kernel releases because long term
> > > releases for at least two important other distros are based on it. I
> > > doubt .26 will get the same upstream attention.
> > > Given the lack of capacity in Debian to do any real stabilization
> > > (cherry picking/backporting of fixes from later releases) ourselves,
> > > that could IMO be an important consideration for staying with .25 for
> > > Lenny.
> >
> > that doesn't matter a lot, if you look into our 2.6.18 or the RH patch
> > biest you'll notice the RH men force boot behind their backporting
> > machine.
>
> I'm having serious trouble parsing what you're trying to say here. Could
> you rephrase?
you never checked the rh kernel. they do a *lot* of backporting and
have a big team working on that. so you'll notice that none of those
patches landed in ours. so your argument sounds nice, but doesn't
help in practise.
.26 got a *lot* upstream attention and solves a number of .25 regressions.
it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless
improvements, allmost net namespaces and uvc cam support.
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote: > On Tue, Jul 08, 2008 at 06:59:40AM +0000, maximilian attems wrote: > > On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: > > > * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: > > > > Changing kernel at this point of the release would be too destructive, > > > > so unless there is a big fat problem in the .25 that the .26 should fix > > > > and is unbackportable (does such a beast even exist ?) I'm rather > > > > opposed to it. Note that the asm/page.h mess is still not fixed thanks > > > > to hppa. > > > > > > > > Disclaimer: it's my own opinion, I did not check what other Release Team > > > > member think about this. > > > > > > I agree with you, at least with my current informations. > > > > please read the changelog trunk on all the 2.6.26 fixes. > > Huh, that's not really our work, you as the maintainer should help us > understand why we would like to deal with 3 months of FTBFS *right now*. > Not to mention the libata changes fjp talks about, that would probably > break many upgrades and for which there is no known solution. right so the 2.6.26 summary: * closes 50 bugs on upload (mostly 2.6.25 regressions) * has upstream coordination with xen and openvz * is the first version with kernel debugger * much better laptop support (wireless, uvc,..) * kvm ported to IA64, PPC and S390 > > we have allways stated that .26 will be the release kernel. > > The sole mail from the kernel team that I can find is[0]. We've seen > no updates from you since AFAICT. Given the content of the mail, and its > age, I don't see how we can know that. right to debian-release that was the last time we got asked to give a statement. in discussion on d-kernel and with d-boot we allways stated to work on 2.6.26 for Lenny. > > I don't understand why this would come as a surprise. > > I'll start with reminding you that the toolchain is frozen and that > the kernel is part of it. > > Now could you explain how changing kernel for a new upstream, with the > well known fact that one needs to wait for the .2/.3 to have a decent > working kernel (IOW in at least 2/3 weeks after the release) is not a > disruptive change[1]? Add testing migration to that, plus tied > transitions, then I expect a really good rationale from you to explain > why a 6-8 weeks delay in the toolchain freeze (IOW in the release > process) is acceptable and needed[2]. a freeze exception for releasing debian with an uptodate and tuned system is worth. > [1] e.g. have you done full scale archive rebuilds to show that a new > linux-libc-dev won't at least cause dozens of FTBFS like the > 2.6.25 did ? there are statements from waldi and vorlon to consider the 2.6.25 linux-libc-dev status as frozen. kind regards -- maks ps fjp is wrong we don't switch to pata and are not forced to do so for 2.6.26, no idea, where he got that idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 03:27:17PM +0200, Pierre Habouzit wrote: > On Tue, Jul 08, 2008 at 12:43:49PM +0000, maximilian attems wrote: > > On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote: > > > On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: > > > > On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: > > > > > * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: > > > > > > Changing kernel at this point of the release would be too > > > > > > destructive, > > > > > > so unless there is a big fat problem in the .25 that the .26 should > > > > > > fix > > > > > > and is unbackportable (does such a beast even exist ?) I'm rather > > > > > > opposed to it. Note that the asm/page.h mess is still not fixed > > > > > > thanks > > > > > > to hppa. > > > > > > > > > > > > Disclaimer: it's my own opinion, I did not check what other Release > > > > > > Team > > > > > > member think about this. > > > > > > > > > > I agree with you, at least with my current informations. > > > > > > > > please read the changelog trunk on all the 2.6.26 fixes. > > > > > > Huh, that's not really our work, you as the maintainer should help us > > > understand why we would like to deal with 3 months of FTBFS *right now*. > > > Not to mention the libata changes fjp talks about, that would probably > > > break many upgrades and for which there is no known solution. > > > > right so the 2.6.26 summary: > > * closes 50 bugs on upload (mostly 2.6.25 regressions) > > I'm really afraid with the number of bugs it'll open though. upstream has much better control of it thanks to kernelopps, random .config boot tests and regression handling. > > * has upstream coordination with xen and openvz > > Does this mean that dom0 will work with .26 ? If yes, then maybe .26 > is really worth considering. If not, this is quite moot. we get snapshot working, that is *important* for guest. otherwise you would not be able to migrate your debian guest. and please don't dismiss openvz, which is the new emerging namespace solution that has more features then vserver and works actively on upstream merge. we have worked together with openvz devs to have .26 openvz images. > > * is the first version with kernel debugger > > * much better laptop support (wireless, uvc,..) > > * kvm ported to IA64, PPC and S390 of course a lot of fixes and forgot to mention the * Read-only bind mounts which can come in really handy for chroots and buildd. > > > > we have allways stated that .26 will be the release kernel. > > > > > > The sole mail from the kernel team that I can find is[0]. We've seen > > > no updates from you since AFAICT. Given the content of the mail, and its > > > age, I don't see how we can know that. > > > > right to debian-release that was the last time we got asked to give a > > statement. in discussion on d-kernel and with d-boot we allways stated > > to work on 2.6.26 for Lenny. > > Well, we did asked for updates from core teams in our mails to d-d-a > numerous times without our prior nagging, which was clearly meant to > avoid this kind of communication issues. > > For the rest I assume the release team will have to discuss things a > bit further. okay sorry for having not catched that. > > > [1] e.g. have you done full scale archive rebuilds to show that a new > > > linux-libc-dev won't at least cause dozens of FTBFS like the > > > 2.6.25 did ? > > > > there are statements from waldi and vorlon to consider the 2.6.25 > > linux-libc-dev status as frozen. > > Well, that's a sine qua non condition. L-L-Dev breakages are horrible, > and we just cannot aford one. It does not mean that I consider .26 to be > a clever idea right now, but a l-l-d breakage would be a plain no-go. sure fully agreeed. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 05:41:57PM +0300, Eugene V. Lyubimkin wrote: > maximilian attems wrote: > > * Read-only bind mounts > > > > which can come in really handy for chroots and buildd. > JFYI: recently 'bindfs' package was uploaded to Debian archive, it can > do it easily without new kernel. not at vfs level. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
imminent 2.6.26 sid upload
latest 2.6.25 stable release is in testing, we expect to keep it as backup plan for lenny. release team wishes to have unstable coverage of 2.6.26 before final ack on that release. the current release blocker is the linux-libc-dev patch by waldi that is reviewed by vorlon to keep the lenny build chain stable. shortlist of 2.6.26 features: * ro bind mounts, udf 2.50 * kgdb, kvm archs, better wireless drivers, uvcvideo * olpc, ps3 support * upstream coordination with xen and opevnz * lots of fixed 2.6.25 x86 regressions * request_firmware() work reenabling ip3, acenic and keyspan * arm, mips fixes * closing bunch of x86 regressions thanks to all -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: imminent 2.6.26 sid upload
On Tue, 22 Jul 2008, maximilian attems wrote: > the current release blocker is the linux-libc-dev patch by > waldi that is reviewed by vorlon to keep the lenny build chain stable. patch incorporating review got in. thanks waldi and vorlon! i'll announce upload of 2.6.26-1 for tomorrow, will hit NEW. currently open, but not blockers (they can be added on the way): - vserver for 2.6.26 - openvz on ia64 arch shall we give a README.Debian note on the vserser-xen flavour dropping? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
klibc unblock
please unblock klibc 1.5.12-1 it contains mostly gcc-4.3 fixes, even if not used for it's compilation would be good to have them in stable. also we have a grave packaging error in klibc, which causes signal() not to be exported, see that message http://marc.info/?l=util-linux-ng&m=121743832321246&w=2 thus i would have to upload 1.5.12-2 soonest. i'd prefer to have 1.5.12-1 before in testing. or shall i upload against 1.5.11-3 ?? best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
please unblock klibc 1.5.12-2
hello dannf,
please review belows diff between klibc 1.5.12-1 and 1.5.12-2,
added backport of upstream fix so that klibc exports signal(2)
+ corrected watch file.
thanks
--
maks
diff --git a/debian/changelog b/debian/changelog
index 8518eef..eb672c7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+klibc (1.5.12-2) unstable; urgency=medium
+
+ * Add backport 11_klibc-Default-signal-3-to-bsd_signal-3.patch.
+ * Adjust watch file.
+
+ -- maximilian attems <[EMAIL PROTECTED]> Mon, 11 Aug 2008 16:09:45 +0200
+
klibc (1.5.12-1) unstable; urgency=low
* New upstream release (memmove, fflush, cpio) (closes: #489945)
diff --git a/debian/patches/11_klibc-Default-signal-3-to-bsd_signal-3.patch
b/debian/patches/11_klibc-Default-signal-3-to-bsd_signal-3.patch
new file mode 100644
index 000..05a6f99
--- /dev/null
+++ b/debian/patches/11_klibc-Default-signal-3-to-bsd_signal-3.patch
@@ -0,0 +1,97 @@
+From 40a8a74d148297bc029aafab844c3845fbe10186 Mon Sep 17 00:00:00 2001
+From: H. Peter Anvin <[EMAIL PROTECTED]>
+Date: Wed, 30 Jul 2008 14:04:34 -0700
+Subject: [PATCH] klibc: Default signal(3) to bsd_signal(3)
+
+The Linux universe, at least, seems to have settled on BSD semantics
+for signal(3) -- even though signal(2) implements SysV semantics.
+POSIX has gone from mandating SysV semantics to permitting either.
+
+Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
+---
+ usr/include/signal.h |3 +++
+ usr/klibc/CAVEATS | 12 +---
+ usr/klibc/bsd_signal.c |3 +++
+ 3 files changed, 7 insertions(+), 11 deletions(-)
+
+diff --git a/usr/include/signal.h b/usr/include/signal.h
+index bb6b470..a513282 100644
+--- a/usr/include/signal.h
b/usr/include/signal.h
+@@ -88,6 +88,9 @@ static __inline__ int sigismember(sigset_t * __set, int
__signum)
+ }
+
+ __extern __sighandler_t __signal(int, __sighandler_t, int);
++#ifndef signal
++__extern __sighandler_t signal(int, __sighandler_t);
++#endif
+ __extern __sighandler_t sysv_signal(int, __sighandler_t);
+ __extern __sighandler_t bsd_signal(int, __sighandler_t);
+ __extern int sigaction(int, const struct sigaction *, struct sigaction *);
+diff --git a/usr/klibc/CAVEATS b/usr/klibc/CAVEATS
+index 02b9b9e..2cead70 100644
+--- a/usr/klibc/CAVEATS
b/usr/klibc/CAVEATS
+@@ -4,7 +4,6 @@
+
+ optimization:
+ -
+-
+ Compiling with -O0 is not supported. It may or may not work; please
+ use -O1 if you want to do maximize debuggability.
+
+@@ -13,7 +12,6 @@ Compiling with -O0 is more likely to work on gcc 3.
+
+ setjmp()/longjmp():
+ ---
+-
+ setjmp() and longjmp() *do not* save signal state. sigsetjmp() and
+ siglongjmp() *do* save the signal mask -- regardless of the value of
+ the extra argument.
+@@ -27,7 +25,6 @@ value of 0 you get what you deserve -- setjmp() will happily
return 0.
+
+ stdio:
+ --
+-
+ Only a small subset of the stdio functions are implemented. Those
+ that are implemented do not buffer, although they *do* trap EINTR or
+ short read/writes and iterate.
+@@ -38,23 +35,16 @@ read/write), but do handle EINTR/short return are also
available.
+
+ namespaces:
+ ---
+-
+ klibc frequently includes headers in other headers in a way that
+ exposes more symbols than POSIX says they should. "Live with it."
+
+
+ theading:
+ -
+-
+ klibc is not thread-safe. Consequently, clone() or any of the
+ pthreads functions are not included.
+
+
+ bsd_signal vs sysv_signal:
+ --
+-
+-There is no signal() call, because you never know if you want
+-Linux/SysV semantics (SA_RESETHAND) or GNU/BSD semantics (SA_RESTART).
+-The best, in *any* circumstances, is to never use signal() and instead
+-use sigaction(), but in order to simplify porting you can use either
+-sysv_signal() or bsd_signal(), depending on what you actually want.
++signal() now defaults to bsd_signal().
+diff --git a/usr/klibc/bsd_signal.c b/usr/klibc/bsd_signal.c
+index 4e6238c..3d78d2c 100644
+--- a/usr/klibc/bsd_signal.c
b/usr/klibc/bsd_signal.c
+@@ -9,3 +9,6 @@ __sighandler_t bsd_signal(int signum, __sighandler_t handler)
+ /* BSD signal() semantics */
+ return __signal(signum, handler, SA_RESTART);
+ }
++
++__sighandler_t signal(int signum, __sighandler_t handler)
++ __alias("bsd_signal");
+--
+1.5.6.3
+
diff --git a/debian/watch b/debian/watch
index d64ec30..aee5d4e 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,2 @@
version=3
-http://www.kernel.org/pub/linux/libs/klibc/klibc-([0-9].[0-9]+).tar.bz2
+http://www.kernel.org/pub/linux/libs/klibc/Testing/klibc-([0-9].[0-9].[0-9]+).tar.bz2
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402746: undefined reference to __FD_ZERO and __FD_SET
reassign rootskel stop On Tue, 12 Dec 2006, sferriol wrote: > Package: libklibc-dev > Version: 1.4.30-2 > Severity: normal > > in d-i, building rootskel/src-bootfloppy/bin/timeout_read.c failed on > alpha, amd64, ia64, s390 > undefined reference to '__FD_ZERO' > undefined reference to '__FD_SET' > > sylvain > wtf are you poking around in internal kernel routines. the double underscore should be a warning enough. __FD_SET and __FD_ZERO are found in __KERNEL__ sections of posix_types.h -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-9
On Fri, Dec 15, 2006 at 06:08:08PM +0100, Frederik Schueler wrote: > > If you have any last minute changes which are that important they cannot > wait for the first point release kernel, please list them here so we can > discuss them. - 2.6.16.X backports that are missing in 2.6.18. - latest 2.6.18 breaks swsusp on x41 (not critical but bad) - there are lots of unreviewed/unresponded bug reports against 2.6.18 might need more team engangement on that front regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-9
On Wed, Dec 20, 2006 at 02:50:59PM +0100, Norbert Tretkowski wrote: > * Frederik Schueler wrote: > [...] > > The upload should be scheduled for Tuesday, unless someone vetoes. > > Is there a new schedule already? > > Norbert waiting for the upstream mm fix.. or in the improbable case of no fix the revert should be folded in the abi breakage. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vacation - status of partman-crypto / cryptsetup
On Mon, 18 Dec 2006, David Härdeman wrote: > Conclusion: provided that the two reports above are indeed > unreproducible, that 2:1.0.4+svn16-2 in unstable migrates to > testing, and that klibc-utils >= 1.4.30-2 migrates, cryptsetup should > be fine. that is expected to happen soonest. happy christmas -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-9
hi, quick update on current linux-2.6 state. On Fri, 15 Dec 2006, Frederik Schueler wrote: > I would like to schedule the upload of the next linux-2.6 2.6.18 > version, with the following changes: > > 1. new vserver patch, breaks ABI > 2. new Xen patch > 3. Activate PAE on i386 Xen subarch, breaks ABI > 4. arm changes > 5. 2.6.18.5 ABI breaking patch (Honour source routing for LVS-NAT) > - 2.6.16.X backports that are missing in 2.6.18. > - patch to fix cciss for external devices > - 2.6.18.6 stable series patches > - r8169 speed troubles > - mm alternative msync() fix seems all done inbetween, but needs testing and test-builds. > - latest 2.6.18 breaks swsusp on x41 (not critical but bad) works, must have been bad luck that day current open issues (please add if you know more): - bcm43xx ?backports? - hp amd64 acpi blacklists -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-9
heya, On Tue, Jan 02, 2007 at 07:38:38PM -0800, Steve Langasek wrote: > On Sat, Dec 30, 2006 at 10:36:32AM +0100, maximilian attems wrote: > > On Fri, 15 Dec 2006, Frederik Schueler wrote: > > > - mm alternative msync() fix this is beeing tested for lsb compliance, once there is an ok for it, i agree that we should upload soonest. > > current open issues (please add if you know more): > > - bcm43xx ?backports? > > - hp amd64 acpi blacklists > > I don't see any follow-ups from anyone adding more. How about these two > issues in particular -- is there any progress on them, or is any help > needed? well as you probably know there are different wireless stacks around. bcm43xx main dev does not happen with the one that is currently used in the stock kernel so this is a bit of a red herring and afaik not resolved upstream until alternative stack is due to be merged.. according to sjoerd bcm43xx troubles happen lot less often. have checked latest git state and didn't see meaningfull patches that we miss, but i might be wrong and have no test box myself. the acpi blacklist is just a matter of doing it for my laptop seeing that acpi is disabled and then doing a similar patch for this kind of laptops. if someone wants to chimme in feel free. we have collected all the relevant dmidecode output. happy day -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373621: Bug#334104: tagging wontfix
tags 334104 -wontfix tags 334104 pending thanks morning jurij, On Thu, Jan 04, 2007 at 10:36:12PM -0800, Jurij Smakov wrote: > tag 373621 wontfix > thanks > > My attempt to actually do something about this ancient bug (#334104) > has been blocked by Bastian Blank, who considers the proposed patch to > violate the patch acceptance policy. As I don't feel like wasting my > breath arguing about it, the best thing I can do is tag this bug > wontfix, in hope that the debian-installer people will be able to > provide some alternative solution. well i considered your patch to be a fine distro specific workaround. now i've gone another way and disabled the dup pci-id's in tulip for i386. afaik dmfe.ko explodes on parisc. so you could do the inverse for sparc. ideally dmfe and tulip shouldn't pretend to work for chipsets they can't, but that codebase won't get fixed in time for the etch release. happy day -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373621: Bug#334104: tagging wontfix
On Fri, Jan 05, 2007 at 10:50:26PM -0800, Jurij Smakov wrote: > > As I said, I don't think the solution of dropping the duplicate PCI > IDs in different drivers for different architectures to be optimal. > There is always a possibility that someone will insert an arbitrary > PCI card into any box with a PCI bus. If currently the user will be > slightly inconvenienced, if your proposed solution is implemented, > he/she will have to rebuild the kernel to get it to work. well afaik my proposal is just mirroring discover1 knownledge, so it shouldn't be far off. also having heard of the doubtful quality of dmfe on hppa, i doubt it does any good on sparc.. > Anyway, Frans Pop has recently posted a proposed patch for the > installer, which will make it possible to blacklist and arbitrary > module from loading, see > > http://lists.debian.org/debian-boot/2007/01/msg00207.html > > If this will make it into etch, that will solve the problem. well this require an intelligent monkey booting d-i.. ;-) happy weekend -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#280768: install on a vaio
Package: installation-reports INSTALL REPORT Debian-installer-version: netinstall 11. november http://cdimage.debian.org/pub/cdimage-testing/daily/i386/20041110/sarge-i386-netinst.iso uname -a: Linux axion 2.4.27-1-686 #1 Fri Sep 3 06:28:00 UTC 2004 i686 GNU/Linux Date: Thu Nov 11 16:06:58 CET 2004 Method: boot from cd, no proxy, static network. Machine: sony vaio Processor: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 744.467 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1484.39 Memory: total:used:free: shared: buffers: cached: Mem: 130179072 126062592 41164800 10338304 68059136 Swap: 19987333120 1998733312 MemTotal: 127128 kB MemFree: 4020 kB MemShared: 0 kB Buffers: 10096 kB Cached: 66464 kB SwapCached: 0 kB Active: 37880 kB Inactive:54656 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 127128 kB LowFree: 4020 kB SwapTotal: 1951888 kB SwapFree: 1951888 kB Root Device: hda Root Size/partition table: /dev/hda3 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw) /dev/hda4 on /mnt type ext2 (rw) table, with notes on which partitions are mounted where. Output of lspci and lspci -n: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] Comments/Problems: worked like a charm :) thanks wishlists: * hint on howto choose your partition in partman. first time users stumble.. list not evident as list in the template. * going back from grub screen should not automatically lower debconf priority as some user prefer lilo (known configs, old habits,..) -- maks kernel janitor http://janitor.kernelnewbies.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Usability test: Debian Installation on a laptop
1 Description of the test a) Short description of the test user The male user is a 35 year old theoretical physics professor. He is also the system administrator of this physics institute. b) Short description of the test setup Netinstall CD on quick university lan with no proxy, static networking. Box is a common sony laptop. After second stage most done through ssh via users workstation. hardware details in #280768. 2 Question on the test user about his level of experience a) Debian Linux experience of the test user system administrator of ~70 Debian workstations + some server. b) Free software experience of the test user daily use of fvwm, tex, vi, dselect, .. d) Expectations regarding Debian easy upgrade and maintenance (paid for doing physics). e) Expectations of the Debian-installer (short d-i) bad, as failed on his first try when d-i switched to partman. 3 d-i installation manual. no remarks as not consulted. 4 The installation process with d-i The test user chooses english, as country austria, german as keyboard layout. Surprised that d-i already knows that his network has no dhcp. Enters Network configuration and is once more surprised that d-i knows the hostname and domainname. User already seems pleased about d-i! The partitioner comes up with the choice of erasing the hard disc or to manually edit the partition table. Later is chosen. User takes a bit of a time to realise how to choose the partition. No hint on the template related to the key. User press . (blind guess and it works). The 3 partition is chosen to be ext3 and /. seconds later the user is prompted for grub. the user prefers lilo so chooses go back. lilo is placed on mbr. second stage works quick. user doesn't choose anything in tasksel. he prefers known dselect. ;) user resets debconf to high, wonders a bit why it got medium!? (lilo choice - reported as wishlist in installation-report). installs xserver and the rest of his known stuff from his workstation. as the default for the xserver is not to choose the autodetection and he knowns anyway the graphics card - this path is choosen. 5. Conclusions The d-i templates provided either good information or already good defaults for a user with debian experience. The user is very charmed by d-i and happy that the sarge installer does such a good job. woody getting old for the desktops setups (mozilla, gnome/kde, no openoffice) he is very confident in sarge. Although he would prefer to have better xfree integration in the hardware detection of d-i. comment: "Things gotten better since the 30 diskette installs on 386." -- maks kernel janitor http://janitor.kernelnewbies.org/ ps this is a follow up to a previous d-i usability test, *) which featured a novice debian user. will do so from time to time when a d-i install pops up in my env. *) http://lists.debian.org/debian-boot/2004/09/msg01737.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[patch] debian-manual simplify dhcpd pxe sample conf
the example snippet for pxe use is quite complicated.
belows simplified config works for me and is greatly inspired by
-> http://wiki.debian.net/index.cgi?DebianInstallerBootpTFTP
yourfoobar may guide newbies like me. :-)
--
maks
Index: installer/doc/manual/en/install-methods/tftp/dhcp.xml
===
--- installer/doc/manual/en/install-methods/tftp/dhcp.xml (revision 24001)
+++ installer/doc/manual/en/install-methods/tftp/dhcp.xml (working copy)
@@ -63,10 +63,11 @@
-option domain-name "example.com";
+option domain-name "yourdomain.org";
+option domain-name-servers yournameserver.org;
-default-lease-time 6048;
-max-lease-time 604800;
+default-lease-time 600;
+max-lease-time 7200;
allow booting;
allow bootp;
@@ -74,30 +75,17 @@
# The next paragraph needs to be modified to fit your case
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.200 192.168.1.253;
- option subnet-mask 255.255.255.0;
- option broadcast-address 192.168.1.255;
+# tftp server ip address
+ next-server 192.168.1.90;
# the gateway address which can be different
# (access to the internet for instance)
option routers 192.168.1.1;
-# indicate the dns you want to use
- option domain-name-servers 192.168.1.3;
-}
-
-host tftpserver {
-# tftp server ip address
- fixed-address 192.168.1.90;
+ filename "/tftpboot/pxelinux.0";
+ host tftpserver {
# tftp server hardware address
hardware ethernet 01:23:45:67:89:AB;
}
-group {
- next-server 192.168.1.3;
- host tftpclient {
-# tftp client hardware address
- hardware ethernet 00:10:DC:27:6C:15;
- filename "/tftpboot/pxelinux.0";
- }
-}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[patch] debian-manual add xinetd snippet for tftpd
belows patch adds a note about how to start tftpd from xinetd.
--
maks
Index: installer/doc/manual/en/install-methods/install-tftp.xml
===
--- installer/doc/manual/en/install-methods/install-tftp.xml(revision 24001)
+++ installer/doc/manual/en/install-methods/install-tftp.xml(working copy)
@@ -91,8 +91,27 @@
Debian packages will in general set this up correctly by default when they
-are installed.
+are installed. But if you are using xinetd, you may need to
add the following snippet in /etc/xinetd.conf:
+
+
+
+service tftp
+{
+disable = no
+ socket_type = dgram
+ protocol= udp
+ wait= yes
+ user= root
+ server = /usr/sbin/in.tftpd
+ flags = IPv4
+}
+
+
+
+
+Restart afterwards the xinetd with
/etc/init.d/xinetd restart.
+
Look in that file and remember the directory which is used as the
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[patch] debian-manual pxe boot add small hint
belows patch adds a small hint where to find that tftp boot. perhaps it makes user more confident. ;-) but maybe to specific, maybe just added without the last phrase with special case? i leave it up to you. -- maks Index: installer/doc/manual/en/boot-installer/i386.xml === --- installer/doc/manual/en/boot-installer/i386.xml (revision 24001) +++ installer/doc/manual/en/boot-installer/i386.xml (working copy) @@ -295,7 +295,8 @@ PXE boot functionality. This is a Intel re-implemention of TFTP boot. If so you may be able to configure your BIOS to boot from the -network. +network. Watch out Bios messages for Network boot. They may tell you which +hot key enables it. Newer boards often use . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [patch] debian-manual add xinetd snippet for tftpd
On Sat, 27 Nov 2004, Geert Stappers wrote: > On Fri, Nov 26, 2004 at 11:05:19PM +0100, maximilian attems wrote: > > belows patch adds a note about how to start tftpd from xinetd. > > > > -- > > maks > > > > Thanks, but didn't I see just a patch about simply things? > > > Geert Stappers well having a config to paste simplifies things. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [patch] debian-manual pxe boot add small hint
On Sat, 27 Nov 2004, Geert Stappers wrote: > On Fri, Nov 26, 2004 at 11:05:38PM +0100, maximilian attems wrote: > > belows patch adds a small hint where to find that tftp boot. > > perhaps it makes user more confident. ;-) > > > > but maybe to specific, maybe just added without the last phrase > > with special case? i leave it up to you. > > The "F12" seems indeed some kind of standard. ok, so better add this hint properly. :-) > > -- > > maks > > > > > > Index: installer/doc/manual/en/boot-installer/i386.xml > > === > > --- installer/doc/manual/en/boot-installer/i386.xml (revision 24001) > > +++ installer/doc/manual/en/boot-installer/i386.xml (working copy) > > @@ -295,7 +295,8 @@ > > PXE boot functionality. > > This is a Intel re-implemention > > of TFTP boot. If so you may be able to configure your BIOS to boot from the > > -network. > > +network. Watch out Bios messages for Network boot. They may tell you which > > +hot key enables it. Newer boards often use . > +hot key enables it. Newer boards often use <F12>. > > > Or something else to get it through the XML parser. yup. > > > > > > > > Maks, > > Your feedback is appricated. > Please don't feel offended that I didn't accept your patches. i do not care about my patches, as long the manual gets better. as a first time tftp user i wanted to send feedback on the relevant parts. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [patch] debian-manual simplify dhcpd pxe sample conf
On Sat, 27 Nov 2004, Geert Stappers wrote:
> On Fri, Nov 26, 2004 at 11:05:02PM +0100, maximilian attems wrote:
> > the example snippet for pxe use is quite complicated.
> > belows simplified config works for me and is greatly inspired by
> > -> http://wiki.debian.net/index.cgi?DebianInstallerBootpTFTP
> >
> > yourfoobar may guide newbies like me. :-)
> >
> > --
> > maks
> >
> >
> > Index: installer/doc/manual/en/install-methods/tftp/dhcp.xml
> > ===
> > --- installer/doc/manual/en/install-methods/tftp/dhcp.xml (revision 24001)
> > +++ installer/doc/manual/en/install-methods/tftp/dhcp.xml (working copy)
> > @@ -63,10 +63,11 @@
> >
> >
> >
> > -option domain-name "example.com";
> > +option domain-name "yourdomain.org";
> > +option domain-name-servers yournameserver.org;
> DNS
> > -default-lease-time 6048;
> > -max-lease-time 604800;
> > +default-lease-time 600;
> > +max-lease-time 7200;
> the longer times are fine
shure but also pretty useless and aboves values are the one
from the default config.
> > allow booting;
> > allow bootp;
> > @@ -74,30 +75,17 @@
> > # The next paragraph needs to be modified to fit your case
> > subnet 192.168.1.0 netmask 255.255.255.0 {
> >range 192.168.1.200 192.168.1.253;
> > - option subnet-mask 255.255.255.0;
> > - option broadcast-address 192.168.1.255;
> > +# tftp server ip address
> > + next-server 192.168.1.90;
> > # the gateway address which can be different
> > # (access to the internet for instance)
> >option routers 192.168.1.1;
> > -# indicate the dns you want to use
> > - option domain-name-servers 192.168.1.3;
> ^^^DNS
>
>
> You moved the DNS entry
> and asume a proper working DNS for the DHCP server.
> ( I don't like IP address neither in config files,
> but it's "advantage" is that it don't need DNS )
ok thanks for the hint, yes on the networks that i administer
i assume a working dns. glad to hear d-i doesn't..
anyway i still think that aboves dhcp entry is overcrafted
and that the one in the wiki gives you nice results.
> > -}
> > -
> > -host tftpserver {
> > -# tftp server ip address
> > - fixed-address 192.168.1.90;
> > + filename "/tftpboot/pxelinux.0";
> > + host tftpserver {
> > # tftp server hardware address
> >hardware ethernet 01:23:45:67:89:AB;
> > }
> >
> > -group {
> > - next-server 192.168.1.3;
> > - host tftpclient {
> > -# tftp client hardware address
> > - hardware ethernet 00:10:DC:27:6C:15;
> > - filename "/tftpboot/pxelinux.0";
> > - }
> > -}
>
> That is deleting the client it is all about.
well this entry got pushed up!
i agree that patches are not always easy readable.
> >
> >
>
> Please change the wiki
no i won't for shure as it's config is much easier to implement
and works for lots of people.
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel & installer issues discussion at debconf
hello, On Tue, May 16, 2006 at 06:11:53AM +0200, Andreas Barth wrote: > > I just want to point out that we have at Tuesday, 10.05 in the Hacklab > the stable release BoF, which will give us a chance to discuss that > topic. (Thanks to Frans for pointing out how usefull such a pointer > would be. :) ok, please take into account for remote participants the responses to the thread "which kernel version for etch?" on d-kernel. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
initramfs-tools confdir mv
latest initramfs-tools mv /etc/mkinitramfs /etc/initramfs-tools for better consistency. (package on mentors not yet in unstable) d-i uses in base-installer as confdir /target/etc/mkinitramfs/ in postinst. how should the transition happen? could we coordinate an base-installer upload with newer initramfs-tools 0.61? thanks for your input and sorry for the trouble should only happen once to have it settled for the etch release. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-tools confdir mv
On Wed, 24 May 2006, Bastian Blank wrote: > On Mon, May 22, 2006 at 09:04:11AM +0200, maximilian attems wrote: > > latest initramfs-tools mv /etc/mkinitramfs /etc/initramfs-tools > > for better consistency. (package on mentors not yet in unstable) > > Just a plain NACK. It moves files around which don't belongs to the > package, it don't takes care about upgrades where another package > already put files into /etc/initramfs-tools, which is not forbidden. i don't know of a package that puts file there yet? if they do content should still be on the initramfs as intended. will add an NEWS.Debian entry in 0.62 that warns about the move. as all my installs use default, i hadn't tested the modified conf setting, which could potentially reprompt the user. will do so. thanks to jbailey for pointing that out. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-tools confdir mv
On Wed, 24 May 2006, Joey Hess wrote: > maximilian attems wrote: > > latest initramfs-tools mv /etc/mkinitramfs /etc/initramfs-tools > > for better consistency. (package on mentors not yet in unstable) > > > > d-i uses in base-installer as confdir /target/etc/mkinitramfs/ > > in postinst. how should the transition happen? > > could we coordinate an base-installer upload with newer > > initramfs-tools 0.61? > > base-installer can be modified to write to /etc/initramfs-tools if the > directory exists and fall back to the old /etc/mkinitramfs/modules > otherwise. Here's the patch that should do that (untested): woow already discovered it in svn trunk + unstable :) > Index: debian/postinst > === > + initramfs-tools) > + ramdiskconf=/target/etc/mkinitramfs/initramfs.conf > + ;; > + yaird) > + ramdiskconf= > + ;; > + initrd-tools) > + if [ -d /target/etc/initramfs-tools ]; then > + > ramdiskconf=/target/etc/initramfs-tools/mkinitrd.conf > + else > + # old location > + ramdiskconf=/target/etc/mkinitrd/mkinitrd.conf > + fi > + ;; belows patch fixes the correct tools dir choice. a bit annoyed by svn diff, i did _not_ touch the yaird entry. thanks a lot for the quick support. Index: debian/postinst === --- debian/postinst (revision 37758) +++ debian/postinst (working copy) @@ -673,19 +673,19 @@ # Figure out how to configure the ramdisk creation tool. case "$package" in initramfs-tools) - ramdiskconf=/target/etc/mkinitramfs/initramfs.conf - ;; - yaird) - ramdiskconf= - ;; - initrd-tools) if [ -d /target/etc/initramfs-tools ]; then ramdiskconf=/target/etc/initramfs-tools/mkinitrd.conf else # old location - ramdiskconf=/target/etc/mkinitrd/mkinitrd.conf + ramdiskconf=/target/etc/mkinitramfs/initramfs.conf fi ;; + yaird) + ramdiskconf= + ;; + initrd-tools) + ramdiskconf=/target/etc/mkinitrd/mkinitrd.conf + ;; *) db_subst base-installer/initramfs/unsupported GENERATOR "$package" exit_error base-installer/initramfs/unsupported -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: swap on a LVM volume in debian-installer
On Thu, Jun 22, 2006 at 10:46:59PM +0200, David Härdeman wrote: > > I'm currently considering whether to change partman-auto-lvm so that the > swap partition is created as a lvm lv rather than a separate partition, > and I'd like to ask for some comments and feedback before doing so. ack. cool, already using since long, as swap on lvm allows much more flexibility. > o suspend-to-disk > There have been concerns that suspend/resume may not work with swap on a > lvm volume. > > Using initramfs-tools, it seems perfectly possible to resume from a swap > partition on lvm (I do so daily). I am not sure whether yaird supports > this feature. works right now fine on initramfs-tools. thanks for addressing the trouble of multiple volume groups. good work. :) -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
initramfs-tools 0.7x pending changes - klibc only initramfs
heya, :) klibc 1.4.11 has almost all binaries (kill, mknod, resume) initramfs-tools 0.70 needs to successfully boot. thus it is envisaged to deliver for etch an klibc only default initramfs. the following steps are needed to ensure that decision: - klibc-utils missing bin: readlink (minimal already present in my klibc tree, will be soon pushed upstream), needed to kill udevd. - hooks for other packages: evms and mdadm got merged, lvm2 is in preparation - prereqs mechanism: uses costly boot time and there is no easy solution to be first nor to be last. proposed solution is to remove it plainly. (scripts that don't use wouldn't be affected, as prereqs only enters in the game if you invoke the script with the `prereqs' arg) the proposed simple solution would be do use numerical precedences, aka a simple 05evms 10mdadm 20lvm 90cryptsetup (example for scripts/local-top/ dir) thus the complex prereqs mechanism would be replaced by for s in dir/*; do $s done thus package maintainers would need to rename their scripts according aboves. - fallback shell klibc provides dash. dash works fine for all used busybox ash functionability - busybox dependency once aboves steps are done, can be changed in a Suggests. BUSYBOX=n would be the default in initramfs.conf several initramfs-tools hook scripts need busybox functionality. to the mind comes lvm2, mdadm and cryptsetup hooks. they would need to add a dependency to: busybox (>= 1:1.01-3) | busybox-cvs-static (>= 20040623-1) and they would have to ship a file in /usr/share/initramfs-tools/conf.d/ with BUSYBOX=y mkinitramfs would than include the busybox in initramfs-tools. it would use the busybox shell and allow usage of it's tools. an alternative would be busybox on klibc, but for that klibc is not yet powerful enough and that is not a realistic goal for etch. - against klibc compiled bin udev and module-init-tools would have to be compiled against klibc. tested udev atm and it works. as simple as build-dep libklibc-dev and pass CC=klcc that would allow an klibc based initramfs as asked for embedded Debian targets. smaller initramfs is quicker unpacked and the dropping of the prereqs should speed up boot. thanks for your input -- maks ps for d-i bootfloppies klibc-utils needs an ramdisk_load that will be worked on once aboves is sorted. pps adding package maintainers on cc which either have initramfs-tools hooks or were addition is envisaged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378984: fstab default /proc entry nosuid
Package: partman-target Version: 44 Severity: normal Tags: patch please apply belows patch, to add the /proc line to fstab with nosuid. rationale: setuid and setgid bits have nothing lost in /proc, nice workaround for kernel /proc vulnerability, see suggested at the lwn.net article: http://lwn.net/SubscriberLink/191954/dfb24a687f9b032e/ Index: finish.d/create_fstab_header === --- finish.d/create_fstab_header(revision 39223) +++ finish.d/create_fstab_header(working copy) @@ -9,4 +9,4 @@ printf "%-15s %-15s %-7s %-15s %-7s %s\n" '# ' '' '' '' '' '' >> /target/etc/fstab -printf "%-15s %-15s %-7s %-15s %-7s %s\n" proc /proc proc defaults 0 0 >> /target/etc/fstab +printf "%-15s %-15s %-7s %-15s %-7s %s\n" proc /proc proc defaults,nosuid 0 0 >> /target/etc/fstab -- maks -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-tools 0.7x pending changes - klibc only initramfs
On Wed, 19 Jul 2006, maximilian attems wrote: > > - prereqs mechanism: > uses costly boot time and there is no easy solution to be first > nor to be last. proposed solution is to remove it plainly. > (scripts that don't use wouldn't be affected, as prereqs only > enters in the game if you invoke the script with the `prereqs' arg) > > the proposed simple solution would be do use numerical precedences, > aka a simple > 05evms 10mdadm 20lvm 90cryptsetup (example for scripts/local-top/ dir) > thus the complex prereqs mechanism would be replaced by > for s in dir/*; do > $s > done > thus package maintainers would need to rename their scripts according > aboves. addition: discussed that shortly with Keybuk, and jbailey's arg that the initramfs is supposed to be runtime assembled takes precendence. using parameter expansion instead of basename for prereqs for 0.71. so prereqs will stay for etch. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379494: add gthumb to the gnome task
Package: tasksel Version: 2.50 Severity: minor Tags: patch gthumb is a much better image viewer than eog. found it missing on latest gnome-desktop install of daily snapshot. --- tasksel-2.50/tasks/gnome-desktop.orig 2006-07-23 23:17:30.0 +0200 +++ tasksel-2.50/tasks/gnome-desktop2006-07-23 23:17:54.0 +0200 @@ -50,3 +50,5 @@ Packages-list: firefox-gnome-support # hardware browser, broader scope than hal hardinfo +# fine image viewer + gthumb -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages tasksel depends on: ii aptitude 0.4.1-1.1 terminal-based apt frontend ii debconf [debconf-2.0] 1.5.2 Debian configuration management sy ii liblocale-gettext-perl1.05-1 Using libc functions for internati ii tasksel-data 2.50 Official tasks used for installati tasksel recommends no packages. -- debconf information: tasksel/title: tasksel/first: Laptop, Standard system tasksel/tasks: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379485: preseed exim4 template for desktop+laptop class to local delivery
Package: tasksel Version: 2.50 Severity: wishlist rationale: either webmail or pop3/imap via thunderbird/evolution are the highest probable case for laptop+desktop user. expert user will want anyway better configurability of the exim4 configs. exim4, popularity-contest and xorg warning were the only templates that prompted irc. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages tasksel depends on: ii aptitude 0.4.1-1.1 terminal-based apt frontend ii debconf [debconf-2.0] 1.5.2 Debian configuration management sy ii liblocale-gettext-perl1.05-1 Using libc functions for internati ii tasksel-data 2.50 Official tasks used for installati tasksel recommends no packages. -- debconf information: tasksel/title: tasksel/first: Laptop, Standard system tasksel/tasks: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#360619: Processed: Re: Bug#360619: Installer numbers SCSI drives diffently than the post install system does on Dell PE1855 (Debian 3.1r1)
On Tue, Jul 25, 2006 at 03:14:10PM +0200, Martin Michlmayr wrote: > * maximilian attems <[EMAIL PROTECTED]> [2006-07-25 14:27]: > > Scott has a nice script that converts the fstab, > > that will of course only work with initramfs-tools. > > Any idea where this script will be included so applications can use > it? latest ubuntu udev has integrated the script, which seems fine as UUID stuff without udev doesn't make much sense. although there mighte be some resistance in udev "messing" around on /etc/fstab. see also #358510 will add info there. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#380049: debian-installer/etch bug report
In-Reply-To=<[EMAIL PROTECTED]> hello, > Comments/Problems: > The machine is set to install on /dev/md0 raid1. The installer worked > like a charm, and on reboot into the live system I end up with major > failure, the scripts try to start the raid system with mdrun but I end > up with the error; > > > "mdadm: cannon open device /dev/hda5: Device or resource busy" > > When I attempt to mount /dev/hda1 I end up with the same error. that is a known problem of the mdrun initramfs boot script. it got dropped for proper hook scripts, you need newer initramfs-tools > 0.70 and mdadm from unstable. try to fetch those before reboot. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Upcoming Release of Debian GNU/Linux 4.0
On Thu, Jul 27, 2006 at 01:14:55PM -0700, Jason Self wrote: > On 7/27/06, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > >Backporting the necessary changes is certainly an option. I would > >think this is up to the powerpc Porters to handle. > > Thank you. I'll continue to pursue this on debian-powerpc. 2.6.18 is considered as release kernel, so please don't draw to quick conclusions. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Upcoming Release of Debian GNU/Linux 4.0
On Fri, Jul 28, 2006 at 12:06:50PM +0200, Marc 'HE' Brockschmidt wrote: > maximilian attems <[EMAIL PROTECTED]> writes: > > On Thu, Jul 27, 2006 at 01:14:55PM -0700, Jason Self wrote: > >> On 7/27/06, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > >>> Backporting the necessary changes is certainly an option. I would > >>> think this is up to the powerpc Porters to handle. > >> Thank you. I'll continue to pursue this on debian-powerpc. > > 2.6.18 is considered as release kernel, > > No, it is not. As you may have noticed, we had a release update a few > days ago, telling people that we're currently planning to release with > 2.6.17. Though we're aware that it might be needed to update the kernel > in October, the current upstream release quality is not something we > want to rely on. the last announcement by the release team was coordinated with d-kernel and said 2.6.17 or higher. also if you look at the mails of fjp and aba, they all state that the Sarge Debian kernel freeze was too long and if things get coordinated with d-i an newer kernel is fine. we are about to stabilize 2.6.17, although we won't backport 2.6.18 stuff, as from the timing 2.6.18 looks good. 2.6.18 has features for several archs ppc, amd64 (smp alternatives), sparc (sbus sysfs) plus big sata/acpi merge. best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Upcoming Release of Debian GNU/Linux 4.0
On Fri, Jul 28, 2006 at 12:25:34PM +0100, Thiemo Seufer wrote: > maximilian attems wrote: > > we are about to stabilize 2.6.17, although we won't backport 2.6.18 > > stuff, as from the timing 2.6.18 looks good. 2.6.18 has features for > > several archs ppc, amd64 (smp alternatives), sparc (sbus sysfs) plus > > big sata/acpi merge. > > AFAIU you on IRC we agreed to keep 2.6.17 with the necessary backports > as a plan B release candidate. Did I misunderstand you, or did you > change your mind? no did not, some parts are non-trivial to backport like amd64 smp alternatives. or whole sparc drivers so 2.6.17 is really plan B. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
sorry for the late dropin, haven't seen that before today #498712 came in. which clearly shows the uglyness of the current situation, why should the same variable be set on *two* places. On Mon, 25 Aug 2008, Frans Pop wrote: > On Monday 25 August 2008, Martin Michlmayr wrote: > > - the question was not asked (because debconf priority > medium) > > That would break the case where the architecture default if different from > the default of initramfs-tools. > > > - the policy is the same as the default of initramfs-tools (most) > > I thought about that, but that assumes the default of initramfs-tools > won't ever change. I'd prefer not to base code on that assumption. it won't change. initramfs-tools per default has the concept of generating an allmost generic initramfs. i'm happy with d-i setting it for specific embedded arch, but please drop that file when it is useless. as tbm said ($RET != "most") is easy to check. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lenny regression initrd/lvm/ rootfs detection timeout
On Tue, Oct 07, 2008 at 03:05:47PM +0200, Florian Lohoff wrote: > On Tue, Oct 07, 2008 at 03:02:05PM +0200, maximilian attems wrote: > > Subject: Re: lenny regression initrd/lvm/ rootfs detection timeout > > > > On Tue, Oct 07, 2008 at 02:20:13PM +0200, Florian Lohoff wrote: > > > > > > Hi, > > > after upgrading an FSI RX/300 from etch to lenny the machine would not > > > boot anymore. It got stuck in the initrd not beeing able to find the > > > root filesystem. The cause was that the aacraid took too long to make > > > the root filesystem available. Thus the boot timed out and the initrd > > > waited for the root filesystem to get available. After some seconds >45 > > > the root disks (sda on an aacraid) got available but the boot failed > > > anyway dropping into the initrd. The cause was that the root is an lvm > > > which is on that disk and the lvm does not get retried after more disks > > > get available. > > > > > > I got the machine to boot by running /scripts/top-local/lvm2 which made > > > the root filesystem in the lvm available and ctrl-d to continue booting. > > > > > > I think after more disks get available the initrd should retry running > > > the lvm detection otherwise a lot of lvm based systems might die/get > > > stuck on upgrade. > > > > > > I'd consider this a RC bug - no clue whose fault this is though ... > > > > standard answer boot with > > rootdelay=X > > It worked with etch without that parameter and the upgraded did not add > it so its a lenny regression - isnt it? no it was just luck that it didn't hit you previously. kernel gives no guarantee on timing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lenny regression initrd/lvm/ rootfs detection timeout
On Tue, Oct 07, 2008 at 03:54:59PM +0200, Florian Lohoff wrote: > On Tue, Oct 07, 2008 at 03:10:47PM +0200, maximilian attems wrote: > > > > standard answer boot with > > > > rootdelay=X > > > > > > It worked with etch without that parameter and the upgraded did not add > > > it so its a lenny regression - isnt it? > > > > no it was just luck that it didn't hit you previously. > > kernel gives no guarantee on timing. > > This renders the argument with "rootdelay=" moot - When the kernel gives > no guarantee on timing ANY rootdelay works just by luck. So coming back > to this issue i consider this still a bug - When a block device comes > available the lvm code needs to scan it in case the rootfs is an lvm. > > The whole issue with finding the rootfs in the initrd needs to be > triggered and not waited for base on the statement of yours. too late for such changements and no that is not the solution either. if you read realease notes for etch you find a rootdelay chapter, probably is copied over to lenny. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lenny regression initrd/lvm/ rootfs detection timeout
On Tue, Oct 07, 2008 at 02:20:13PM +0200, Florian Lohoff wrote: > > Hi, > after upgrading an FSI RX/300 from etch to lenny the machine would not > boot anymore. It got stuck in the initrd not beeing able to find the > root filesystem. The cause was that the aacraid took too long to make > the root filesystem available. Thus the boot timed out and the initrd > waited for the root filesystem to get available. After some seconds >45 > the root disks (sda on an aacraid) got available but the boot failed > anyway dropping into the initrd. The cause was that the root is an lvm > which is on that disk and the lvm does not get retried after more disks > get available. > > I got the machine to boot by running /scripts/top-local/lvm2 which made > the root filesystem in the lvm available and ctrl-d to continue booting. > > I think after more disks get available the initrd should retry running > the lvm detection otherwise a lot of lvm based systems might die/get > stuck on upgrade. > > I'd consider this a RC bug - no clue whose fault this is though ... standard answer boot with rootdelay=X -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
initramfs-tools unblock
please unblock initramfs-tools 0.92n
it contains 3 important fixes plus minor docs update.
the ide one is relevant for the upcoming d-i release.
see belows diff.
happy christmas to everyone
maks
diff --git a/debian/changelog b/debian/changelog
index 9acbfcc..4edb150 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+initramfs-tools (0.92n) unstable; urgency=high
+
+ [ Eugene Paskevich ]
+ * hook-functions: Fix MODULES=dep for lvm LABEL fstab notation.
+(closes: #508906)
+
+ [ maximilian attems ]
+ * all_generic_ide: Also parse boolean bootoption. (closes: #507805)
+ * initramfs-tools.8: Document where to look up NFSOPTS. (closes: #502927)
+ * update-initramfs.8: List -d and mark the non-optional as such.
+
+ [ S. Sakar ]
+ * hook-functions: MODULES=dep fix encrypted loop device.
+(closes: #499666)
+
+ -- maximilian attems Fri, 19 Dec 2008 14:03:13 +0100
+
initramfs-tools (0.92m) unstable; urgency=medium
[ Colin Watson ]
diff --git a/hook-functions b/hook-functions
index 5b6230a..6a68910 100644
--- a/hook-functions
+++ b/hook-functions
@@ -246,7 +246,8 @@ dep_add_modules()
manual_add_modules "${FSTYPE}"
# lvm or luks root
- if [ "${root#/dev/mapper/}" != "${root}" ]; then
+ if [ "${root#/dev/mapper/}" != "${root}" ] \
+ || [ "${root#/dev/dm-}" != "${root}" ]; then
minor=$((0x$(stat --format "%T" ${root}) % 256))
block=$(ls -1 /sys/block/dm-${minor}/slaves | head -n 1)
# lvm on luks or luks on lvm
@@ -277,6 +278,11 @@ dep_add_modules()
elif [ "${root#/dev/ida/}" != "${root}" ]; then
block=${root#/dev/ida/*}
block="ida!${block%p*}"
+ # loop root /dev/loopX
+ elif [ "${root#/dev/loop}" != "${root}" ]; then
+ root=${root#/dev/}
+ block=$(losetup -a \
+ | awk "/${root}/{print substr(\$3, 7, 3); exit}")
# classical root device
else
block=${root#/dev/}
diff --git a/initramfs-tools.8 b/initramfs-tools.8
index 5e1f083..ea0952b 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -1,4 +1,4 @@
-.TH INITRAMFS-TOOLS 8 "2008/07/05" "" "mkinitramfs script overview"
+.TH INITRAMFS-TOOLS 8 "2008/12/18" "" "mkinitramfs script overview"
.SH NAME
initramfs-tools \- an introduction to writing scripts for mkinitramfs
@@ -58,7 +58,8 @@ set the root file system type.
\fB\fI nfsroot
can be either "auto" to try to get the relevant information from DHCP or a
string of the form NFSSERVER:NFSPATH or NFSSERVER:NFSPATH:NFSOPTS.
-Use root=/dev/nfs for NFS to kick to in.
+Use root=/dev/nfs for NFS to kick to in. NFSOPTS can be looked up in
+\fInfs(5)\fP.
.TP
\fB\fI ip
diff --git a/scripts/init-top/all_generic_ide b/scripts/init-top/all_generic_ide
index 28b519a..3274ee8 100755
--- a/scripts/init-top/all_generic_ide
+++ b/scripts/init-top/all_generic_ide
@@ -18,5 +18,10 @@ for x in $(cat /proc/cmdline); do
all_generic_ide)
modprobe ide-generic
;;
+ all_generic_ide=*)
+ if [ ${x#all_generic_ide=} ]; then
+ modprobe ide-generic
+ fi
+ ;;
esac
done
diff --git a/update-initramfs.8 b/update-initramfs.8
index 77ebe17..a01ba06 100644
--- a/update-initramfs.8
+++ b/update-initramfs.8
@@ -1,14 +1,13 @@
-.TH UPDATE-INITRAMFS 8 "2006/10/12" "" "update\-initramfs manual"
+.TH UPDATE-INITRAMFS 8 "2008/12/19" "" "update\-initramfs manual"
.SH NAME
update\-initramfs \- generate an initramfs image
.SH SYNOPSIS
.B update\-initramfs
+.RB \-c | \-d | \-u
.RB [ \-k
.IR version ]
-.RB [ \-c ]
-.RB [ \-u ]
.RB [ \-t ]
.RB [ \-v ]
.RB [ \-b ]
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#450836: installation-reports: Does not allow ethernet over firewire
On Thu, Nov 15, 2007 at 12:53:31PM +0100, Frans Pop wrote: > On Thursday 15 November 2007, Frans Pop wrote: > > Those should all be set for powerpc and should also be available during > > installation. Please check: > > - whether these modules are present > > - whether they are loaded automatically or not > > - if not, whether loading them manually gives you firewire support > > > > If the new firewire stack does not work for powerpc, that will have to be > > discussed with the kernel team. > > It looks as if the new stack just does not have any Ethernet support (yet?). > I also no longer have a firewire Ethernet device on my x86_64 system. > > This is confirmed on: > http://wiki.linux1394.org/JujuMigration > > That same page lists several issues with the new stack when compared to the > old one and also has the following recommendation: > ! Regarding Linux 2.6.22 and 2.6.23, the best advice to Linux > ! distributors (kernel packagers) as well as to regular users is: Build only > ! the old IEEE 1394 drivers. > > Please activate the old stack again. the new stack is very promising, we will reconsider later if no eth1394 shows up, for now that's just a minor regression. see discussions on d-kernel, nobody spoke up when the anncouncement about missing eth1394 was declared. best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451367: installation-reports: Does not allow ethernet over firewire
On Thu, 15 Nov 2007, Frans Pop wrote: > On Thursday 15 November 2007, you wrote: > > the new stack is very promising, > > we will reconsider later if no eth1394 shows up, > > for now that's just a minor regression. > > No, that is not a "minor" regression. Half the functionality of the old > drivers is missing! eth1394 is missing that is by far the less used firewire driver. the switch to the juju stack allowed to close a huge nr. of bugs. the old stack is just not supportable and never was, plus is a security nightmare. ieee1394 in fact deserves the Kbuild variable BROKEN. the new stack is aiming for feature parity, but with interface incompatibility, so the various firewire userland needs to pick up the switch. the new stack although more compact is already more stable. > What discussion? I googled for it and after skimming through about 20 pages > I still have not found it. What I _did_ find is several other reports of > problems with the new stack, two of which complain about missing Ethernet > support: > - http://lists.debian.org/debian-kernel/2007/10/msg00414.html > - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441206 > - http://www.debianhelp.org/node/9328 i consider that smallish to the *huge* usability improvement on not having a strange firewire ethernet device to choose for your network connectivity in d-i. so no tears for it. > So Google does not help. Let's check the changelog: > linux-2.6 (2.6.22~rc5-1~experimental.1) experimental; urgency=low > * Enable the new firewire stack labeled to be more simple and robust. > -- Bastian Blank <[EMAIL PROTECTED]> Tue, 19 Jun 2007 17:49:52 +0200 > > Strange. No mention of the fact that the new stack is [1]: > - experimental > - not recommended for distributions by its upstream developers > - has a _major_ regression in it's lack of Ethernet support > - lacks userspace integration > - has had only limited testing if i'm wrong, we can still enable both and start blacklisting the bad oldie one in m-i-t early enough. RH did rewrite the stack and it's main upstream developer ships it already enabled in 2 major releases fedora 7 and 8. juju has already nicely improved since the 2.6.22 inclusion, so still looks for the most promising option for the lenny release. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451367: installation-reports: Does not allow ethernet over firewire
On Tue, Nov 20, 2007 at 08:32:44PM +0100, Helge Kreutzmann wrote: > > It would be great if also eth1394 would reappear in the new stack, > especially since the original developer is an @debian.org person. > you seem to have a strange confidence in someone, whose stack went so badly down the road, but yeah an upstream push for firewire juju eth1394 is best for all. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451367: installation-reports: Does not allow ethernet over firewire
On Tue, Nov 20, 2007 at 11:50:58AM -0800, Steve Langasek wrote: > > The device was listed in d-i because people were using it. This thread is > here because they can no longer do so. It's rather rude of you to declare > that it's ok for the kernel team to "fix" usability issues in the installer > by removing functionality from the kernel. as i mentioned on the mail announcing the switch eth1394 might go missing for a while, if it doesn't reappear soon enough for lenny, the m-i-t blacklisting of the old stack seems an easy way to get it back. and yes i have seen quite a lot of people stumble on that dialogue. > I understand the technical arguments regarding the replacement of the stack, > and have no informed position on this bigger issue (though it seems that > plenty of people have been using the previous stack without complaint?), but > that doesn't make it ok that functionality has been dropped, whether or not > you happen to like that functionality. plenty of people have left *lots* of bug reports on ieee1394. it is trivialy easy to crash any box as user with it. it's buggyness was the reason for rh to sponsor the rewrite. also it's sysfs device name support is quite lacking afair. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[PATCH] autopartkit: remove mkfs.ext3 default option
mkfs.ext3 /dev/dualvg0/foo > /dev/null
mke2fs 1.40.2 (12-Jul-2007)
tune2fs -l /dev/dualvg0/foo | grep features
Filesystem features: has_journal resize_inode dir_index filetype
sparse_super
Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
---
packages/autopartkit/autopartkit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/packages/autopartkit/autopartkit.c
b/packages/autopartkit/autopartkit.c
index 8882520..605ec2c 100644
--- a/packages/autopartkit/autopartkit.c
+++ b/packages/autopartkit/autopartkit.c
@@ -858,7 +858,7 @@ makefs(const char *devpath, const char *fstype)
else if (0 == strcmp("ext2", fstype))
mkfs = "/sbin/mkfs.ext2";
else if (0 == strcmp("ext3", fstype))
-mkfs = "/sbin/mkfs.ext3 -O resize_inode";
+mkfs = "/sbin/mkfs.ext3";
else if (0 == strcmp("jfs", fstype))
mkfs = "/sbin/mkfs.jfs";
else if (0 == strcmp("xfs", fstype))
--
1.5.3.6
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i support for running in a Xen guest domain
On Wed, Jan 09, 2008 at 09:58:45PM +, Ian Campbell wrote: > I'd like to propose enabling Xen guest support in all the native i?86 > kernel images (and eventually amd64 too), or at least in the -686-bigmem > kernel. Since paravirt ops is already enabled in all kernels (for KVM > and lguest) there is only minimal additional overhead to enabling Xen. > > As a nice bonus this would also allow the separate -xen flavour kernels > to be removed/deprecated which seems like a good thing in the > paravirt_ops based world. this sounds like a good plan, getting rid of the number of images is always a welcome bonus. i know that fedora also is very keen to move to the paravirt_ops world. for Etch linux-2.6 had dom0 images, when will those be merged, where are the patches based on paravirt ops against 2.6.24? we wouldn't want to release Lenny without the support we had given in Etch (which turned out to be *very* buggy, but that is another story) of a dom0 linux-2.6 linux-image variant. > Given a suitable kernel it would then be possible to add a -bigmem > flavour of d-i. That would give us installer images which support > native, Xen, KVM and lguest via paravirt_ops both PAE and non-PAE > allowing Debian to be installed as a guest on a wide variety of domain0 > distributions. linux-2.6 already builds the -bigmem flavour and afaik it is instelled by d-i later but not used on boot. > So, what do the kernel folks think about enabling Xen guest support in > all kernels where it is available and getting rid of the -xen specific > variants? I've got a massive (mainly due to lots of deletion) patch > against SVN which does just that, if there is interest I'll work out the > kinks and file it as a wishlist bug. 2.6.24 is right now open for such changes, thanks for your already filed and fixed virtualization i386 bug report, had gone unnoticed for a while as focus slipps to amd64. happy hacking -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i support for running in a Xen guest domain
On Sat, 12 Jan 2008, Ian Campbell wrote: > Unfortunately the Xen domain builder isn't capable of loading a native > bzImage directly -- it requires the ELF vmlinux. I hacked > around that when I was playing with Xen enabled d-i and > then promptly forgot I had done so, which is a shame because it's quite > important! For now I grabbed the 686-bigmem vmlinux from the build tree > and boot tested that. hmm there were the xen images i guess they did something similar, maybe look there on how to grab them with maintainer scripts. so enabling won't bring us much for now also due to !pae i only see a current value in i386 bigmem. > The Fedora guys announced that they were working on dom0 paravirt_ops > stuff at the end of last year [0]. I must admit I haven't really been > keeping up with their efforts though. > > I had a dig around and didn't see anything further to what was > announced. They were targeting Fedora 9. According to [1] feature freeze > is start of March so I'd presume they plan to have patches before then. referring to that: http://fedoraproject.org/wiki/Features/XenPvops (seem to not load right now on my end, but should be the page) amicalement -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463844: [tasksel] gnome-desktop: s/gnome-btdownload/transmission-gtk/
Package: tasksel Version: 2.71 Severity: normal Tags: patch transmission is an easy and fast lightweight BitTorrent client. gnome-btdownload lacks many features in comparison. --- tasks/gnome-desktop |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tasks/gnome-desktop b/tasks/gnome-desktop index 8f43554..0b4dfb5 100644 --- a/tasks/gnome-desktop +++ b/tasks/gnome-desktop @@ -36,7 +36,7 @@ Packages-list: # click on deb to install gdebi # everyone uses bittorrent these days, right? - gnome-btdownload + transmission-gtk # and rss. epiphany integrates with liferea liferea # and does instant messanging -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii aptitude 0.4.10-1 terminal-based package manager ii debconf [debconf-2.0] 1.5.18 Debian configuration management sy ii liblocale-gettext-perl1.05-1 Using libc functions for internati ii tasksel-data 2.71 Official tasks used for installati tasksel recommends no packages. -- debconf information: tasksel/title: tasksel/desktop: gnome tasksel/first: tasksel/tasks: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please add following hint to block linux-2.6 until Beta1 is out
On Thu, 14 Feb 2008, Otavio Salvador wrote: > > Hello RM and SRM teams, > > I hereby ask for a block on linux-2.6 source package until d-i Beta1 > gets out. If it migrates before we do the final images we can need to > delay d-i release. nacked as maintainer, you are blocking for more then 2 weeks linux-2.6 migration to testing. we need massife testing of 2.6.24 for etch+half, sid is not enough. also 2.6.22 was meant to be ready 4 month ago, sorry but that schedule is over. > As discussed[1] previously at debian-boot we've decided to stay at > 2.6.22 for this release and do a release as fast as possible with > 2.6.24. > > 1. http://lists.debian.org/debian-boot/2008/02/msg00012.html very bad decision 2.6.24 is needed for a lot of recent hardware, d-i doesn't install on those. signature.asc Description: Digital signature
Re: Please add following hint to block linux-2.6 until Beta1 is out
On Thu, 14 Feb 2008, Philippe Cloutier wrote: > linux-2.6 can't migrate to testing with normal delays before 2008-02-21. The > planned beta release on 2008-03-03 is 11 days later. > > Also, this assumes that linux-2.6 2.6.24-4 will migrate to testing. In > reality, it's unlikely that linux-2.6 would migrate before March. that is totally untrue. linux-2.6 always needs hint from the release team to migrate. properly set up it can happen in less then a week. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please add following hint to block linux-2.6 until Beta1 is out
On Thu, 14 Feb 2008, Philippe Cloutier wrote: > > that is totally untrue. > > linux-2.6 always needs hint from the release team to migrate. > > properly set up it can happen in less then a week. > What do you mean? What "it" can happen in less than one week? omg, what are we talking about? migration of linux-2.6 to testing. i repeat that with proper urgency hints from the release team linux-2.6 can be in a week in testing. nobody gave a proper reason why this upper late beta1 needs to happen with a retarted kernel. signature.asc Description: Digital signature
Re: kernel 2.6.24 & speakup
On Tue, Mar 25, 2008 at 03:06:58PM -0300, Otavio Salvador wrote: > Samuel Thibault <[EMAIL PROTECTED]> writes: > > > Hello, > > > > Mario Lang, le Tue 25 Mar 2008 17:28:32 +0100, a écrit : > >> Samuel Thibault <[EMAIL PROTECTED]> writes: > >> > (speakup can now be compiled fully independently) > >> > >> linux-modules-extra-2.6 seems like the perfect place for speakup, now that > >> it > >> does not require the kernel to be patched anymore. > > > > Well, a small patch is still needed, but it just boils down to > > GPL-exporting 4 symbols, and that is already in the -mm tree, so > > backporting it to the debian kernel shouldn't be a problem.. > > It would be nice if you could talk to Debian Kernel Team (just added > it to cc list) and see if this could be added for next 2.6.24 upload > or later. That would allow the module to be build from > linux-modules-extra-2.6 and later to be added to d-i if needed. ok thanks for informing us. :) afair we had a discussion about speakup and it would point to security troubles of that patch. but i don't remember the cicurmstances why it got droped when going from 2.4 to 2.6? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 & speakup
On Tue, Mar 25, 2008 at 06:50:01PM +, Samuel Thibault wrote: > Samuel Thibault, le Tue 25 Mar 2008 18:39:54 +, a écrit : > > Apply patches/kernel-integration-2.6.24-source.patch to the main kernel > > source to GPL-export 4 symbols, > > Note: by that, I mean to pick that patch into the regular linux-2.6 > kernel. That patch is already in the -mm tree actually. once it is in next we can maybe backport, other wise we'll just pick it up when merged. 2.6.24 window is closed anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 & speakup
On Tue, Mar 25, 2008 at 07:43:47PM +, Samuel Thibault wrote: > maximilian attems, le Tue 25 Mar 2008 20:13:30 +0100, a écrit : > > > > once it is in next > > "in next"? next is the linux tree of things that are ready for the next merge window aka 2.6.26 now. > > 2.6.24 window is closed anyway. > > You mean the upstream or the Debian? debian, see -> http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.24 & speakup
On Tue, 25 Mar 2008, Samuel Thibault wrote: > Ah, so since Lenny's d-i is supposed to use 2.6.24, speakup won't make > it into it :/ as otavio said we gonna release with > 2.6.24 for debian 2.6.24 stuff would have to go through the stable releases. 7 out of 9 hunks FAILED -- saving rejects to file drivers/char/keyboard.c.rej 12 out of 16 hunks FAILED -- saving rejects to file drivers/char/vt.c.rej 1 out of 2 hunks FAILED -- saving rejects to file include/linux/keyboard.h.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/notifier.h.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/vt.h.rej (+) FAIL notifier-integration.patch notifier-integration.patch taken from HEAD 465da369435f5dc853656bb01731c59759d0a5e2 it'be nice if your git repo would feature a gitweb and a git server. anyway the -mm patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc5/2.6.25-rc5-mm1/broken-out/input-put-ledstate-in-the-keyboard-notifier.patch seems to apply fine for 2.6.25, but has none of the wanted exports. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475398: tasksel: add kerneloops to standard task
Package: tasksel Version: 2.73 Severity: wishlist kerneloops allows to track oopses accross distribution and versions. it is default installed since fedora 9. it be really cool if Lenny would ship it too. it would allow to have better feedback of the shipped quality of the corresponding Linux image. Looked into the tasksel repo and saw that the standard task has no pacakges listed. so please advise how to get kerneloops shipped across d-i standard installs? thanks -- maks -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-rc8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii aptitude 0.4.10-1+b1 terminal-based package manager ii debconf [debconf-2.0]1.5.20 Debian configuration management sy ii liblocale-gettext-perl 1.05-3 Using libc functions for internati ii tasksel-data 2.73Official tasks used for installati tasksel recommends no packages. -- debconf information: tasksel/title: tasksel/desktop: gnome tasksel/first: tasksel/tasks: Print server -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475398: tasksel: add kerneloops to standard task
On Fri, 11 Apr 2008, Matthew Wilcox wrote: > My opinion is that this will still be useful even if people with headless > servers don't activate it. I think many more people encounter kernel > bugs on desktop Debian machines than they do on servers. ack yes please add it to the gnome, kde and xfce desktop tasks. that is a good first step, we can always see later if we want it standard. concerning debconf question i find that overkill. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#475525: Both sis5513 and pata_sis claim 1039:5513 (was: reboot failure)
On Thu, Apr 17, 2008 at 01:37:23AM +0200, Frans Pop wrote: > reassign 475525 linux-2.6 2.6.22-6 > retitle 475525 Both sis5513 and pata_sis claim 1039:5513 > thanks > > On Saturday 12 April 2008, Facundo Ariel Pérez wrote: > > Here they go ... > > Thanks. This shows that indeed two modules are currently competing for the > same chipset, which is not desirable. Therefore reassigning to the kernel > team. > > $ grep 1039.*5513 /lib/modules/2.6.24-1-amd64/modules.pcimap > pata_sis 0x1039 0x5513 ... > sis5513 0x1039 0x5513 ... > > (2.6.22-3 gives the same result) > > waldi, maks: should we maybe do another inventory for such cases? > (please CC d-boot on reply as I'm not subscribed to d-kernel ATM) yep the pata_sis case is known. it is an unfortunate example of why we shouldn't use oldstyle device names in fstab. it wasn't desactivated as currently pata_sis seems to be quicker in grabbing the device thus many people have /dev/sdaX as their root and bouncing around seemed stupid. also the hope was put on the pata transition and stable dev usage. as none of those currently happend it seems time to reconsider (having testing user bite the sour switch again) -- maks ps fjp mutt seemed strangely not to put you on cc, please cc me on any reply (subscribed or not). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] mass kernel udeb update and preparations for RC1
On Fri, Sep 22, 2006 at 02:31:43PM +0200, Frans Pop wrote: > > * 2.4 support now officially dropped > > Starting with RC1 d-i will no longer support 2.4 based installations. > > All arches have been switched now and some cleanup has been started; > > more cleanup is expected and this may cause unexpected breakage. :) > > * powerpc: oldworld boot problems with recent kernels benh made a patch that still needs confirmation, patch is included in latest 2.6.18 regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Possible (partial) solution for device persistence issue
On Tue, Oct 17, 2006 at 04:27:19PM +0200, Geert Stappers wrote: > Op 16-10-2006 om 00:06 schreef Frans Pop: > > On Sunday 15 October 2006 23:45, Geert Stappers wrote: > > > The thing I would like to see is that the _difference_ in device naming > > > between d-i kernel plus fellows and installed kernel plus fellows is > > > solved. > > > > See the discussions that we have had about this in the past. > > The culprit is the kernel/udev: that can load drivers in a different order > > any time. It is not something we can solve in the installer. > > > > The experts have said that using UUID is the best solution. I agree that > > it is extremely ugly. it is see very practical, see for example this usage example http://michael-prokop.at/blog/2006/08/11/stable-root-device-aka-uuid/ > Dear Kernel developers, > > > Your work is appriceated, but I have a request: > > > Please allow reproducable hardware detection. > > > As systemadministrator I can't affort having a disk that is one moment > /dev/sda and the next reboot /dev/sdb. > > Having a fast booting system is great, having disks swapped not. the kernel _never_ guaranteed stable device nodes, that is an userspace policy. use the tools that provide that. > Please prefer consistence above speed. > > > > Thank you for reading this humble plea. > Geert Stappers edgy udev transforms the fstab to use plain uuids, to guarantee correct root recognition. i guess their installer also add uuid entries to the newly installed fstab - why is that not in d-i? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397950: initramfs-tools: incorrectly tries to use external disk as root FS instead of internal disk
reassign 397950 debian-installer-utils stop On Fri, Nov 10, 2006 at 05:45:49PM +0100, Laurent Bonnaud wrote: > Hi, > > this system usually boots from an internal SATA disk (/dev/sda). I > recently added an external IEEE1394 disk and when I tried to reboot > the system, it failed. /dev/sda had become the external disk and the > internal disk had become /dev/sdb therefore the initramfs did not find > the correct root FS. > > I could change grub and the fstab to use /dev/sdb instead of /dev/sda, > but I do not want to because I would like to be able to boot my system > even if the external disk is unplugged. > > I could boot my system with the external disk unplugged and plug it > later, but this would not allow me to perform remote reboots. > > Ubuntu solves this problem by using root=UUID= instead of > root=/dev/ on the kernel command line. > > A simpler fix would be to change the loading order of kernel modules. > According to the list below, the 1394 modules are loaded before the > sata modules. This order could probably be reversed without harming > anybody. the kernel never guarantees device ordering, this is an userspace policy to implement. initramfs-tools support to boot via uuid. the installer folks know the ubuntu patches for it, so reassigning. > I have another system (amd64 architecture) with an external IEEE1394 > disk and I have no problem because curiously the modules are loaded in > a different order: > Do you know why ? This other system boots on /dev/md0, which avoids > the problem altogether. mdadm uses uuid too, but needs some udev fixes to be completly migrated allowing uuid root. > I did not flag this bug as "grave" because there is a simple > work-around (unplug the external disk), but an unbootable system at > least deserves to be "important". it is currently the most report bug.. so surely a duplicate, anyway etch should not ship without uuid usage. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397985: debian-installer: use kexec for the first 'boot'
> I think it would be nice if the first boot of the newly installed system > would occur with kexec, avoiding BIOS and boot loader "loss of time". well kexec has not yet the coverage in the wild, so kexec boot failures are expected. i routinely use in on a x41, there ipw2200 does panic and needs an reload, due to missing kexec init routine.. but i agree that an menu entry for kexec and a kexec udeb would be nice. http://www.itp.tuwien.ac.at/~mattems/blog/2006/05/25#kexec_usage -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r42623 - in trunk/packages/rootskel: debian src-bootfloppy src-bootfloppy/bin
On Fri, 17 Nov 2006, Joey Hess wrote: > sferriol wrote: > > yes, but it is the only solution that i've found because cpio is not in > > klibc-utils > > and it frees ~80k on bootfloppy because we do not use all klibc commands > > A klibc udeb would not need to include all klibc commands, but only the > ones the boot floppy needs. klibc-utils produces an udeb, currently it adds all the commands. if you want to restrict that choice, please tell which you want and it's easy to put just those in. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r42623 - in trunk/packages/rootskel: debian src-bootfloppy src-bootfloppy/bin
On Tue, 21 Nov 2006, sferriol wrote: > maximilian attems a écrit : > >klibc-utils produces an udeb, currently it adds all the commands. > >if you want to restrict that choice, please tell which you want > >and it's easy to put just those in. > > > the klibc commands used in d-i: > /usr/lib/klibc/bin/sh.shared > /usr/lib/klibc/bin/mount > /usr/lib/klibc/bin/insmod > /usr/lib/klibc/bin/mknod > /usr/lib/klibc/bin/mkdir > /usr/lib/klibc/bin/cat > /usr/lib/klibc/bin/umount > /usr/lib/klibc/bin/zcat > /usr/lib/klibc/bin/run-init hmm that are not much, i see no fstype in there, no ipconfig, no nfsmount.. i guess it would make sense to have an seperate boot floppy udeb, i'll catch the linux-headers -3 abi and then will add the new udeb. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
reenabling sparc32 for 2.6.22
thanks to kylem for fixing the failure upstream. afaik the sparc porter and the release team haven't made any decision concerning sparc32 for lenny. so i think it is only logical to reenable it. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hint klibc 1.5-4
klibc switched to linux-libc-dev thus ending the FTBFS when linux headers bump abi. relevant mips patch landed upstream. klibc-utils-floppy-udeb is enhanced newer upstream has more fstype support, i'll upload soon. so i'd like to have that in testing once the 10 sid days are passed. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#438123: klibc stable/etch fix nfsroot on mips/mipsel
[trimmed long reviewer cc, added debian-boot and fjp ] On Thu, 16 Aug 2007, Martin Zobel-Helas wrote: > On Thu Aug 16, 2007 at 18:27:58 +0100, Thiemo Seufer wrote: > > dann frazier wrote: > > > On Thu, Aug 16, 2007 at 04:05:12PM +0200, maximilian attems wrote: > > > > could you please review #438123 ? > > > > the fix propagated in new upstream and is thus in testing / sid. > > > > the consequences are that currently nfsroot on mips/mipsel fails. > > please upload ok great thanks for the quick ack! please note that i'm not a d-i expert. klibc produces udebs which are in use in rootskel irc i don't know of the d-i consequences of an klibc upload. have the package ready to upload and tested, will wait from an ack or explanation for the d-i side of the story. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
