Re: Question about having an always clean base system in Debian Sid
Le mercredi 27 janvier 2010 à 10:43 +0100, Frans Pop a écrit : > On Wednesday 27 January 2010, Geek87 wrote: > > I also would like to have it working similarly for the tasks: for > > example if I have a task "Mail server" installed depending on Sendmail > > and that the new version of this task now depends on Postfix, I would > > like Sendmail to be automatically removed and Postfix to be > > automatically installed. The technique above doesn't work for the tasks. > > I don't think that's possible as the package management system does not > keep any state information about which tasks are installed. > > You have to see tasks and tasksel as an optional convenience feature, not > as something that's a part of the core package management (unlike for > example meta packages). > > Cheers, > FJP > > Thanks! So it's impossible to have it work with tasksel. And for the base system? Does someone have an idea? Thanks in advance. Bye Geek87 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about having an always clean base system in Debian Sid
On Thursday 28 January 2010, Geek87 wrote: > Thanks! So it's impossible to have it work with tasksel. And for the > base system? Does someone have an idea? That's a question that's probably better asked on the debian-user list. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of netcfg-static
On Wed, Jan 27, 2010 at 03:39:46PM +0100, Frans Pop wrote:
> On Wednesday 27 January 2010, Josef Wolf wrote:
> > I am wondering what netcfg-static is good for. Looks like it is an
> > (outdated) subset of the more generic netcfg.
>
> No. It's used for s390:
> installer/build/pkg-lists/netboot/s390.cfg:1:netcfg-static
> installer/build/pkg-lists/generic/s390.cfg:3:netcfg-static
This can not be replaced by the generic netcfg with netcfg/use_dhcp set
to "false" or netcfg/disable_dhcp set to "true"?
And won't generic netcfg fall back to static when dhcp fails? So even the
above settings should not be needed, IMHO.
What is so special about the s390 that it requires/deserves its own netcfg?
Why not introduce netcfg-thinkpad or netcfg-eeepc or something?
Please don't get offended, I'm just asking questions since I don't understand
it.
> > Here is a first attempt to bring those two programs in sync again. There
> > are more differences (especially in the GET_INTERFACE state), but I have
> > not done a closer look at them yet.
> > -enum { BACKUP, GET_INTERFACE, GET_HOSTNAME_ONLY, GET_STATIC,
> > WCONFIG, WCONFIG_ESSID, WCONFIG_WEP, QUIT} state = GET_INTERFACE; +
> > enum { BACKUP,
> > + GET_INTERFACE,
> > + GET_HOSTNAME_ONLY,
> > + GET_STATIC,
> > + WCONFIG,
> > + WCONFIG_ESSID,
> > + WCONFIG_WEP,
> > + QUIT } state = GET_INTERFACE;
>
> Wireless is useless for s390 (and static network config is almost per
> definition not suitable for wireless), so the wireless bits should not be
> synced.
Frans, I have not changed any wireless bits here.
All I have done here was to change whitespace to get the same formatting
of the enum as in the generic netcfg. The wireless stuff is already in
netcfg-static for quite a while. I haven't done any functional changes here
at all. BTW: the wireless bits in netcfg-static are quite different from
the wireless bits in generic netcfg.
IMHO, this proves my point. netcfg-static is a piece of duplicated code for
a very special case. This code tends to be rarely tested and rarely looked
at. When bugs are fixed in the generic netcfg, the fixes are not always
propagated to netcfg-static. This is why I think it would be better to
replace it by the generic netcfg if possible. If this is not possible, at
least the code should be synced as far as possible. A simple "diff -uw"
would then help to check if there are any fixes which have been forgotten
to propagate. Please put a big "IMHO" onto all this writing.
I don't really care about netcfg-static. I don't have a s390 and I don't
know anybody who have one. I just think duplicated code to be a bad thing.
Especially if I see differences like
case WCONFIG_WEP:
-if (netcfg_wireless_set_wep (client, interface))
+if (netcfg_wireless_set_wep(client, interface) == GO_BACK)
state = WCONFIG_ESSID;
I get the feeling that there's something wrong. You may argue that wireless
is not used by s390 anyway, but the bad feeling remains.
> > -while (1) {
> > +/* Check to see if netcfg should be run at all */
> [...]
>
> On s390 network configuration is required.
But netcfg/enable is set to "true" by default. So I don't see a functional
change here. Even more: I don't see any reason why netcfg-static could not
be replaced by the generic netcfg.
> > netcfg.c - Configure a network via DHCP or manual configuration
> > - for debian-installer
> > + for the debian-installer
>
> This is incorrect.
OK, I see. I did not know that netcfg-static is for s390 only and that dhcp
don't work on s390. But my original question remains: are there any reasons
_not_ to replace netcfg-static by generic netcfg?
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565639: SunBlade 1000 installation report - boot fails after installation
reassign 565639 linux-2.6 2.6.30-8 severity 565639 serious affects 565639 debian-installer On Sunday 24 January 2010, Jurij Smakov wrote: > Adding kernel team for comment: it looks like the value returned by > uname -m has changed from 'sparc64' in kernel 2.6.26 to 'sparc' in > 2.6.30 (and, probably, later ones). This breaks SILO, which uses this > value to determine what first-stage bootloader to install, as a result > the sparc machines installed with current daily installer builds turn > unbootable by the end of installation. Thanks for tracing the cause to this. Reassigning to the kernel team for further investigation. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed (with 5 errors): Re: Bug#565639: SunBlade 1000 installation report - boot fails after installation
Processing commands for cont...@bugs.debian.org: > reassign 565639 linux-2.6 2.6.30-8 Bug #565639 [installation-reports] SunBlade 1000 installation report - boot fails after installation Bug reassigned from package 'installation-reports' to 'linux-2.6'. Bug #565639 [linux-2.6] SunBlade 1000 installation report - boot fails after installation There is no source info for the package 'linux-2.6' at version '2.6.30-8' with architecture '' Unable to make a source version for version '2.6.30-8' Bug Marked as found in versions 2.6.30-8. > severity 565639 serious Bug #565639 [linux-2.6] SunBlade 1000 installation report - boot fails after installation Severity set to 'serious' from 'normal' > affects 565639 debian-installer Bug #565639 [linux-2.6] SunBlade 1000 installation report - boot fails after installation Added indication that 565639 affects debian-installer > On Sunday 24 January 2010, Jurij Smakov wrote: Unknown command or malformed arguments to command. > > Adding kernel team for comment: it looks like the value returned by Unknown command or malformed arguments to command. > > uname -m has changed from 'sparc64' in kernel 2.6.26 to 'sparc' in Unknown command or malformed arguments to command. > > 2.6.30 (and, probably, later ones). This breaks SILO, which uses this Unknown command or malformed arguments to command. > > value to determine what first-stage bootloader to install, as a result Unknown command or malformed arguments to command. Too many unknown commands, stopping 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
32-bit install kernel sleeps off during installation
Hi, I'm a linux hardware test engineer and I'm also testing Debian on new hardware from time to time. Actually I'm trying to figure out a strange problem: I have a system that sleeps of when I'm installing Debian/Lenny 32bit. The installation is done by booting the netboot kernel & initrd.gz from PXE and then doing a normal network installation. This task is usally easy, just respond to the dialogs and your system will be installed in around 30 minutes. On this system its different. The progress bars stop until you hit a key on the keyboard (text installer) or move the mouse (graphical installer). Switching to one of the consoles and doing a dmesg there sometimes shows a message that CPU#0 has a soft lockup for more than xxx seconds! So the installation needs a frequent "kick" with the keyboard or the mouse to finish. Once the system is installed I never see this problem again. Would be nice to figure out the "why" behind this problem. My guess at the moment is that it is related to a) the CPU which is a new AMD dual core athlon b) the 2.6.26-2-486 kernel that is used during the installation The later would also explain why the problem doesn't occur anymore once the installation is done, because then the 2.6.26-2-686 kernel is used. To prove this theory I also did a 64-bit installation which luckily uses 2.6.26-2-amd64 for both installation and running system and here everything worked without the kernel sleeping of. So I think there is a sort of "incompatibilty" on new Athlon processors and the -486 kernel from Debian. Question is: Is there a easy (means debian like and good documented) way to build a netboot image with a different kernel architecture. From my understanding this would mean replacing both the kernel image as well as all the modules that are provided from the initrd.gz image. Comments, hints & ideas are welcome. I would really nail down the root cause of this just to be sure about the "why". Here are some details from my tests so far: /proc/cpuinfo (from the -486 kernel): processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) Neo X2 Dual Core Processor L325 stepping: 2 cpu MHz : 1500.020 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow up pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch bogomips: 3078.71 clflush size: 64 power management: ts fid vid ttp tm stc 100mhzsteps System-components (lspci): 00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge 00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx) 00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 2) 00:07.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3) 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14) 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) 08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Regards & thanks for the excellent work on the Debian project Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Business Clients Dept. TSP CLI R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-
Processed: Block
Processing commands for cont...@bugs.debian.org: > block 373253 by 567182 Bug #373253 [debian-installer] "libgcc_s.so.1 on AMD64 and PowerPC should be provided Was not blocked by any bugs. Added blocking bug(s) of 373253: 567182 > 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: 32-bit install kernel sleeps off during installation
On Thursday 28 January 2010, Rainer Koenig wrote: > Would be nice to figure out the "why" behind this problem. My guess at > the moment is that it is related to > a) the CPU which is a new AMD dual core athlon > b) the 2.6.26-2-486 kernel that is used during the installation > > So I think there is a sort of "incompatibilty" on new Athlon processors > and the -486 kernel from Debian. The problem you describe indeed sounds like a kernel problem. The first thing I would suggest to do is try if the Squeeze installer [1] (which currently uses a 2.6.30 kernel) still has the same problem. > Question is: Is there a easy (means debian like and good documented) way > to build a netboot image with a different kernel architecture. From my > understanding this would mean replacing both the kernel image as well as > all the modules that are provided from the initrd.gz image. You're in luck as the 686 kernel is already available as udebs. The steps are roughly as follows: - check out the lenny branch of the D-I source repository: svn co svn://svn.debian.org/svn/d-i/branches/d-i/lenny/installer - cd installer/build - edit config/i386.cfg and change -486 to -686 in KERNELVERSION - install build dependencies - build a netboot image using: make reallyclean; fakeroot make build_netboot - use either the netboot image itself, or the mini.iso Cheers, FJP [1] http://www.debian.org/devel/debian-installer/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
On 27.01.2010 23:26, Frans Pop wrote: Thanks a lot for the quick reply. On Wednesday 27 January 2010, Matthias Klose wrote: The patch itself looks ok, some other questions: - did you consider building the udeb from a separate source package, build-depending on gcc-4.4-source? No, I had not considered that. It's an option that has both advantages and disadvantages. The main disadvantage IIUC would be that we'd have to upload or binNMU that separate package every time gcc gets uploaded (for source compliance), which means it needs special tracking. I think for that reason it's a solution the Release team is generally not all that happy with. no, that's wrong. this is only required if the upstream tarball changes, and this is easily discovered by looking at the build dependencies. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
On Thursday 28 January 2010, Matthias Klose wrote: > On 27.01.2010 23:26, Frans Pop wrote: > > On Wednesday 27 January 2010, Matthias Klose wrote: > >>- did you consider building the udeb from a separate source > >> package, build-depending on gcc-4.4-source? > > > > No, I had not considered that. It's an option that has both advantages > > and disadvantages. > > > > The main disadvantage IIUC would be that we'd have to upload or binNMU > > that separate package every time gcc gets uploaded (for source > > compliance), which means it needs special tracking. I think for that > > reason it's a solution the Release team is generally not all that > > happy with. > > no, that's wrong. this is only required if the upstream tarball changes, > and this is easily discovered by looking at the build dependencies. Right. That reduces the problem a bit. It would mean that migrations of gcc could be blocked until a new "gcc-udeb" source package is uploaded. That would not be the case if the udebs are built from gcc. I'm still not convinced that the (IMO minor) disadvantages of having a udeb in gcc are sufficient to treat gcc different from all other packages that provide udebs. I would appreciate input from the Release team on this. Could someone please comment? See http://bugs.debian.org/567182#10 and later for most relevant info. Comments from others in the D-I team would also be welcome. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build failures for hd-media
On Thursday 28 January 2010, Christian PERRIER wrote: > Since 2 or 3 days, I'm having build failures on my local daily build > for i386. The IA64 buildd has a similar error: mkfs.msdos -i deb1 -n "Debian Inst" -C ./tmp/cdrom/boot.img 32768 mkfs.msdos 3.0.8 (23 Jan 2010) mmd -i./tmp/cdrom/boot.img ::/efi Cannot initialize '::' make[2]: *** [arch_boot] Error 1 Can you check what packages you've upgraded recently (aptitude or dpkg logs) and try downgrading likely candidates? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build failures for hd-media
On Thursday 28 January 2010, Frans Pop wrote: > On Thursday 28 January 2010, Christian PERRIER wrote: > > Since 2 or 3 days, I'm having build failures on my local daily build > > for i386. > > The IA64 buildd has a similar error: > mkfs.msdos -i deb1 -n "Debian Inst" -C ./tmp/cdrom/boot.img 32768 > mkfs.msdos 3.0.8 (23 Jan 2010) > mmd -i./tmp/cdrom/boot.img ::/efi > Cannot initialize '::' > make[2]: *** [arch_boot] Error 1 > > Can you check what packages you've upgraded recently (aptitude or dpkg > logs) and try downgrading likely candidates? The aptitude log for my i386 chroot had: [UPGRADE] dosfstools 3.0.7-1 -> 3.0.8-1 Downgrading that solved it. I'll file a BR. Cheers, FJP P.S. It really would be great if you could do such basic and simple checks yourself next time instead of always leaving it to others to solve problems. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[RFT]: Debian Installer - Pre-Alpha1 images ready for testing
Hello, The images using last uploaded debian-installer are available for testing[1]; If all looks fine I'd like to call it "a release". 1. http://cdimage.debian.org/cdimage/squeeze_di_test1/ I'd like to ask people to run tests using those so we can decide about releasing it or fixing any major issue. Cheers, -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: CDFC6E4F Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFT]: Debian Installer - Pre-Alpha1 images ready for testing
On Thu, 2010-01-28 at 13:53 -0200, Otavio Salvador wrote: > Hello, > > The images using last uploaded debian-installer are available for > testing[1]; If all looks fine I'd like to call it "a release". > > 1. http://cdimage.debian.org/cdimage/squeeze_di_test1/ > > I'd like to ask people to run tests using those so we can decide about > releasing it or fixing any major issue. Should the multiarch images be part of this release? http://cdimage.debian.org/cdimage/squeeze_di_test1/multi-arch/iso-dvd/ is empty. I'd like to test the xen guest install functionality and this is only present on the amd64+i386+powerpc netinst image. Ian. -- Ian Campbell Current Noise: Rammstein - Rammlied Larkinson's Law: All laws are basically false. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFT]: Debian Installer - Pre-Alpha1 images ready for testing
Hello Ian, On Thu, Jan 28, 2010 at 2:07 PM, Ian Campbell wrote: > On Thu, 2010-01-28 at 13:53 -0200, Otavio Salvador wrote: >> Hello, >> >> The images using last uploaded debian-installer are available for >> testing[1]; If all looks fine I'd like to call it "a release". >> >> 1. http://cdimage.debian.org/cdimage/squeeze_di_test1/ >> >> I'd like to ask people to run tests using those so we can decide about >> releasing it or fixing any major issue. > > Should the multiarch images be part of this release? > > http://cdimage.debian.org/cdimage/squeeze_di_test1/multi-arch/iso-dvd/ > is empty. > > I'd like to test the xen guest install functionality and this is only > present on the amd64+i386+powerpc netinst image. The images are being synced; check in few minutes again please. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Critical points concerning the current Debian Sid installer
Hi, I tested the Debian Sid Installer from January 25th. It's close to perfection, it is really good and usable. Here are the critical points I am missing: 1. At the end of the first gothrough you are asked whether you want UTC or local time. Knowing that UTC is the standard switch I always chose local time. The result of this choice is - pardon me - rubbish in purity: When the system starts into its second gothrough you need to repair the ext3 filesystem manually because the time stamp of the superblock(s) differ from the real clock. 2. In the latest kernel release (i. e. 2.6.33-rc5) the usage of the old IDE drivers is not encouraged, and they are declared as obsolete / deprecated. However, the current installer of the "unstable" development line does not pay any respect to that fact - it simply ignores it. The question is: Why please? Me personally I have found out that it is no problem to mark drivers like "ide-core" or "piix" or "ide-gd" as blacklisted and thus prevent the fuc... udev from loading them. BUT: How can I force udev to load "ata-piix" for instance? I've tried several methods to do that - in vain. What did I do wrong please? Especially an installer of an "unstable" development line should at least contain an option to load these newer and better maintained drivers for "old" parallel ATA disks and DVDs or other devices. "Unstable" should conform to acknowledging latest development issues. It should NOT conform to "conservative 0815 mainstream" at all. I do not understand why this is still not the case, because I am quite sure that the traditional IDE drivers will disappear quite soon. 3. In the first two gothroughs I normally perform a minimum adequate core installation. When this is done, I edit etc/apt/sources.list to my personal needs. And after performing "apt-get update" plus "apt-get upgrade" I enter "apt-get install gnome". If you go that way there is no pitfall and everything is running fine so far: The downloaded packages are buffered in the var-Partition, and the minimum requirement of the var-Partition is about 1.2 Gigabytes of hard disk space. BUT: There is also the option to make "apt-get install gnome" a graphical part of the first and second gothrough, graphically. During my first try the size of the var-Partition was 1.3 Gigabytes. During my second try it was 2 Gigabytes. After waiting for about 20 minutes I got back a system message that the installer cannot write to disk anymore because of lack disk space. My question is: If I chose "graphical desktop environment" as default installer option, where the hell does this black-boxed installer buffer this huge mass of downloaded Debian packages? This is a real crude bug, isn't it? It's obvious that it cannot be the var-Partition, proven by facts. So where is the pitfall if I go the default path? If you manage to really fix these 3 points I would call this installer a real good one. Best regards CS -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of netcfg-static
On Thursday 28 January 2010, Josef Wolf wrote:
> This can not be replaced by the generic netcfg with netcfg/use_dhcp set
> to "false" or netcfg/disable_dhcp set to "true"?
In theory that could maybe be done (but see below). Also note that setting
an arch-dependent default while still fully supporting preseeding is not
trivial.
> And won't generic netcfg fall back to static when dhcp fails? So even
> the above settings should not be needed, IMHO.
But that does not give give the same functionality. For s390 static
configuration makes the most sense, *even* if there is a DHCP server on
the network.
> What is so special about the s390 that it requires/deserves its own
> netcfg? Why not introduce netcfg-thinkpad or netcfg-eeepc or something?
Because it is exclusively a server platform without any relevant
application in other environments.
> Frans, I have not changed any wireless bits here.
Sorry, I misread the patch.
> I don't really care about netcfg-static. I don't have a s390 and I don't
> know anybody who have one. I just think duplicated code to be a bad
> thing.
OTOH, it just works, so why worry too much about it?
> I get the feeling that there's something wrong. You may argue that
> wireless is not used by s390 anyway, but the bad feeling remains.
Maybe it is wrong, but nobody will ever hit it. IMO it would make sense to
strip all wireless support from -static (if possible).
> > > -while (1) {
> > > +/* Check to see if netcfg should be run at all */
> >
> > [...]
> >
> > On s390 network configuration is required.
>
> But netcfg/enable is set to "true" by default. So I don't see a
> functional change here.
Sure, there's no real functional change, but it's also not a necessary
change.
> I did not know that netcfg-static is for s390 only and that
> dhcp don't work on s390. But my original question remains: are there any
> reasons _not_ to replace netcfg-static by generic netcfg?
One reason is to avoid needless inclusion of the dhcp3-client-udeb in the
s390 initrds. Another is to not complicate the code by needing different
defaults for static/dhcp.
I'm not saying that a cleanup of -static may not be useful, but it should
only be done with a proper appreciation of how its used. And dropping it
is more work than you might think.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFT]: Debian Installer - Pre-Alpha1 images ready for testing
On Thu, 2010-01-28 at 14:35 -0200, Otavio Salvador wrote: > Hello Ian, > > On Thu, Jan 28, 2010 at 2:07 PM, Ian Campbell wrote: > > On Thu, 2010-01-28 at 13:53 -0200, Otavio Salvador wrote: > > I'd like to test the xen guest install functionality and this is only > > present on the amd64+i386+powerpc netinst image. > > The images are being synced; check in few minutes again please. Got it now, thanks! Ian. -- Ian Campbell Work consists of whatever a body is obliged to do. Play consists of whatever a body is not obliged to do. -- Mark Twain -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build failures for hd-media
Frans Pop wrote: > P.S. It really would be great if you could do such basic and simple checks > yourself next time instead of always leaving it to others to solve > problems. From 7:51 am timestamp, I assume Christian needed to get to work and didn't have time. Anyway, the message has value as a warning to daily builders. -- see shy jo signature.asc Description: Digital signature
Re: Build failures for hd-media
Quoting Frans Pop (elen...@planet.nl): > The aptitude log for my i386 chroot had: > [UPGRADE] dosfstools 3.0.7-1 -> 3.0.8-1 > > Downgrading that solved it. I'll file a BR. Confirmed on my side. > > Cheers, > FJP > > P.S. It really would be great if you could do such basic and simple checks > yourself next time instead of always leaving it to others to solve > problems. Well, as I said earlier, the time I'm giving to D-I these days is limitedvery limited. I happen to still have daily builds running on my machine and was thinking that reporting a failure could be helpful even if I don't investigate the problem. I can of course just not report and leave my builds silently fail if you think this is better suited. signature.asc Description: Digital signature
Re: Build failures for hd-media
On Thursday 28 January 2010, Joey Hess wrote: > From 7:51 am timestamp, I assume Christian needed to get to work and > didn't have time. It also said "for the last few days". -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFT]: Debian Installer - Pre-Alpha1 images ready for testing
Otavio Salvador, le Thu 28 Jan 2010 13:53:26 -0200, a écrit : > The images using last uploaded debian-installer are available for > testing[1]; If all looks fine I'd like to call it "a release". > > 1. http://cdimage.debian.org/cdimage/squeeze_di_test1/ Braille seems to be working. As this doesn't include the gtk flavor, I can't check speakup. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 32-bit install kernel sleeps off during installation
Frans Pop schrieb: > The first thing I would suggest to do is try if the Squeeze installer [1] > (which currently uses a 2.6.30 kernel) still has the same problem. Tried this out and yes, it works with Squeeze 32bit installer from todays snapshot. > You're in luck as the 686 kernel is already available as udebs. > > The steps are roughly as follows: > - check out the lenny branch of the D-I source repository: > svn co svn://svn.debian.org/svn/d-i/branches/d-i/lenny/installer > - cd installer/build > - edit config/i386.cfg and change -486 to -686 in KERNELVERSION > - install build dependencies > - build a netboot image using: > make reallyclean; fakeroot make build_netboot > - use either the netboot image itself, or the mini.iso Thanks. Just some "stupid questions": a) can I build a 32bit install image on a Debian amd64 system? b) is there a bit of documentation for those things? Websites, books or whatever. Wouldn't mind reading some stuff to get deeper into this. Regards and thanks Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Business Clients Dept. TSP CLI R&D SW OSE Fujitsu Siemens Computers Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:rainer.koe...@fujitsu-siemens.com Internet www.fujitsu-siemens.com Company Details www.fujitsu-siemens.com/imprint.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 32-bit install kernel sleeps off during installation
On Thursday 28 January 2010, you wrote: > a) can I build a 32bit install image on a Debian amd64 system? Only if you create an i386 chroot (using debootstrap). > b) is there a bit of documentation for those things? Websites, books > or whatever. Wouldn't mind reading some stuff to get deeper into this. http://d-i.alioth.debian.org/doc/internals/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build failures for hd-media
Hello Christian, On Thu, Jan 28, 2010 at 4:28 PM, Christian PERRIER wrote: > Quoting Frans Pop (elen...@planet.nl): > Well, as I said earlier, the time I'm giving to D-I these days is > limitedvery limited. I happen to still have daily builds running > on my machine and was thinking that reporting a failure could be > helpful even if I don't investigate the problem. I can of course just > not report and leave my builds silently fail if you think this is > better suited. It is appreciated; specially because many of us are limited in time lately. I do enjoy when you report failures; this serves as warning for all of us and then it helps, even if you don't have the time to trace it. Cheers, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564441: new version of the proposed patch
Hello,
I've updated my patch to follow suggestions from F. Pop, and tested
it at my level. Perhaps some enhancements could be added for a better
usability.
If you call the Debian Installer with default debconf level, it
automatically scans all devices and select the first detected ISO
(*but*, on the contrary of old iso-scan behaviour, it scans all
available disks before to select first ISO). If we call Debian Installer
with 'medium' level (debconf/priority=medium), we can choose which
device to scan, then select an ISO among detected ones.
There are some areas where I'm not sure the proposed patch is fully ok :
- the templates are definitely not best written texts
- about suggestions from F. Pop, I didn't know how to handle 'preseed',
as I don't know how it works
- then looking at the second pass for ISOs in sub-directories, I wonder
if I had to give also the top-directories' detected ISO ; I left them
in the final list, but perhaps it isn't the best choice.
with regards,
Fred.
diff -Naur iso-scan-1.28ref/debian/iso-scan.postinst iso-scan-1.28+testiso2/debian/iso-scan.postinst
--- iso-scan-1.28ref/debian/iso-scan.postinst 2009-01-10 01:25:38.0 +0100
+++ iso-scan-1.28+testiso2/debian/iso-scan.postinst 2010-01-28 21:23:22.0 +0100
@@ -2,13 +2,8 @@
. /usr/share/debconf/confmodule
set -e
-ISO_COUNT=0
-ISO_MOUNT_COUNT=0
-MOUNTABLE_DEVS_COUNT=0
-TOPLEVEL_DIRS_COUNT=0
-
log () {
-logger -t iso-scan "$@"
+ logger -t iso-scan "$@"
}
mount_device () {
@@ -17,12 +12,12 @@
db_progress INFO iso-scan/progress_mount
mount -t auto -o ro $dev_to_mount /hd-media 2>/dev/null
}
-
+
is_debian_iso () {
test -e /cdrom/.disk/info
}
-register_cd () {
+analyze_cd () {
# Make sure that the iso is usable for the architecture. If so,
# set the suite and codename to the suite/codename that is on the CD.
# This assumes that there will be no more than one distribution on
@@ -33,17 +28,14 @@
for dir in $(cat /etc/default-release) $(ls -1 /cdrom/dists/); do
relfile=/cdrom/dists/$dir/Release
if [ -e $relfile ] &&
- egrep -q 'Architectures:.* '$(udpkg --print-architecture)'( |$)' $relfile
- then
+ egrep -q 'Architectures:.* '$(udpkg --print-architecture)'( |$)' $relfile
+ then
suite=$(sed -n 's/^Suite: *//p' $relfile)
+ version=$(sed -n 's/^Version: *//p' $relfile)
codename=$(sed -n 's/^Codename: *//p' $relfile)
log "Detected ISO with '$suite' ($codename) distribution"
- db_set cdrom/suite $suite
- db_set cdrom/codename $codename
- db_subst iso-scan/success SUITE $suite
description=`sed -n 's/^Description: *//p' $relfile`
- db_subst iso-scan/success DESCRIPTION $description
return 0
fi
@@ -53,179 +45,339 @@
}
# Try to mount a file as an iso, and see if it's a Debian cd.
-try_iso () {
+add_usable_iso () {
iso_to_try=$1
iso_device=$2
- if mount -t iso9660 -o loop,ro,exec $iso_to_try /cdrom 2>/dev/null; then
- ISO_MOUNT_COUNT=$(expr $ISO_MOUNT_COUNT + 1)
- if is_debian_iso; then
- if register_cd $iso_to_try $iso_device; then
-# This could be more sophisticated, and try
-# to deal with multiple Debian ISO's. For
-# now, once we've got a Debian ISO, any
-# Debian ISO, we're done.
-db_progress STOP
-db_subst iso-scan/success FILENAME $iso_to_try
-db_set iso-scan/filename $iso_to_try
-db_subst iso-scan/success DEVICE $iso_device
-db_input medium iso-scan/success || true
-db_go || true
-
-anna-install apt-mirror-setup || true
-if [ ! -e /cdrom/.disk/base_installable ]; then
- log "Base system not installable from CD image, requesting choose-mirror"
- anna-install choose-mirror || true
-else
- anna-install apt-cdrom-setup || true
- # Install -support udeb (if available).
- db_get cdrom/codename
- anna-install $RET-support || true
-fi
-exit 0
+ if ! mount -t iso9660 -o loop,ro,exec $iso_to_try /cdrom 2>/dev/null; then
+ log "Failed mounting $iso_to_try (from $iso_device) as an ISO image"
+ return
+ fi
+ ISO_MOUNT_COUNT=$(expr $ISO_MOUNT_COUNT + 1)
+
+ if is_debian_iso; then
+ if analyze_cd; then
+ log "Debian ISO $iso_to_try usable."
+ isodesc="[$(echo $iso_device | sed -e 's?^/dev/??')]"
+ isodesc="$isodesc $iso_to_try ($suite - ${version:-?})"
+ # comma is used to separate possible ISO
+ isodesc=$(echo "$isodesc" | sed -e 's/,/ /g')
+ if [ -z "$ISOS_FOUND" ]; then
+ISOS_FOUND="$isodesc"
else
-log "Debian ISO not usable, skipping"
+ISOS_FOUND="$ISOS_FOUND, $isodesc"
fi
else
- log "Not a Debian ISO"
- umount /cdrom
+ log "Debian ISO not usable, skipping"
fi
else
- log "Failed mounting $iso_to_try"
+ log "$iso_to_try not a Debian ISO"
fi
-}
-
-# Try to unmount anything that was previously mounted.
-umount /cdrom 2>/dev/null || true
-umount /hd-media 2>/dev/null || true
-
-# Hopefully this will find the drive.
-hw-detect iso-scan/detect_progress_title || true
-
-# Load up ever
d-i documentation [was: 32-bit install kernel sleeps off during installation]
On Thu, Jan 28, 2010 at 08:58:41PM +0100, Frans Pop wrote: > On Thursday 28 January 2010, you wrote: > > b) is there a bit of documentation for those things? Websites, books > > or whatever. Wouldn't mind reading some stuff to get deeper into this. > > http://d-i.alioth.debian.org/doc/internals/ Great reading. Thank you. Douglas. - Peace of mind is there for the taking. - But you must *take* it, - For no one will give it to you. signature.asc Description: Digital signature
Bug#557242: Acknowledgement (debian-installer: current daily squeeze installer installs grub to mbr without asking the user)
Just tested again with the current network installer. MBR is still destroyed. How to reproduce: - say no to "want to install in mbr" question - leave field empty when asked where to install grub (this time i entered "doesnotexist" but mbr was destroyed anyway) - continue without bootloader - finish installation - mbr is overwritten with "useless" grub I see no obvious way using the current debian squeeze installer without destroying the MBR. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#433568: VLANs during install are important
On Sun, Jan 17, 2010 at 09:35:47PM +0100, Josef Wolf wrote: > AFAICS, getting vlan support into the installer needs to be done in three > steps: > > 1. Get 8021q kernel module into installer environment. > > 2. Install vlan package into installer environment. Only the vconfig >binary (9kb) is really needed. But it needs libc6. Is this an issue? > > 3. Check interface names for vlan-format and call vconfig accordingly. > > Doesn't look like rocket science, IMHO. OK, I've now checked how this could be done technically. Now I need some guidance concerning the user interface. My first assumption is that vlan is not really a common setup, so the average user should not be bothered with questions about it. Thus any debconf values concerning vlan should be of "low" priority (or even better be avoided entirely) The next question is how this should be integrated into netcfg. My favorite would be to simply check whether the nectfg/choose_interface value matches one of the vlan naming conventions. In other words, we would have to recognize four formats here: eth0.0005 => phys_if=eth0, vlan=5, name_type=DEV_PLUS_VID eth0.5 => phys_if=eth0, vlan=5, name_type=DEV_PLUS_VID_NO_PAD vlan0005 => phys_if=ASK, vlan=5, name_type=VLAN_PLUS_VID vlan5 => phys_if=ASK, vlan=5, name_type=VLAN_PLUS_VID_NO_PAD Since the interface name can be used to decide whether to activate vlan support, no new debconf questions (like netcfg/enable_vlan or something) are needed, IMHO. The rest would be mostly straight forward: load stp, garp and 8021q modules, install vlan.udeb, run vconfig, adjust /e/n/i. Opinions? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562575: Bug still present [Re: Bug#562575: installation-reports: Buisnesscard PowerPC installer loops with Segmentation faults]
I tested it today with the sid-di daily PowerPC buisnesscard dated "Thu Jan 28 22:35:10 UTC 2010" It still segfaults at startup. Sadly, I don't have the chops to fix this myself. If someone else doesn't step up, PowerPC will not be working when Squeeze releases. I can test anything you want tested. But I can't diagnose it all by myself. I'll need help. Rick Rick Thomas wrote: This bug (562575) is still present in today's netinst CD. The businesscard installer boots and prints the ususal flock of kernel startup messages. then it says: Starting system log daemon Segmentation fault and then it loops saying INFO: kbd-mode: setting console mode to Unicode (UTF-8) Segmentation fault It never gets to the point of asking the usual installation questions for locale, language, etc... -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug still present [Re: Bug#562575: installation-reports: Buisnesscard PowerPC installer loops with Segmentation faults]
I tested it today with the sid-di daily PowerPC buisnesscard dated "Thu Jan 28 22:35:10 UTC 2010" It still segfaults at startup. Sadly, I don't have the chops to fix this myself. If someone else doesn't step up, PowerPC will not be working when Squeeze releases. I can test anything you want tested. But I can't diagnose it all by myself. I'll need help. Rick Rick Thomas wrote: > This bug (562575) is still present in today's netinst CD. > >> The businesscard installer boots and prints the ususal flock of kernel startup messages. >> then it says: >>Starting system log daemon >>Segmentation fault >> >> and then it loops saying >>INFO: kbd-mode: setting console mode to Unicode (UTF-8) >>Segmentation fault >> >> It never gets to the point of asking the usual installation questions for locale, language, etc... > > -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567431: Installation Report
Package: installation-reports Boot method: CD Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: 1/28/2010 Machine: Custom AMD64 Processor: Athlon64 3500 Memory: 2GB Partitions: FilesystemType 1K-blocks Used Available Use% Mounted on /dev/sda9 ext320762164 4471576 15235924 23% / tmpfstmpfs 1030804 0 1030804 0% /lib/init/rw udev tmpfs 10240 236 10004 3% /dev tmpfstmpfs 1030804 0 1030804 0% /dev/shm Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: VIA Technologies, Inc. K8T800Pro Host Bridge [1106:0282] Subsystem: ABIT Computer Corp. Device [147b:1415] 00:00.1 Host bridge [0600]: VIA Technologies, Inc. K8T800Pro Host Bridge [1106:1282] 00:00.2 Host bridge [0600]: VIA Technologies, Inc. K8T800Pro Host Bridge [1106:2282] 00:00.3 Host bridge [0600]: VIA Technologies, Inc. K8T800Pro Host Bridge [1106:3282] 00:00.4 Host bridge [0600]: VIA Technologies, Inc. K8T800Pro Host Bridge [1106:4282] 00:00.7 Host bridge [0600]: VIA Technologies, Inc. K8T800Pro Host Bridge [1106:7282] 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] [1106:b188] 00:07.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller [1106:3044] (rev 46) Subsystem: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller [1106:3044] Kernel driver in use: firewire_ohci 00:0e.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter [1106:3119] (rev 11) Subsystem: ABIT Computer Corp. Device [147b:1415] Kernel driver in use: via-velocity 00:0f.0 IDE interface [0101]: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller [1106:3149] (rev 80) Subsystem: ABIT Computer Corp. Device [147b:1415] 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: ABIT Computer Corp. Device [147b:1415] 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: ABIT Computer Corp. Device [147b:1415] 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: ABIT Computer Corp. Device [147b:1415] Kernel driver in use: uhci_hcd 00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 81) Subsystem: ABIT Computer Corp. Device [147b:1415] Kernel driver in use: uhci_hcd 00:10.3 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 81) Subsystem: ABIT Computer Corp. Device [147b:1415] Kernel driver in use: uhci_hcd 00:10.4 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 86) Subsystem: ABIT Computer Corp. Device [147b:1415] 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: ABIT Computer Corp. Device [147b:1415] 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] Kernel driver in use: k8temp 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV635 PRO AGP [Radeon HD 3650] [1002:9596] Subsystem: Hightech Information System Ltd. Device [1787:0028] 01:00.1 Audio device [0403]: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series] [1002:aa20] Subsystem: Hightech Information System Ltd. Device [1787:aa20] Kernel driver in use: HDA Intel Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] 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: Using the text installer, USB Keyboard did not work even with BIOS legacy emulation enabled once I passed the "Install" menu choice and was on the language sc
Seg faults on PowerPC Re: [RFT]: Debian Installer - Pre-Alpha1 images ready for testing
Otavio Salvador wrote: Hello, The images using last uploaded debian-installer are available for testing[1]; If all looks fine I'd like to call it "a release". 1. http://cdimage.debian.org/cdimage/squeeze_di_test1/ I'd like to ask people to run tests using those so we can decide about releasing it or fixing any major issue. Cheers, The PowerPC installer suffers from bug # 564150 Rick -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
