Bug#583650: hw-detect: Too high priority for driver-injection-disk/load template?
Quoting Petter Reinholdtsen (p...@hungry.com): > > tags 583650 + patch > thanks Of course, I personnally agree with that change..:-)...So, is there any reason not to commit it? I would say: if someone has objection, speak now or forever hold your peace... (I had to google around to fid the right expressionDebian development is good to learn good English...:-)) signature.asc Description: Digital signature
Re: Driver injection disk debconf templates in D-I
Quoting Frans Pop (elen...@planet.nl): > On Sunday 30 May 2010, Frans Pop wrote: > > Maybe use "hardware vendor" instead of OEM. Using just "hardware" does > > lose information as the essence is that the drivers are provided by the > > vendor, not by the distro. > > Or maybe better "hardware manufacturer". (re-adding -l10n-english) _Description: Detect hardware manufacturer driver injection disks That "fits" (menu item entries are limited in size). Justin proposed "-supplied" in this thread which could turn into: _Description: Detect hardware manufacturer-supplied driver injection disks 60 characters is, IIRC, OK for menu entries (if nothing changed, the limit is 65) Any preference? I personnally prefer the first solution as "supplied" in the second one is related to "hardware manufacturer", but the dash only links it to "manufacturer" which makes things look a little bit weird, IMHO. I committed the first choice as of now. We have until Tuesday to finally settle on this (l10n sync run). signature.asc Description: Digital signature
Re: Driver injection disk debconf templates in D-I
Steve Langasek wrote: > Er, no. The OEM is the "original manufacturer" of the equipment. There's > nothing ambiguous or diluted about this. There are many different OEMs, and > in different contexts the term will be used to refer to different equipment, > but the term is used quite consistently and accurately across the industry. I'm sure that's how it looks from your angle, but it looks very different to poor ignorant industry outsiders like me and the authors of Wikipedia's entry on this TLA, which starts with a paragraph titled "Contradictory and confusing definitions" and says they date right back to the sixties. >> So ? I dont' think we lose any information by being more explicit. > > You're not being more explicit, you're being *less* explicit. An "OEM > driver injection disk" explicitly refers to a driver injection disk provided > by the OEM. That's true. Would "manufacturer-supplied" cover it? Or maybe even just "built-in"? > A "hardware driver injection disk" could refer to a driver disk > provided by anyone, with no hint to the user as to where they should find > this or when to give up looking. If you tell the user, "this refers to > disks provided by your OEM", then they know where to look for such a disk > and when to conclude that no such disk exists for their use. How specialised is this hardware? I don't think ordinary shoppers in PC World consider themselves to _have_ OEMs, and nor would they benefit particularly from fine distinctions between the manufacture, assembly, and retail stages in the supply chain - all the users want to know is that the driver injection disk is provided as part of the hardware they're buying. In fact, emphasising the fact that it's built in might save the user some trouble looking for removable-media OEM driver disks. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100529235154.ga19...@xibalba.demon.co.uk
using cdn.debian.net with choose-mirror
Somehow I was not aware of cdn.debian.net until recently, but it seems
solid and good in the 3 countries I've tried it from. In particular in
the US, it's more reliable than using the http.us.debian.org rotation,
because it detects and disables failing mirrors. Its weighted load
balancing also seems good; it seems to pick fast mirrors.
I'd like it to be at least an option in choose-mirror. Possibly the default
for countries that it supports well[1]. Probably not the only choice,
since that would introduce a single point of failure. Maybe eventually,
the default and only prompt to choose a mirror if it fails.
The attached patch will, once cdn.debian.net is added to Mirrors.masterlist,
make choose-mirror include it as a choice in the list of mirrors for
all the countries the data says it supports.
For now I've sorted it below push-primary and push-secondary mirrors,
but above leaf mirrors. So it's not the default choice for most countries.
--
see shy jo
[1] cdn.debian.net does not include all countries that have Debian
mirrors. For example, Costa Rica has a mirror that it does not
include for whatever reason. I'm unsure if it directs Costa Rican
users to a mirror in a nearby country.
diff --git a/packages/choose-mirror/debian/changelog b/packages/choose-mirror/debian/changelog
index f85efd1..d01a1a3 100644
--- a/packages/choose-mirror/debian/changelog
+++ b/packages/choose-mirror/debian/changelog
@@ -1,3 +1,13 @@
+choose-mirror (2.34) UNRELEASED; urgency=low
+
+ * Support entries in Mirrors.masterlist of "Type: GeoIP", which have
+a Countries field listing all countries the GeoIP mirror supports well.
+ * For now, GeoIP mirrors are listed above Leaf mirrors, but after
+Push-Primary and Push-Secondary mirrors. We may later choose to
+change the ordering so cdn.debian.net is used by default.
+
+ -- Joey Hess Sat, 29 May 2010 19:19:00 -0400
+
choose-mirror (2.33) unstable; urgency=low
* Correctly move progress bar to 100% after reading suites.
diff --git a/packages/choose-mirror/mirrorlist b/packages/choose-mirror/mirrorlist
index c5b6996..1444bf6 100755
--- a/packages/choose-mirror/mirrorlist
+++ b/packages/choose-mirror/mirrorlist
@@ -80,12 +80,13 @@ for (my $id = 0; $id < @data; $id++) {
}
}
-# Poor man's mirror rating system: push-primary, push* (-secondary), others
+# Poor man's mirror rating system: push-primary, push* (-secondary), geoip, others
foreach my $id (0..$#data) {
my $rating=0;
if (exists $data[$id]->{type}) {
- $rating=1 if $data[$id]->{type} =~ /push/i;
-$rating=2 if $data[$id]->{type} =~ /push-primary/i;
+ $rating=1 if $data[$id]->{type} =~ /geoip/i;
+ $rating=2 if $data[$id]->{type} =~ /push/i;
+$rating=3 if $data[$id]->{type} =~ /push-primary/i;
}
$data[$id]->{rating}=$rating;
}
@@ -132,15 +133,23 @@ else {
print OUT "static struct mirror_t mirrors_$type\[] = {\n";
my $q='"';
foreach my $id (sort { $data[$b]->{rating} <=> $data[$a]->{rating} } 0..$#data) {
- next unless exists $data[$id]->{"archive-$type"} and
- exists $data[$id]->{country};
- if (! exists $data[$id]->{'archive-architecture'}) {
- print STDERR "warning: missing archive-architecture for mirror ".$data[$id]->{site}."; assuming it contains all architectures.\n";
+ my @cc;
+ if (exists $data[$id]->{type} && $data[$id]->{type} =~/geoip/i) {
+ @cc=split(' ', $data[$id]->{countries});
+ }
+ else {
+ @cc=$data[$id]->{country};
+ }
+ foreach my $cc (@cc) {
+ next unless exists $data[$id]->{"archive-$type"} and defined $cc;
+ if (! exists $data[$id]->{'archive-architecture'}) {
+print STDERR "warning: missing archive-architecture for mirror ".$data[$id]->{site}."; assuming it contains all architectures.\n";
+ }
+ print OUT "\t{",
+ join(", ", $q.$data[$id]->{site}.$q, $q.$cc.$q,
+ $q.$data[$id]->{"archive-$type"}.$q),
+ "},\n";
}
- print OUT "\t{",
- join(", ", $q.$data[$id]->{site}.$q, $q.$data[$id]->{country}.$q,
-$q.$data[$id]->{"archive-$type"}.$q),
- "},\n";
}
print OUT "\t{NULL, NULL, NULL}\n";
print OUT "};\n";
signature.asc
Description: Digital signature
Re: Driver injection disk debconf templates in D-I
On Sunday 30 May 2010, Frans Pop wrote: > Maybe use "hardware vendor" instead of OEM. Using just "hardware" does > lose information as the essence is that the drivers are provided by the > vendor, not by the distro. Or maybe better "hardware manufacturer". -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005300123.30482.elen...@planet.nl
Re: Driver injection disk debconf templates in D-I
On Saturday 29 May 2010, Christian PERRIER wrote: > > > I replaced "OEM" by "hardware" in an attempt to unjargonize. > > > > And thereby losing information. > > Well, then define OEM in this contextThis acronym is used in each > and every possible situation and nearly means nothing nowadays. So ? I > dont' think we lose any information by being more explicit. I fully agree that OEM is a nonsense term and confusing to users. Maybe use "hardware vendor" instead of OEM. Using just "hardware" does lose information as the essence is that the drivers are provided by the vendor, not by the distro. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005300029.23354.elen...@planet.nl
Re: Driver injection disk debconf templates in D-I
On Sat, May 29, 2010 at 11:15:20PM +0200, Christian PERRIER wrote: > Quoting Steve Langasek (vor...@debian.org): > > On Sat, May 29, 2010 at 09:43:03AM +0200, Christian PERRIER wrote: > > > I committed the changes with two extra changes: > > > 1) the sublevel has be changed to 3. There is no reason to enforce the > > > translation of this template that hard (sublevels 1 and 2 being > > > complete is theoretically mandatory). > > > > Template: debian-installer/driver-injection-disk-detect/title > > > > Type: text > > > > # Main menu item > > > > # :sl1: > > > > _Description: Detect OEM driver injection disks > > > I replaced "OEM" by "hardware" in an attempt to unjargonize. > > And thereby losing information. > Well, then define OEM in this contextThis acronym is used in each > and every possible situation and nearly means nothing nowadays. Er, no. The OEM is the "original manufacturer" of the equipment. There's nothing ambiguous or diluted about this. There are many different OEMs, and in different contexts the term will be used to refer to different equipment, but the term is used quite consistently and accurately across the industry. > So ? I dont' think we lose any information by being more explicit. You're not being more explicit, you're being *less* explicit. An "OEM driver injection disk" explicitly refers to a driver injection disk provided by the OEM. A "hardware driver injection disk" could refer to a driver disk provided by anyone, with no hint to the user as to where they should find this or when to give up looking. If you tell the user, "this refers to disks provided by your OEM", then they know where to look for such a disk and when to conclude that no such disk exists for their use. If you just let them think that it's a generic hardware driver disk, who knows where they'll look for it (in fact, many of them will probably look around on the Debian website trying to find these driver disks, thinking they're something extra we're supposed to provide). If this udeb only handles the OEM-bundled style of driver disks, we should let users know this so they don't wind up on a fruitless search for something that doesn't exist. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100529214024.ga9...@dario.dodds.net
Re: Driver injection disk debconf templates in D-I
Quoting Steve Langasek (vor...@debian.org): > On Sat, May 29, 2010 at 09:43:03AM +0200, Christian PERRIER wrote: > > I committed the changes with two extra changes: > > > 1) the sublevel has be changed to 3. There is no reason to enforce the > > translation of this template that hard (sublevels 1 and 2 being > > complete is theoretically mandatory). > > > > Template: debian-installer/driver-injection-disk-detect/title > > > Type: text > > > # Main menu item > > > # :sl1: > > > _Description: Detect OEM driver injection disks > > > I replaced "OEM" by "hardware" in an attempt to unjargonize. > > And thereby losing information. Well, then define OEM in this contextThis acronym is used in each and every possible situation and nearly means nothing nowadays. So ? I dont' think we lose any information by being more explicit. > > The d-i main menu is only shown in expert mode or when there's been an > exception in the install. We shouldn't make these menu items less accurate > to avoid using "jargon", that will only confuse users into thinking this > menu item could be used for something it can't. > > > I also reported a bug suggesting to lower the priority at which this > > template is displayed. > > It's a main menu item. Doesn't the priority of udeb menu item templates > affect either a) whether the udeb is *run* by default, or b) nothing (I > can't remember which)? I'm not talking about he mtnu item priority, I'm talking about the driver-injection-disk/load template priority, in : bubu...@mykerinos:~/src/debian/debian-installer/packages/hw-detect/debian> more ../driver-injection-disk.sh #!/bin/sh .../... db_input high driver-injection-disk/load || true .../... s/high/medium is what I propose. signature.asc Description: Digital signature
Bug#583650: hw-detect: Too high priority for driver-injection-disk/load template?
tags 583650 + patch thanks [Christian Perrier] > IMHO, this template has a quite sane default and I don't think there > is a need to display it for default installs. After all, all it is > asking is "should I try to detect the OEM divers injection disk?" > which is a quite safe action. > > Even though my understanding is that the package itself is used only > in specific cases, I'd suggest lowering the priority to medium. I agree as long as the default is true. This patch would do it. Index: debian/driver-injection-disk-detect.templates === --- debian/driver-injection-disk-detect.templates (revision 63340) +++ debian/driver-injection-disk-detect.templates (working copy) @@ -6,6 +6,7 @@ Template: driver-injection-disk/load Type: boolean +Default: true # :sl3: _Description: Load drivers from internal "drivers disk"? Installing on this hardware may require some drivers provided by the Index: driver-injection-disk.sh === --- driver-injection-disk.sh(revision 63340) +++ driver-injection-disk.sh(working copy) @@ -32,7 +32,7 @@ for device in $(list-devices usb-partition); do label=$(block-attr --label $device 2>/dev/null || true) if [ "$label" = "OEMDRV" ]; then - db_input high driver-injection-disk/load || true + db_input medium driver-injection-disk/load || true if ! db_go; then exit 10 # back up fi Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl7hmmsbgv@login1.uio.no
Re: lilo removal in squeeze (or, "please test grub2")
On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote: > Stephen Powell wrote: >> On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: >>> After some discussion about lilo on #debian-devel in IRC, it has pretty >>> much been determined that kernel sizes have crossed the line past where >>> lilo can reliably determine the payload size. >> > > We're speaking about #505609 I assume? I hope not. Strictly speaking, 505609 is not a lilo bug. The key is that he was still able to boot his old kernel that had been de-installed. That's a sure sign that lilo's map installer did not get run during the kernel upgrade process. It used to be that if do_bootloader = yes was specified in /etc/kernel-img.conf that installing a new kernel would cause lilo to be run. That is no longer the case. "update-initramfs -u ..." will cause lilo to be run if this option is set; but "update-initramfs -c ..." (or mkinitramfs ...) which is what is run during installation of a new kernel, will not. I have created my own hook script to fix that problem on my system. Strangely, though, "do_bootloader = yes" in /etc/kernel-img.conf still causes zipl to be run during kernel installation on the s390 platform. Something must have changed in the kernel maintainer script or in update-initramfs that causes the lilo map installer to not be run anymore under conditions that used to cause it to be run. Look carefully at the console log. There is no output from the map installer until he manually runs lilo. He apparently thinks that running lilo from the command line simply lists the installed kernels. No. Running lilo from the command line is what fixed the problem. If there's a bug here, it's somewhere else in the kernel installation process, not in lilo itself. If this so-called bug in lilo is what prompted the decision to drop lilo, then the decision was based on bad data. lilo, at least in this case, is working as designed. The problem is that the lilo map installer did not get run during the kernel installation process. I've helped a number of people on debian-user with problems like this, and in every case so far running lilo at the command line fixed the problem. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/267435255.153128.1275165812236.javamail.r...@md01.wow.synacor.com
Processed: Re: Bug#583650: hw-detect: Too high priority for driver-injection-disk/load template?
Processing commands for cont...@bugs.debian.org: > tags 583650 + patch Bug #583650 [hw-detect] hw-detect: Too high priority for driver-injection-disk/load template? Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 583650: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583650 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127516466219783.transcr...@bugs.debian.org
Re: Driver injection disk debconf templates in D-I
On Sat, May 29, 2010 at 09:29:40PM +0200, Petter Reinholdtsen wrote: > >> I also reported a bug suggesting to lower the priority at which this > >> template is displayed. > > It's a main menu item. Doesn't the priority of udeb menu item > > templates affect either a) whether the udeb is *run* by default, or > > b) nothing (I can't remember which)? > I suspect Christian was refering to the debconf question presented by > the package. It is using debconf priority high to ask if the detected > drive should be used to load drivers. I suspect its priority should > be lowered to medium as Christian suggests. > The menu item do not have a debconf priority, and thus its menu > handling is not affected by any debconf priority. :) > There is also the template priority which affect what translators work > on, and there I suspect Christians changes were correct. This new > udeb is not used in the common case, and its translations should thus > not be very high priority. Oh, sorry for misunderstanding. Yes, if this is about the priority of the question about whether to *use* the driver disk that's been found, I think medium (with a default answer of 'yes') seems reasonable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100529200956.ga5...@dario.dodds.net
Re: Driver injection disk debconf templates in D-I
[Steve Langasek] > And thereby losing information. > > The d-i main menu is only shown in expert mode or when there's been > an exception in the install. We shouldn't make these menu items > less accurate to avoid using "jargon", that will only confuse users > into thinking this menu item could be used for something it can't. Good point. >> I also reported a bug suggesting to lower the priority at which this >> template is displayed. > > It's a main menu item. Doesn't the priority of udeb menu item > templates affect either a) whether the udeb is *run* by default, or > b) nothing (I can't remember which)? I suspect Christian was refering to the debconf question presented by the package. It is using debconf priority high to ask if the detected drive should be used to load drivers. I suspect its priority should be lowered to medium as Christian suggests. The menu item do not have a debconf priority, and thus its menu handling is not affected by any debconf priority. :) There is also the template priority which affect what translators work on, and there I suspect Christians changes were correct. This new udeb is not used in the common case, and its translations should thus not be very high priority. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fld3wesdzv@login1.uio.no
Re: Driver injection disk debconf templates in D-I
On Sat, May 29, 2010 at 09:43:03AM +0200, Christian PERRIER wrote: > I committed the changes with two extra changes: > 1) the sublevel has be changed to 3. There is no reason to enforce the > translation of this template that hard (sublevels 1 and 2 being > complete is theoretically mandatory). > > Template: debian-installer/driver-injection-disk-detect/title > > Type: text > > # Main menu item > > # :sl1: > > _Description: Detect OEM driver injection disks > I replaced "OEM" by "hardware" in an attempt to unjargonize. And thereby losing information. The d-i main menu is only shown in expert mode or when there's been an exception in the install. We shouldn't make these menu items less accurate to avoid using "jargon", that will only confuse users into thinking this menu item could be used for something it can't. > I also reported a bug suggesting to lower the priority at which this > template is displayed. It's a main menu item. Doesn't the priority of udeb menu item templates affect either a) whether the udeb is *run* by default, or b) nothing (I can't remember which)? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100529190627.gb15...@dario.dodds.net
Bug#278116: GOOD NEWS
Your e-mail address has made you a winner of 2,500,000GBP, from the Canadian Lottery Promo. Contact our British Agent Trevor Allan via: E-mail: lotto...@gala.net Tel: +447031979972 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1432087145.67681275154966265.javamail.r...@moh-zcs-mbs1.moh.gov.om
Re: lilo removal in squeeze (or, "please test grub2")
* Stephen Powell (zlinux...@wowway.com) [100523 21:21]: > On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: > > After some discussion about lilo on #debian-devel in IRC, it has pretty > > much been determined that kernel sizes have crossed the line past where > > lilo can reliably determine the payload size. We're speaking about #505609 I assume? I'm not sure this bug requires an removal of lilo (see below), however I think this means we should strongly discourage usage of lilo. > > (1) The release notes need to be updated to reflect that lilo is no > > longer a bootloader option; The release notes should be updated in case we keep lilo that we recommend to move to another boot loader now. > > (2) The debian-installer team needs to remove the lilo-installer udeb; This should indeed happen - if someone activly requires lilo, then doing it by hand should be ok-ish. > I am not a Debian package maintainer or a Debian developer. I am just an > ordinary system administrator. So I'm sure that my opinion will not count > for much. But I am opposed to the removal of lilo. Both grub-legacy and > grub-pc use sectors on the hard disk outside of the master boot record > (cylinder 0, head 0, sector 1). In other words they use cylinder 0, head 0, > sector 2 and possibly subsequent sectors on cylinder 0 head 0. This breaks > the design of the backup software that my employer uses. This backup software > backs up the master boot record and all partitions; but since the extra > sectors used by grub-legacy and grub-pc are outside the master boot record > and are not part of any partition, they don't get backed up. Consequently, > if we have a hard drive failure and restore from a backup, we have an > unbootable machine. Lilo uses only the master boot record. A lilo-booted > machine can be backed up and restored with our existing backup software > just fine. Given these requirements, I wouldn't use grub-pc even if it > were bug free and well documented. (But neither is the case!) Would it be possible to move (perhaps optionally) the extra grub sectors into an (perhaps dummy) partition (this question is for the grub2-people)? Would that be ok for you? > As for the claims that kernels are too big now, I find that hard to > believe, especially now that we have the large-memory option available. > The standard stock Debian kernel image file that I use for Squeeze, > vmlinuz-2.6.32-3-686, is currently 2234080 bytes. Are you trying to tell > me that there's no room for a 2M kernel below the start of the EBDA? > > I am able to load *both* the kernel *and* the initial RAM filesystem > below the EBDA (i.e. the large-memory option is not used) if I use > MODULES=dep instead of MODULES=most in the initial RAM filesystem > under Lenny. I'll bet I can do it with Squeeze too. This sounds like we should add an wrapper around lilo that warns that lilo is deprecated and warns if the images are too large. Andi -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100529184041.gk13...@mails.so.argh.org
Re: [RFC] Dealing with mdadm superblock metadata default change
also sprach Frans Pop [2010.05.29.1756 +0200]: > But is that realistic for Squeeze? Colin Watson says Grub2 is not too badly out of shape. Upstream would be willing to introduce a compile-time flag. I think I'll go the latter path. -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems obviously i was either onto something, or on something. -- larry wall on the creation of perl digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: [RFC] Dealing with mdadm superblock metadata default change
On Friday 28 May 2010, martin f krafft wrote: > also sprach Frans Pop [2010.03.14.0811 +0100]: > > > Yes, I think it should be in mdadm. It should be as easy as > > > reverting > > > http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=commitdiff;h=7d5c3964 > > >ccfa ace123f7b75e15d38c2650e013d8 > > > > What's the status of this? > > Upstream has since moved the default to 1.2. I am hesitant to revert > all of that. > > I only see three ways: > > 1. Ask upstream to provide a compile-time switch to keep the default >at 0.9. > > 2. Default to 0.9 in the mdadm.conf file. > > 3. Expect and require the bootloaders to catch up. > > I prefer 3 over 1 over 2. But is that realistic for Squeeze? BTW, someone else will have to follow up on this from the D-I side. I'm dropping the issue from my ToDo list. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005291756.09385.elen...@planet.nl
Bug#583673: Installation of squeeze at FSC Amilo Pro V2055
Package: installation-reports Boot method: CD Image version: self-made installation CD with actual installer from sid Date: 2010-05-29 Machine: Notebook: Fujitsu-Siemens Amilo Pro V2055 Processor: Celeron 1,4GHz Memory: 768MB Partitions: Dateisystem Typ1K‐Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/sda1 ext4 9611492 4966868 4156384 55% / tmpfstmpfs 378416 0378416 0% /lib/init/rw udev tmpfs 374236 188374048 1% /dev tmpfstmpfs 37841688378328 1% /dev/shm /dev/sda6 ext426659076177572 25127264 1% /home Output of lspci -knn: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:0314] Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: agpgart-via 00:00.1 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:1314] 00:00.2 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:2314] 00:00.3 Host bridge [0600]: VIA Technologies, Inc. PT890 Host Bridge [1106:3208] 00:00.4 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:4314] 00:00.7 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:7314] 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237/VX700 PCI Bridge [1106:b198] 00:06.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02) Subsystem: Device [17f9:0006] Kernel driver in use: b43-pci-bridge 00:0c.0 CardBus bridge [0607]: ENE Technology Inc CB1410 Cardbus Controller [1524:1410] (rev 01) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: yenta_cardbus 00:0f.0 IDE interface [0101]: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller [1106:3149] (rev 80) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: sata_via 00:0f.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: VIA_IDE 00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 81) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: uhci_hcd 00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 81) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: uhci_hcd 00:10.4 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 86) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: ehci_hcd 00:11.0 ISA bridge [0601]: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] [1106:3227] Subsystem: Fujitsu Technology Solutions Device [1734:10ca] 00:11.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] (rev 60) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: VIA 82xx Audio 00:11.6 Communication controller [0780]: VIA Technologies, Inc. AC'97 Modem Controller [1106:3068] (rev 80) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: VIA 82xx Modem 00:12.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6102 [Rhine-II] [1106:3065] (rev 78) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Kernel driver in use: via-rhine 01:00.0 VGA compatible controller [0300]: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro] [1106:3344] (rev 01) Subsystem: Fujitsu Technology Solutions Device [1734:10ca] Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: General: No problems detected One minor issue detected: The installation of the package gnome-system-monitor failed during installation without error message during installation (see syslog): May 29 08:07:27 in-target: Hole:735 ftp://ftp.de.debian.org squeeze/main libcairomm-1.0-1 1.8.4-3 [72,2kB] May 29 08:07:27 in-target: Hole:736 ftp://ftp.de.debian.org squeeze/main libpangomm-1.4-1 2.26.2-1 [70,6kB] May 29 08:07:28 in-target: Hole:737 ftp://ftp.de.debian.org squeeze/main libgtkmm-2.4-1c2a 1:2.20.3-1 [1.2
Bug#578927: debian-installer: No kernel driver for powerpc mac mini ethernet (Sun GEM)
On Fri, Apr 23, 2010 at 05:33:44PM +0100, Roger Leigh wrote: > Package: debian-installer > Version: daily-image powerpc netinst ISO 2010-0419 > Severity: normal > > During the installer check for an ethernet interface prior to > bringing up the network, it fails to find an ethernet interface. > > lspci -v reports: > > 0002:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun > GEM) (rev ff) (prog-if ff) > !!! Unknown header type 7f > > This worked just fine for earlier Debian releases; maybe it's > just missing the appropriate kernel module? I used the netboot image from 03-Apr to successfully install on a PowerBook G4 (powerbook5,8). It has a similar ethernet controller also using the sungem driver. The pci id of my card is 106b:006b. So this is probably not a general problem for all powermacs. You could also try one of the newer daily images. I just discovered that they are now built again. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100529072812.gs7...@soziologie.ch
Re: Driver injection disk debconf templates in D-I
I committed the changes with two extra changes: 1) the sublevel has be changed to 3. There is no reason to enforce the translation of this template that hard (sublevels 1 and 2 being complete is theoretically mandatory). > Template: debian-installer/driver-injection-disk-detect/title > Type: text > # Main menu item > # :sl1: > _Description: Detect OEM driver injection disks I replaced "OEM" by "hardware" in an attempt to unjargonize. I also reported a bug suggesting to lower the priority at which this template is displayed. signature.asc Description: Digital signature
Bug#583650: hw-detect: Too high priority for driver-injection-disk/load template?
Package: hw-detect Severity: normal IMHO, this template has a quite sane default and I don't think there is a need to display it for default installs. After all, all it is asking is "should I try to detect the OEM divers injection disk?" which is a quite safe action. Even though my understanding is that the package itself is used only in specific cases, I'd suggest lowering the priority to medium. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100529074015.27392.23755.report...@mykerinos.kheops.frmug.org
