Bug#509378: should use labels for all partitions in fstab
Quoting Colin Watson (cjwat...@debian.org): I absolutely think that we should be using UUIDs by default for devices where there isn't some other stable naming, as Ubuntu does. I agree. As I said earlier, we now just need to dinf someone who would commit self to do it. I suggest we add this to the release goals for squeeze. Indeed, we need something like a two-step release goals list: - the wished featureswhich nobody committed self to implement - the ones where a volunteer popped up to implement (those would of course have the entire support of the D-I team...or what remains of the D-I team) I even wonder if this static naming system couldn't be the main part of a GSOC project for 2009? signature.asc Description: Digital signature
Bug#509556: installation-reports: Successful installation
Package: installation-reports Severity: wishlist -- Package-specific info: Boot method: DVD Image version: Debian testing - Official RC i386 DVD Binary-1 20081104-07:33 Date: 22 dec 2008 Machine: Notebook Packard Bell EASYNOTE MZ36-U-055 Partitions: df -Tl will do; the raw partition table is preferred /dev/sda1 ext374318844 26175016 44368556 38% / tmpfstmpfs 452284 0452284 0% /lib/init/rw udev tmpfs 1024080 10160 1% /dev tmpfstmpfs 452284 0452284 0% /dev/shm 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: Installation completed successfully. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=5.0 (lenny) - installer build 20081029 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == umame -a: Linux debian 2.6.26-1-486 #1 Thu Oct 9 14:22:52 UTC 2008 i686 unknown lspci -knn: 00:00.0 Host bridge [0600]: ATI Technologies Inc Device [1002:5a31] (rev 01) lspci -knn: 00:01.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a3f] lspci -knn: 00:12.0 IDE interface [0101]: ATI Technologies Inc IXP SB400 Serial ATA Controller [1002:4379] (rev 80) lspci -knn: Kernel driver in use: sata_sil lspci -knn: Kernel modules: sata_sil lspci -knn: 00:13.0 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB Host Controller [1002:4374] (rev 80) lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: Kernel modules: ohci-hcd lspci -knn: 00:13.1 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB Host Controller [1002:4375] (rev 80) lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: Kernel modules: ohci-hcd lspci -knn: 00:13.2 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB2 Host Controller [1002:4373] (rev 80) lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: Kernel modules: ehci-hcd lspci -knn: 00:14.0 SMBus [0c05]: ATI Technologies Inc IXP SB400 SMBus Controller [1002:4372] (rev 82) lspci -knn: 00:14.1 IDE interface [0101]: ATI Technologies Inc IXP SB400 IDE Controller [1002:4376] (rev 80) lspci -knn: Kernel driver in use: ATIIXP_IDE lspci -knn: Kernel modules: atiixp lspci -knn: 00:14.2 Audio device [0403]: ATI Technologies Inc IXP SB4x0 High Definition Audio Controller [1002:437b] (rev 01) lspci -knn: 00:14.3 ISA bridge [0601]: ATI Technologies Inc IXP SB400 PCI-ISA Bridge [1002:4377] (rev 80) lspci -knn: 00:14.4 PCI bridge [0604]: ATI Technologies Inc IXP SB400 PCI-PCI Bridge [1002:4371] (rev 80) lspci -knn: 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RC410 [Radeon Xpress 200M] [1002:5a62] lspci -knn: 09:02.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10) lspci -knn: Kernel driver in use: 8139too lspci -knn: Kernel modules: 8139too, 8139cp lspci -knn: 09:04.0 Network controller [0280]: RaLink RT2561/RT61 rev B 802.11g [1814:0302] lsmod: Module Size Used by lsmod: ufs63620 0 lsmod: qnx47684 0 lsmod: ntfs 180416 0 lsmod: dm_mod 45384 0 lsmod: md_mod 65940 0 lsmod: xfs 446836 0 lsmod: reiserfs 187008 0 lsmod: jfs 148060 0 lsmod: ext3 103432 1 lsmod: jbd35092 1 ext3 lsmod: vfat8832 0 lsmod: fat39964 1 vfat lsmod: ext2 52616 0 lsmod: mbcache 6656 2 ext3,ext2 lsmod: 8139too20096 0 lsmod: 8139cp 17024 0 lsmod: mii 4864 2 8139too,8139cp lsmod: nls_utf81664 2 lsmod: isofs 27684 0 lsmod: nls_base6528 6 ntfs,jfs,vfat,fat,nls_utf8,isofs lsmod: zlib_inflate 13952 1 isofs lsmod: rsrc_nonstatic 9344 0 lsmod: pcmcia_core31760 1 rsrc_nonstatic lsmod: ide_generic 2432 0 [permanent] lsmod:
Bug#509299: installation: Error in Windows-Based Debial Installation
[ Please keep CC to the BTS ] On Mon, Dec 22, 2008 at 09:48:15PM -0600, Armstrong, Mike wrote: Perhaps that is the problem. My boot drive is C: and does not have a C:\Windows or a C:\Windows\Temp directory. My system drive is D: and it does have a D:\Windows\Temp dir. I DO have a Temp directory in the root of all my filesystems (I always create one). Also there is %SystemDrive%\Windows\Temp and %SystemDrive%\Users\loginID\Appdata\Local\Temp With the error message dialog box still open, I did a full search (all logical drives) for cpio.bat == no find. It looks like the cpio.bat files (and others??) are not being extracted because an assumption is made as to the existence of the parent (temp) directory??? Ok. Please try this one: http://goodbye-microsoft.com/pub/pluginsdir/ and see if it properly creates a pluginsdir. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509178: booting Debian installer kernel on SunBlade from CDROM is not really supported (was: Re: Bug#509178: installation-reports: sparc fails to boot 2.6.26: Memory Address not Aligned)
Hi, Op Sat 20 Dec 2008 om 10:43:17 +0100 schreef Joost van Baal: This might be the same bug as #509202. I'll try to setup cu or minicom to collect kernel messages on tuesday, while I am at the university again. FWIW, the boot fails in the same way with http://cdimage.debian.org/cdimage/lenny_di_rc1/sparc/iso-cd/debian-testing-sparc-netinst.iso , built on 20081104-23:58 : Allocated 8 Megs of memory at 0x4000 for kernel Loaded kernel version 2.6.26 Loading initial ramdisk (4284688 bytes at Memory Address not Aligned I'll try to get it to boot with the latest etch kernel on tuesday. Which fails too. On http://d-i.alioth.debian.org/manual/en.sparc/ch05s03.html#sparc-boot-problems it says: We recommend to install [SunBlade] systems by netbooting the installer. I am confident that'll work out fine: closing this bug. Bye, Joost -- Joost van Baalhttp://abramowitz.uvt.nl/ Tilburg University mailto:joostvb.uvt.nl The Netherlands signature.asc Description: Digital signature
Bug#509178: marked as done (installation-reports: sparc fails to boot 2.6.26: Memory Address not Aligned)
Your message dated Tue, 23 Dec 2008 14:42:12 +0100 with message-id 20081223134212.gc8...@dijkstra.uvt.nl and subject line booting Debian installer kernel on SunBlade from CDROM is not really supported (was: Re: Bug#509178: installation-reports: sparc fails to boot 2.6.26: Memory Address not Aligned) has caused the Debian Bug report #509178, regarding installation-reports: sparc fails to boot 2.6.26: Memory Address not Aligned to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 509178: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509178 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-reports Severity: important -- Package-specific info: Boot method: CD Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/sparc/iso-cd/debian-testing-sparc-businesscard.iso built on 20081218-10:06 Date: vr dec 19 10:50:07 CET 2008 Machine: SunBlade 2000 SUNW,Sun-Blade-1000 (UltraSPARC-III+) Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] 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: Using a VT420 console. Boots from CDROM, starts SILO Version 1.4.13, display welcome message (welcome to Debian GNU/Linux lenny! [...] built on 20081218-10:06 [...]). boot: Allocated 8 Megs of memory at 0x4000 for kernel Loaded kernel version 2.6.26 Loading initial ramdisk (4284688 bytes at Memory Address not Aligned Choosing boot: rescue or boot: expert gives the same. The machine boots SunOS 5.8 from its disk0 just fine, so the hardware apparently is quite OK. The machine has 2048 MB memory installed. I'll try to collect output from report-hw for this bugreport once I have found a working Linux kernel for this machine. Thanks for working on the Debian Installer! Bye, Joost ---End Message--- ---BeginMessage--- Hi, Op Sat 20 Dec 2008 om 10:43:17 +0100 schreef Joost van Baal: This might be the same bug as #509202. I'll try to setup cu or minicom to collect kernel messages on tuesday, while I am at the university again. FWIW, the boot fails in the same way with http://cdimage.debian.org/cdimage/lenny_di_rc1/sparc/iso-cd/debian-testing-sparc-netinst.iso , built on 20081104-23:58 : Allocated 8 Megs of memory at 0x4000 for kernel Loaded kernel version 2.6.26 Loading initial ramdisk (4284688 bytes at Memory Address not Aligned I'll try to get it to boot with the latest etch kernel on tuesday. Which fails too. On http://d-i.alioth.debian.org/manual/en.sparc/ch05s03.html#sparc-boot-problems it says: We recommend to install [SunBlade] systems by netbooting the installer. I am confident that'll work out fine: closing this bug. Bye, Joost -- Joost van Baalhttp://abramowitz.uvt.nl/ Tilburg University mailto:joostvb.uvt.nl The Netherlands signature.asc Description: Digital signature ---End Message---
Bug#509299: installation: Error in Windows-Based Debial Installation
On Tue, Dec 23, 2008 at 09:04:17AM -0600, Armstrong, Mike wrote: Yup - the temp dir was created (see attached). FYI it was empty. I think I'll have to try reproduce this bug. Can you give me instructions on how to setup an environment that has the same problem? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509556: marked as done (installation-reports: Successful installation)
Your message dated Tue, 23 Dec 2008 18:18:53 +0100 with message-id 20081223171853.gt30...@mykerinos.kheops.frmug.org and subject line Re: Bug#509556: installation-reports: Successful installation has caused the Debian Bug report #509556, regarding installation-reports: Successful installation to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 509556: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509556 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-reports Severity: wishlist -- Package-specific info: Boot method: DVD Image version: Debian testing - Official RC i386 DVD Binary-1 20081104-07:33 Date: 22 dec 2008 Machine: Notebook Packard Bell EASYNOTE MZ36-U-055 Partitions: df -Tl will do; the raw partition table is preferred /dev/sda1 ext374318844 26175016 44368556 38% / tmpfstmpfs 452284 0452284 0% /lib/init/rw udev tmpfs 1024080 10160 1% /dev tmpfstmpfs 452284 0452284 0% /dev/shm 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: Installation completed successfully. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=5.0 (lenny) - installer build 20081029 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == umame -a: Linux debian 2.6.26-1-486 #1 Thu Oct 9 14:22:52 UTC 2008 i686 unknown lspci -knn: 00:00.0 Host bridge [0600]: ATI Technologies Inc Device [1002:5a31] (rev 01) lspci -knn: 00:01.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a3f] lspci -knn: 00:12.0 IDE interface [0101]: ATI Technologies Inc IXP SB400 Serial ATA Controller [1002:4379] (rev 80) lspci -knn: Kernel driver in use: sata_sil lspci -knn: Kernel modules: sata_sil lspci -knn: 00:13.0 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB Host Controller [1002:4374] (rev 80) lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: Kernel modules: ohci-hcd lspci -knn: 00:13.1 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB Host Controller [1002:4375] (rev 80) lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: Kernel modules: ohci-hcd lspci -knn: 00:13.2 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB2 Host Controller [1002:4373] (rev 80) lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: Kernel modules: ehci-hcd lspci -knn: 00:14.0 SMBus [0c05]: ATI Technologies Inc IXP SB400 SMBus Controller [1002:4372] (rev 82) lspci -knn: 00:14.1 IDE interface [0101]: ATI Technologies Inc IXP SB400 IDE Controller [1002:4376] (rev 80) lspci -knn: Kernel driver in use: ATIIXP_IDE lspci -knn: Kernel modules: atiixp lspci -knn: 00:14.2 Audio device [0403]: ATI Technologies Inc IXP SB4x0 High Definition Audio Controller [1002:437b] (rev 01) lspci -knn: 00:14.3 ISA bridge [0601]: ATI Technologies Inc IXP SB400 PCI-ISA Bridge [1002:4377] (rev 80) lspci -knn: 00:14.4 PCI bridge [0604]: ATI Technologies Inc IXP SB400 PCI-PCI Bridge [1002:4371] (rev 80) lspci -knn: 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RC410 [Radeon Xpress 200M] [1002:5a62] lspci -knn: 09:02.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10) lspci -knn: Kernel driver in use: 8139too lspci -knn: Kernel modules: 8139too, 8139cp lspci -knn: 09:04.0 Network controller [0280]: RaLink RT2561/RT61 rev B 802.11g [1814:0302] lsmod: Module Size Used by lsmod: ufs63620 0 lsmod: qnx47684 0 lsmod: ntfs 180416 0 lsmod: dm_mod 45384 0 lsmod: md_mod
Bug#509299: installation: Error in Windows-Based Debial Installation
OK. I will assume you start with an empty (unpartitioned) hard drive. I added the XP stuff to completely duplicate my HD. I don't think it is necessary to duplicate the problem. 1) Use a Linux live CD or repair disk to create: a) Partition 1 (boot volume) -- primary - 750 to 1024 MB Type = 7 (HPFS/NTFS) Make it the active partition b) Partition 2 -- Extended - Rest of the HD c) Logical drive 5 (For Vista) -- 10 to 20 GB Type = 7 (HPFS/NTFS) d) Logical Drive 6 (optional for XP) Type = 7 (HPFS/NTFS) 2) (Optional) Install XP into logical drive 6 3) Install Vista into logical drive 5 That should do it. In my scenario I have: Part/LogVolType O/S 1 NTFS boot volume 2 Extended 5 Linux /boot 6 Linux / 7 Linux Linux logical volume 8 NTFS Vista 9 NTFS Data 10 NTFS XP Free space - On Tue, Dec 23, 2008 at 09:04:17AM -0600, Armstrong, Mike wrote: Yup - the temp dir was created (see attached). FYI it was empty. I think I'll have to try reproduce this bug. Can you give me instructions on how to setup an environment that has the same problem? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: permission to upload hdparm
Stephen Gran sg...@debian.org writes: +hdparm (8.9-3) unstable; urgency=low + + * Fix output formatting for drives configured from /etc/default/hdparm +(closes: #494660) + * Add documentation about changing device names (closes: #421087) This change is OK from the release team's POV. d-i people should ACK it, though (CCed). Marc -- BOFH #173: Recursive traversal of loopback mount points pgp3qiTi9TFZi.pgp Description: PGP signature
Bug#509379: firmware not found on virtual floppy or virtual CDROM
Christian Perrier wrote: reassign 509379 hw-detect thanks Quoting Daniel Pocock (dan...@pocock.com.au): Package: debian-installer Installing lenny amd64 on a Dell M600 blade server using PXE/netboot method. bnx2 firmware required for network access. Installer prompts for a floppy or USB device. I attempted to mount an ext3 formatted floppy image, and an ISO CDROM You attempted to *mount*? What exactly did you try to do apart from putting the firmware file (or deb package for the record) on a removable medium and hit Enter when prompted for firmware? My explanation wasn't thorough enough: - I saw the prompt to insert the floppy or USB disk - I used the iDRAC (Dell's iLO solution) to enable the virtual floppy - I pressed the OK button in d-i, telling it to search for the removable media - d-i told me no removable media found (I can't remember the exact message I saw) - I then opened a shell (Alt-F2) and tried to manually locate the firmware If you tried some manual actions in a shell in VT2, that might be the cause of the problem. I only did that after getting errors from d-i. I wanted to know if the removable media was recognised by the installer's kernel. In this case, it was recognised by the kernel as a SCSI device. If you just did what's instructed (put the files on a floppy, USB stick or CD, then hit Enter), then something went wrong, really..:-) In such case, after seeing the error message that the media can't be located, could you switch to VT2 (Alt+F2), then check if something is mounted on /media... I will test this on a similar box, as this one has already gone live. It may not happen until January now. Thanks for taking the time to look into this issue, I hope the detail I'm providing is useful. Regards, Daniel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509378: should use labels for all partitions in fstab
Colin Watson wrote: On Sun, Dec 21, 2008 at 08:15:55PM +, Daniel Pocock wrote: I believe it would be much safer to use labels for partitions rather than using the device nodes. Automatically assigning labels is a really, really bad idea. Red Hat tried this and the result was that if you did two Red Hat installations on the same machine then they would get terribly confused on boot as there would be two filesystems with LABEL=root. I spoke to the Anaconda That is why my earlier email proposed that we check for duplicates before creating fstab - however, I'm not saying it's a perfect solution. Of course you could try to generate universally unique labels, but this is a bit silly when we already have UUIDs. Labels should be reserved for assignment by the system administrator. That is a reasonable argument - in this case, d-i may need to force the user to specify (or agree to) a set of labels. I absolutely think that we should be using UUIDs by default for devices where there isn't some other stable naming, as Ubuntu does. I think this is reasonable too, as long as we deal with the fstab issues. Note that pretty much every naming system has its downsides: * Traditional device names Fail when devices are enumerated in a different order at boot, or when the kernel changes device naming (e.g. IDE - libata). With removable disks becoming more common, this is going to become more of an issue. * Labels Good when assigned manually by the system administrator, but assigning automatically is fraught with problems. Bit-for-bit filesystem copies will preserve the label, which is fine for backup and restore but can have surprising results. If you have to reconstruct a filesystem during disaster recovery you need to remember to reset the label too (or adjust /etc/fstab). Maybe we can create a hidden file in each filesystem to provide a clue about where it was mounted? IMO the best answer is to use UUIDs by default, but use labels if they are manually set during installation. This way people who don't care can have it just work, and people who care can set labels. In Ubuntu we put a comment above the UUID in /etc/fstab with the original traditional device name for the device in question, which is often a useful aide-memoire. The only solution I can see is for d-i to enforce the use of labels for /boot and other non-LVM filesystems. Using the labels with LVM filesystems would be nice but not essential. I think it's best to use the LVM names for LVM filesystems, since they already form a stable naming scheme. This is all fine for me, with the additional possibility that we create a hidden file (maybe .debian-mount or something) to provide a clue about where to mount when re-constructing fstab. It would be nice if such information could be kept in filesystem metadata, but the label field is only quite small. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Opening trunk for post-lenny changes?
Hi, IIRC, we never used to keep trunk closed during release periods; instead, we used to create a branch, do all the release work off that, and open trunk for post-release changes. I have to say that I've been feeling quite frustrated with the extended closure of trunk. There's lots of post-lenny stuff I'd like to check in, and while I could send patches in bug reports, and have done so in a few cases of more significant work I've been doing, I'd really like to get back to being able to commit directly. I'm not expecting to be able to upload to unstable for some time, obviously, but could we please open trunk for general commits? There appear to be rather few discrepancies between /branches/d-i/lenny and the archive, in any case. They are: auto-install Archive has 1.2, /branches/d-i/lenny has 1.3. efi-reader Archive has 0.9, /branches/d-i/lenny has 0.10 (UNRELEASED). linux-kernel-di-m68k-2.6, linux-modules-di-m68k-2.6 Not sure about these - remind me where the archive is again? /branches/d-i/lenny has 0.96 and 1.00 respectively, the latter UNRELEASED. partconf Archive has 1.30, /branches/d-i/lenny has 1.31 (UNRELEASED). sarge-support Not in archive, probably correctly. /branches/d-i/lenny has 0.03. vmelilo-installer Probably in the m68k archive, as above, so I don't have the archive version number. /branches/d-i/lenny has 1.18. win32-loader Archive has 0.6.9, /branches/d-i/lenny also has 0.6.9 but UNRELEASED. I don't know which of these are intentional, if any, but it doesn't seem that hard to roll back the few places where /branches/d-i/lenny is ahead, and bring win32-loader into sync. If somebody can confirm that this is desirable then I'm willing to do the legwork. The only downside to opening trunk for general commits seems to be that translators would have to start operating on /branches/d-i/lenny as well. Christian, is this straightforward and can you provide guidance? I seem to remember that we did this before. (An alternative would be to have a shared post-lenny branch that we *all* commit to; distributed revision control is great but the centralised model is useful for making sure everyone's going in roughly the same direction, and at any rate I'd want to have things merged to a primary branch anyway. However, this would make the Bazaar imports I use rather messier and so I'd prefer us to just open trunk instead. We'd have the same translation problem in reverse in any case.) Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Opening trunk for post-lenny changes?
On Wednesday 24 December 2008, Colin Watson wrote: IIRC, we never used to keep trunk closed during release periods; instead, we used to create a branch, do all the release work off that, and open trunk for post-release changes. At the risk of angering Otavio and Christian, the simple reason is lack of actual release *management*, and especially any form of communication with the team from the D-I RM. There appear to be rather few discrepancies between /branches/d-i/lenny and the archive, in any case. They are: You missed a fairly big number of discrepancies, at least: - rootskel - hw-detect - kernel/* Otavio is currently on VAC. This will probably need to wait until he is back. After that he may prefer to concentrate on releasing RC2 first. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#509238: panic backtrace
Quoting: Christian Perrier bubu...@debian.org Quoting The Eclectic One (eclec...@sdf.lonestar.org): First thought: race condition (the panic message contained a backtrace of different threads), so then I tried multiple times with only one change at at time: expert mode, regular mode, ethdetect -x, vga=771, vga normal. It turns out that the culprit was the vga option. With vga=771, I get no crash/panic in either expert or regular mode, with So, in short, in regular mode, it crashes (always at the same place) but in vga=771 mode, it doesn't, right? Correct. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509379: firmware not found on virtual floppy or virtual CDROM
Quoting Daniel Pocock (dan...@pocock.com.au): My explanation wasn't thorough enough: - I saw the prompt to insert the floppy or USB disk - I used the iDRAC (Dell's iLO solution) to enable the virtual floppy - I pressed the OK button in d-i, telling it to search for the removable media - d-i told me no removable media found (I can't remember the exact message I saw) I would suggest yo to try enabling the virtual floppy earlier in the process. The sequence you describe means that d-i would have to rescan available devices before looking around and try mounting the ones that are present. however, I'm unsure (and can't check right now) if such a scan is done between the moment you're prompted and the failure message. So, imho, you'd get better chances if you enable your virtual floppy as early as possible. signature.asc Description: Digital signature
Re: Opening trunk for post-lenny changes?
Quoting Frans Pop (elen...@planet.nl): On Wednesday 24 December 2008, Colin Watson wrote: IIRC, we never used to keep trunk closed during release periods; instead, we used to create a branch, do all the release work off that, and open trunk for post-release changes. At the risk of angering Otavio and Christian, the simple reason is lack of actual release *management*, and especially any form of communication with the team from the D-I RM. This is not angering. Could we just accept that we're dramatically short of manpower and that not everything is done the perfect way? I've personnally accepted this for a while and, though very frustrating, I think it is still motivating to try keeping the hype at a sufficient level for D-I not to fall in deep sleep mode (this is basically the point of /me sending a non perfect Bits from D-I mail even though I'm not the D-I RM). About Colin's remarks, my personal opinion is that it could be time to resync the lenny branch with trunk and work off that lenny branch, yes. Definitely, even. Do *I* want to do this? Nofor a very simple reason: there's is way too much risk that I mess things around by lack of full time commitment. As you recently pointed, I still succeed in messing up changelogs from time to time, so you can imagine if I try to play around with SVN branches signature.asc Description: Digital signature
Bug#389881: Bug#509378: should use labels for all partitions in fstab
reassign 509378 partman-target forcemerge 509378 389881 thanks I now have the right reference: http://bugs.debian.org/389881 ...is roughly the same suggestion than the one you're doing right now. It talks about SCSI devices but the bug discussion makes it clear that persistent naming goes much beyond SCSI devices. There is even a patch proposed by David Härdeman (who was very active implementing encrypted partitions support in the past)...but unfortunately, nobody cared to try incorporating this in D-I, when we moved to the Lenny D-I release cycle..:-( It is even listed in the D-I Lenny release goals: http://wiki.debian.org/DebianInstaller/LennyGoals As you'll see by looking around this release goals list, there's still a lot that we *didn't* do. signature.asc Description: Digital signature
Processed: Re: Bug#509378: should use labels for all partitions in fstab
Processing commands for cont...@bugs.debian.org: reassign 509378 partman-target Bug#509378: should use labels for all partitions in fstab Bug reassigned from package `partman-base' to `partman-target'. forcemerge 509378 389881 Bug#509378: should use labels for all partitions in fstab Bug#389881: SCSI device renaming breaks install Bug#225802: disk device names not persistant from install to target system Bug#295134: disk device names not persistant from install to target system Bug#308565: disk device names not persistant from install to target system Forcibly Merged 225802 295134 308565 389881 509378. 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#509238: panic backtrace
Quoting The Eclectic One (eclec...@sdf.lonestar.org): Quoting: Christian Perrier bubu...@debian.org Quoting The Eclectic One (eclec...@sdf.lonestar.org): First thought: race condition (the panic message contained a backtrace of different threads), so then I tried multiple times with only one change at at time: expert mode, regular mode, ethdetect -x, vga=771, vga normal. It turns out that the culprit was the vga option. With vga=771, I get no crash/panic in either expert or regular mode, with So, in short, in regular mode, it crashes (always at the same place) but in vga=771 mode, it doesn't, right? Correct. And I assume that you get no crash as well if you're using the graphical installer. I'm puzzled to reassign this bug report. This is obviously a race condition somewhere. Probably a weird kernel issue but investigating further istricky and I fear that this bug report might remain uninvestigated further for quite a while until it magically solves in the future with a new kernel (though probably not for Lenny). I propose documenting this in the errata file, at the minimum. signature.asc Description: Digital signature
Re: permission to upload hdparm
Quoting Marc 'HE' Brockschmidt (h...@ftwca.de): Stephen Gran sg...@debian.org writes: +hdparm (8.9-3) unstable; urgency=low + + * Fix output formatting for drives configured from /etc/default/hdparm +(closes: #494660) + * Add documentation about changing device names (closes: #421087) This change is OK from the release team's POV. d-i people should ACK it, though (CCed). As Otavio is VAC for some time, and as, from the above changelog, I see no objection, in name of the remainings of the D-I team, I can say : go... signature.asc Description: Digital signature
