Bug#1033686: installation-reports: non-bootable install due to no UEFI entries
After a discussion on IRC, I tried doing the installation in expert mode and forcing installation of grub onto the removable media path: https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path The machine successfully booted after the installation completed. My understanding from IRC is that installing Debian's grub onto the removable media path is _technically_ wrong, but it is what Windows does and various firmwares out there are broken without it. Doing this, however, means clobbering any other OS's UEFI bootloader that was previously installed there. Because every BIOS has a different interface for fixing this kind of thing, it's not very nice for users to have to fix a non-bootable fresh install. If we can *reliably* detect that there's no other OS installed during the grub installation.. I'd vote for just going ahead and installing onto the removable media path by default in that scenario. I don't have any suggestions for what to do in the case of someone installing onto a machine that is intending to dual-boot Debian with another OS. It's been a decades since I've dealt with dual-booting x86 machines. On Thu, Mar 30 2023 at 03:40:00 AM -04:00:00, Andres Salomon wrote: Oh duh, the nvram is on the board itself, not on the disk drive. Okay, that makes more sense. The machine itself came with windows, and then I had a different drive in it with Debian on it. Originally legacy mode, at some point I switched to EFI and used both shimx64.efi and grubx64.efi at alternative points in the BIOS. So that was added by me in the BIOS, not d-i! And then I installed this drive, which had Mint on it, and I added an entry in the BIOS to boot it.
Re: Bug#1033686: installation-reports: non-bootable install due to no UEFI entries
[I'm manually sending the bug report since it never made it to the list due to attachment size. See the BTS to view attachments: https://bugs.debian.org/1033686 ] Package: installation-reports Boot method: usb stick Image version: March 26 2023 image (https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso) Date: March 30th 2023 01:30am Machine: Dell Latitude E7470 Processor: Intel i5-6300U Memory: 16GB Partitions: Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors Disk model: Micron 2200S NVMe 256GB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: FA0C6048-0B58-4E48-BEA6-5C6BAA9CF15B Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1050623 1048576 512M EFI System /dev/nvme0n1p2 1050624 498116607 497065984 237G Linux filesystem /dev/nvme0n1p3 498116608 500117503 2000896 977M Linux swap Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:1904] (rev 08) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: skl_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) DeviceName: Onboard IGD Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: i915 Kernel modules: i915 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 08) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: proc_thermal Kernel modules: processor_thermal_device_pci_legacy 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: intel_pch_thermal Kernel modules: intel_pch_thermal 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: mei_me Kernel modules: mei_me 00:16.3 Serial controller [0700]: Intel Corporation Sunrise Point-LP Active Management Technology - SOL [8086:9d3d] (rev 21) Subsystem: Dell Sunrise Point-LP Active Management Technology - SOL [1028:06dc] Kernel driver in use: serial 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] [8086:9d03] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: ahci Kernel modules: ahci 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1) Subsystem: Dell Sunrise Point-LP PCI Express Root Port [1028:06dc] Kernel driver in use: pcieport 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1) Subsystem: Dell Sunrise Point-LP PCI Express Root Port [1028:06dc] Kernel driver in use: pcieport 00:1d.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #11 [8086:9d1a] (rev f1) Subsystem: Dell Sunrise Point-LP PCI Express Root Port [1028:06dc] Kernel driver in use: pcieport 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-LP LPC Controller [8086:9d48] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC [8086:9d21] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d70] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci_intel_skl 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: i801_smbus Kernel modules: i2c_i801 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-LM [8086:156f] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: e1000e Kernel modules: e1000e 01:00.0 Network controller [0280]: Intel Corporation Wireless 7265 [8086:095a] (rev 59) Subsystem: Intel Corporation Dual Band Wireless-AC 7265 [8086:5410] Kernel driver in use: iwlwifi Kernel modules: iwlwifi 02:00.0
Bug#1033688: installation-reports: full-disk encryption partitioning takes way too long
This didn't make it to the list due to attachment size. For attachments, see https://bugs.debian.org/1033688 On Thu, Mar 30 2023 at 02:36:48 AM -04:00:00, Andres Salomon wrote: Package: installation-reports Boot method: usb stick Image version: March 26 2023 image (https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso) Date: March 30th 2023 02:30am Machine: Dell Latitude E7470 Processor: Intel i5-6300U Memory: 16GB Partitions: Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors Disk model: Micron 2200S NVMe 256GB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: EB75FC3A-C6E7-444E-BAB5-1255ABE5BF4D Device Start End Sectors Size Type /dev/nvme0n1p12048 1050623 1048576 512M EFI System /dev/nvme0n1p2 1050624 2050047999424 488M Linux filesystem /dev/nvme0n1p3 2050048 500117503 498067456 237.5G Linux filesystem Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:1904] (rev 08) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: skl_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) DeviceName: Onboard IGD Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: i915 Kernel modules: i915 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 08) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: proc_thermal Kernel modules: processor_thermal_device_pci_legacy 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: intel_pch_thermal Kernel modules: intel_pch_thermal 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: mei_me Kernel modules: mei_me 00:16.3 Serial controller [0700]: Intel Corporation Sunrise Point-LP Active Management Technology - SOL [8086:9d3d] (rev 21) Subsystem: Dell Sunrise Point-LP Active Management Technology - SOL [1028:06dc] Kernel driver in use: serial 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] [8086:9d03] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: ahci Kernel modules: ahci 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1) Subsystem: Dell Sunrise Point-LP PCI Express Root Port [1028:06dc] Kernel driver in use: pcieport 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1) Subsystem: Dell Sunrise Point-LP PCI Express Root Port [1028:06dc] Kernel driver in use: pcieport 00:1d.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #11 [8086:9d1a] (rev f1) Subsystem: Dell Sunrise Point-LP PCI Express Root Port [1028:06dc] Kernel driver in use: pcieport 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-LP LPC Controller [8086:9d48] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC [8086:9d21] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d70] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci_intel_skl 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: i801_smbus Kernel modules: i2c_i801 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-LM [8086:156f] (rev 21) Subsystem: Dell Latitude E7470 [1028:06dc] Kernel driver in use: e1000e Kernel modules: e1000e 01:00.0 Network controller [0280]: Intel Corporation Wireless 7265 [8086:095a] (rev 59) Subsystem: Intel Corporation Dual Band Wireless-AC 7265 [8086:5410] Kernel driver in use
Bug#1033686: installation-reports: non-bootable install due to no UEFI entries
Oh duh, the nvram is on the board itself, not on the disk drive. Okay, that makes more sense. The machine itself came with windows, and then I had a different drive in it with Debian on it. Originally legacy mode, at some point I switched to EFI and used both shimx64.efi and grubx64.efi at alternative points in the BIOS. So that was added by me in the BIOS, not d-i! And then I installed this drive, which had Mint on it, and I added an entry in the BIOS to boot it.
Bug#1033686: installation-reports: non-bootable install due to no UEFI entries
I was asked in #debian-boot for the output of efibootmgr -v:
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0001,0002,0003,0004,0005,0007
Boot*
ubuntu HD(1,GPT,54fdc960-7b34-4ff5-a95f-83dd7a4d6ab3,0x800,0x10)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* Diskette DriveBBS(Floppy,Diskette Drive,0x0)..BO
Boot0002* M.2 PCIe SSD BBS(HD,Micron 2200S NVMe 256GB ,0x0)..BO
Boot0003* USB Storage DeviceBBS(USB,USB Storage Device,0x0)..BO
Boot0004* CD/DVD/CD-RW DriveBBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot0005* Onboard NIC BBS(Network,IBA CL Slot 00FE v0110,0x0)..BO
Boot0006* Windows Boot
Manager HD(2,GPT,8f2f7ac4-db5d-4a70-95ed-f086712eb7a0,0x109000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}
Boot0007*
debian PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-A0-75-01-25-65-56-7E)/HD(1,GPT,86047261-ce5a-40e9-841e-d8ae32870d9a,0x800,0x10)/File(\EFI\debian\grubx64.efi)
Boot0008*
debian HD(1,GPT,86047261-ce5a-40e9-841e-d8ae32870d9a,0x800,0x10)/File(\EFI\debian\shimx64.efi)
I, uh, don't have a great explanation for how that weird list of
entries came to be- other than the drive probably had Windows on it
originally, and then it had Mint on it when I got my hands on it (which
would've used ubuntu kernels/shims/whatever), and then I've installed
debian bookworm twice on it so far? But honestly, who knows. *shrug*
Bug#561283: debootstrap: honor --components when using mirror_style 'main'
Package: debootstrap
Version: 1.0.20
Tags: patch
I have a mirror that requires mirror_style 'main' (because the top-level
Release file lacks an md5sum list for Packages). However, when using
a mirror_style of 'main', the COMPONENTS list is hardcoded to 'main'.
This is fine if we're not specifying a component list via command
line. However, if we're passing debootstrap --components=foo,bar,baz,
it should really be attempting to use those components.
This patch updates download_main_indices to respect --components.
--- /usr/share/debootstrap/functions.bak2009-12-15 16:40:08.0
-0500
+++ /usr/share/debootstrap/functions2009-12-15 16:50:34.0 -0500
@@ -649,9 +649,14 @@
download_main_indices () {
local m1=${MIRRORS%% *}
+ local comp=${USE_COMPONENTS}
progress 0 100 DOWNMAINPKGS Downloading Packages file
progress_next 100
- COMPONENTS=main
+
+ # if USE_COMPONENTS is empty, just use main
+ [ -z $comp ] comp=main
+ COMPONENTS=$(echo $comp | tr '|' ' ')
+
export COMPONENTS
for m in $MIRRORS; do
for c in $COMPONENTS; do
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561298: debootstrap: download_main fails to iterate through components
Package: debootstrap
Version: 1.0.20
Tags: patch
There's a bug in the following code in download_main. I've left
comments in the code below describing it:
# Let's assume $p contains 'coreutils' for this explanation..
# $COMPONENTS contains at least 2 entries (ie, foo bar)
for c in $COMPONENTS; do
local details=
# $details contains
for m in $MIRRORS; do
local path=dists/$SUITE/$c/binary-$ARCH/Packages
local pkgdest=$TARGET/$($DLDEST pkg $SUITE $c
$ARCH $m $path)
if [ ! -e $pkgdest ]; then continue; fi
details=$($PKGDETAILS PKGS $m $pkgdest $p)
# $details contains coreutils - if the package wasn't found in component
'foo'.
if [ $details = $p - ]; then continue; fi
# Assuming only 1 entry in $MIRRORS, break out of the loop..
...
done
# At this point, $details contains coreutils -
if [ $details != ]; then
break
# Whoops, coreutils wasn't actually found in 'foo'; it's actually in 'bar'.
# But since $details contains something other than , we break out of
# the $COMPONENTS loop! Debootstrap then fails, because coreutils couldn't
# be downloaded.
fi
done
This bug is only triggered when you have multiple COMPONENTS, which is
presumably why no one else has hit this (see bug #561283, which allows
usage of multiple components w/ mirror_style main).
The patch below fixes this issue.
--- /usr/share/debootstrap/functions.bak2009-12-15 16:57:03.0
-0500
+++ /usr/share/debootstrap/functions2009-12-15 19:23:57.0 -0500
@@ -685,7 +685,10 @@
local pkgdest=$TARGET/$($DLDEST pkg $SUITE $c
$ARCH $m $path)
if [ ! -e $pkgdest ]; then continue; fi
details=$($PKGDETAILS PKGS $m $pkgdest $p)
- if [ $details = $p - ]; then continue; fi
+ if [ $details = $p - ]; then
+ details=
+ continue
+ fi
size=${details##* }; details=${details% *}
md5=${details##* }; details=${details% *}
local debdest=$($DLDEST deb $details)
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Tue, 8 Jul 2008 09:15:14 +0200 maximilian attems [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote: [...] I'm having serious trouble parsing what you're trying to say here. Could you rephrase? you never checked the rh kernel. they do a *lot* of backporting and have a big team working on that. so you'll notice that none of those patches landed in ours. so your argument sounds nice, but doesn't help in practise. .26 got a *lot* upstream attention and solves a number of .25 regressions. it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless improvements, allmost net namespaces and uvc cam support. Not to mention OLPC support; it would be *really* nice to be able to use d-i to install Debian onto an XO. Of course, other things (grub-under-OFW or just plain OFW support, jffs2 formatting support, etc) would need to be in place as well for it to work. I haven't kept up on the status of those things, but I know that people have been working on them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383710: busybox: missing versioned build-dep on dpkg-dev
Package: busybox Version: 1:1.1.3-2 Severity: serious Attempting to build busybox on sarge yields the following during build: make[1]: Leaving directory `/busybox-1.1.3/debian/build/build-udeb' cp debian/build/build-udeb/docs/BusyBox.1 debian/build/build-udeb/docs/busybox.1 touch debian/stamps/build-udeb DEB_HOST_ARCH_OS is not a supported variable name at /usr/bin/dpkg-architecture line 271. DEB_HOST_ARCH_CPU is not a supported variable name at /usr/bin/dpkg-architecture line 271. DEB_HOST_ARCH_OS is not a supported variable name at /usr/bin/dpkg-architecture line 271. mkdir debian/build/build-floppy-udeb cp '' debian/build/build-floppy-udeb/.config cp: cannot stat `': No such file or directory make: *** [debian/stamps/build-floppy-udeb] Error 1 debuild: fatal error at line 765: According to the dpkg-architecture manpage: BACKWARD COMPATIBILITY The DEB_HOST_ARCH_CPU and DEB_HOST_ARCH_OS variables were only intro duced in relatively recent versions of dpkg-architecture (since dpkg 1.13.2), before this debian/rules files tended to check the values of the DEB_HOST_GNU_CPU or DEB_HOST_GNU_TYPE variables which have been subject to change. busybox needs one of the following: either a Build-Dependency upon dpkg-dev (= 1.13.2), or backwards compatibility code of the following nature: DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU 2/dev/null) ifeq ($(DEB_HOST_ARCH_CPU),) DEB_HOST_ARCH_CPU := $(shell dpkg-architecture -qDEB_HOST_GNU_CPU) ifeq ($(DEB_HOST_ARCH_CPU),x86_64) DEB_HOST_ARCH_CPU := amd64 endif endif DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS 2/dev/null) ifeq ($(DEB_HOST_ARCH_OS),) DEB_HOST_ARCH_OS := $(subst -gnu,,$(shell dpkg-architecture -qDEB_HOST_GNU_SYSTEM)) ifeq ($(DEB_HOST_ARCH_OS),gnu) DEB_HOST_ARCH_OS := hurd endif endif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
On Wed, 2006-03-15 at 11:25 +0100, Pierre Habouzit wrote: Le Mer 15 Mars 2006 03:01, Andres Salomon a écrit : Hi, I am going through the expulsion process to have Sven Luther removed from the project. The process is outlined here: http://lists.debian.org/debian-devel-announce/2005/08/msg5.html , and I have already completed step 1. I strongly oppose to such an expulsion. It amazes me that people oppose expulsion, but are perfectly happy to allow the DAMs to decide whether or not a NM is to be let into the project. Why do we trust the DAM's judgement in one scenario but not the other? what is wrong with you ? are you gone completely insane or what ? I'm tired of discussions immediately degrading into personal insults. I know Sven may sometimes be a bit overpresent in some trolls, he also may answer too quick, without having read the mail he answers to correctly enough. But AFAICT, I've always seen him apologies when he did so (I can provide links if you can't believe me…). That is not the case. Furthermore, apologizing repeatedly does not make his behavior right. If you want to expulse any DD that taunts a release manager, a ftp-master or a debian sys-admin, hey, please begin with the recent thread about the NEW queue beeing stuck again. There is a lot of DDs that need you to rule about them. This is not about taunting a release manager, an ftp master, or a DAM. This is about repeated aggressive, childish behavior, against a number of people. Sven seems to anger almost everyone he works closely with. The examples I provided are just the tip of the iceberg. I thought I explained this in my followup email[0]. [0] http://lists.debian.org/debian-devel/2006/03/msg00621.html signature.asc Description: This is a digitally signed message part
Re: removal of svenl from the project
The DAM has accepted the request; please send seconds directly to [EMAIL PROTECTED], cc'ing me as well. For the people who seem to think that there are more constructive ways of dealing w/ this issue rather than the expulsion process: http://squishy.cc/svenl.txt This is a lot from two weeks ago, right after Sven threatened Jonas. If he had actually changed his behavior sometime in the past two years, rather than just viewing every discussion as a battle that must be won at all costs, I would not be making this request. signature.asc Description: This is a digitally signed message part
removal of svenl from the project
Hi,
I am going through the expulsion process to have Sven Luther removed
from the project. The process is outlined here:
http://lists.debian.org/debian-devel-announce/2005/08/msg5.html,
and I have already completed step 1.
Step #2 requires the support of some 15 developers. I am attempting to
find people that are interested in publically seconding my explusion
request. If you are interested, please email me. Remember that your
request will be public, and you will have to provide reasons why you
feel that his removal will benefit the project. I'm looking both for
people who have had conflicts w/ him (logs are always good, too), as
well as people who have just seen the effects of his actions (ie,
unbiased opinions).
Sven has always been a nuisance to deal w/, but up until now I have not
considered this action. In the past two weeks, the following comments
made by him have changed my mind:
2006-03-07:
svenl jonas: i hope we never again meet in public, because i promise i
will hit you if i do.
2006-03-14:
svenl vorlon: so, you think it is correct of jonas to mention
traveller and thanking him for investigating the issue, while fully
ignoring my own contribution ?
-- vorlon ([EMAIL PROTECTED]) has left
#debian-kernel
svenl yeah, coward.
Sven's behavior has always been combative (and some might argue
hostile), but this is beyond what is acceptable. He threatens bodily
harm upon another developer in a public forum, and then a week later
publically insults/taunts a developer (one of the Release Managers,
even), behind his back. This is incredibly childish, aggressive
behavior, and should not be tolerated within the project (IMO).
Some might argue that we should just kick him from the channel and
remove his commit access to the debian-kernel project, but that does not
solve the problem of him abusing other teams, as well as his abusive
mailing list posts. He also {co-,}maintains some 47 packages, which
means users for those packages will have to deal w/ him as well. I
believe it is better if he is removed from the project altogether, as he
damages it more than he helps.
So, if you are interested in seconding the expulsion request, please let
me know. Please do not turn this into a flamewar; I don't care about
your reasons why people should not be forcefully removed from the
project. Those who feel this way probably have not had to work w/ Sven
on a team for the past 2 years.
signature.asc
Description: This is a digitally signed message part
Re: removal of svenl from the project
On Tue, 2006-03-14 at 21:01 -0500, Andres Salomon wrote: [...] Sven has always been a nuisance to deal w/, but up until now I have not considered this action. In the past two weeks, the following comments made by him have changed my mind: 2006-03-07: svenl jonas: i hope we never again meet in public, because i promise i will hit you if i do. 2006-03-14: svenl vorlon: so, you think it is correct of jonas to mention traveller and thanking him for investigating the issue, while fully ignoring my own contribution ? -- vorlon ([EMAIL PROTECTED]) has left #debian-kernel svenl yeah, coward. A few clarifications/comments based upon what people have said: 1) These quotes are examples of his destructive behavior. One can find plenty more in the mailing lists. The ones I supplied here are the ones that made *me* decide to take action. 2) Yes, I have tried talking to him. After a number of blowups on the debian-kernel list, myself and a number of kernel team members have talked to him to calm him down (and in some cases getting him to apologize). The behavior he displays happens repeatedly, despite warnings and requests that he behave himself. The rest of the IRC log from when he threatened Jonas is basically me attempting to show Sven how destructive his behavior is. The fact that, a week later, he continues w/ this behavior (after years of doing the same thing) is why you're seeing this request. 3) If he was in the NM queue, and you were his AM, would you accept him after seeing how he behaves? If not, why is that so different from kicking him out of the project (other than asking that he be banned from the lists, but this is a request of the list masters, not the DAM)? In that regards, I have a wonderful quote from Sven: I am not in the AM queue, so i can be as rude as i want. [0] I presume he meant the NM queue. [0] http://lists.debian.org/debian-legal/2004/07/msg00967.html signature.asc Description: This is a digitally signed message part
Re: Re: Dropping 2.4 hppa kernel-image packages
On Fri, 14 Jan 2005 02:47:01 -0500, Joey Hess wrote: [...] It's been no secret that the 2.4 kernel was not in good shape and hppa folk were happier with 2.6. But this idea of just dropping 2.4 altogether was a suprise to me. (FWIW, I'm also concerned that the kernel team (except for joshk and horms) has back-burnered 2.4 now for all other arches too.) Now? This is nothing new. Ever since Herbert gave up maintenance, the only people from the kernel team willing to work on 2.4 (iirc) have been joshk, horms, and jens. Jens doesn't appear particularly active currently, so that leaves just joshk and horms. The 2.4 packages, thanks to a mess of backports and other issues, are quite a mess to deal w/. I certainly don't consider it a good use of time to attempt to beat the packages into shape, when time could be spent beating 2.6 into shape.
Re: Bug#275006: Bug still present in linux26 netinst 20041118 RC2
On Tue, 30 Nov 2004 15:06:39 +0900, Horms wrote: reassign 275006 debian-installer thanks On Tue, Nov 23, 2004 at 02:15:31PM +0200, Tapio Lehtonen wrote: Same as before, linux26 does not find the SCSI disk, aic7xxx is loaded. Installation logs in http://people.debian.org/~tale/peli/ Hi, There was a fix to the aic7xxx driver included in kernel-source-2.6.8 2.6.8-10 (actually it was in 2.6.8-9) but that was broken. Wait, -9's fix was broken? I haven't heard any feedback about this yet; the last change was the hostraid patch removal, which is the only other thing I could think of that might be breaking stuff for people. Is -9/-10 working for people w/ aic7xxx/aic79xx cards, or not? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Hi Fabio, Thanks for feeding changes back to d-k. No one else in Ubuntu has bothered to do that thus far... On Mon, 29 Nov 2004 08:35:03 +0100, Fabio Massimo Di Nitto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, ~right last week i have been asked to merge the linux-kernel-di-* packages directly into the kernel-source (that in Ubuntu we call linux-source) so that all the different binary packages are built from one and only one source. Basically killing kernel-image packages (that was done a few months back) and now linux-kernel-di-* Killing kernel-image packages is something that we've been planning post-sarge (if I hadn't gotten caught up doing other stuff, I would've started w/ 2.6.9 last week). The goals are: a) Kill all the separate image packages, so that instead of requiring a psuedo-package in the BTS (w/ no versioning support), we can view all bugs for a specific kernel version (since they all come from the same source package). b) Get archs autobuilt, so that they don't lag behind. They may not boot, but they'll at least compile. Given the way that kernel development upstream is happening, the development process will look something like this: 1) release k-s 2.6.10-1, upload i386 images, 2) autobuilders for all other archs attempt to build arch-specific images, 3) many fail; the kernel is therefore kept out of etch, 4) k-s 2.6.10-3 is uploaded (after -2 fixes some build failures as well), 5) autobuilders successfully build for all archs, 6) testers report bugs for archs that don't work; obviously, an arch-specific RC bug will keep a kernel out of etch, 7) after developers fix arch-specific bugs, k-s 2.6.10-4 is uploaded and autobuilt, 8) k-s 2.6.10, now that it builds and runs on all (used) archs, flows into etch. Of course, there's a good chance there may be some arch breakage on a rarely used arch, and the package gets into etch w/ the breakage; however, I'd rather see that than the arch sticking w/ a kernel version that's a year old, has known security holes, but boots. 3) Simplify packaging. Dump the kernel-tree-X crap, etc. The cons of this are that one will no longer be allowed to build against an older, known-working k-s. Kernel config handling will be unified (probably something similar to what the powerpc images do), so that there's not a bunch of out-of-sync config options between different archs. I would eventually like to use a cdbs-like build system for the kernel stuff, but that's highly dependent upon cdbs gaining some necessary functionality that it doesn't currently have (and allowing this to be implemented in a clean fashion). The resulting diff of the merge (based on our linux-source) can be found here: http://people.ubuntulinux.org/patches/kernel_udebs_from_kernel_source.diff Patch saved on my hard drive for posterity. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping 386 support
On Sat, 2004-10-23 at 18:35 +0200, Frank Lichtenheld wrote: On Fri, Oct 22, 2004 at 11:34:50AM -0400, Andres Salomon wrote: [...] If someone from the kernel or glibc team had access to a real 386, we might be able to make (userspace) support work. Would it be possible to get access to this machine? hmm, I can make that possible (I can probably get it connected to the internet somewhere in the university and then offer ssh access to it). What kind of access would you need? Do you need to test woody-sid upgrades or do you need a plain woody or a plain sarge? Chroots? Is ssh enough or do you need serial console, too? At least for me, I'm thinking simply shell access to a plain sarge install would be fine. I'd like to play w/ catching SIGILLs via a preloaded shared library. From there, it should be possible to either a) make a package for the lib, add it as a dependency, and have the preload stuff set up if running on a true 80386, or b) add the functionality to glibc. I shouldn't need any special privileges or kernel/system modifications. Just ssh should be fine. -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Dropping 386 support
On Fri, 2004-10-22 at 00:31 +0200, Frank Lichtenheld wrote: On Sat, Oct 02, 2004 at 06:01:31PM -0400, Andres Salomon wrote: The kernel team is considering dropping 386 support (the 80386 processor, not the i386 arch) from Debian. Currently, in order to support 386, we include a 486 emulation patch (the patch can be viewed [...] Comments? Thoughts? I think the following should pretty much outline the current opinion of the release team (at least vorlon and me agreed explicetly on it): We're in favor of keeping a -386 kernel image that is compiled with the patch activated and therefor runs on real i386 machines. It should be mentioned in the release notes and in the description of the option in the kernel config that it has known security risks and that there may no fix for this available in the near or even far future. That leaves i386 users the choice whether they want to accept the risk or if they want to stay on older software (which probably has its own risks). As the patch doesn't has any affects on all other machines we think this is an acceptable solution. Works for me. Has the current image compiled the patch in? (I haven't checked that yet) Yes, it does. If yes, there should be no problem at all to implement this solution (as long as the patch works). If no, the d-i team will have to speak Heh, that's the rumor. Can't say that I've actually tested it. :) up and say if a new kernel image could still be added before release with reasonable effort. As most 386 machines will already fail to satisfy other requirements of d-i (as RAM), it may even be acceptable only support 386 via upgrades or manual installation... I will begin next week with some upgrade tests from woody on a 386 machine and could then handle the further steps like creation of a upgrade-i386 directory with backported modutils, initrd-tools and a current kernel-image. If someone from the kernel or glibc team had access to a real 386, we might be able to make (userspace) support work. Would it be possible to get access to this machine? -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Dropping 386 support
Hi, The kernel team is considering dropping 386 support (the 80386 processor, not the i386 arch) from Debian. Currently, in order to support 386, we include a 486 emulation patch (the patch can be viewed from here: http://svn.debian.org/viewcvs/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/x86-i486_emu.dpatch). The patch is a requirement for 386 machines, as debian's gcc generates binaries with 486 opcodes. This patch is known to be buggy (see bug #250468), and is considered unreleasable. The members of the kernel team don't have the hardware, time, and/or desire to fix it, and the upstream author is too busy to fix it. As d-i rc2 is about to be released (and that is presumably what sarge will release with), we need to make the decision what to do. We have two options; we can either keep the patch in, risk releasing sarge w/ 386 support containing known security holes, and hope someone someone fixes the problem soon; or, we can drop 386 support completely. Reasons for dropping 386 support are as follows: * d-i currently requires at least 20 megs of ram to install. My 386 had 4 megs of ram, which required using lowmem w/ potato's installer. I don't see standard d-i as being a viable option for installing debian on your 386 anytime soon. * Potato ran decently on my 386 (functioning as a NAT box). I upgraded to woody, and it ran much slower. Sarge will be even worse; this will not get better, especially considering 486 opcodes will be emulated on the 386. * Memory requirements have expanded, as have disk requirements. i386 kernels require an initrd, and use more memory than, say, 2.0 or 2.2 kernels. * Embedded 386 users will end up creating custom kernels, anyways; they will want to strip out unneeded functionality to pare down the memory requirements of the kernel. They can, of course, also apply the 486 emulation patch to their kernel. Reasons for keeping 386 support: * 386 users currently running woody will be left out in the cold, wrt security updates. Of course, there's nothing stopping them from coordinating with the security team to offer security updates for woody long after sarge releases; I wouldn't bet on it, though. Given d-i's memory requirements, and the fact that you'd be hard-pressed to find a (desktop) 386 system with more than 16 megs of memory, I don't consider debian 3.1 to be a viable candidate for installing onto a 386. Also, note that if we do drop 386 support, I will rename kernel-image-2.6.8-386 to kernel-image-2.6.8-486, and update optimizations accordingly. Comments? Thoughts? -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: usb memory stick booting w/ grub
On Tue, 2004-09-28 at 14:41 -0400, Joey Hess wrote: Andres Salomon wrote: Syslinux does not work for me (as well as a few other people), for memory stick booting (see #273453 for more details). Unfortunatly, booting grub from a USB device has always failed for me and your method did not seem to work. :-( Hrm. What ends up happening? Where does it fail? Instead, I ended up using grub to boot from my memory stick. Since people may be interested in bypassing the syslinux/mbr dance, and/or may be more comfortable w/ grub, here's what I did: Another reason might be if you have a larger stick and want partitions on it so you can use part of it for something other than debian-installer. *nod*. I hadn't really thought about that, but yes, that would be handy. 1) If not already created, create a partition on the memory stick. The type doesn't matter (I left it at the default for linux, which is 0x83), just make sure the bootable flag is toggled. Format the partition, as well (ext2 works perfectly well; mke2fs /dev/sda1 tune2fs -m0 /dev/sda1). I'm not sure if grub supports vfat, so this procedure may not be for you if you want to mount the contents of your memory stick in windows. If grub did support vfat, this would be easier yet since the boot.img.gz is a vfat filesystem with the installer files on it and could be uncompressed onto the partition. In my testing, writing that to the disk as /dev/sda1 made grub-installer fail though. grub-installer bailed out due to a fs type sanity check, or what? title Debian Installer root(hd0,0) kernel /vmlinuz ramdisk_size=1 root=/dev/rd/0 init=/linuxrc devfs=mount,dall rw initrd /initrd.gz Doesn't this assume that the usb stick appears to grub as the first hard drive on the system you install? Seems unlikely if there is another disk. Yes; I assume an IDE based system, here. I'd have to play around w/ a scsi system to see how grub (or the bios?) ends up ordering disks and usb-storage devices. -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
usb memory stick booting w/ grub
Hi, Syslinux does not work for me (as well as a few other people), for memory stick booting (see #273453 for more details). Instead, I ended up using grub to boot from my memory stick. Since people may be interested in bypassing the syslinux/mbr dance, and/or may be more comfortable w/ grub, here's what I did: 1) If not already created, create a partition on the memory stick. The type doesn't matter (I left it at the default for linux, which is 0x83), just make sure the bootable flag is toggled. Format the partition, as well (ext2 works perfectly well; mke2fs /dev/sda1 tune2fs -m0 /dev/sda1). I'm not sure if grub supports vfat, so this procedure may not be for you if you want to mount the contents of your memory stick in windows. 2) Mount the partition (mount /dev/sda1 /mnt). 3) Install grub onto the stick's MBR (grub-install --root-directory=/mnt /dev/sda). 4) Create a menu.lst for grub and copy it to the boot/grub directory on the partition (cat menu.lstEOF default 0 timeout 5 color cyan/blue white/blue title Debian Installer root(hd0,0) kernel /vmlinuz ramdisk_size=1 root=/dev/rd/0 init=/linuxrc devfs=mount,dall rw initrd /initrd.gz savedefault boot EOF cp menu.lst /mnt/boot/grub). 5) Copy the other necessary files over to the partition (cp initrd.gz vmlinuz /mnt). 6) At this point, you should have a bootable usb stick. Choose the image you want to install, copy it over, and you're done. I went with the netinst CD image (cp sarge-i386-netinst.iso /mnt/sarge.iso). 7) Unmount the partition (umount /mnt). It would be fairly trivial to script something to do this for people; the only variables are the block device to mangle (ie, /dev/sda), how to handle mangling it (ie, do you want to use the entire disk?), and which image you want to use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.6 kernel removals
From what I can gather, it would appear that debian-installer is using 2.6.7 kernels for the following archs: i386, ia64, powerpc, and sparc. Every other arch is using 2.4 or older. In sid, we've got 2.6.6 for alpha, and 2.6.7 for i386, ia64, and powerpc. I plan to request the removal of all older kernels. This means the following will go: kernel-source-2.6.3 kernel-source-2.6.5 kernel-source-2.6.6 (if alpha still needs this, let me know) kernel-patch-powerpc-2.6.5 kernel-patch-powerpc-2.6.6 (already requested: #261468) kernel-patch-2.6.3-ia64 kernel-patch-2.6.4-ia64 kernel-patch-2.6.6-ia64 kernel-image-2.6.4-ia64 (already requested: #261457) kernel-image-2.6.6-ia64 kernel-image-2.6.5-alpha kernel-image-2.6.5-i386 (already requested: #261773) kernel-image-2.6.6-i386 (already requested: #261773) If anyone has any problems w/ the removal of these, let me know. Otherwise, I'll file bugs. Hopefully someone's working on 2.6.7 for alpha, so we can get rid of all traces of 2.6.[1-6] from sid.. -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#248787: installation-reports
On Thu, 2004-05-13 at 11:04, Martin Michlmayr wrote: * Andres Salomon [EMAIL PROTECTED] [2004-05-13 10:57]: This is definitely not available in 2.6. The way I've historically checked for the existence of lvm driver support in 2.6 has been with: grep [0-9] device-mapper$ /proc/misc But does this work under 2.4? Hmm, yeah, seem so. 574:[EMAIL PROTECTED]: ~] cat /proc/misc 63 device-mapper 134 apm_bios 135 rtc 1 psaux 575:[EMAIL PROTECTED]: ~] uname -a Linux unjust.cyrius.com 2.4.26-1-686 #3 Sun Apr 18 21:17:21 EST 2004 i686 GNU/Linux 576:[EMAIL PROTECTED]: ~] Yes, it works for all kernel versions using device-mapper. Does d-i allow you to pick whether to use lvm10 or lvm2? If so, then you'll need to keep your lvm10 check for /proc/lvm, and add the additional /proc/misc dm check for lvm2. If d-i always uses lvm2, then checking /proc/misc (regardless of kernel version) should always work. signature.asc Description: This is a digitally signed message part
Bug#248787: installation-reports
On Thu, 2004-05-13 at 23:07, Steve Langasek wrote: On Thu, May 13, 2004 at 11:26:16AM -0400, Andres Salomon wrote: On Thu, 2004-05-13 at 11:16, Martin Michlmayr wrote: * Andres Salomon [EMAIL PROTECTED] [2004-05-13 11:11]: Yes, it works for all kernel versions using device-mapper. Does d-i allow you to pick whether to use lvm10 or lvm2? If so, then you'll need to keep your lvm10 check for /proc/lvm, and add the additional /proc/misc dm check for lvm2. If d-i always uses lvm2, then checking /proc/misc (regardless of kernel version) should always work. We always use lvm2 now... I don't think it's worthwhile to give offer lvm1 as an option. Do you disagree? It depends if users want snapshotting support. If not, then there's no need for lvm10. If users do want snapshotting support, then we're left with a few options: - support choosing lvm10. - get a more complete device-mapper patch into the debian 2.4 kernel (current debian 2.4 only includes a subset of the device-mapper patch). This is something I'd push for with whomever Herbert hands the kernel over to. For 2.6, snapshotting is not an option yet. - get a more complete dm patch into the debian 2.4 kernel, and include the experimental 2.6 dm patch that includes snapshot support. Not recommended. Even if someone does want snapshotting support, I can't imagine this being relevant within the installer. They can always upgrade to a snapshot-capable lvm2 kernel once it becomes available. Cheers, I was thinking more along the lines of someone installing 2.6 w/ d-i, attempting to take a snapshot, and being suprised when it doesn't work (despite docs in the package saying that it should work). Then, in order to get snapshots working, they realize they'll need to use an experimental devmapper patch. If the system is destined for production (hey, I know people using 2.6 in production already), that probably isn't an option. They can't downgrade to lvm10, either, since lvm2 LVs will have been created with lvm2-only metadata. They must downgrade to a self-compiled 2.4 kernel, with proper device-mapper patch applied manually. If I was a user, this would probably piss me off. :p Of course, this problem gets solved quicker w/ more people testing (experimental) 2.6 devmapper snapshotting patches. signature.asc Description: This is a digitally signed message part
