Bug#505111: will suggest removal from testing
On Saturday 07 August 2010, Neil McGovern wrote: As there isn't a resolution in sight, I'll add a hint at the end of August for the removal of the package unless there's significant progress to fixing the issue. I still feel this is an overreaction as only the original reporter has ever seen the issue in practice. No one else has ever reported being affected by the issue. The described use case requires an combination of factors which is quite unlikely to occur in practice. I'm also CCing Colin Watson as he is the original author of rescue mode and its primairy maintainer. Maybe he'll be motivated to look into this or comment. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590993: installation-reports: netboot install report broken mirror if installation CD is used as mirror
reassign 590993 debian-cd severity 590993 normal thanks Since you are trying something that's not really supported, this is certainly *not* a grave issue. After all, a CD image is not a mirror even if both contain a repository. It is correct that the error occurs because CD images have symlinks for all suites to the release (codename) included on the CD. This is mostly for historic reasons and no longer has any purpose (since current versions of the installer select by codename instead of suite). In a bit more detail. The latest versions of choose-mirror (including the current Etch and Lenny versions) perform validity checks on the Release files and will reject a mirror as broken if the Release file under a suite symlink lists a different suite inside the Release file. It would be better if debian-cd was modified to only include the symlink for the suite actually specified in the Release file. Reassigning accordingly. Looks like my whole attempt to use the ISO image as netboot installation source is futile, as the files are not signed on the CD, so netinst gives up in the next step. This can be worked around by telling the installer to ignore the signatures. See the installation guide for details. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588608: aptitude (priority important) depends on libboost-iostreams (priority optional)
Steve Langasek wrote: This manual represents the opinion of a single developer. And what does that have to do with the price of bananas in Iceland? The fact that aptitude is currently the recommended tool for package management has various reasons: user interface, features, dependency handling, etc. That status has evolved over the last 3 or so release cycles. You have even been part of some of the discussions (for example sarge - etch upgrade issues) aptitude is the primary tool used by Debian Installer (and because of that its current priority of important is actally necessary). It is also recommended in both the Release Notes (for stable release upgrades) and the Installation Guide. So what's listed in the Debian Reference is a correct reflection of aptitude's current status and not, as you imply, the result of some single developer being on crack. The growing dependency chain of aptitude *is* of some concern and may be reason to re-evaluate its role, but in no way does that change its _current_ status. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583388: Non-US keyboard problem with graphical installer
On Tuesday 06 July 2010, Cyril Brulebois wrote: 5. Fix for real: Edit /var/lib/dpkg/info/keyboard-configuration.config, and add the following line in ask_debconf(), right before the if part, once all choices have been merged together: choices=`echo $choices | sed 's/,$//'` Nice job tracing this. It's an error that crops up once in a while (in most cases because a comma _inside_ one (translated) option in the option list is not escaped and causes a count difference). The proposed fix could well be OK, but maybe the code can be fixed a bit earlier so the trailing comma is avoided in the first place? It's in general better to create the option list correctly than to clean it up afterwards. 'ask_debconf()' sounds like a rather general function that should be fed correct input rather than have this overhead. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583388: Non-US keyboard problem with graphical installer
On Tuesday 06 July 2010, Cyril Brulebois wrote: Frans Pop elen...@planet.nl (06/07/2010): The proposed fix could well be OK, but maybe the code can be fixed a bit earlier so the trailing comma is avoided in the first place? Whatever unbreaks g-i. Not really. There's also such things as doing things right or wrong, not to mention performance. If you care enough to investigate an issue like this, it takes only very little extra time to find the real trouble spot and fix things there instead of just papering over the real bug and making the code less efficient and maintainable than it already is. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: [SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel
reopen 505609 reassign 505609 linux-2.6 affects 505609 lilo thanks Stephen Powell wrote: The real question is, Why didn't the map installer get run during the kernel upgrade? [...] So is this a bug in the kernel maintainer scripts? Or is it a feature? I don't know. I'll leave that up to the kernel maintainers to decide. Reopening and reassigning to the kernel team. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582223: partman - Wants to overwrite swap partition/lv
severity 582223 normal tags 582223 wontfix thanks On Wednesday 19 May 2010, Bastian Blank wrote: partman wants to overwrite the swap partitions on a already setup machine. As swap partition can contain hibernation data, this is an data-destroying operation. Doing any system install while the system is in hibernation is asking for trouble and IMO is simply user error. I don't think we need to support that case. See also the warning at the top of: http://www.debian.org/releases/testing/i386/ch05s01.html.en Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580799: linux-image-2.6.32-5-sparc64: Should include pata_cmd64x driver instead of cmd64x
Package: linux-2.6 Version: 2.6.32-12 Severity: serious Because of the IDE - ATA transition for Squeeze the pata_cmd64x driver should be enabled instead of the (old) cmd64x driver. AFAIK the pata_cmd64x has been tested and is known to work correctly. My system failed to boot after updrading to 2.6.32-12 because I had updated my bootloader config and fstab as per the debconf dialogs, but was still getting the /dev/hdX devices from the old driver. -- Package-specific info: ** Version: Linux version 2.6.32-5-sparc64 (Debian 2.6.32-12) (b...@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-10) ) #1 Mon May 3 12:15:34 UTC 2010 ** Command line: root=/dev/hda2 ro ** Not tainted ** Kernel log: [ 34.412487] Unpacking initramfs... [ 36.425976] Freeing initrd memory: 8542k freed [ 36.428004] power: Control reg at 1fff1724000 [ 36.429219] audit: initializing netlink socket (disabled) [ 36.429481] type=2000 audit(2.160:1): initialized [ 36.430530] HugeTLB registered 4 MB page size, pre-allocated 0 pages [ 36.446641] VFS: Disk quotas dquot_6.5.2 [ 36.447294] Dquot-cache hash table entries: 1024 (order 0, 8192 bytes) [ 36.448042] msgmni has been set to 2016 [ 36.450085] alg: No test for stdrng (krng) [ 36.450673] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 36.450782] io scheduler noop registered [ 36.450847] io scheduler anticipatory registered [ 36.450913] io scheduler deadline registered [ 36.451104] io scheduler cfq registered (default) [ 36.451824] atyfb: 3D RAGE II+ (Mach64 GT) [0x4754 rev 0x9a] [ 36.453534] atyfb: 2M SGRAM (1:1), 14.31818 MHz XTAL, 200 MHz PLL, 67 Mhz MCLK, 67 MHz XCLK [ 36.516048] Console: switching to colour frame buffer device 144x56 [ 36.541375] atyfb: fb0: ATY Mach64 frame buffer device on PCI [ 36.542671] /SUNW,f...@1e,0: FFB at 01fc, type 51, DAC pnum[236e] rev[10] manuf_rev[1] [ 36.556761] [drm] Initialized drm 1.1.0 20060810 [ 36.557763] /p...@1f,0/p...@1,1/e...@1/s...@14,3083f8: Keyboard port at 1fff13083f8, irq 6 [ 36.558491] /p...@1f,0/p...@1,1/e...@1/s...@14,3062f8: Mouse port at 1fff13062f8, irq 7 [ 36.559586] f0061c64: ttyS0 at MMIO 0x1fff140 (irq = 5) is a SAB82532 V3.2 [ 36.560168] f0061c64: ttyS1 at MMIO 0x1fff1400040 (irq = 5) is a SAB82532 V3.2 [ 36.893614] Floppy drive(s): fd0 is 1.44M [ 36.910680] FDC 0 is a National Semiconductor PC87306 [ 36.912772] Uniform Multi-Platform E-IDE driver [ 36.913344] ide-gd driver 1.18 [ 36.914572] mice: PS/2 mouse device common for all mice [ 36.916206] rtc-m48t59 rtc-m48t59.0: rtc core: registered m48t59 as rtc0 [ 36.920416] TCP cubic registered [ 36.922175] NET: Registered protocol family 10 [ 36.927110] lo: Disabled Privacy Extensions [ 36.930640] Mobile IPv6 [ 36.930789] NET: Registered protocol family 17 [ 36.931687] registered taskstats version 1 [ 36.932518] rtc-m48t59 rtc-m48t59.0: setting system clock to 2010-05-08 17:43:06 UTC (1273340586) [ 36.932895] Initalizing network drop monitor service [ 37.102842] udev: starting version 153 [ 37.560607] PCI: Enabling device: (:01:01.1), cmd 2 [ 37.560667] sunhme.c:v3.10 August 26, 2008 David S. Miller (da...@davemloft.net) [ 37.567765] input: Sun Type 5 keyboard as /devices/root/f005f9c0/f00601b4/f0061504/f0063594/serio0/input/input0 [ 37.570655] input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/input1 [ 37.580218] eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:9c:14:f5 [ 37.613386] cmd64x :01:03.0: IDE controller (0x1095:0x0646 rev 0x03) [ 37.627752] cmd64x :01:03.0: 100% native mode on irq 14 [ 37.634742] ide0: BM-DMA at 0x1fe02c00020-0x1fe02c00027 [ 37.641890] ide1: BM-DMA at 0x1fe02c00028-0x1fe02c0002f [ 37.649158] Probing IDE interface ide0... [ 37.937464] hda: ST34342A, ATA DISK drive [ 38.613346] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [ 38.613792] hda: MWDMA2 mode selected [ 38.621602] Probing IDE interface ide1... [ 38.909368] hdc: Maxtor 6E040L0, ATA DISK drive [ 39.417005] hdd: CD-ROM 56X/AKH, ATAPI CD/DVD-ROM drive [ 39.425289] hdc: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [ 39.425427] hdc: MWDMA2 mode selected [ 39.433355] hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [ 39.433451] hdd: MWDMA2 mode selected [ 39.441443] ide0 at 0x1fe02c0-0x1fe02c7,0x1fe02ca on irq 14 (serialized) [ 39.450618] ide1 at 0x1fe02c00010-0x1fe02c00017,0x1fe02c0001a on irq 14 (serialized) [ 39.459783] hda: max request size: 128KiB [ 39.468269] hda: 8404830 sectors (4303 MB), CHS=8894/15/63 [ 39.477020] hda: cache flushes not supported [ 39.486101] hda: hda1 hda2 hda3 hda4 [ 39.521765] hdc: max request size: 128KiB [ 39.541162] hdc: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=65535/16/63 [ 39.550586] hdc: cache flushes supported [ 39.561151] hdc: hdc1 hdc2 hdc3 hdc4 [
Bug#579948: SunBlade 1000 installation report - fails to mount root partition on /target
reassign 579948 libparted0debian1 2.2-5 tags 579948 d-i affects 579948 partman-base thanks On Sunday 02 May 2010, Jurij Smakov wrote: On Sun, May 02, 2010 at 03:57:48PM +0100, Jurij Smakov wrote: ~ # fdisk -l /dev/sdb Disk /dev/sdb (Sun disk label): 255 heads, 63 sectors, 8864 cylinders Units = cylinders of 16065 * 512 bytes Device FlagStart EndBlocks Id System /dev/sdb1 013 972801 Boot /dev/sdb2 2048 2049 1024 83 Linux native /dev/sdb3 0 8864 712000805 Whole disk /dev/sdb4 4096 4097 1024 82 Linux swap /dev/sdb5 6144 8864 21848064 83 Linux native Right. So the free space shown in partman *is* really there (although it shouldn't be). And sdb2 is completely wrong as it's way too small for a root fs. I think this may be the result of new partition alignment code in parted. The error is certainly in libparted as the log shows the following. Creation of first partition (100MB for /boot; looks OK): /bin/perform_recipe: IN: NEW_PARTITION =dev=sdb primary ext2 0-72908881919 beginning 10001 parted_server: OUT: 1 0-99614719 99614720primary ext2 /dev/sdb1 Creation of second partition (7GB for /): /bin/perform_recipe: IN: NEW_PARTITION =dev=sdb primary ext3 99614720-72908881919 beginning 71 parted_server: OUT: 2 16845373440-16846422015 1048576 primary ext3 /dev/sdb2 So partman requests a partition of 7GB, but libparted creates one of 1MB. Looks broken to me. The swap partition has the same problem: partman requests ~2GB, but we get only 1MB. Here's the fdisk output and illustration of the mounting error: ~ # mount -t ext3 /dev/sdb2 /target/ mount: mounting /dev/sdb2 on /target/ failed: Invalid argument This is a consequence of the error above. The syslog shows: May 2 17:12:42 partman: mke2fs 1.41.11 (14-Mar-2010) May 2 17:12:42 partman: Filesystem too small for a journal So, the FS is too small for a journal and therefore not a valid ext3 filesystem. But apparently ext4 is able to mount it (and you should also be able to mount it as ext2). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505111: will suggest removal from testing
On Wednesday 24 March 2010, Robert Lemmen wrote: unless you object soon, i will suggest the removal of these packages from testing. the rationale is (a mixture of these will apply to the package in question) This package should not be removed. The bug is partly theoretical and only affects a minority of use cases. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505111: will suggest removal from testing
On Wednesday 24 March 2010, Robert Lemmen wrote: On Wed, Mar 24, 2010 at 02:51:41PM +0100, Frans Pop wrote: This package should not be removed. The bug is partly theoretical and only affects a minority of use cases. ok, so you think it should be squeeze-ignore? do you think it should be ignored for any release in the future? or downgraded? having bugs which are marked as grave, but at the same time are ignored forever seems like a slightly suboptimal usage of the BTS... I think it should be fixed, but that the bug is not sufficient reason for removal of the package. Unfortunately the D-I team is understaffed. Leaving the bug at it's current (technically correct) severity will maybe help get other people to take in interest in it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574854: libklibc-dev: D-I rootskel FTBFS because of missing header files
Package: libklibc-dev Version: 1.5.16-1 Severity: serious The D-I package rootskel failed to build with this version and also after upgrading to 1.5.17-2 because header files could not be found. The cause was traced to the fact that instead of symlinks there are empty directories: $ ls -dl /usr/lib/klibc/include/linux drwxr-xr-x 2 root root 28672 Mar 18 16:21 /usr/lib/klibc/include/linux $ ls -dl /usr/lib/klibc/include/asm* drwxr-xr-x 2 root root 4096 Mar 18 16:21 /usr/lib/klibc/include/asm drwxr-xr-x 2 root root 4096 Mar 18 16:21 /usr/lib/klibc/include/asm-generic $ ls -l /usr/lib/klibc/include/linux total 0 $ ls -l /usr/lib/klibc/include/asm* /usr/lib/klibc/include/asm: total 0 /usr/lib/klibc/include/asm-generic: total 0 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.1 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libklibc-dev depends on: ii libklibc 1.5.17-2 minimal libc subset for use with i ii linux-libc-dev2.6.32-10 Linux support headers for userspac libklibc-dev recommends no packages. libklibc-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571044: [Debian-hebrew-package] Bug#571044: FYI: daily images borked; cause not yet known
On Wednesday 24 February 2010, أحمد المحمودي wrote: So, after reading #570581, is this actually a fribidi or a newt bug ? It can probably be argued that it's both :-) In newt for not initializing and in fribidi for not terminating. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571044: [Debian-hebrew-package] Bug#571044: Seeing this with debconf prompts
On Tuesday 23 February 2010, أحمد المحمودي wrote: That's debconf right ? Both debconf D-I use newt, am I right about this ? Yes, that's correct. You should probably also be able to reproduce the issue using whiptail. Note that D-I uses cdebconf (C implementation) and not debconf (perl implementation). That could possibly make a difference, although I doubt it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571044: fribidi: new version causes regressions in Debian Installer
Package: fribidi Version: 0.19.2-1 Severity: serious Tags: d-i We're seeing regressions in the newt frontend with the new version of the fribidi udeb, as these screenshots show: http://people.debian.org/~fjp/tmp/d-i/daily-borked2.png http://people.debian.org/~fjp/tmp/d-i/daily-borked3.png Note the line with the window title and the Go Back button. If I build a D-I image using the fribidi version from testing, the problems disappear. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570749: vlc-data: file conflict with Lenny version of vlc
Package: vlc-data Version: 1.0.5-1 Severity: serious I backported vlc myself for Lenny from unstable. During the upgrade (from version 0.8.6.h-4+lenny2) I got the following error: Unpacking vlc-data (from .../vlc-data_1.0.5-1~bpo1_all.deb) ... dpkg: error processing /var/cache/apt/archives/vlc-data_1.0.5-1~bpo1_all.deb (--unpack): trying to overwrite `/usr/share/pixmaps/vlc.png', which is also in package vlc As I did not make any changes that would affect this, I expect the file conflict will also affect Lenny-Squeeze upgrades. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570906: w3m: Recommends for migemo should be lowered to Suggests
Package: w3m Version: 0.5.2-2.1 Justification: Policy 7.2 Severity: serious Given the package description for migemo installing it as a Recommends and thus by default for all users of w3g is IMO not correct. Recommends should only be used (see policy 7.2) for packages that are found together in all but unusual installation. It is especially problematic because of the very heavy dependencies migemo has: it pulls in emacs and ruby. Both of those are completely irrelevant for w3m's base functionality and I would think that migemo is only relevant for Japanese users. So IMO it completely fails the requirements for a status as Recommends. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages w3m depends on: ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libgc1c21:6.8-1.2conservative garbage collector for ii libgpm2 1.20.4-3.3 General Purpose Mouse - shared lib ii libncurses5 5.7+20090803-2 shared libraries for terminal hand ii libssl0.9.8 0.9.8k-8 SSL shared libraries ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages w3m recommends: ii ca-certificates 20090814 Common CA certificates Versions of packages w3m suggests: ii man-db2.5.7-1on-line manual pager ii menu 2.1.43 generates programs menu for all me pn migemonone (no description available) ii mime-support 3.48-1 MIME files 'mime.types' 'mailcap pn w3m-elnone (no description available) pn w3m-img none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551646: installation-reports: [i386] installation failed using netboot
screen on PC hangs, the splash screen and the boot prompt does not appear last line of the screen: Trying to load: pxelinux.cfg/default We've had another report of the same issue where the problem was identified. It's a known limitation of syslinux, which is documented in the installation guide. See the Note here: http://www.debian.org/releases/lenny/i386/ch04s05.html.en Sorry for the late reply. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512740: Sparc disk labels broken on LDOM and Parallel installs
On Sunday 14 February 2010, Jurij Smakov wrote: 1. dh-di needed for build of partman-base is not pulled in as a result of 'apt-get build-dep debian-installer', probably should be? No: base-installer is a separate source package and thus has its own build deps. I just forgot to include a step to install those (but luckily DDs are smart enough to figure such minor omissions out by themselves ;-) 2. Firmware loading is broken in the mini iso image, error is 'mountmedia not found'. Added now for future builds. Please 'svn up'. 3. The installation is still affected by the kernel issue where it misreports the architecture and SILO installs the incorrect second-stage bootloader as a result. Correct. The installer still uses 2.6.30 and the bug is related to the kernel version that's running when silo is installed. It'll get solved when we switch to 2.6.32, which should happen soon after the (delayed) D-I alpha1 release gets out. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002141742.20722.elen...@planet.nl
Bug#569763: I cannot install lenny 5.04 mini.iso because of problem configuring DHCP.
merge 569763 569761 severity 569763 normal tags 569763 moreinfo thanks On Sunday 14 February 2010, Patrick Naylor wrote: Comments/Problems: The network modem is detected. The DHCP configuration failed. I cannot continue with the installing process. Being loaded at the same hw the lenny 5.03 mini.iso configure DHCP without problems. Nothing has changed in the installer itself that would explain this change in behavior. But the updated Lenny installer does use an updated kernel, which could possibly be a factor. Comments/Problems: Using Debian Squeeze netinst (mini.iso) I can make the installation but after rebooting the system for the first time, I have no internet conection. The modem is detected. I excecute 'ifdown eth1' then 'ifup eth1' and appears the DHCPDESCOVER ending with No DHCP offers received. I have checked /etc/hosts, /etc/network/interfaces, /etc/resolv.conf and they all are OK. This shows that DHCP sometimes does work with a current kernel (because DHCP did succeed during the installation). Modem: Motorola SB5101 Surfboard Cable Modem. After searching on Google it seems this is an external modem, which means that it is extremely unlikely that the installer is the problem here. In almost all cases of DHCP failing the problem is local. The most likely cause of the problem is hardware. Possibly a faulty cable. Another option is that your modem is not 100% standards compliant. I'm very tempted to close your report because it really is extremely unlikely that this is an installer or even a kernel problem. I suggest asking for help on for example the debian-user mailing list to figure out the real cause of the problem. You could also try using a network packet sniffer like wireshark or tcpdump to help figure out what's happening. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002141828.17481.elen...@planet.nl
Bug#569719: cdrom: sparc testing 20100208 will not boot after CD install, stuck at openboot.
reassign 569719 linux-kernel-di-sparc-2.6 1.49 severity 569719 important thanks On Saturday 13 February 2010, James Boughton wrote: Installation from the three CD's for the Feb 8, 2010 build of sparc testing seems to go without a hitch. The problem is that the system will not then boot from the hard disk (IDE). This is a known issue caused by a bug in the 2.6.30 kernel the installer is currently using. It will be fixed once we switch to the 2.6.32 kernel for the installer. Please see http://bugs.debian.org/565639 for details. It also mentions a way to fix the issue manually. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002141854.20376.elen...@planet.nl
Bug#512740: Sparc disk labels broken on LDOM and Parallel installs
On Tuesday 09 February 2010, Stefano Zacchiroli wrote:
On Mon, Feb 08, 2010 at 10:04:05PM +, Jurij Smakov wrote:
My main concern is whether it affects installer in any adverse way, so
if you could arrange for an installer image to be built with the
modified parted, we could do some testing. I don't have access to a
machine which supports LDOMs, but I could at least confirm that it
does not introduce any regressions.
Personally, I'm not very proficient in d-i (read: not at all), so I'm
getting -boot into the loop forwarding your request, for help. Bottom
line for d-i, to test the patch proposed to fix #512740, we need a d-i
sparc image to check for regression on sparc. The patch is attached for
your convenience, see bug log for full context.
I've read through the patch, but must admit I don't understand it. What
seems to be missing is *how* exactly it fixes the problem.
And somehow I doubt this patch stands on its own. I would think that it is
a requirement for patches in other packages (such as partman). If that is
true, then testing the patch in isolation is not much use (as applying it
on its own would not fix the reported issue anyway).
Also, I question the definition of (unused?) tags for usr, var, home etc.
What's the purpose of that? How's that supposed to be used? Does it mean
you're not allowed to put e.g. /srv on a separate partition as there's no
tag for it?
More porter input is definitely needed here.
Below are instructions for building a custom D-I image that includes a
patched libparted and partman. It's not that hard.
Cheers,
FJP
0) preparation
- check out D-I SVN
- install build deps for debian-installer
1) build patched parted
- build parted with the patch (preferably with increased package version)
- install the lib and -dev packages
- suggestion: install 'parted' and test that before continuing
2) build partman against the patched libparted
- cd to packages/partman/partman-base
- increase package version ('dch')
- debuild
3) build a D-I image
- cd to installer/build
- cp ../../partman/*.udeb ./localudebs
- cp all (lib)parted udebs (from the first step) to ./localudebs
- echo partman-base ./pkg-lists/local
# This will include the custom udebs in the D-I initrd and thus ensure
# they'll be used instead of the versions in the archive.
- make reallyclean; make build_netboot
# Instead of build_netboot you can also use build_miniiso.
4) test
- boot the installer from the image you'll find under ./dest
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568639: debian-installer: winxp partition detected, but not added to grub.cfg
reassign 568639 grub-pc 1.98~20100115-1 severity 568639 important thanks On Saturday 06 February 2010, Miroslav Rudisin wrote: At the end of installation of debian testing from netboot.tar.gz (build 20100122) the windows xp partition was correctly detected, because the dialog if you see all your OS here, everything will be ok appeared. So it looks like a grub issue rather than an os-prober issue. Reassigning accordingly. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568381: debconf segfauls with DEBIAN_FRONTEND=text
On Friday 05 February 2010, Colin Watson wrote: On Thu, Feb 04, 2010 at 07:52:23PM +, Colin Watson wrote: I've traced this to Colin's commit that adds the passthrough frontend (r59807). If I revert that the text frontend works fine again. Fixed in r62177. I've asked Otavio on IRC if it's OK to upload this, since I don't want to inadvertently stomp on d-i release preparation. Thanks a lot Colin. Works fine again now. AFAIK Otavio is planning another D-I upload (a few other components migrated only a few days ago), so it would be nice to get this in especially as without it s390 is unusable. So I've gone ahead and uploaded with 'high' priority. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568529: overwrites MBR of installation medium
reassign 568529 grub-installer 1.49 severity 568529 serious thanks On Friday 05 February 2010, Piotr Lewandowski wrote: I'm aware that device enumeration issues were reported in #517563 and #516280 and are present in errata for lenny release RC2, but I believe that installer should not overwrite installation medium under any circumstances. Agreed. But I'm lowering the severity to serious (still not suitable for release) as a boot sector can be repaired. I would not expect any actual data loss. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568381: debconf segfauls with DEBIAN_FRONTEND=text
On Thursday 04 February 2010, Frans Pop wrote: But I can confirm as I'm also seeing a segfault during an installation on s390. During mirror selection (but not 100% reliably). And can also confirm for amd64 in Virtualbox, also during mirror selection. And it does not go away if I recompile cdebconf (tried for amd64). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568381: debconf segfauls with DEBIAN_FRONTEND=text
On Thursday 04 February 2010, Martin Michlmayr wrote: Marko Jung reported that d-i segfaults when you use DEBIAN_FRONTEND=text. I can reproduce this. I've traced this to Colin's commit that adds the passthrough frontend (r59807). If I revert that the text frontend works fine again. It may possibly have something to do with the progress bar STEP increasing to a value higher than the specified maximum, but that's a guess. Someone more at home in C than I will have to look deeper than that. Colin, do you have time? Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568381: debconf segfauls with DEBIAN_FRONTEND=text
On Thursday 04 February 2010, Otavio Salvador wrote: On Thu, Feb 4, 2010 at 4:19 PM, Frans Pop elen...@planet.nl wrote: And it does not go away if I recompile cdebconf (tried for amd64). ^^^-- This is similar to what happened in powerpc to me. I have no glue why :-( Really? See above. Also, the crash happens in a totally different place than it did on ppc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559815: gcc warnings about array bounds in Hercules
Just happened to be looking at the BTS... Thorsten Glaser wrote: You might want to have a look at all these gcc warnings about array accesses being below/above array bounds, though. There may be more security issues hiding. These warnings have been fixed in the upcoming upstream release. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567337: Regression: '::' prefix for targets no longer works
Package: dosfstools Version: 3.0.8-1 Severity: serious Tags: d-i Justification: Breaks Debian Installer With the new version we're getting the following errors during builds of images for D-I. On i386: mcopy -i./tmp/hd-media/boot.img ./tmp/hd-media/vmlinuz ::linux Cannot initialize '::' On ia64: mmd -i./tmp/cdrom/boot.img ::/efi Cannot initialize '::' After downgrading to 3.0.7-1 everything works again. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.33-rc5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dosfstools depends on: ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib dosfstools recommends no packages. dosfstools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
On Tuesday 19 January 2010, dann frazier wrote: This fixes the issue for me, can you verify? zelenka.debian.org:~dannf/linux-image-2.6.18-6-s390_2.6.18.dfsg.1-27~562 525.testfix.1_s390.deb Works for me too. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565433: localization-config-deb: udeb depends on debconf
Package: localization-config-udeb
Version: 1.06
Severity: serious
A dependency on debconf was added, but debconf is not a valid udeb.
This incorrect dependency was added for some reason in today's upload.
If a dependency on debconf is needed (Lintian warning?), then please add
${misc:Depends} instead. This should automatically result in a correct
dependency on cdebconf-udeb.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564489: multipath-udeb: Has depedency on multipath-tools, which does not exist
found 564489 0.4.8+git0.761c66f-6 thanks Reopening as the patch was applied incorrectly. The --udeb option should be added to dh_makeshlibs, not to dh_shlibdeps! P.S. Note that you also have build failures on mips and mipsel. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564489: multipath-udeb: Has depedency on multipath-tools, which does not exist
Package: multipath-udeb Version: 0.4.8+git0.761c66f-5 Severity: serious Tags: d-i multipath-udeb currently has a dependency on multipath-tools. This is incorrect as no such udeb exists. Please fix the packaging so this dependency is no longer generated. If help with that is needed, please try contacting the debian-boot list. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564489: multipath-udeb: Has dependency on multipath-tools, which does not exist
tags 564489 patch thanks The correct fix for this is to tell the build tools to look in multipath-udeb for libraries when building the udeb (instead of looking in multipath-tools). The resulting self-dependency is automatically filtered out. Needed change in debian/rules: dh_installman - dh_makeshlibs + dh_makeshlibs --add-udeb=multipath-udeb dh_link -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
On Sunday 03 January 2010, dann frazier wrote: Thanks. This suggests that the fixes for CVE-2009-0029 are causal. To verify, can you test this kernel which drops only those fixes? zelenka.debian.org:~dannf/linux-headers-2.6.18-6-s390_2.6.18.dfsg.1-26et ch1+nocve20090029_s390.deb s/headers/image/ :-) Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-26etch1+nocve20090029) [...] mordor login: Works! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562190: mac-fdisk: udebs should depend on libc6-udeb instead of libc6
On Saturday 02 January 2010, Michael Schmitz wrote: I've build tested the attached patch on a porter box and to me the result looks good. I can build it on my powerbook but testing it (short of installing it on I have considered doing an NMU, but was scared off by the huge amount of compilation warnings. that system, which will hardly test whether it works with libc6-udeb) is another matter. That's not a problem. The only thing to check is that the dependency is correct. What _is_ mac-fdisk udeb still being used for these days?? Maybe time to retire it? I have no idea. powerpc is an architecture I know very little about as I've never had the hardware. If it's still useful for anything, it probably is manual troubleshooting and rescue. I've no idea if it offers any advantages over regular fdisk and/or parted. A decision to retire the udebs should be made by the powerpc and m68k [1] porters. Cheers, FJP [1] Note that even though m68k is no longer a release arch, it is still being maintained to some degree, including D-I support for it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
On Saturday 02 January 2010, you wrote: Can you try: zelenka.debian.org:~dannf/linux-image-2.6.18-6-s390_2.6.18.dfsg.1-26etch 1+div64_s390.deb Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-26etch1+div64) [...] Failed to execute /init Kernel panic - not syncing: No init found. Try passing init= option to kernel. If that *doesn't* work, can you then try: zelenka.debian.org:~dannf/linux-image-2.6.18-6-s390_2.6.18.dfsg.1-24+cve 20090029_s390.deb Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-24+cve20090029) Failed to execute /init Kernel panic - not syncing: No init found. Try passing init= option to kernel. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
On Tuesday 29 December 2009, dann frazier wrote: I don't see an obvious cause for the failure. Can you try booting 24etch1 in an effort to bisect the failure? In case you can't find the deb (I couldn't) I've built one that you can find in my home directory on zelenka.debian.org. Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-24etch1) (da...@debian.org) [...] [...] Freeing unused kernel memory: 100k freed Failed to execute /init Kernel panic - not syncing: No init found. Try passing init= option to kernel. There's a suspicious similarity to [1] maybe? I won't be able to compile any kernels myself on this one, but I can test what you build. [1] http://lists.debian.org/debian-s390/2009/07/msg2.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562143: apt is no longer in base system created by debootstrap?
Torsten Werner wrote: The Build-Essential: yes field has been updated 2 months ago to better match the declared Depends in the package build-essential as requested in bug #548801. It seems there is a misunderstanding about the purpose of the Build-Essential flag then. Obviously it is not to tag packages that are dependencies of the build-essential meta package. That would make the flag rather redundant as you'd get the same effect by just installing build-essentials. The real purpose is that it should contain any packages that are not essential themselves, but are required to set up a working base system for a buildd. From that perspective apt should be tagged Build-Essential. Simply because without apt you don't have a working build system. And build-essential should of course also be tagged, but IMO *not* any packages on which build-essential already depends. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562143: apt is no longer in base system created by debootstrap?
On Sunday 27 December 2009, Kurt Roeckx wrote: On Sun, Dec 27, 2009 at 01:39:28PM +0100, Frans Pop wrote: From that perspective apt should be tagged Build-Essential. Simply because without apt you don't have a working build system. apt is not and never was needed to build a package and therefor is not build essential. The buildds never required apt to be in the chroots until recently. Having apt in the chroot however has always been handy. Right, and existing tools depend on the fact that it has always been tagged Build-Essential. You can argue about changing that, but if you do you will also need to agree on a transition period. Because it is completely valid to e.g. have use Lenny's cowbuilder for a sid build environment, the current change breaks those tools. Modifying the tools in unstable will only fix the issue for people already running unstable or testing. IMO the correct action for now is to revert the changes. Then agree on how things should look in the future and give the relevant packages notice (via BRs and/or d-d-a) so they can adjust for Squeeze. Then when Sqeeze has been released for some time, the Build-Essential tags could be changed. The debootstrap buildd variant should probably add that, just like it should probably add sudo and/or fakeroot and debfoster. It's not something that belongs in the Packages file. Personally I think adding apt in debootstrap would be OK (especially as the minbase variant also includes apt). However, any other tools should IMO be installed in the chroot by the tools that require them, not by debootstrap. I'm also not sure why pbuilder, cowbuilder or whatever should use the buildd variant, they're not buildds. Probably because the buildd variant is a natural fit for creating package build environments. I see no reason why it should be limited to only official buildds. Maybe debootstrap needs a build-essential variant and they should use that and add the packages that they need. I don't see any need for an extra variant in debootstrap. I agree with the last part of the sentence. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
Package: linux-2.6 Severity: serious Version: 2.6.18.dfsg.1-26etch1 Tags: d-i X-Debbugs-CC: da...@debian-org While testing the update for oldstable of debian-installer on my Hercules s390 emulator, I found that the new kernel fails to boot. It fails to execute init after loading the initramfs. The current oldstable version (2.6.18.dfsg.1-24) boots fine. And the current oldstable D-I (which has 2.6.18.dfsg.1-18) also boots fine. Attached a diff between the boot messages. This diff is for an installed system, but I get the exact same Failed to execute /init error when booting D-I which suggests that the problem is not in the initrd but in the kernel. The diff for the lines bringing up CPUs is mostly due to two messages getting mixed up. Probably not significant. --- s390_etch.cur 2009-12-25 13:37:55.0 +0100 +++ s390_etch.new 2009-12-25 13:53:15.0 +0100 @@ -1,57 +1,55 @@ -Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-24) (da...@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Sat Dec 27 08:51:06 UTC 2008 +Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-26etch1) (da...@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Thu Nov 5 21:15:26 UTC 2009 We are running native (31 bit mode) This machine has an IEEE fpu Detected 2 CPU's -Boot cpu address 0 +Boot cpu address 1 Built 1 zonelists. Total pages: 65536 Kernel command line: root=/dev/disk/by-path/ccw-0.0.0122-part1 BOOT_IMAGE=0 PID hash table entries: 2048 (order: 11, 8192 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) -Memory: 252928k/262144k available (2195k kernel code, 0k reserved, 789k data, 100k init) +Memory: 252928k/262144k available (2195k kernel code, 0k reserved, 792k data, 100k init) Write protected kernel read-only data: 0x227000 - 0x29afff Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 -cpu 0 phys_idx=0 vers=00 ident=002623 machine=3090 unused= +cpu 0 phys_idx=1 vers=00 ident=102623 machine=3090 unused= +cpu 1 phys_idx=0 vers=00 ident=002623 machine=3090 unused= Brought up 2 CPUs -migration_cost=cpu 1 phys_idx=1 vers=00 ident=102623 machine=3090 unused=1000 +migration_cost=1000 checking if image is initramfs... it is Freeing initrd memory: 3005k freed NET: Registered protocol family 16 debug: Initialization complete cio: Was not able to determine available CHSCs. NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 98304 bytes) TCP bind hash table entries: 4096 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 4096) TCP reno registered hypfs: diag 204 not working.3hypfs: Initialization failed with rc = -61. audit: initializing netlink socket (disabled) -audit(1261744119.616:1): initialized +audit(1261745535.320:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) RAMDISK driver initialized: 16 RAM disks of 24576K size 1024 blocksize Channel measurement facility using basic format (autodetected) qdio: loading QDIO base support version 2 qdio : Not all CHSCs supported. Continuing. TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 10 lo: Disabled Privacy Extensions IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 Freeing unused kernel memory: 100k freed -Loading, please wait... -Begin: Loading essential drivers... ... -Done. -Begin: Running /scripts/init-premount ... -[...] +Failed to execute /init +Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Bug#562503: #562503 upgrade of man-db hangs during postinst, consumes 100% cpu for over 30 minutes
On Friday 25 December 2009, Frans Pop wrote: I'm seeing the same issue in an amd64/sid pbuilder environment when mandb gets installed as one of the build dependencies of cdebconf-entropy. To show the severity of the issue, this is from my sparc box during a regular upgrade (last one was 2 months ago): 9630 man 20 0 5448 1960 680 R 98.8 0.2 54:11.05 mandb And no idea how much longer it's going to take. One problem is that there is absolutely no indication man-db is doing anything special. It just shows: Processing triggers for man-db ... Users are very likely to conclude something is in an endless loop. And even if it did show some king of progress, processes that take so much time IMO shouldn't be done from maintainer scripts. An upgrade should be completed within a reasonable time to avoid the risk of leaving random services of unrelated packages stopped for so long. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562398: anna: fails if multiple versions of a udeb in Packages file
Package: anna Severity: serious Yesterday I uploaded some packages, including base-installer and hw-detect. Today during a test install from a local build this resulted in: Failed to load installer component loading base-installer failed for unknown reasons. Aborting. The syslog does not show much info, but this is interesting: [...] anna: DEBUG: retrieving base-installer 1.104 anna: DEBUG: retrieving base-installer 1.104 anna: DEBUG: retrieving bootstrap-base 1.104 [...] anna: DEBUG: retrieving disk-detect 1.74 anna: DEBUG: retrieving disk-detect 1.74 [...] So the error is probably the result of anna trying to install the same package twice. I ran anna a second time and that finished without errors and the rest of the installation also completed without problems, so the impact is limited. The packages file on my local mirror shows the cause of the problem. It contains two versions of both base-installer (1.103, 1.104) and disk-detect (1.73, 1.74). Both are arch:all packages, so this is probably the simple result of the recent changes in the archive and the packages not yet being built for all arches. We need to at least make sure anna does not try to process the same package twice. It already seems to return the correct (highest) version. The actual fix is probably in libd-i rather than anna itself. This issue will only manifest for packages that have both arch:any and arch:all udebs, and only while it has not been built for all arches. So the problem will be fairly rare [1], but IMO it should still be fixed as it looks extremely fatal. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562398: anna: fails if multiple versions of a udeb in Packages file
On Thursday 24 December 2009, Frans Pop wrote: So the error is probably the result of anna trying to install the same package twice. The exit code of anna was 8, which matches an error during unpack or configure. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562190: mac-fdisk: udebs should depend on libc6-udeb instead of libc6
Package: mac-fdisk Version: 0.1-15 Severity: serious Tags: patch d-i The udebs do not get a correct dependency on libc6-udeb, but instead depend on the regular libc6 package. We've ignored this for previous releases, but for Squeeze it's RC because of britney support for udebs. I originally thought this could be solved with a binNMU, but that turned out not to be enough. The basic reason is that the control file does not set the correct package type for the udeb. Doing that also allows to simplify debian/rules a bit as the package type triggers all the necessary magic for udebs in debhelper. I've build tested the attached patch on a porter box and to me the result looks good. diff -u mac-fdisk-0.1/debian/rules mac-fdisk-0.1/debian/rules --- mac-fdisk-0.1/debian/rules +++ mac-fdisk-0.1/debian/rules @@ -164,9 +164,8 @@ dh_strip -p$(packudeb); \ dh_installdeb -p$(packudeb); \ dh_shlibdeps -p$(packudeb); \ - dh_gencontrol -p$(packudeb) -- -isp -DSubarchitecture=$(mac_subarches) -fdebian/files~; \ - dpkg-distaddfile $(packudeb)_$(shell dpkg-parsechangelog | grep ^Version: | cut -d ' ' -f 2)_$(BUILDARCH).udeb debian-installer standard; \ - dh_builddeb -p$(packudeb) --filename=$(packudeb)_$(shell dpkg-parsechangelog | grep ^Version: | cut -d ' ' -f 2)_$(BUILDARCH).udeb; \ + dh_gencontrol -p$(packudeb); \ + dh_builddeb -p$(packudeb); \ fi # build pmac-fdisk-udeb on powerpc @@ -174,9 +173,8 @@ dh_strip -p$(packpudeb); \ dh_installdeb -p$(packpudeb); \ dh_shlibdeps -p$(packpudeb); \ - dh_gencontrol -p$(packpudeb) -- -isp -DSubarchitecture=$(pmac_subarches) -fdebian/files~; \ - dpkg-distaddfile $(packpudeb)_$(shell dpkg-parsechangelog | grep ^Version: | cut -d ' ' -f 2)_$(BUILDARCH).udeb debian-installer standard; \ - dh_builddeb -p$(packpudeb) --filename=$(packpudeb)_$(shell dpkg-parsechangelog | grep ^Version: | cut -d ' ' -f 2)_$(BUILDARCH).udeb; \ + dh_gencontrol -p$(packpudeb); \ + dh_builddeb -p$(packpudeb); \ fi define checkdir diff -u mac-fdisk-0.1/debian/control mac-fdisk-0.1/debian/control --- mac-fdisk-0.1/debian/control +++ mac-fdisk-0.1/debian/control @@ -38,6 +38,7 @@ interactive tool similar to PC fdisk. Package: mac-fdisk-udeb +XC-Package-Type: udeb Architecture: powerpc ppc64 m68k Priority: standard Section: debian-installer @@ -54,6 +55,7 @@ This is a minimal mac-fdisk package used by the debian-installer. Package: pmac-fdisk-udeb +XC-Package-Type: udeb Architecture: powerpc ppc64 Priority: standard Section: debian-installer
Bug#552497: hw-detect: file conflict with udev-udeb for /lib/udev/firmware.agent
tag 552497 - pending thanks There is a difference between the scripts. The hw-detect version writes some info to a file needed to support firmware loading. There are however two issues. 1) The custom script never gets included in initrds as hw-detect gets unpacked first and thus the original udev version of the script overwrites the modified hw-detect version. 2) The two scripts get out of sync when there are upstream changes to the script. Note that the current version of the original script also has a facility to register missing firmware. The hw-detect version does: echo $PHYSDEVDRIVER $FIRMWARE /tmp/missing-firmware While the udev version does: if [ -d /dev/.udev/ ]; then mkdir -p /dev/.udev/firmware-missing/ file=$(echo $FIRMWARE | sed -e 's#/#\\x2f#g') ln -s -f $DEVPATH /dev/.udev/firmware-missing/$file fi So, if we can somehow get the PHYSDEVDRIVER info from sysfs, we should be able to just use the original version. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552497: hw-detect: file conflict with udev-udeb for /lib/udev/firmware.agent
tag 552497 - pending thanks On Thursday 24 December 2009, Frans Pop wrote: There are however two issues. 1) The custom script never gets included in initrds as hw-detect gets unpacked first and thus the original udev version of the script overwrites the modified hw-detect version. 2) The two scripts get out of sync when there are upstream changes to the script. This is not true. I compared incorrect versions of the script. The custom script *can* be dropped without problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562014: dmidecode-udeb: should depend on libc6-udeb instead of libc6
tag 562014 pending
thanks
On Tuesday 22 December 2009, Frans Pop wrote:
The udeb does not get a correct dependency on libc6-udeb, but instead
depends on the regular libc6 package.
Given that the last maintainer upload for dmidecode was very long ago, I've
uploaded an NMU to the 5-day delayed queue.
The full debdiff (including changelog) for the upload is attached.
Cheers,
FJP
diff -u dmidecode-2.9/debian/rules dmidecode-2.9/debian/rules
--- dmidecode-2.9/debian/rules
+++ dmidecode-2.9/debian/rules
@@ -10,9 +10,6 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
-# This is the debhelper compatibility version to use.
-export DH_COMPAT=4
-
INSTALL = install
include /usr/share/dpatch/dpatch.make
@@ -58,7 +55,7 @@
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
- -$(MAKE) clean
+ $(MAKE) clean
dh_clean
@@ -80,39 +77,22 @@
# We have nothing to do by default.
# Build architecture-dependent files here.
-binary-arch: build install binary-dmidecode binary-dmidecode-udeb
-
-binary-dmidecode: install
+binary-arch: build install
dh_testdir
dh_testroot
- dh_installdocs -Ndmidecode-udeb
+ dh_installdocs
dh_installexamples
- dh_installman -Ndmidecode-udeb
- dh_installchangelogs -Ndmidecode-udeb CHANGELOG
- dh_link
- dh_strip -Ndmidecode-udeb
- dh_compress -Ndmidecode-udeb
- dh_fixperms -Ndmidecode-udeb
- dh_installdeb -Ndmidecode-udeb
- dh_shlibdeps -Ndmidecode-udeb
- dh_gencontrol -Ndmidecode-udeb
- dh_md5sums -Ndmidecode-udeb
- dh_builddeb -Ndmidecode-udeb
-
-binary-dmidecode-udeb: install
- dh_testdir
- dh_testroot
+ dh_installman
+ dh_installchangelogs CHANGELOG
dh_link
- dh_strip -pdmidecode-udeb
- dh_compress -pdmidecode-udeb
- dh_fixperms -pdmidecode-udeb
- dh_installdeb -pdmidecode-udeb
- dh_shlibdeps -pdmidecode-udeb
- # Don't write your stupid guesses to debian/files.
- dh_gencontrol -n -pdmidecode-udeb -- -fdebian/files~
- # Register file manually.
- dpkg-distaddfile $(UFILENAME) debian-installer optional
- dh_builddeb -pdmidecode-udeb --filename=$(UFILENAME)
+ dh_strip
+ dh_compress
+ dh_fixperms
+ dh_installdeb
+ dh_shlibdeps
+ dh_gencontrol
+ dh_md5sums
+ dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure
diff -u dmidecode-2.9/debian/control dmidecode-2.9/debian/control
--- dmidecode-2.9/debian/control
+++ dmidecode-2.9/debian/control
@@ -2,7 +2,7 @@
Section: utils
Priority: optional
Maintainer: Petter Reinholdtsen p...@debian.org
-Build-Depends: debhelper ( 3.0.0), dpatch
+Build-Depends: debhelper (= 6), dpatch
Standards-Version: 3.7.2
Package: dmidecode
@@ -18,6 +18,7 @@
hardware detection programs.
Package: dmidecode-udeb
+XC-Package-Type: udeb
Section: debian-installer
Architecture: i386 ia64 amd64 kfreebsd-i386 knetbsd-i386 kfreebsd-amd64
Depends: ${shlibs:Depends}
diff -u dmidecode-2.9/debian/changelog dmidecode-2.9/debian/changelog
--- dmidecode-2.9/debian/changelog
+++ dmidecode-2.9/debian/changelog
@@ -1,3 +1,13 @@
+dmidecode (2.9-1.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Correctly set package type for the udeb. Allows to simplify debian/rules
+and ensures a correct dependency on libc6-udeb. Closes: #562014.
+ * Update debhelper compat to version 6.
+ * Don't ignore errors during 'make clean'.
+
+ -- Frans Pop f...@debian.org Tue, 22 Dec 2009 05:13:24 +0100
+
dmidecode (2.9-1.1) unstable; urgency=low
* Non-maintainer upload.
only in patch2:
unchanged:
--- dmidecode-2.9.orig/debian/compat
+++ dmidecode-2.9/debian/compat
@@ -0,0 +1 @@
+6
Bug#562001: beep-udeb: should depend on libc6-udeb instead of libc6
Package: beep Version: 1.2.2-23 Severity: serious Tags: patch d-i X-Debbugs-CC: debian-b...@lists.debian.org The udeb does not get a correct dependency on libc6-udeb, but instead depends on the regular libc6 package. Personally I would recommend a switch to debhelper for the packaging as it's by far the simplest method to correctly build packages that have udebs, but if you want to avoid that, the attached patch will also get the correct dependencies. Only strange thing is that dpkg-shlibdeps versions the dependency for the deb as (= 2.7), but for the udeb as (= 2.10). I've been unable to find out why, but for us it does not matter. diff -u beep-1.2.2/debian/rules beep-1.2.2/debian/rules --- beep-1.2.2/debian/rules +++ beep-1.2.2/debian/rules @@ -34,7 +34,7 @@ clean: unpatch $(checkdir) $(checkroot) - -rm -rf $(TMP1) $(TMP2) debian/substvars debian/files build-stamp + -rm -rf $(TMP1) $(TMP2) debian/beep.substvars debian/beep-udeb.substvars debian/files build-stamp [ ! -f beep ] || $(MAKE) clean @@ -86,13 +86,14 @@ $(INSTALL_SCRIPT) debian/postinst debian/postrm debian/config \ $(TMP1)/DEBIAN po2debconf debian/templates $(TMP1)/DEBIAN/templates - dpkg-shlibdeps -Tdebian/substvars -dDepends $(TMP1)/usr/bin/beep - dpkg-gencontrol -ldebian/changelog -isp -Tdebian/substvars -p$(PKG1) \ + dpkg-shlibdeps -Tdebian/beep.substvars -dDepends $(TMP1)/usr/bin/beep + dpkg-shlibdeps -Tdebian/beep-udeb.substvars -dDepends $(TMP2)/usr/bin/beep -tudeb + dpkg-gencontrol -ldebian/changelog -isp -Tdebian/beep.substvars -p$(PKG1) \ -P$(TMP1) cd $(TMP1) find * -type f ! -regex '^DEBIAN/.*' -print0 | \ xargs -r0 md5sum DEBIAN/md5sums dpkg --build $(TMP1) .. - dpkg-gencontrol -ldebian/changelog -isp -Tdebian/substvars -p$(PKG2) \ + dpkg-gencontrol -ldebian/changelog -isp -Tdebian/beep-udeb.substvars -p$(PKG2) \ -P$(TMP2) -UHomepage -n$(PKG2)_$(VERSION)_$(ARCH).udeb dpkg --build $(TMP2) ../$(PKG2)_$(VERSION)_$(ARCH).udeb
Bug#562014: dmidecode-udeb: should depend on libc6-udeb instead of libc6
Package: dmidecode
Version: 2.9-1.1
Severity: serious
Tags: patch d-i
X-Debbugs-CC: debian-b...@lists.debian.org
The udeb does not get a correct dependency on libc6-udeb, but instead
depends on the regular libc6 package.
The basic reason is that the control file does not set the correct package
type for the udeb. Doing that also allows to simplify debian/rules.
The patch also includes a few other packaging improvements:
* Update debhelper compatibility to version 6.
* Don't ignore errors during 'make clean' (Linian warning).
The debdiff for the resulting binary packages is clean.
diff -u dmidecode-2.9/debian/rules dmidecode-2.9/debian/rules
--- dmidecode-2.9/debian/rules
+++ dmidecode-2.9/debian/rules
@@ -10,9 +10,6 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
-# This is the debhelper compatibility version to use.
-export DH_COMPAT=4
-
INSTALL = install
include /usr/share/dpatch/dpatch.make
@@ -58,7 +55,7 @@
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
- -$(MAKE) clean
+ $(MAKE) clean
dh_clean
@@ -80,39 +77,22 @@
# We have nothing to do by default.
# Build architecture-dependent files here.
-binary-arch: build install binary-dmidecode binary-dmidecode-udeb
-
-binary-dmidecode: install
+binary-arch: build install
dh_testdir
dh_testroot
- dh_installdocs -Ndmidecode-udeb
+ dh_installdocs
dh_installexamples
- dh_installman -Ndmidecode-udeb
- dh_installchangelogs -Ndmidecode-udeb CHANGELOG
- dh_link
- dh_strip -Ndmidecode-udeb
- dh_compress -Ndmidecode-udeb
- dh_fixperms -Ndmidecode-udeb
- dh_installdeb -Ndmidecode-udeb
- dh_shlibdeps -Ndmidecode-udeb
- dh_gencontrol -Ndmidecode-udeb
- dh_md5sums -Ndmidecode-udeb
- dh_builddeb -Ndmidecode-udeb
-
-binary-dmidecode-udeb: install
- dh_testdir
- dh_testroot
+ dh_installman
+ dh_installchangelogs CHANGELOG
dh_link
- dh_strip -pdmidecode-udeb
- dh_compress -pdmidecode-udeb
- dh_fixperms -pdmidecode-udeb
- dh_installdeb -pdmidecode-udeb
- dh_shlibdeps -pdmidecode-udeb
- # Don't write your stupid guesses to debian/files.
- dh_gencontrol -n -pdmidecode-udeb -- -fdebian/files~
- # Register file manually.
- dpkg-distaddfile $(UFILENAME) debian-installer optional
- dh_builddeb -pdmidecode-udeb --filename=$(UFILENAME)
+ dh_strip
+ dh_compress
+ dh_fixperms
+ dh_installdeb
+ dh_shlibdeps
+ dh_gencontrol
+ dh_md5sums
+ dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure
diff -u dmidecode-2.9/debian/control dmidecode-2.9/debian/control
--- dmidecode-2.9/debian/control
+++ dmidecode-2.9/debian/control
@@ -2,7 +2,7 @@
Section: utils
Priority: optional
Maintainer: Petter Reinholdtsen p...@debian.org
-Build-Depends: debhelper ( 3.0.0), dpatch
+Build-Depends: debhelper (= 6), dpatch
Standards-Version: 3.7.2
Package: dmidecode
@@ -18,6 +18,7 @@
hardware detection programs.
Package: dmidecode-udeb
+XC-Package-Type: udeb
Section: debian-installer
Architecture: i386 ia64 amd64 kfreebsd-i386 knetbsd-i386 kfreebsd-amd64
Depends: ${shlibs:Depends}
only in patch2:
unchanged:
--- dmidecode-2.9.orig/debian/compat
+++ dmidecode-2.9/debian/compat
@@ -0,0 +1 @@
+6
Bug#551929: [Adduser-devel] Bug#551929: deluser: creates backup of user's files when not requested
On Friday 18 December 2009, Stephen Gran wrote: Both of these requests are completely reasonable, but conflict, so I think probably what I'll do is go for option b, and have deluser fail if --backup-to is set but --backup isn't. Given that we ship a default of '.', that should at least be the pronciple of least surprise. Thoughts? Objections? If not, I'll commit something tomorrow. It is obviously completely unacceptable to ignore the BACKUP = 0 setting from the config file. Given that wanting to set a different default location for backups in the config file without wanting to enable backups by default seems reasonable, option b looks like the more reasonable solution to me. For reference, option b) was: --backup-to should loudly refuse to act without --backup However, *if* the config file is read before parsing options, there is another solution: make --backup-to imply --backup, but *only* if passed on the command line. This may require slightly more complex coding, but should be possible to implement. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558980: Fwd: Re: access to hppa machine to work on Bug#558980
--- Forwarded message (begin) From: Stephen Leake stephen_le...@stephe-leake.org Date: Sun, 13 Dec 2009 16:03:24 +0100 Frans Pop gave me access to his machine. I have some more information on the bug. If I compile from full GNADE source (not using the GNADE dynamic or static libraries), the code works. With the dynamic library, I get a SIGSEGV, somewhere in the program startup, before any user code. With the static library, I get a stack overflow (caught and reported by the Ada runtime), during elaboration of a compiler-provided container library. So the problem is related to libraries, which means it's probably in the linker and/or loader somewhere. It seems clear that no user will be able to use GNADE in its current form on hppa, so I should remove hppa from the arch list in debian/control for the squeeze release. If there is some more debugging I could do? --- Forwarded message (end) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558980: Fwd: Re: access to hppa machine to work on Bug#558980
--- Forwarded message (begin) From: Carlos O'Donell car...@systemhalted.org Date: Sun, 13 Dec 2009 16:39:17 +0100 On Sun, Dec 13, 2009 at 10:03 AM, Stephen Leake wrote: Frans Pop gave me access to his machine. I have some more information on the bug. If I compile from full GNADE source (not using the GNADE dynamic or static libraries), the code works. What does from full GNADE source mean? With the dynamic library, I get a SIGSEGV, somewhere in the program startup, before any user code. Export LD_DEBUG=all, run the program, this will tell you what the dynamic loader is doing every step of the way. If you see transferring control: then the dynamic loader has just handed off control the real program, and any fault after that is possibly related to the real program. With the static library, I get a stack overflow (caught and reported by the Ada runtime), during elaboration of a compiler-provided container library. Could you please define during elaboration? So the problem is related to libraries, which means it's probably in the linker and/or loader somewhere. It seems clear that no user will be able to use GNADE in its current form on hppa, so I should remove hppa from the arch list in debian/control for the squeeze release. Thanks for the help. Cheers, Carlos. --- Forwarded message (end) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560068: libslang2: Library reduction for Debian Installer fails
Package: libslang2 Version: 2.2.2-1 Severity: serious Tags: d-i Justification: Breaks Debian Installer image builds Since the update of libslang2 earlier today building Debian Installer images on amd64 fails during library reduction (mklibs) with: /usr/bin/ld: /usr/lib//libslang.a(sldisply.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC /usr/lib//libslang.a: could not read symbols: Bad value collect2: ld returned 1 exit status Command failed with status 1 : gcc -nostdlib -nostartfiles -shared -Wl,-soname=libnewt.so.0.52 -unewtVerticalScrollbar -unewtPopHelpLine -unewtTextboxSetHeight -unewtFormSetHeight -unewtCompactButton -unewtListbox -unewtCheckboxSetFlags -unewtSetColors -unewtListboxSetCurrent -unewtCenteredWindow -unewtListboxAppendEntry -unewtDrawForm -unewtScaleSet -unewtForm -unewtPushHelpLine -unewtFormSetBackground -unewtFormWatchFd -unewtDefaultColorPalette -unewtFormSetTimer -unewtRefresh -unewtFormAddComponent -unewtPopWindow -unewtGetScreenSize -unewtSetHelpCallback -unewtScale -unewtFormRun -unewtFormSetWidth -unewtCls -unewtFormSetCurrent -unewtEntry -unewtInit -unewtRunForm -unewtListboxGetCurrent -unewtCheckbox -unewtComponentTakesFocus -unewtDrawRootText -unewtFormDestroy -unewtTextboxSetText -unewtFormAddComponents -unewtFinished -unewtTextbox -unewtEntrySet -unewtLabel -unewtTextboxGetNumLines -o ./tmp/netboot/tree/lib/libnewt.so.0.52-so /usr/lib//libnewt_pic.a -Wl,--version-s cript=/usr/lib//libnewt_pic.map -lgcc -L./tmp/netboot/tree/lib -L./tmp/netboot/tree/usr/lib -L./tmp/netboot/udeblibs -L./tmp/netboot/tree/usr/lib/cdebconf/frontend -L/lib/ -L/usr/lib/ -L/usr/X11R6/lib/ -L./tmp/netboot/tree//usr/lib/cdebconf -lslang -lc I've verified that the udeb used during the D-I build has the same version as the libslang2 packages installed on the system. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libslang2 depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries Versions of packages libslang2 recommends: ii libpng12-01.2.41-1 PNG library - runtime libslang2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538354: sysconfig-hardware: Fails to activate extra dasd when system shell is dash
As this grave bug, which affects any new Squeeze installation for s390 and any upgrade from Lenny to Squeeze, has now remained unfixed for 4 months, even though it has been tagged pending for almost 2 months, I've uploaded an NMU to fix the issue. The debdiff for the upload is attached. It also includes a fix for the only other BR against the package (#523178). diff -Nru sysconfig-0.0.9/debian/changelog sysconfig-0.0.9+nmu1/debian/changelog --- sysconfig-0.0.9/debian/changelog 2009-04-09 09:14:52.0 +0200 +++ sysconfig-0.0.9+nmu1/debian/changelog 2009-12-02 02:57:19.0 +0100 @@ -1,3 +1,13 @@ +sysconfig (0.0.9+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Use bash as shell for hwup and hwdown. Closes: #523178. + * udev-net: quote variable to avoid syntax errors if it's empty. +Closes: #523178. + * Increase debhelper compatibility to 5. + + -- Frans Pop f...@debian.org Wed, 02 Dec 2009 02:00:15 +0100 + sysconfig (0.0.9) unstable; urgency=low * Don't use the deprecated PHYSDEVPATH interface. diff -Nru sysconfig-0.0.9/debian/compat sysconfig-0.0.9+nmu1/debian/compat --- sysconfig-0.0.9/debian/compat 2008-07-04 12:49:34.0 +0200 +++ sysconfig-0.0.9+nmu1/debian/compat 2009-12-02 02:56:18.0 +0100 @@ -1 +1 @@ -4 +5 diff -Nru sysconfig-0.0.9/debian/control sysconfig-0.0.9+nmu1/debian/control --- sysconfig-0.0.9/debian/control 2008-07-04 12:49:34.0 +0200 +++ sysconfig-0.0.9+nmu1/debian/control 2009-12-02 02:56:34.0 +0100 @@ -2,7 +2,7 @@ Section: admin Priority: optional Maintainer: Bastian Blank wa...@debian.org -Build-Depends: debhelper (= 4.0.0) +Build-Depends: debhelper (= 5.0.0) Standards-Version: 3.6.2 Package: sysconfig-hardware diff -Nru sysconfig-0.0.9/etc/sysconfig/scripts/hardware/udev-net sysconfig-0.0.9+nmu1/etc/sysconfig/scripts/hardware/udev-net --- sysconfig-0.0.9/etc/sysconfig/scripts/hardware/udev-net 2009-03-27 18:23:58.0 +0100 +++ sysconfig-0.0.9+nmu1/etc/sysconfig/scripts/hardware/udev-net 2009-12-02 01:59:24.0 +0100 @@ -11,7 +11,7 @@ ID=$(readlink /sys/$DEVPATH/device | sed -e 's,.*/,,') BUS=$(readlink /sys/$DEVPATH/device/subsystem | sed -e 's,.*/,,') -[ $BUS = ccwgroup ] BUS=ccw +[ $BUS = ccwgroup ] BUS=ccw read_config $BUS $ID diff -Nru sysconfig-0.0.9/sbin/hwdown sysconfig-0.0.9+nmu1/sbin/hwdown --- sysconfig-0.0.9/sbin/hwdown 2008-07-04 15:22:51.0 +0200 +++ sysconfig-0.0.9+nmu1/sbin/hwdown 2009-12-02 01:57:49.0 +0100 @@ -1,3 +1,3 @@ -#!/bin/sh +#!/bin/bash source /etc/sysconfig/scripts/hardware/hwdown $@ diff -Nru sysconfig-0.0.9/sbin/hwup sysconfig-0.0.9+nmu1/sbin/hwup --- sysconfig-0.0.9/sbin/hwup 2008-07-04 15:22:51.0 +0200 +++ sysconfig-0.0.9+nmu1/sbin/hwup 2009-12-02 01:57:57.0 +0100 @@ -1,3 +1,3 @@ -#!/bin/sh +#!/bin/bash source /etc/sysconfig/scripts/hardware/hwup $@
Bug#538086: installation-reports: Installation works, but neither is user created nor a root password set
reassign 538086 user-setup 1.23 retitle 538086 user-setup: Lenny version is incompatible with Squeeze/Sid tags 538086 lenny wontfix thanks On Wednesday 18 November 2009, Yaroslav Rozhylo wrote: Steps to reproduce: 1. Boot from CD debian-503-i386-businesscard.iso 2. Advanced Installation - KDE - Expert mode 3. LVM: / and /home 4. unstable 5. targeted initrd 6. choose hide passwords and root login through sudo 7. can't login after boot This is far from a standard installation... I had tried to reproduce the same with stable, max initrd and grub (not grub2) - everything was ok, withot errors. So, the problem is in point 4 or 5. It is your selection of unstable. Because it is impossible to anticipate on changes after a stable release, there is never a guarantee that a stable installer will work correctly to install testing or unstable. It looks like the problem you encountered is: http://bugs.debian.org/529475 Which was solved in the user-setup component of the installer in version 1.24: * No longer use the -m switch of chpasswd. It uses PAM now and no longer has this switch. The password will use settings from libpam-runtime, so MD5 by default. To install either testing or unstable, you should either - use the installer for Squeeze [1] - install stable using the Lenny installer and then upgrade BTW, you should have been able to find the cause of the problem fairly easily yourself by checking the syslog of the installation. Cheers, FJP [1] http://www.debian.org/devel/debian-installer/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552576: live-installer: should have a Standards-Version field
On Tuesday 27 October 2009, Frans Pop wrote: The live-installer source package not only has a udeb, but also a deb. This means that it must also have a Standards-Version field in debian/control. Only source packages that have *only* udebs are allowed to omit that field. When this is fixed the current Lintian override should be removed as well. Severity was set to serious as this is a policy violation, and also because it means the package will likely get rejected by DAK on a next upload. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552576: live-installer: should have a Standards-Version field
Package: live-installer Version: 13 Severity: serious The live-installer source package not only has a udeb, but also a deb. This means that it must also have a Standards-Version field in debian/control. Only source packages that have *only* udebs are allowed to omit that field. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552497: hw-detect: file conflict with udev-udeb for /lib/udev/firmware.agent
Package: hw-detect Version: 1.73 Severity: serious During a D-I build on armel I noticed the following: Unpacking udev-udeb (from udebs/udev-udeb.udeb) ... dpkg: warning: overriding problem because --force enabled: trying to overwrite '/lib/udev/firmware.agent', which is also in package hw-detect 0:1.73 This should be resolved. I vaguely recall a discussion between Joey and Marco about this, but am not sure which package is now suppose to provide the file. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552233: locales: cannot map archive header: Invalid argument
Package: locales Version: 2.10.1-2 Severity: serious During a regular upgrade from version 2.9.-25 I got the following error: Generating locales (this might take a while)... en_US.UTF-8...cannot map archive header: Invalid argument done Generation complete. I read #524483, but this looks to be a different issue: $ ls -al /usr/lib/locale/locale-archive ls: cannot access /usr/lib/locale/locale-archive: No such file or directory The system is rarely used, and thus infrequently updated, but has a clean unstable installation. The file system is mounted rw and has plenty of space. Manually creating the directory does not fix the problem: if I do that and then run 'dpkg-reconfigure locales', the directory gets deleted... -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc (sparc64) Kernel: Linux 2.6.26-1-sparc64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii libc6 [glibc-2.10-1] 2.10.1-2 GNU C Library: Shared libraries locales recommends no packages. locales suggests no packages. -- debconf information: locales/default_environment_locale: en_US.UTF-8 locales/locales_to_be_generated: en_US.UTF-8 UTF-8 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546834: debootstrap fails when invoked from lh_build
reassign 546834 util-linux 2.16-3 severity 546834 serious affects 546834 debootstrap tags 546834 d-i thanks On Wednesday 16 September 2009, Tak Auyeung wrote: lh_build failed and stopped in debootstrap phase. lh_build is set up to use sid for both bootstrap and chroot. Attached please find a log of lh_build (build.log) and a log of debootstrap (debootstrap.log) when it was invoked from lh_build. Thanks! Thanks for including the logs. As you can see in the debootstrap log, the real problem is in either util-linux or insserv. Setting up util-linux (2.16-3) ... install-info: warning: maintainer scripts should not call install-info anymore, install-info: warning: this is handled now by a dpkg trigger provided by the install-info: warning: install-info package; package util-linux should be updated. update-alternatives: using /bin/more to provide /usr/bin/pager (pager) in auto mode. insserv: Service checkroot has to be enabled to start service hwclock insserv: exiting now! dpkg: error processing util-linux (--configure): subprocess installed post-installation script returned error exit status 1 The install-info message is just a warning. The real problem looks to be a boot dependency error. Reassigning to util-linux. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545801: qcontrol: no longer works in lenny
On Wednesday 09 September 2009, Nis Martensen wrote: After installing the latest stable updates, qcontrol stopped working: qcontrol error: gpio_keys device not available A fixed version of the packages is now also available from the proposed-updates distribution, or it can be downloaded directly from a mirror: http://ftp.nl.debian.org/debian/pool/main/q/qcontrol/ You'll want the .deb with version '0.4.2-1lenny1' for either arm or armel. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545801: qcontrol: no longer works in lenny
tags 545801 pending
thanks
On Thursday 10 September 2009, Nis Martensen wrote:
2009/9/9 Frans Pop elen...@planet.nl:
Can you please provide the output of the following command (as root):
udevadm test /class/input/event0
[output of command snipped]
Thanks Nis, that confirms my suspicion: udev fixed the old rule that
created a slightly broken persistent device name (trailing dash), but
failed to add the new udev rule which creates the improved device name.
I've just uploaded a new version of qcontrol, but that will only really
become available with the next stable point release.
In the mean time here's the correct workaround. The one I posted in reply
to your original mail lacked the trailing dash needed by qcontrol in
stable.
Create a file /etc/udev/rules.d/z60-qcontrol.rules:
KERNEL==event*, ENV{ID_PATH}==platform-gpio-keys, \
SYMLINK+=input/by-path/$env{ID_PATH}-event-
In fact, the uploaded new version creates the same file (but then without
the trailing dash).
Thanks again,
FJP
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545226: Grub didn't install because diff (cmp) is not installed
reassign 545226 ftp.debian.org forcemerge 544478 545226 thanks On Saturday 05 September 2009, Christian Perrier wrote: reassign 545226 grub-installer This has nothing to do with grub-installer. The issue has been reported and analyzed before. See #544478. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545018: fails to setup squeeze system
reassign 545018 libsepol1 2.0.37-1 retitle 545018 libsepol1: causes debootstrap to fail severity 545018 serious thanks This is unlikely to be a bug in debootstrap itself, but more likely to be temporary breakage in the testing distribution. I can reproduce the error and the installation fails at: Setting up libsepol1 (2.0.37-1) ... telinit: /dev/initctl: No such file or directory dpkg: error processing libsepol1 (--configure): subprocess installed post-installation script returned error exit status 1 This issue affects *all* new installations, therefore setting severity to serious. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544400: s390 Debian Installer panic bug # 536354
reassign 544400 debian-installer forcemerge 536375 544400 thanks This is my first install of debian on s390. I downloaded your images, booted and got a kernel panic. This looks like problem # 536354. Correct. The kernel is now fixed, but the installer still needs to be updated, which will happen with the next stable point release (which should happen fairly soon now). In the mean time the only other option is to install Etch and upgrade to Lenny later. Please see the following mail (bottom part) for details: http://lists.debian.org/debian-s390/2009/07/msg3.html Cheers, FJP P.S. The CD images for s/390 are only of limited value. You can just as well use the generic images available under other images from: http://www.debian.org/releases/lenny/debian-installer/ or for etch from: http://www.debian.org/releases/etch/debian-installer/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544478: grub-legacy: should depend on diffutils
Package: grub-legacy Version: 0.97-56 Severity: serious Tags: d-i List-CC: diffut...@packages.debian.org During a new installation using D-I of testing today I got: /usr/sbin/grub-install: 400: cmp: not found cmp is from the recently renamed diffutils, which is no longer required and essential and thus cmp can no longer be relied on to be available. The only strange thing here is that the new pakage has not yet migrated to testing, but I guess the overrides have already been changed (which are the same for unstable and testing). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543590: directfb: regressions in D-I with experimental 1.4 version
Package: directfb Version: 1.4.1-2 Severity: serious Tags: d-i As already announced in my reply to the call to test the 1.4 version in experimental, this version introduces a few of important regression in Debian Installer. I've built cairo, gtk+2.0 and cdebconf (all from unstable) against it for a D-I test. The builds were all OK, but I see serious regressions in D-I. In this screenshot you can see that our banner is missing: http://people.debian.org/~fjp/tmp/d-i/directfb_regression.png And the same goes for icons, so basically any image. Also, if I move the cursor using the arrow keys, it jumps one line. E.g. if I go down, the current line moves from Moldova to Montenegro and skips Monaco. I guess the same happens for selection between two radiobuttons, but there it actually results in the selection not changing at all (because there's nothing to skip). I've verified that both issues are not present in a daily built image using current libraries from unstable. I'll file a bug against the experimental version of directfb later. There's also a rather large size increase of a D-I image: a daily built image is 18458624, while one with the new directfb is 18905088; that's an increase of 436kB (compressed!). Are there options that can be disabled for the udeb? Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541725: eglibc: libc6-udeb is empty causing Debian installs to fail
Package: eglibc Version: 2.9-24 Severity: serious Tags: d-i Justification: Breaks Debian Installer In the latest upload the udebs for all architectures are empty. This breaks installations at the partitioning stage and later as symbols cannot be found: md-devices: mdadm: relocation error: mdadm: symbol nftw64, version GLIBC_2.3.3 not defined in file libc.so.6 with link time reference partman: pvscan: relocation error: pvscan: symbol alphasort64, version GLIBC_2.2 not defined in file libc.so.6 with link time reference $ dpkg -c libc6-udeb_2.9-24_i386.udeb drwxr-xr-x root/root 0 2009-08-11 03:20 ./ -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541115: busybox: No longer creates tty[1-4] devices on s390
Package: busybox Severity: serious Version: 1:1.14.2-1 Tags: d-i On s390 the installer fails to boot with: can't open /dev/tty2: No such file or directory can't open /dev/tty3: No such file or directory can't open /dev/tty4: No such file or directory I'm not sure how busybox can be responsible for this, but it's the only relevant change in the D-I initrd I can see since my last working test. The weird thing is that even with busybox 1:1.13.3-1 we only have: # ls /dev/tty* /dev/tty /dev/ttysclp0 But despite that D-I does boot correctly, so I guess the old busybox init allowed devices to be referenced in /etc/inittab which do not exist and would silently skip them (?). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541112: kde cd does not install kde, nor a working graphical environment.
reassign 541112 ftp.debian.org forcemerge 536312 541112 thanks On Tuesday 11 August 2009, Kurt Roeckx wrote: I've used the 5.0.2 KDE i386 install image (debian-cd/5.0.2/i386/iso-cd/debian-502-i386-kde-CD-1.iso) After a reboot, kdm started and asked for a login/pass. I could log in, but the only thing I got was a background. Nothing else was running. Known issue. See http://bugs.debian.org/536312. Unfortunately the FTP-masters don't seem to regard this as a serious or urgent issue. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541115: busybox: No longer creates tty[1-4] devices on s390
It looks like busybox also causes a failure on i386. If I boot a daily mini.iso, the boot hangs when executing the last line from /sbin/init: exec /usr/sbin/chroot . /bin/busybox init /dev/console /dev/console 21 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540023: cdrom: netinst installation might freeze with out-of-date keyring
severity 540023 wishlist reassign 540023 debian-installer thanks On Wednesday 05 August 2009, Patrick Vervoorn wrote: Digging deeper, finally the output shown in the output from the underlying installation scripts (Alt-F4), showed what had happened: the PGP-keyring was out of date, and the big 'apt-get install loads-of-packages' command was waiting for input from the user, to confirm to continue with an untrusted PGP key. Unfortunately it is technically rather difficult to catch this situation inside the installer. It would be wise to fix this, especially if the same can happen with the current installation (5.x/lenny). At the very least, the installing user should be made aware he/she is installing a rather out-of-date system, and whether to reconsider. It would probably also be handy if a user who knows what they're doing, could push through this install, and install anyway. That is possible by using the debian-installer/allow_unauthenticated=true boot option as documented in the Installation Guide. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539744: chroot to lenny /target in debootstrap segfaults
On Tuesday 04 August 2009, Frans Pop wrote: And yes, replacing the UUIDs in the fstab by regular devices gets rid of the segfault. Still weird that an empty mtab avoids it though. Colin, any thoughts (given that you implemented the switch to UUID)? The problem is essentially that we have a configured fstab in an otherwise unconfigured chroot. One, IMO fairly logical, solution to this could be to not let partman create /etc/fstab *in* /target, but instead create it somewhere in the the D-I environment and then let a base-installer.d script copy it over to /target. This would also be more in line with how other components do things. debootstrap handles a missing fstab correctly by creating a dummy file, which explains why there was no segfault when I ran base-installer after doing a 'rm -r /target/*'. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539744: chroot to lenny /target in debootstrap segfaults
reassign 539744 base-installer
tags 539744 pending
thanks
On Tuesday 04 August 2009, Frans Pop wrote:
One, IMO fairly logical, solution to this could be to not let partman
create /etc/fstab *in* /target, but instead create it somewhere in the
the D-I environment and then let a base-installer.d script copy it over
to /target.
This would also be more in line with how other components do things.
This oneliner change would fix the issue as well:
+++ b/packages/base-installer/debian/bootstrap-base.postinst
@@ -88,7 +88,7 @@ install_base_system () {
# so make a backup to be restored later
copied_fstab=true
cp /target/etc/fstab /target/etc/fstab.orig
- echo # UNCONFIGURED FSTAB FOR BASE SYSTEM /target/etc/fstab
+ echo # UNCONFIGURED FSTAB FOR BASE SYSTEM /target/etc/fstab
fi
if [ $PROTOCOL = http ]; then
And it even makes more sense than the current code...
I'll go ahead and commit this.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539744: chroot to lenny /target in debootstrap segfaults
On Tuesday 04 August 2009, you wrote:
Frans Pop wrote:
This oneliner change would fix the issue as well:
+++ b/packages/base-installer/debian/bootstrap-base.postinst
@@ -88,7 +88,7 @@ install_base_system () {
# so make a backup to be restored later
copied_fstab=true
cp /target/etc/fstab /target/etc/fstab.orig
thus this should be a mv
Doesn't make any difference. The next line overwrites it.
- echo # UNCONFIGURED FSTAB FOR BASE SYSTEM
/target/etc/fstab
+ echo # UNCONFIGURED FSTAB FOR BASE SYSTEM
/target/etc/fstab
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539586: [s390] partman-base: fails ugly when ext4 is selected
severity 539586 normal retitle 539586 [s390] partman-base: fails ugly when ext4 is selected thanks On Sunday 02 August 2009, Frans Pop wrote: I just tried an install on s390 and after I chose ext4 as partition I got a dialog containing only ? / ? (or something close to that). I think this is probably because libparted still hasn't been built for s390, which means D-I is using a libparted that does not have support for ext4. The failure mode is rather ugly though with libparted apparently returning something that partman isn't able to handle correctly and the pipe to parted-server dying as a result. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539586: partman-base
Package: partman-base Version: 129 Severity: serious I just tried an install on s390 and after I chose ext4 as partition I got a dialog containing only ? / ? (or something close to that). I also got the following in the syslog: main-menu[622]: INFO: Menu item 'partman-base' selected anna-install: Installing partman-lvm anna[2033]: DEBUG: retrieving lvm2-udeb 2.02.44-3 anna[2033]: DEBUG: retrieving partman-lvm 67 anna-install: Installing partman-crypto anna[2102]: DEBUG: retrieving partman-crypto 38 kernel: [ 569.627581] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled kernel: [ 569.650990] SGI XFS Quota Management subsystem md-devices: mdadm: No arrays found in config file or automatically kernel: [ 572.502330] device-mapper: uevent: version 1.0.3 kernel: [ 572.516658] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-de...@redhat.com partman: No matching physical volumes found partman: Reading all physical volumes. This may take a while... main-menu[622]: (process:2020): /lib/partman/visual.d/10type: main-menu[622]: (process:2020): line 16: main-menu[622]: (process:2020): can't open /var/lib/partman/outfifo: no such file main-menu[622]: (process:2020): /lib/partman/visual.d/35name: main-menu[622]: (process:2020): line 16: main-menu[622]: (process:2020): can't open /var/lib/partman/outfifo: no such file main-menu[622]: (process:2020): /lib/partman/active_partition/15method/do_option: main-menu[622]: (process:2020): line 10: main-menu[622]: (process:2020): can't open /var/lib/partman/outfifo: no such file main-menu[622]: (process:2020): /lib/partman/active_partition/10change_name/choices: line 9: main-menu[622]: (process:2020): can't open /var/lib/partman/outfifo: no such file main-menu[622]: (process:2020): /lib/partman/active_partition/65toggle_bootable/choices: main-menu[622]: (process:2020): line 11: main-menu[622]: (process:2020): can't open /var/lib/partman/outfifo: no such file main-menu[622]: (process:2020): /lib/partman/active_partition/67toggle_biosgrub/choices: main-menu[622]: (process:2020): line 11: main-menu[622]: (process:2020): can't open /var/lib/partman/outfifo: no such file main-menu[622]: (process:2020): /lib/partman/active_partition/80resize/choices: main-menu[622]: (process:2020): line 9: main-menu[622]: (process:2020): can't open /var/lib/partman/outfifo: no such file etcetera Something looks to be seriously borked. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539425: On upgrade of existing system, dash becomes system default if debconf non-interactive
Package: dash Version: 0.5.5.1-2.3 Severity: serious During the upgrade of a pbuilder environment I noticed that if DEBIAN_FRONTEND=noninteractive, and possibly also if debconf is not available at all, dash - when not previously installed - can not ask its question and will thus become the default system shell, which is not what we want. This use case should IMO be recognized in the maintainer scripts and handled appropriately so that the default system shell remains unchanged for *all* existing systems. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc4-agp-pat (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dash depends on: ii debianutils 3.2Miscellaneous utilities specific t ii dpkg 1.15.3.1 Debian package management system ii libc6 2.9-23 GNU C Library: Shared libraries dash recommends no packages. dash suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539425: On upgrade of existing system, dash becomes system default if debconf non-interactive
On Friday 31 July 2009, Sven Joachim wrote: Wasn't the plan to do this differently in noninteractive installs, precisely because dash should become the default /bin/sh on build systems? Well, how would you distinguish between a build system and a regular system at some user that for whatever reason is being upgraded non-interactively? If build systems need special treatment, then I'd say that you need to positively identify them, not use some random setting that is likely to also test true for other systems. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535513: daily fails to generate ramdisk because / not mounted
On Tuesday 21 July 2009, Martin Michlmayr wrote: * Martin Michlmayr t...@cyrius.com [2009-07-02 22:39]: I just tried a daily image on ARM and it failed because the ramdisk cannot be generated. Apparently this is because / is not mounted in the chroot. I don't know why root is no longer mounted in the chroot (it was in lenny and until recently in the daily images). Would busybox be responsible for this or where should this bug be reassigned to? What *exactly* do you mean by / is no longer mounted? It seems to me that it is kind of a silly statement because without a / I would say you can't have a chroot. I guess what you mean is that /etc/mtab or /proc/mounts or the mount command no longer *lists* /. Is that it? If it is, then somebody very simply will have to trace the cause of that change. My suggestion: spend some actual time on tracing it instead of waiting for other people to solve the mystery. If you suspect busybox, then try building an image with the Lenny version of busybox. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535513: daily fails to generate ramdisk because / not mounted
On Tuesday 21 July 2009, Martin Michlmayr wrote: * Frans Pop elen...@planet.nl [2009-07-21 16:23]: What *exactly* do you mean by / is no longer mounted? It seems to me that it is kind of a silly statement because without a / I would say you can't have a chroot. I guess what you mean is that /etc/mtab or /proc/mounts or the mount command no longer *lists* /. Is that it? Yes, that's what I meant. It shows up fine in the d-i system but not in the target. Which of the three I mentioned is the actual problem? Did they all change or just one or two? Which is used in the relevant code? Wasn't /etc/mtab for installed systems changed after Lenny to be a symlink to /proc/mounts? I seem to remember a discussion on d-devel about that. I also seem to remember that D-I had some special handling for /target/etc/mtab, but I'm not sure. Guess a grep in the lenny branch of D-I SVN (and trunk for comparison) should tell. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536312: task overrides for stable appear to be updated when unstable changes - no network-manager etc in default debian 5.0r2 install
Here's an (untested) patch that should avoid this issue for the future.
It determines the codename for testing from the testing symlink.
A manual cleanup for the current incorrect override files (for both lenny
and squeeze) will still be needed of course.
Cheers,
FJP
--- mk-extra-overrides.sh.orig 2009-07-10 08:34:29.0 +
+++ mk-extra-overrides.sh 2009-07-10 08:51:53.0 +
@@ -5,8 +5,23 @@
x=build-essential tag task
opath=/org/ftp.debian.org/scripts/override
+apath=/org/ftp.debian.org/ftp/dists
-for s in lenny sid; do
+if [ ! -d $apath ]; then
+ echo $0: invalid path to archive 2
+ exit 1
+elif [ ! -L $apath/testing ]; then
+ echo $0: symlink for testing suite does not exist 2
+ exit 1
+fi
+
+codename_testing=$(basename $(readlink $apath/testing))
+if [ -z $codename_testing ] || [ ! -d $apath/$codename_testing ];
then
+ echo $0: invalid codename for testing suite ('$codename_testing') 2
+ exit 1
+fi
+
+for s in $codename_testing sid; do
for c in main contrib non-free; do
echo Making $opath/override.$s.extra.$c
if [ $c = main ]; then
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536312: task overrides for stable appear to be updated when unstable changes - no network-manager etc in default debian 5.0r2 install
On Friday 10 July 2009, Frans Pop wrote: Here's an (untested) patch that should avoid this issue for the future. It determines the codename for testing from the testing symlink. As the script is maybe not under version control, attached the full new version. mk-extra-overrides.sh Description: application/shellscript
Bug#536353: debian-installer: [s390,etch] gpgv: Can't check signature: public key not found
Package: debian-installer Version: 20070308etch5 Severity: serious Installs of Etch for s390 fail because the Release signature cannot be verified. From the syslog: Jul 9 09:33:42 main-menu[656]: INFO: Menu item 'choose-mirror' selected Jul 9 09:33:47 choose-mirror[808]: DEBUG: command: wget -q http://ftp.nl.debian.org/debian//dists/oldstable/Release -O - | grep ^Suite: | cut -d' ' -f 2 Jul 9 09:33:47 choose-mirror[808]: DEBUG: command: wget -q http://ftp.nl.debian.org/debian//dists/oldstable/Release -O - | grep ^Codename: | cut -d' ' -f 2 Jul 9 09:33:47 choose-mirror[808]: INFO: codename set to: etch Jul 9 09:33:47 choose-mirror[808]: DEBUG: command: wget -q http://ftp.nl.debian.org/debian//dists/oldstable/main/binary-s390/Release -O - | grep Architecture Jul 9 09:33:48 anna-install: Queueing udeb etch-support for later installation Jul 9 09:33:48 main-menu[656]: DEBUG: resolver (libc6): package doesn't exist (ignored) Jul 9 09:33:48 main-menu[656]: INFO: Menu item 'download-installer' selected Jul 9 09:33:49 net-retriever: gpgv: WARNING: multiple signatures detected. Only the first will be checked. Jul 9 09:33:50 net-retriever: gpgv: Signature made Sat May 23 17:28:27 2009 UTC using RSA key ID 55BE302B Jul 9 09:33:50 net-retriever: gpgv: Can't check signature: public key not found Jul 9 09:33:50 net-retriever: error: Bad signature on /tmp/net-retriever-858-Release. The problem can be worked around by adding the following boot parameters: suite=etch debian-installer/allow_unauthenticated=true But of course it would be a lot better to just have working images... -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536375: debian-installer: [s390,lenny] kernel panic during boot
Package: debian-installer Version: 20090123lenny3 Severity: serious Installs of Lenny for s390 fail because of a kernel problem. See http://lists.debian.org/debian-s390/2009/07/msg2.html for details. A bug against the kernel has already been reported (#536354). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536312: task overrides for stable appear to be updated when unstable changes - no network-manager etc in default debian 5.0r2 install
On Thursday 09 July 2009, Joey Hess wrote: Ftpmasters: Task override updating is handled by an autobyhand script fjp wrote, /srv/ftp.debian.org/dak/scripts/debian/byhand-task. I don't have access to look at what's on ftpmaster, AFAIK everything can also be found on merkel though. but looking at the patches fjp posted about this, it seems to update /srv/ftp.debian.org/scripts/external-overrides/task with the file from tasksel, and then run mk-extra-overrides.sh in the same directory. Perhaps the issue of keeping differing overrides for stable and unstable separate was entirely overlooked? Although IIRC ftpmaster had a different set of task override files for stable. I doubt that that is the cause as I do remember considering that aspect when we made the change. For that reason my patches also still force a real by-hand for uploads of tasksel to stable. /me looks on merkel... Hmmm, mk-extra-overrides.sh has this: for s in lenny sid; do for c in main contrib non-free; do echo Making $opath/override.$s.extra.$c So it looks like the problem is that that script should have been updated to 'for s in squeeze sid; do' when lenny was released, but that this was forgotten. Perhaps the releases to act on should not be hardcoded but instead taken from some configuration file? Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#527641: Package installation overwrites /etc/default/console-setup without warning
On Wednesday 20 May 2009, Raphael Hertzog wrote: To fix it, you have to: 1/ document in the file that it's auto-updated based on the debconf infos and that dpkg-reconfigure console-setup is recommended to update it 2/ use ucf or something similar to detect if the file has been edited by the user since last generation and avoid overwriting the file in that case (ucf like dpkg let the user choose what to do in that case) It sounds like c-s is using debconf as a registry. If that is the case, it is just plain wrong. Configuration scripts should read the current settings from the configuration file(s) and set the defaults for debconf questions based on that, and not just display the current value in the debconf database. From debconf-devel(7): [...] The issue to watch out for here is that debconf is not intended to be, and must not be used as a registry. This is unix after all, and programs are configured by files in /etc, not by some nebulous debconf database (that is only a cache anyway and might get blown away). [...] See also the example under Config file handling in the same man page. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517231: Processed: forcibly merging 517231 528929
On Sunday 17 May 2009, Frans Pop wrote: There may be a problem with weekly built CD images too. In this period (after a Debian release and before the first Beta, when udeb migrations are allowed without worrying about breaking D-I images in testing) they really should be built using D-I images and udebs from unstable, instead of using those from Lenny. OTOH, we currently don't link to the weekly built images either... signature.asc Description: This is a digitally signed message part.
Bug#517231: Processed: forcibly merging 517231 528929
On Sunday 17 May 2009, Aurelien Jarno wrote: This is why it only appears with images generated with glibc 2.7 (ie lenny images), and not with the daily ones which use glibc 2.9. This type pf problem is well known and will not get fixed until the first Beta release of D-I. It is also virtually unavoidable. At the moment Lenny images very simply should not be used. For exactly that reason we do not link to them from the D-I page. There may be a problem with weekly built CD images too. In this period (after a Debian release and before the first Beta, when udeb migrations are allowed without worrying about breaking D-I images in testing) they really should be built using D-I images and udebs from unstable, instead of using those from Lenny. Getting this right is the responsibility of the D-I release manager or team or whatever. Anyway, there is no bug. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#517231: Processed: forcibly merging 517231 528929
On Sunday 17 May 2009, Frans Pop wrote: On Sunday 17 May 2009, Aurelien Jarno wrote: This is why it only appears with images generated with glibc 2.7 (ie lenny images), and not with the daily ones which use glibc 2.9. This type pf problem is well known and will not get fixed until the first Beta release of D-I. It is also virtually unavoidable. At the moment Lenny images very simply should not be used. For exactly that reason we do not link to them from the D-I page. s/Lenny/Squeeze/ rather. Basically: you very simply cannot use images built for Lenny to install Squeeze. At least not netboot images. I guess that if you took a Lenny businesscard CD and selected expert mode, it would happily install Squeeze if you asked it to. Reason: it will take the libc6 udeb from the CD images and that will of course match the version of libnss-files-udeb included in the initrd. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517231: Processed: forcibly merging 517231 528929
On Sunday 17 May 2009, Frans Pop wrote: Basically: you very simply cannot use images built for Lenny to install Squeeze. At least not netboot images. I guess that if you took a Lenny businesscard CD and selected expert mode, it would happily install Squeeze if you asked it to. Reason: it will take the libc6 udeb from the CD images and that will of course match the version of libnss-files-udeb included in the initrd. Aarrgh! Hate needing to correct myself. Netboot images should be fine, because they will automatically take udebs from Lenny [1]. So the only images that should be broken are the daily built Squeeze CD images and the weekly built CD images. And as mentioned before that is expected, not the result of a bug. [1] Unless you'd boot with mirror/udeb/suite=testing, but that would be user error. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528443: debian-installer: error setting up powerpc-utils cannot stat `/etc/adjtime'
reassign 528443 powerpc-utils 1.1.3-22 severity 528443 important thanks On Wednesday 13 May 2009, Rick Thomas wrote: Everything progressed normally until during the installation of the base packages, it failed. According to the syslog file there was a problem setting up the powerpc-utils package. So why are you reporting this against debian-installer? IMHO you should know a bit better by now (you've done enough installation testing over the past years, which we very much *do* appreciate). Please make an effort to report issues against the actual package causing the problem! Also, please don't use inflated bug priorities. Debian Installer does NOT become unusable because one random package fails to install on a single architecture. Whether it's of RC severity for powerpc-utils I'll leave to its maintainer. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504721: Reason for console detection failure on Sparc Niagara
-- Forwarded Message -- From: David Miller da...@davemloft.net The reason this bug happens is because CONFIG_PROM_CONSOLE is enabled in the kernel. It unconditionally gets registered as a real console before the Sun Hypervisor console driver has a chance to register. The kernel takes whatever real console registers first, as the highest priority console (unless specified otherwise on the command line). This is why the test program that runs to determine the inittab getty settings doesn't see the console as a serial device. And no, using console=ttyS0 will not fix this problem on Niagara. On Niagara you would need to use console=ttyHV0. The only reasonable fix for this bug is to disable CONFIG_PROM_CONSOLE in the kernel configuration. Nobody should be enabling that kernel config option on sparc. It specifically creates this problem because unlike the framebuffer and serial console drivers, it does not have a way to know whether it should register or not. The serial and framebuffer drivers check the PROM indicated device node of the console device, and it only registers the device as the console if it matches the value of the 'output-device' PROM environment variable setting. Therefore, having CONFIG_PROM_CONSOLE enabled in the tree is going to do nothing other than constantly create problems and conflicts like this. It needs to be turned off, forever. --- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525209: Layout messed up in daily images
On Thursday 23 April 2009, Frans Pop wrote: This is almost certainly a result of the cdebconf changes committed by Nicolas François (CCed). Although the new version of newt uploaded a few days ago could also be a factor (and possibly even the slightly older slang2 update). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523151: udev: [s390] Fails to configure additional disk/net devices
Package: udev Version: 0.140-2 Severity: critical Justification: breaks the whole system User: debian-s...@lists.debian.org Usertags: s390 After upgrading udev the system fails to boot correctly as my second disk (dasdb) and network interface (ctc0) are no longer brought up. The initrd loads correctly and / is mounted correctly. Other than the two missing devices the system boots correctly. Because dasdb is not activated I'm missing my /home (which is on LVM). I also upgraded the kernel, but as I can bring up both devices manually without any problems I doubt this is a kernel problem. As I see there are s390 specific rules files present, I'm not sure what the problem is here. -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 20 -rw-r--r-- 1 root root 1137 2008-10-01 16:51 65_dmsetup.rules -rw-r--r-- 1 root root 1137 2008-07-15 23:59 65_s390-tools.rules -rw-r--r-- 1 root root 168 2008-09-12 13:33 65-sysconfig-hardware-net.rules -rw-r--r-- 1 root root 534 2009-04-08 13:50 70-persistent-net.rules -rw-r--r-- 1 root root 112 2008-09-12 13:33 85-sysconfig-hardware.rules -- /sys/: /sys/dev /sys/devices/css0/0.0.0004/0.0.0120/block/dasda/dasda1/dev /sys/devices/css0/0.0.0004/0.0.0120/block/dasda/dasda2/dev /sys/devices/css0/0.0.0004/0.0.0120/block/dasda/dev /sys/devices/css0/0.0.0005/0.0.0121/block/dasdb/dasdb1/dev /sys/devices/css0/0.0.0005/0.0.0121/block/dasdb/dasdb2/dev /sys/devices/css0/0.0.0005/0.0.0121/block/dasdb/dev /sys/devices/virtual/block/dm-0/dev /sys/devices/virtual/block/ram0/dev /sys/devices/virtual/block/ram10/dev /sys/devices/virtual/block/ram11/dev /sys/devices/virtual/block/ram12/dev /sys/devices/virtual/block/ram13/dev /sys/devices/virtual/block/ram14/dev /sys/devices/virtual/block/ram15/dev /sys/devices/virtual/block/ram1/dev /sys/devices/virtual/block/ram2/dev /sys/devices/virtual/block/ram3/dev /sys/devices/virtual/block/ram4/dev /sys/devices/virtual/block/ram5/dev /sys/devices/virtual/block/ram6/dev /sys/devices/virtual/block/ram7/dev /sys/devices/virtual/block/ram8/dev /sys/devices/virtual/block/ram9/dev /sys/devices/virtual/mem/full/dev /sys/devices/virtual/mem/kmem/dev /sys/devices/virtual/mem/kmsg/dev /sys/devices/virtual/mem/mem/dev /sys/devices/virtual/mem/null/dev /sys/devices/virtual/mem/random/dev /sys/devices/virtual/mem/urandom/dev /sys/devices/virtual/mem/zero/dev /sys/devices/virtual/misc/cpu_dma_latency/dev /sys/devices/virtual/misc/device-mapper/dev /sys/devices/virtual/misc/network_latency/dev /sys/devices/virtual/misc/network_throughput/dev /sys/devices/virtual/tty/console/dev /sys/devices/virtual/tty/ptmx/dev /sys/devices/virtual/tty/sclp_line0/dev /sys/devices/virtual/tty/tty/dev /sys/devices/virtual/tty/ttysclp0/dev -- Kernel configuration: isapnp_init not present. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: s390 Kernel: Linux 2.6.29-1-s390 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages udev depends on: ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii libc6 2.9-7 GNU C Library: Shared libraries ii libselinux1 2.0.71-1 SELinux shared libraries ii libvolume-id1 0.140-2libvolume_id shared library ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip ii s390-tools1.6.2-1A set of fundamental utilities for udev recommends no packages. udev suggests no packages. -- debconf information: udev/new_kernel_needed: false udev/reboot_needed: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523151: udev: [s390] Fails to configure additional disk/net devices
Maybe the following will provide some info:
# udevadm test /sys/bus/ccw/devices/0.0.0121
[...]
udev_device_new_from_syspath: device 0x42b828 has devpath
'/devices/css0/0.0.0005/0.0.0121'
wait_for_file: file '/sys/devices/css0/0.0.0005/0.0.0121/online' appeared after
0 loops
udev_rules_apply_to_event: RUN '/sbin/hwup -A -D $DEVPATH $env{SUBSYSTEM} %b'
/etc/udev/rules.d/85-sysconfig-hardware.rules:2
udev_rules_apply_to_event: RUN 'socket:@/org/kernel/udev/monitor'
/lib/udev/rules.d/95-late.rules:17
udevadm_test: run: '/sbin/hwup -A -D /devices/css0/0.0.0005/0.0.0121 ccw '
udevadm_test: run: 'socket:@/org/kernel/udev/monitor'
Could it be that the last parameter for the call to hwup (%b) is missing?
AFAICT the value for that should be 0.0.0121 in this case.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523151: udev: [s390] Fails to configure additional disk/net devices
On Wednesday 08 April 2009, Frans Pop wrote:
Maybe the following will provide some info:
# udevadm test /sys/bus/ccw/devices/0.0.0121
[...]
udev_device_new_from_syspath: device 0x42b828 has devpath
'/devices/css0/0.0.0005/0.0.0121'
wait_for_file: file '/sys/devices/css0/0.0.0005/0.0.0121/online' appeared
after 0 loops
udev_rules_apply_to_event: RUN '/sbin/hwup -A -D $DEVPATH $env{SUBSYSTEM} %b'
/etc/udev/rules.d/85-sysconfig-hardware.rules:2
udev_rules_apply_to_event: RUN 'socket:@/org/kernel/udev/monitor'
/lib/udev/rules.d/95-late.rules:17 udevadm_test: run: '/sbin/hwup -A -D
/devices/css0/0.0.0005/0.0.0121 ccw '
udevadm_test: run: 'socket:@/org/kernel/udev/monitor'
Could it be that the last parameter for the call to hwup (%b) is
missing? AFAICT the value for that should be 0.0.0121 in this case.
Yes, looks like that's it. After downgrading to udev 0.125 I get:
import_uevent_var: import into environment: 'DRIVER=dasd-eckd'
import_uevent_var: import into environment: 'CU_TYPE=3990'
import_uevent_var: import into environment: 'CU_MODEL=C2'
import_uevent_var: import into environment: 'DEV_TYPE=3390'
import_uevent_var: import into environment: 'DEV_MODEL=02'
import_uevent_var: import into environment: 'MODALIAS=ccw:t3990mC2dt3390dm02'
udevtest: looking at device '/devices/css0/0.0.0005/0.0.0121' from subsystem
'ccw'
wait_for_file: file '/sys/devices/css0/0.0.0005/0.0.0121/online' appeared after
0 loops
udevtest: run: '/sbin/hwup -A -D /devices/css0/0.0.0005/0.0.0121 ccw 0.0.0121'
udevtest: run: 'socket:@/org/kernel/udev/monitor'
Note that those 'import_uevent_var' messages are not displayed with 0.140,
but that may be as expected or unrelated.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: initramfs-tools: must support relative paths in modules.dep
On Thursday 19 March 2009, maximilian attems wrote: Recently kernels I built from upstream kernel source failed to boot after unpacking them because no modules got included in the initramfs initrd (and thus no root file system). This problem was solved after downgrading to m-i-t 3.4.1. how can i reproduce this? upgraded to latest m-i-t 3.7-pre9-1 and run depmod + mkinitramfs. the generated initramfs had all modules i expect it to have. You have to build a kernel from source while having the new m-i-t installed. And then install that kernel *without* running depmod (which is currently also not done by i-t). If you do run an extra depmod manually before calling i-t the problem will have fixed itself because depmod is then called differently than during the kernel build. I saw this issue after installing a kernel built from upstream source using 'fakeroot make deb-pkg' (i.e. without using kernel-package or anything). With the stable version of m-i-t kernels built that way install perfectly (using custom hook scripts to create the initrd and update grub etc.). You can probably also reproduce it by running the following sequence of commands, which should emulate the way the upstream kernel Makefile calls depmod (using any kernel version you have installed for kvers): # kvers=kvers # mkdir -p /tmp/lib/modules # cp -r /lib/modules/$kvers /tmp/lib/modules/ # rm /tmp/lib/modules/$kvers/modules.* # depmod -ae -F /boot/System.map-$kvers -b /tmp/ -r $kvers The file /tmp/lib/modules/kvers/modules.dep should then show the problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
