Bug#523342: status with Lenny?
Hi I installed Lenny on my machine (net install). The first install failed because I was using the intel 82567 gigabit card. Fortunately I have another network card on my computer and I could install lenny using this one. However I would like to use the 82567 card now. I see that the problem has been solved with newer versions of the kernel. Will this be backported to Lenny? Thanks Brice -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544493: Tyan S7002 fails to detect network chips??
Package: installation-reports Boot method: CD Image version: http://cdimage.debian.org/debian-cd/5.0.2a/amd64/iso-cd/debian-502a-amd64-netinst.iso Date: Aug 31 2009 Machine: Tyan S7002 Processor: Memory: Partitions: na Output of lspci -knn (or lspci -nn): Copied lines by hand: 0200.0 Ethernet controller intel corporation 82574L gigabit network connection [8086:10D3] 0300.0 Ethernet controller intel corporation 82574L gigabit network connection [8086:10D3] Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [o] Detect network card:[E] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: I checked and the e1000e driver exists. Tried several things with the BIOS - updated BIOS to latest version (1.03) NICs are enabled. Plugging live network cable in - causes lights to light - after very small delay. Google led me to this: http://lists.debian.org/debian-kernel/2009/06/msg00305.html Is there someplace I can get an updated driver? Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://xtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 The best way to cheer yourself up is to try to cheer somebody else up. -- Mark twain -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541436: Bug541436: clock-setup: should not change hardware clock if the system time is not updated
On Tuesday 01 September 2009, Frans Pop wrote: > I hope that my changes will have made setting the clock more reliable > now. I cannot be 100% sure as I only tested it in an emulator, not on > real hardware. Right, the reason for the confusion is that /etc/adjtime _was_ present after base installation in Lenny. but isn't for Squeeze. The util-linux changelog does not list that change. And as the default value was UTC in that file, that immediately explains the reported behavior (with Lenny images). It also explains why I see the exact *opposite* error with daily built images: UTC going wrong. Reason for that is that hwclock will assume localtime as default if /etc/adjtime is missing (which is a rather weird default for a Linux utility, but whatever). Anyway, with my changes it no longer matters if the file is there or not, clock-setup should just always do the right thing now. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
On Fri, Aug 07, 2009 at 07:59:04AM +0200, Felix Zielcke wrote:
> Am Dienstag, den 04.08.2009, 11:45 +0200 schrieb Felix Zielcke:
> > Here's now a patch which does it without a version check.
>
> I suggest to change the sed expression to
> "s!^GRUB_CMDLINE_LINUX=\"\?\([^\"]*\)\"\?!GRUB_CMDLINE_LINUX=\"\1 xyz\"!"
> because in lenny we just have GRUB_CMDLINE_LINUX= in /etc/defaul/grub
> or does someone have a better one?
Better to sed s!^GRUB_CMDLINE_LINUX=$!GRUB_CMDLINE_LINUX=""! first. But
then that also leaves unsightly leading spaces. There's no obvious
reason why we need to preserve any existing value in these variables, of
course.
However, now that grub2/linux_cmdline and grub2/linux_cmdline_default
debconf questions exist, we need to preseed them anyway to stop them
being asked in a default installation. As long as we have to do that, it
seems to me that we might as well set them to reasonable values.
How does this patch look?
Index: grub-installer
===
--- grub-installer (revision 60561)
+++ grub-installer (working copy)
@@ -394,6 +394,25 @@
;;
esac
+user_params=$(user-params) || true
+defopt_params=""
+kopt_params=""
+for u_param in $user_params; do
+ case "$u_param" in
+ quiet)
+ defopt_params=${defopt_params:+$defopt_params }$u_param ;;
+ *)
+ kopt_params=${kopt_params:+$kopt_params }$u_param ;;
+ esac
+done
+if [ "$grub_version" = grub2 ]; then
+ # quoting to deconfuse vim
+ chroot /target 'debconf-set-selections' <
Re: Problems with kernel 2.6.26-2-686-bigmem --- RESOLVED
dann frazier wrote: On Fri, Aug 28, 2009 at 12:08:35PM -0600, David Vanfleet wrote: Luk Claes wrote: David Vanfleet wrote: Hi, I'm trying to get Debian (Lenny) to recognize 6 Gig of memory on a Dell PE 2650 server. I installed the basic 5.02a Debian system with just a minimal install then I installed the 2.6.26-2-686-bigmem kernel so it will see all the memory. When I boot into the bigmem kernel it fails to boot, the errors I get are: WARNING boot device may be renamed. Try root=/dev/hda3 ... ALERT! /dev/sda3 does not exist Did you try with changing the root device for the bigmem kernel to /dev/hda3? If you use grub for booting you could do that by pressing 'e' (for edit on the line with the bigmem kernel) and afterwards pressing 'b' (for boot) while in the grub menu (to just try it) or updating /boot/grub/menu.lst (for the bigmem kernel) and running update-grub before rebooting into the bigmem kernel. Thanks for your response, I did try what you suggested but got the same error, except it says that "/dev/hda3 does not exist". Looking in /dev there is no sda* or hda*, there only an hda which I think is the CD drive. When I boot to the default Kernel then /dev/sda3 exists and is used to boot the kernel. Any other ideas? Does this system use the aacraid driver? If so, please try testing the kernel from lenny-proposed-updates (2.6.26-19). I'm not sure if this server is using this driver. However, we have resolved this issue. It turns out that we needed to upgraded the firmware on the Raid controller to get it to work. After the upgrade it boot fine and I can see all the memory. Thanks for the help, David -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Bug541436: clock-setup: should not change hardware clock if the system time is not updated
Processing commands for cont...@bugs.debian.org: > tags 541436 pending Bug #541436 [clock-setup] clock-setup: should not change hardware clock if the system time is not updated Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541436: Bug541436: clock-setup: should not change hardware clock if the system time is not updated
tags 541436 pending thanks My analysis was not entirely correct (or actually quite wrong in some respects). The timezone in the D-I environment was not the issue as the correct timezone _is_ known in the chroot where we run hwclock. So as long as the system time in the D-I environment is set to UTC (which it will be if rdate is run), then the time in the target chroot should be correctly corrected to local time and hwclock will have the correct reference time. The main issue was that we did not let hwclock know correctly whether the clock was to be set to UTC or local time as the file /etc/adjtime does not yet exist when we try to modify it. I hope that my changes will have made setting the clock more reliable now. I cannot be 100% sure as I only tested it in an emulator, not on real hardware. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543149: console-setup: perl errors during installation
On Mon, Aug 31, 2009 at 07:11:11PM +0200, Yann Dirson wrote:
> If I understand correctly what happened with #480533, it was a
> utf8-related module that was already part of perl-base, which suddenly
> gained dependencies it did not have prior to that. I thought we could be
> hitting the same problem again.
Yes, it's a very similar problem.
This one happens when /usr/bin/ckbcomp invokes uc or lc on a UTF-8
string. Consider:
with perl-modules installed:
# perl -le 'binmode(STDOUT, ":utf8"); print lc "\x{0100}"'
ā
without perl-modules installed:
# perl -le 'binmode(STDOUT, ":utf8"); print lc "\x{0100}"'
Use of uninitialized value $list in pattern match (m//) at
/usr/share/perl/5.10/utf8_heavy.pl line 227.
Use of uninitialized value $x in scalar assignment at
/usr/share/perl/5.10/utf8_heavy.pl line 242.
Use of uninitialized value $x in pattern match (m//) at
/usr/share/perl/5.10/utf8_heavy.pl line 243.
Ā
Moving the contents of /usr/share/perl/5.10/unicore/To/ to perl-base
would fix this. Feel free to reassign/clone/whatever to perl.
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian preseed: How to choose the hdd for partman?
Gerolf Ziegenhain skrev: Hi All, I'm setting up a preseed installation scheme. Considering the partitioning the # REFERENCE (b) d-ipartman-auto/disk string /dev/discs/disc1/disc #/dev/sdb This is wrong and deprecrated - Should just be /dev/sdb Seems you is found an old document. See http://www.us.debian.org/releases/lenny/i386/apbs04.html.en for correct style. If one is concerned that the kernel might choose the wrong disk, you want /dev/sdb to be used but the kernel sees them in the wrong order and your usbstick is used instead (been there..) a tip is this: d-i partman-auto/disk string /dev/disk/by-id/scsi-1ATA_SAMSUNG_HM250JI_S0TVJD0P610587 One caveat here is that its what your d-i install kernel sees thats counts. Check first. br //Peter -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: please unblock module-init-tools
unblocked Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543149: console-setup: perl errors during installation
> On Monday 31 August 2009, Yann Dirson wrote: >> This seems to be similar to #480533, which was apparently fixed by >> moving more stuff to perl-base. > > I very much doubt it is related as the version of perl that fixed #480533 > is ancient (included in stable). So if that change had fixed it, then I > would never have seen the problem when I did. > > It may be that *a* solution to this issue could be to move yet more stuff > to perl-base, but I doubt that is desirable. > > IMO console-setup should, if at all possible, make sure that it only uses > functions available in current perl-base. Neither extending perl-base, > nor having console-setup depend on perl are desirable solutions. If I understand correctly what happened with #480533, it was a utf8-related module that was already part of perl-base, which suddenly gained dependencies it did not have prior to that. I thought we could be hitting the same problem again. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian-installer for GNU/kFreeBSD
Aurelien Jarno writes: > Following the work of Luca Favetella [1] during the Google Summer of > Code [2], I am happy to announce that a first version of the > debian-installer images are available here: > > http://temp.aurel32.net/d-i-kfreebsd/ > > Here are the SHA512 of the two images: > > > 754ab22022868a441e76c71d5a5c32b1bb0d5cb46ad7d8ca8da8b01bb5796d246bac34ad101d4f5c2e14798d526bbe93066207e1467efdbde59ccd72254129ce > mini-kfreebsd-amd64-20090831.iso > > c1bfa136ce6caabf39dba989fde08b3388d92754fdd14c71079a3fa5f5ba2938a6f82df899e6c34ae1ef2646e15e4046683ee76544875c670296f0fa0f3b3045 > mini-kfreebsd-i386-20090831.iso > > Please test them and report problems here. If there are not too many > issues, we will make an official release, put the images on the > standard location [3] and make a wider announce (probably with "Bits > from GNU/kFreeBSD porters" on debian-devel-announce). You can find more > details about those images, including bugs or missing features, on the > wiki [4]. I just tried the AMD64 flavour on a kvm virtual machine. Most of the issues I noticed seem to already be documented: - installation report fails - keyboard configuration missing Apart from that, the only problem I had was enabling the serial console. But that might be due to me not knowing FreeBSD too well. The installer worked nicely, except for the already documented missing features. More details: I installed using this command line: kvm -m 512 -usb -hda debian-kfreebsd.base.raw -net nic,vlan=0,macaddr=00:aa:00:ff:00:fb -net vde,vlan=0,sock=/var/run/vde2/tap0.ctl -serial mon:stdio -monitor null -cdrom mini-kfreebsd-amd64-20090831.iso -boot d Original plan was to use serial console only, but this seems to be unsupported (probably more of a generic d-i problem). Also meant to use an e1000 NIC but forgot to specify it. That caused a minor problem when I remembered it afterwords, as the primary NIC was renamed from re0 to em0. But that is of course to be expected with FreeBSD and obviously an user error anyway... Serial console woes: /etc/inittab had a couple of commented out lines as usual, so I just uncommented the first in the belief that the device name was correct: # Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L cuaa0 9600 vt100 But this ended up with INIT: Id "T0" respawning too fast: disabled for 5 minutes So I looked around in /dev/ for other possibilities, and remembered that JUNOS routers (which are the only FreeBSD machines I've ever used before :-) use ttyd0. And this seems to work fine: T0:23:respawn:/sbin/getty -L ttyd0 9600 vt100 But that posed another minor problem: ttyd0 was not in /etc/securetty so I couldn't log in as root on the console. Easily fixed of course. but makes me wonder: Did I do something wrong, or are both /etc/inittab and /etc/securetty really using the wrong serial console device names? Then came the attempt to configure grub for serial console: Getting grub itself to use is of course the same as with Linux: GRUB_PRELOAD_MODULES=serial GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND="serial --unit=0 --speed=9600" But how am I supposed to make the freebsd kernel use it? Adding "-h" on the kernel command line maybe? But there does not seem to be any way to do that using /etc/grub.d/10_freebsd. Or am I missing the obvious? Hmm, maybe the missing feature "support for boot options". Right. For now, I've just added a static copy of the automatic configuration with the command line parameter, but this is of course not a good solution. BTW, while looking for docs, I noticed this weird path: kvm-kfreebsd:~# dpkg -L kfreebsd-image-7.2-1-amd64|grep home /usr/share/doc/home /usr/share/doc/home/aurel32 /usr/share/doc/home/aurel32/tmp /usr/share/doc/home/aurel32/tmp/kernel /usr/share/doc/home/aurel32/tmp/kernel/kfreebsd-7-7.2 /usr/share/doc/home/aurel32/tmp/kernel/kfreebsd-7-7.2/debian /usr/share/doc/home/aurel32/tmp/kernel/kfreebsd-7-7.2/debian/kfreebsd-image-7.2-1-amd64 /usr/share/doc/home/aurel32/tmp/kernel/kfreebsd-7-7.2/debian/kfreebsd-image-7.2-1-amd64/README.Debian Guess that's not supposed to happen :-) Bjørn -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543149: console-setup: perl errors during installation
On Monday 31 August 2009, Yann Dirson wrote: > This seems to be similar to #480533, which was apparently fixed by > moving more stuff to perl-base. I very much doubt it is related as the version of perl that fixed #480533 is ancient (included in stable). So if that change had fixed it, then I would never have seen the problem when I did. It may be that *a* solution to this issue could be to move yet more stuff to perl-base, but I doubt that is desirable. IMO console-setup should, if at all possible, make sure that it only uses functions available in current perl-base. Neither extending perl-base, nor having console-setup depend on perl are desirable solutions. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543149:
This seems to be similar to #480533, which was apparently fixed by moving more stuff to perl-base. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [PATCH] hw-detect: Do not attempt to load ide-generic if paravirt is active.
On Mon, 2009-08-31 at 14:34 +0200, Bjørn Mork wrote: > Ian Campbell writes: > > > The lguest and Xen paravirt_ops implementations both reserve all IO > > ports in the 0-65535 range which prevents ide-generic from loading > > Excuse me for being daft, but wasn't that the whole point of > paravirt-ioport? I guess the so. The problem stems from the driver returning -EBUSY rather than silently registering no devices, although I wouldn't necessarily describe that as a kernel bug. > > and leads to an error dialog being presented to the user. > > so, add a hack to work around the problems introduced by another hack? > Does this scale? How many drivers need to be prevented from attempting > to load just to avoid the (correct) error messages caused by the initial > brute force hack? It's only legacy (non-PnP) ISA drivers of which AFAIK ide-generic is the only one d-i tries to load by default, it's the only one I've seen in my testing at least. I agree that this could be handled better on the kernel side but I don't really know the rationale for how it is now. Ian. -- Ian Campbell Take me drunk, I'm home again! signature.asc Description: This is a digitally signed message part
Processed: Bug#544400: s390 Debian Installer panic bug # 536354
Processing commands for cont...@bugs.debian.org: > reassign 544400 debian-installer Bug #544400 [debian-cd] s390 Debian Installer panic bug # 536354 Bug reassigned from package 'debian-cd' to 'debian-installer'. > forcemerge 536375 544400 Bug#536375: debian-installer: [s390,lenny] kernel panic during boot Bug#544400: s390 Debian Installer panic bug # 536354 Bug#536478: installation-reports Forcibly Merged 536375 536478 544400. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Debian preseed: How to choose the hdd for partman?
Hi All,
I'm setting up a preseed installation scheme. Considering the partitioning the
docs on the debian-websites are not specific enough. It is not possible for
me to spedify the hdd for automatic partition creation. In the following I
shall describe, what I have done and where the problem is.
My setup is:
* USB stick for booting, which loads a preseed from my http-server
* USB stick is /dev/sda
* HDD where debian should be installed is /dev/sdb
This is the relevant section for the partition creation:
**
# REFERENCE (a)
d-i preseed/early_command string dd if=/dev/zero of=/dev/sdb count=64
# REFERENCE (b)
d-ipartman-auto/disk string /dev/discs/disc1/disc #/dev/sdb
d-ipartman-auto/method string regular
d-ipartman/confirm_new_label boolean true
d-ipartman-auto/choose_recipe select one-small-partition
# ok
d-ipartman/confirm_write_new_label boolean true
d-ipartman/choose_partitionselect Finish partitioning and write
changes to disk
d-ipartman/confirm boolean true
# needed to shut up complaint about unused keep_2 lv
d-i partman-basicmethods/method_only boolean false
d-i partman-auto/expert_recipe string one-small-partition :: \
1 1 1 ext3 $primary{ } $bootable{ } method{ format } \
format{ } use_filesystem{ } filesystem{ ext3 } mountpoint{ / } .\
64 512 300% linux-swap method{ swap } format{ } . \
100 1 10 ext2 method{ keep } .
**
Problem:
The problem is now, that reference (b) in the snipplet doesn't choose disk1
aka sdb - even though the disk is recognized after the additional modules
have been loaded (I verified this in another console). The installer always
uses the scheme for sda - aka the usb stick and the debian stuff is installed
on my installation-usb-stick...
How can I configure the hdd choice - the snipplet above is extracted from the
example of the debian website and obiously doesn't work. Maybe this part of
the installer is evaluated, before the hdd-controller modules are loaded and
therefore no sdb exists yet? Is there any way to debug stuff like this? Or is
there a more elegant way to exclude just the usb stick (by uuid) from the
partman-choices?
Additional question:
Further I'm wondering if there is another way to delete old partitions
automatically. In reference (a) in the snipplet I try to do this the hard
way. By the way: Also this line is not working. It has been extracted from my
old patched initrd-scheme.
Best regards & much thanks for your efforts:
Gerolf
--
http://gerolf.ziegenhain.com
signature.asc
Description: Digital signature
debian-installer for GNU/kFreeBSD
Hi, Following the work of Luca Favetella [1] during the Google Summer of Code [2], I am happy to announce that a first version of the debian-installer images are available here: http://temp.aurel32.net/d-i-kfreebsd/ Here are the SHA512 of the two images: 754ab22022868a441e76c71d5a5c32b1bb0d5cb46ad7d8ca8da8b01bb5796d246bac34ad101d4f5c2e14798d526bbe93066207e1467efdbde59ccd72254129ce mini-kfreebsd-amd64-20090831.iso c1bfa136ce6caabf39dba989fde08b3388d92754fdd14c71079a3fa5f5ba2938a6f82df899e6c34ae1ef2646e15e4046683ee76544875c670296f0fa0f3b3045 mini-kfreebsd-i386-20090831.iso Please test them and report problems here. If there are not too many issues, we will make an official release, put the images on the standard location [3] and make a wider announce (probably with "Bits from GNU/kFreeBSD porters" on debian-devel-announce). You can find more details about those images, including bugs or missing features, on the wiki [4]. Cheers, Aurelien [1] http://slackydeb.blogspot.com/ [2] http://wiki.debian.org/SummerOfCode2009 [3] http://glibc-bsd.alioth.debian.org/install-cd/ [4] http://wiki.debian.org/DebianInstaller/kFreeBSD -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: [PATCH] hw-detect: Do not attempt to load ide-generic if paravirt is active.
Ian Campbell writes:
> The lguest and Xen paravirt_ops implementations both reserve all IO
> ports in the 0-65535 range which prevents ide-generic from loading
Excuse me for being daft, but wasn't that the whole point of
paravirt-ioport?
/*
* Reserve the whole legacy IO space to prevent any legacy drivers
* from wasting time probing for their hardware. This is a fairly
* brute-force approach to disabling all non-virtual drivers.
*
* Note that this must be called very early to have any effect.
*/
int paravirt_disable_iospace(void)
{
return request_resource(&ioport_resource, &reserve_ioports);
}
> and leads to an error dialog being presented to the user.
so, add a hack to work around the problems introduced by another hack?
Does this scale? How many drivers need to be prevented from attempting
to load just to avoid the (correct) error messages caused by the initial
brute force hack?
And there are already kernel patches like this in the queue, disabling
paravirt-ioport for Xen: http://patchwork.kernel.org/patch/22432/
Which I believe means that you just as well could remove the hack from
lguest too. It has always been wrong. The prevent "wasting time
probing for their hardware" argument is just as valid for real
hardware. But the result is replacing probing by guessing...
Bjørn
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[PATCH] hw-detect: Do not attempt to load ide-generic if paravirt is active.
The lguest and Xen paravirt_ops implementations both reserve all IO ports in the 0-65535 range which prevents ide-generic from loading and leads to an error dialog being presented to the user. --- packages/hw-detect/debian/changelog |4 packages/hw-detect/hw-detect.sh |3 ++- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/packages/hw-detect/debian/changelog b/packages/hw-detect/debian/changelog index a3eeb4c..a44076e 100644 --- a/packages/hw-detect/debian/changelog +++ b/packages/hw-detect/debian/changelog @@ -22,6 +22,10 @@ hw-detect (1.74) UNRELEASED; urgency=low * Remove code to wait for initialization of megaraid_mbox driver. Should no longer be needed with current kernels. + [ Ian Campbell ] + * Do not attempt to load ide-generic if paravirt has reserved all ioport +regions. + -- Gaudenz Steilin Sat, 25 Jul 2009 13:02:53 +0200 hw-detect (1.73) unstable; urgency=low diff --git a/packages/hw-detect/hw-detect.sh b/packages/hw-detect/hw-detect.sh index 43a39aa..a39f082 100755 --- a/packages/hw-detect/hw-detect.sh +++ b/packages/hw-detect/hw-detect.sh @@ -310,7 +310,8 @@ fi # that have an ISA bus, but that seems like a good start; it could also # be done unconditionally. if [ -z "$LOAD_IDE" ] && is_not_loaded ide-generic && \ - [ -e /sys/bus/isa ] && is_available ide-generic; then + [ -e /sys/bus/isa ] && is_available ide-generic && \ + ! grep -q paravirt-ioport /proc/ioports; then update-dev --settle blockdev_count=$(ls /sys/block | wc -w) -- 1.6.3.3 -- Ian Campbell QOTD: "It was so cold last winter that I saw a lawyer with his hands in his own pockets." signature.asc Description: This is a digitally signed message part
Re: Bug#542113: RM: atari-bootstrap -- RoRA; m68k only
Hi! * Frans Pop [090831 11:28]: > No objection. The dependency is arch-specific, so removing the package > will not affect D-I for other arches. > We will keep the build dependency (and other m68k-specific dependencies) > because AFAIK the m68k porters still build D-I from their debian-ports > repository and for that the build dependency is still needed. Thanks for the fast feedback! Best Regards, Alexander signature.asc Description: Digital signature
Re: Bug#542113: RM: atari-bootstrap -- RoRA; m68k only
tags 542113 - moreinfo + confirmed thanks On Monday 31 August 2009, Alexander Reichle-Schmehl wrote: > * Adam D. Barratt [090817 23:39]: > > Please remove atari-bootstrap from unstable. It only produces binary > > packages for m68k so is redundant now that the architecture is no > > longer in unstable. > > atarai-bootstrap is a build-dependency for d-i. So just for safety I > would like to have their okay before removing it. No objection. The dependency is arch-specific, so removing the package will not affect D-I for other arches. We will keep the build dependency (and other m68k-specific dependencies) because AFAIK the m68k porters still build D-I from their debian-ports repository and for that the build dependency is still needed. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#542113: RM: atari-bootstrap -- RoRA; m68k only
Alexander Reichle-Schmehl wrote: > tags 542113 +moreinfo > thanks > > Hi! > > * Adam D. Barratt [090817 23:39]: > >> Please remove atari-bootstrap from unstable. It only produces binary >> packages for m68k so is redundant now that the architecture is no longer >> in unstable. > > atarai-bootstrap is a build-dependency for d-i. So just for safety I > would like to have their okay before removing it. It's a build dependency on m68k, which is not in unstable nor testing... d-i can still be built for m68k, though only with packages outside the main archive. Currently only the source package atari-bootstrap is in unstable... Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#542113: RM: atari-bootstrap -- RoRA; m68k only
tags 542113 +moreinfo thanks Hi! * Adam D. Barratt [090817 23:39]: > Please remove atari-bootstrap from unstable. It only produces binary > packages for m68k so is redundant now that the architecture is no longer > in unstable. atarai-bootstrap is a build-dependency for d-i. So just for safety I would like to have their okay before removing it. Best Regards, Alexander -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: reassign 544381 to os-prober
Processing commands for cont...@bugs.debian.org: > reassign 544381 os-prober Bug #544381 [os-prober] grub-pc: The os_prober does not include all the systems and entries are also not complete. Ignoring request to reassign bug #544381 to the same package > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: reassign 544381 to os-prober
Processing commands for cont...@bugs.debian.org: > reassign 544381 os-prober Bug #544381 [grub-pc] grub-pc: The os_prober does not include all the systems and entries are also not complete. Bug reassigned from package 'grub-pc' to 'os-prober'. Bug No longer marked as found in versions grub2/1.97~beta1-1. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#544381: grub-pc: The os_prober does not include all the systems and entries are also not complete.
reassign 544381 os-prober thanks Am Montag, den 31.08.2009, 10:00 +0530 schrieb Sridhar M.A.: > Package: grub-pc > Version: 1.97~beta1-1 > Severity: normal > > The configuration of grub-pc calls os_prober is supposed to include other > OS's on the machine. > In my case, I have the following systems installed : > > Debian > Xubuntu > Mandriva > Geexbox > > Of these, entries in /boot/grub/grub.cfg for debian and xubuntu are correct. > For Mandriva, > the initrd entry is not included which makes the system non-bootable. Entries > for geexbox > are not there at all! > > 30_os-prober gets all values from os-prober. It just makes a menu entry out of it. -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
