Bug#1064624: Hard to short-stroke an encrypted drive
On Mon, Feb 26, 2024 at 12:34:50AM +0100, Pascal Hambourg wrote: > Not if you do not write anything to them, or if you TRIM them. You can stop explaining to me how TRIM works. commit 0c659b82d11e Author: Matthew Wilcox Date: Thu Apr 2 10:37:25 2009 -0400 ata: Add TRIM infrastructure > You may either > - tell the installer not to erase (=write) the encrypted partition (if > guided partitioning prompts it, not sure) > or > - enable "discard" in /etc/crypttab (should be the default) > - create a logical volume in the free VG space > - blkdiscard the logical volume Last time I checked, dm-crypt did not pass DISCARD requests through to the underlying device because it's a security hazard.
Bug#1064624: Hard to short-stroke an encrypted drive
On Sun, Feb 25, 2024 at 11:42:37PM +0100, Pascal Hambourg wrote: > On 25/02/2024 at 05:40, Matthew Wilcox wrote: > > > > The partitioner "guided partitioning" offers me: > > > > - use the largest continuous free space > > - use entire disk > > - use entire disk and set up LVM > > - use entire disk and set up encrypted LVM > > > > I want "use largest contiguous space and set up encrypted LVM". > > That would let me reserve 200GB of my SSD as unencrypted free space, > > which will improve the write endurance of my SSD. > > Alternatively, the installer allows to reserve free space in the encrypted > volume group. That does not accomplish my goal of extending the life of my SSD. The SSD will see those blocks as "in use" because they have encrypted data written to them (it cannot tell that they are encrypted blocks of zeroes because, well, they're encrypted). The unused area has to be part of the unencrypted disk. And then I have to call TRIM on it. > > Also once I start partitioning, eg, "and set up LVM", I can't delete the > > partitions again. > > The installer allows to delete logical volumes, volume groups and > unencrypted partitions formerly used as physical volumes, but not encrypted > volumes nor their underlying partitions. Yes. This is a poor experience.
Bug#1064791: No ethernet card in a laptop
Package: debian-installer On my new laptop, d-i prints "No Ethernet card was detected. If you know the name of the driver (etc)". This confused me, as I thought it _also_ couldn't find the wifi driver (since it's a new laptop, it's possible the d-i kernel doesn't know about the wifi device). I suggest that if d-i can find a wifi device, it skips the step where it gives me a long inscrutable list of module names and asks me to choose one to make the network work.
Bug#1064624: Hard to short-stroke an encrypted drive
Package: debian-installer The partitioner "guided partitioning" offers me: - use the largest continuous free space - use entire disk - use entire disk and set up LVM - use entire disk and set up encrypted LVM I want "use largest contiguous space and set up encrypted LVM". That would let me reserve 200GB of my SSD as unencrypted free space, which will improve the write endurance of my SSD. Also once I start partitioning, eg, "and set up LVM", I can't delete the partitions again. Well, I can, but I have to switch to a terminal, run dmsetup remove_all. Which sometimes confuses the partitioner and it gets stuck printing "??? ???" If that happens, I can neither "go back", nor "continue".
Bug#1064617: Passwords should not be changed frequently
Package: debian-installer I just did an installation with the 2024-02-24 debian-testing-amd64-netinst.iso image. I forget the exact wording used, but when setting up a user, d-i printed advice that user passwords should be changed frequently. This is no longer current good advice (since 2017): "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator." https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf I happen to like their suggestion of providing a password-strength meter, but that would be a separate bug. This bug is simply a request to remove this outdated suggestion text from d-i.
Bug#976616: Abysmally slow writes to crypted partition
Package: partman-crypto This isn't really a bug in partman-crypto, but I'm reporting it here for tracking purposes as requested by Steve McIntyre. The symptom I first experienced was when doing an install on a Tiger Lake laptop with a 1TB SSD. The step where we run blockdev-wipe was going to take over 20 hours. I am currently investigating *why* it's taking so long. The SSD is capable of writing at 1.2GB/s and the CPU is capable of encrypting at >4GB/s, so the measured 13.7MB/s is ridiculous. What I've discovered so far is that writing through the page cache is (part of) the problem: # dd if=/dev/zero bs=64k count=1000 of=/dev/mapper/nvme0n1p4_crypt 4.79s, 13.7MB/s # dd if=/dev/zero bs=64k count=10 of=/dev/mapper/nvme0n1p4_crypt oflag=direct 13.6s, 481MB/s If you need to get a release out that doesn't crater performance before I find & fix this bug in the kernel, you could change blockdev-wipe.c to use O_DIRECT. That would be a matter of changing the calloc() call on line 86 to posix_memalign() (and an optional memset()) and specifying O_DIRECT on line 161. You need to align to at least 512 bytes, and for safety, I'd align to sysconf(_SC_PAGESIZE). I have not tested this workaround.
Bug#976112: Overwriting with random data message truncated
Package: debian-installer Version: 2020-11-23 When installing on an NVMe device, the message "The installer is now overwriting /dev/nvme0n1p3 with random data to prevent meta-information leaks from " is truncated in the graphical installer. I'd suggest just s/The installer is now o/O/ Also, it takes a very long time to write a terabyte of random data. I suspect you can't do much about that though (... use RDRAND directly?).
Re: Suggestion: Change the link names on http://www.debian.org/releases/stable/debian-installer/
On Thu, Nov 26, 2009 at 11:17:07PM +0100, Frans Pop wrote: Do you really think that having AMD64, Intel x86 and Intel IA-64 instead of amd64, i386, ia64 will make people magically choose AMD64 if they're looking for 64-bit Intel support? I hadn't realised that Simon had made this change. That was the whole _point_. Put the popular architectures first, and call them something meaningful, ie: [x86 32-bit] [x86 64-bit] [PowerPC] The exact names are debatable of course, but expecting people to deduce that 'amd64' is the right link to click on for their shiny new Intel Xeon system clearly isn't working. The current pages would IMO be more improved by adding a clear link to a *separate* page with info on how to choose the correct architecture, which contains a clear description of what each architecture is. I'm not sure that's a great idea either. Why should users have to learn what Debian's internal name for their architecture is? If you want to really improve the links to images, which you're very welcome to do, then please do it by *redesigning* the pages with the links instead of forcing changes into an existing layout where the changes do more harm than that they improve things. I have no objection to changing the layout. I want to make this page more new-user friendly (since it's rather key to getting new users into Debian). -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475398: tasksel: add kerneloops to standard task
On Fri, Apr 11, 2008 at 01:38:30PM +0200, Frans Pop wrote: I installed it without problems on my KDE desktop. It's dependencies look sane (did not pull in any new packages in my case) and the default configuration is to ask to be allowed to submit. Only remaining question is how it works on systems that do not have a graphical environment installed, especially with the default of ask. If you're not running a graphical interface, with the default of 'ask', nothing's going to listen for kerneloops dbus messages, so the daemon will never be signalled to send oopses. You can, of course, change the default in /etc/kerneloops.conf from 'ask' to 'always'. Do you think we need a debconf question to set this up? Or a note to let people know they can activate it? My opinion is that this will still be useful even if people with headless servers don't activate it. I think many more people encounter kernel bugs on desktop Debian machines than they do on servers. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [hardware-donation] HP 9000 D220 (France)
On Sun, Mar 26, 2006 at 10:30:05PM -0700, Grant Grundler wrote: I also have two more B180s (also PA-7300LC CPU) and some faster 3000/J6000 machines here if someone is interested. Must pick up or arrange pick up. ... from the Silicon Valley area ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353942: SATA CD-ROM drives unnecessarily hard to get working
On Wed, Feb 22, 2006 at 04:45:37PM +0100, Frans Pop wrote: On Wednesday 22 February 2006 04:54, Matthew Wilcox wrote: If this doesn't get fixed, the workaround needs to be documented. I expect Fujitsu won't be the only people shipping SATA CD-ROMs during the lifecycle of Etch. We expect Etch to ship with 2.6.16 or even later and have been told this SATA ATAPI support should be enabled by default in 2.6.16. So this is a temporary problem only. willy jgarzik: apparently you promised to turn on sata atapi by default in 2.6.16 jgarzik willy: hmmm, I guess its 2.6.17 now Possibly the kernel team need to make this change themselves. As you say, Joey's decided to treat this as an example of another kind of bug now, but I want you to be aware that 2.6.16 won't have this on by default. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353983: eth* network interfaces change after install
Package: debian-installer Version: 21-Feb-2006 Hardware: Fujitsu P7120 Lifebook This model has an ieee1394 connector, so we autoload the eth1394 module during the first boot, and this is loaded before the 8139too module that drives the built-in ethernet connector. So eth1394 gets eth0 and 8139too gets eth1. After rebooting, the modules are loaded in the opposite order, so 8139too gets eth0 and eth1394 gets eth1. This means the configured networking doesn't work automatically. You have to edit /etc/network/interfaces to make it work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353942: sigh, udev..
On Wed, Feb 22, 2006 at 01:55:16PM -0500, Joey Hess wrote: Another way to do this might be to tag parameters on the command line with the module they apply to. Matthew Wilcox suggests in this bug report that libata.atapi_enabled=1 will send that parameter to the libata driver if it's compiled in; I wasn't aware of this syntax before. Is it documented somewhere (kernel source file is fine ;-) and does it work for other module parameters? Seems we could just parse that if so. It was introduced as part of the module_param work that Rusty did. If you look at Documentation/kernel-parameters.txt from a 2.6 kernel, you'll see it documented there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353942: SATA CD-ROM drives unnecessarily hard to get working
Package: debian-installer Version: 21-Feb-2006 My wife just got a shiny new Fujitsu Lifebook P7120 (thanks to Joey Hess raving about it on Planet the other day). I downloaded the latest nightly build for Etch and tried to install it. This far too much fun, thanks to the SATA CD-ROM drive. You see, to enable support for SATA CD-ROM drives, you have to set the libata module parameter 'atapi_enabled=1'. If libata were built in, that would be the simple matter of passing 'libata.atapi_enabled=1'. But it's a module, and even in expert mode, libata is loaded before you get to a shell. Busybox doesn't seem to have an rmmod command, so you can't unload it and then load it with the option specified. So you have to boot with BOOT_DEBUG=3 to get a shell prompt where you 'modprobe libata atapi_enabled=1'. If this doesn't get fixed, the workaround needs to be documented. I expect Fujitsu won't be the only people shipping SATA CD-ROMs during the lifecycle of Etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271387: insufficient space in /
Package: installation-reports Sorry; I'd send this somewhere better, but I'm not quite sure which component is actually responsible for this. On my x86 laptop, debian-installer chose to partition the drive thusly: major minor #blocks name 3 0 39070080 hda 3 1 146632 hda1 (/) 3 2 1 hda2 3 54882720 hda5 (/usr) 3 62929720 hda6 (/var) 3 7 390568 hda7 (/tmp) 3 8 30219808 hda8 (/home) 3 9 500440 hda9 (swap) The 130-odd MB found on / is insufficient to allow one to have both 2.6.7 and 2.6.8 installed simultaneously, at least with the other packages I have installed. This is a problem as one is required to know what you are doing to purge the kernel one is currently running. Another 50MB or so would allow one to have two kernel-images installed. Doubling it to 260MB or so would allow several kernels to be installed simultaneously, as well as allowing for future growth in the population of /bin, /sbin and /etc. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Cursor keys failing to work
'lo. I just tried to do a graphical install on an hppa C3600 and failed, probably due to the hppa images being 2 weeks out of date. Jeff has already taken care of that. The problem I'd like to discuss is cursor keys. If I try to use them (USB keyboard), strange things happen. Switching to a shell and using the tried-and-true 'cat /dev/null' shows a newline, followed by ^[[A and another newline when I press the up-arrow. Obviously this is the primary problem that needs to be fixed, but I'd like to talk about workarounds too. Something the ia64 EFI boot console lets you do is use v and ^ as substitute cursor keys. Using v is a conflict with the current meaning go to the next menu item named v. So that's out. What would people think to allowing the use of and to go to the next or previous item in the list instead? It's not quite as intuitive, but it at least requires no strange escape codes to be interpreted. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271011: Failed install on hppa C3600
Package: installation-reports Debian-installer-version: sarge-hppa-businesscard 20040909 uname -a: Linux reseau 2.4.26-32-smp #1 SMP Tue Aug 24 20:39:01 CEST 2004 parisc GNU/Linux Date: 2004-09-10 around 13:00 UTC Method: Downloaded ISO of above, burned to CD-RW, booted. Mirror was ftp.us.debian.org. Local proxy used. Machine: HP C3600 Processor: PA8600 Memory: 3.5GB Root Device: FWSCSI.6.0 Root Size/partition table: major minor #blocks name 8 0 17783240 scsi/host1/bus0/target5/lun0/disc 8 1 33776 scsi/host1/bus0/target5/lun0/part1 8 2 126976 scsi/host1/bus0/target5/lun0/part2 8 3 1 scsi/host1/bus0/target5/lun0/part3 8 5 17121264 scsi/host1/bus0/target5/lun0/part5 8 6 500720 scsi/host1/bus0/target5/lun0/part6 816 35566480 scsi/host1/bus0/target6/lun0/disc 817 33776 scsi/host1/bus0/target6/lun0/part1 818 126976 scsi/host1/bus0/target6/lun0/part2 819 1 scsi/host1/bus0/target6/lun0/part3 821 273392 scsi/host1/bus0/target6/lun0/part5 8224882416 scsi/host1/bus0/target6/lun0/part6 8232929648 scsi/host1/bus0/target6/lun0/part7 8243383280 scsi/host1/bus0/target6/lun0/part8 825 390128 scsi/host1/bus0/target6/lun0/part9 826 23545840 scsi/host1/bus0/target6/lun0/part10 /dev/sdb1 / /dev/sdb2 /boot /dev/sdb10 /home /dev/sdb9 /tmp /dev/sdb6 /usr /dev/sdb7 /var Output of lspci and lspci -n: :00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) :00:0d.0 Multimedia audio controller: Analog Devices AD1889 sound chip :00:0e.0 IDE interface: National Semiconductor Corporation 87415/87560 IDE (rev 03) :00:0e.1 Bridge: National Semiconductor Corporation 87560 Legacy I/O (rev 01) :00:0e.2 USB Controller: National Semiconductor Corporation USB Controller (rev 02) :00:0f.0 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 04) :00:0f.1 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 04) :01:04.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01) :01:05.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02) :01:06.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03) :02:01.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) :02:03.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03) :03:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22) :03:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22) :03:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22) :03:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22) :04:02.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03) :00:0c.0 0200: 1011:0019 (rev 41) :00:0d.0 0401: 11d4:1889 :00:0e.0 0101: 100b:0002 (rev 03) :00:0e.1 0680: 100b:000e (rev 01) :00:0e.2 0c03: 100b:0012 (rev 02) :00:0f.0 0100: 1000:000b (rev 04) :00:0f.1 0100: 1000:000b (rev 04) :01:04.0 0401: 1274:5000 (rev 01) :01:05.0 0200: 8086:100e (rev 02) :01:06.0 0380: 103c:1005 (rev 03) :02:01.0 0604: 1011:0024 (rev 03) :02:03.0 0380: 103c:1005 (rev 03) :03:04.0 0200: 1011:0009 (rev 22) :03:05.0 0200: 1011:0009 (rev 22) :03:06.0 0200: 1011:0009 (rev 22) :03:07.0 0200: 1011:0009 (rev 22) :04:02.0 0380: 103c:1005 (rev 03) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] Comments/Problems: Arrow keys do not work with this USB keyboard. The up arrow emits the following bytes (according to cat | hd): 0a 1b 5b 41 0a -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Why is it so hard to build?
I've had three attempts at building d-i for hppa. 1. It won't build on a woody system (the packages it wants aren't available). 2. Documentation is broken -- build/README does not document that make build_netboot won't work. You need to type fakeroot make build_netboot instead. 3. It won't build on this kernel: mkdir -p ./tmp/netboot/tree/lib/modules/2.4.20-32-udeb/kernel; if [ -e ./tmp/netboot/tree/boot/System.map ]; then depmod -F ./tmp/netboot/tree/boot/System.map -q -a -b ./tmp/netboot/tree/ 2.4.20-32-udeb; mv ./tmp/netboot/tree/boot/System.map ./tmp/netboot; else depmod -q -a -b ./tmp/netboot/tree/ 2.4.20-32-udeb; fi; mkdir -p ./tmp/netboot/tree/lib/modules/2.4.20-64-udeb/kernel; if [ -e ./tmp/netboot/tree/boot/System.map ]; then depmod -F ./tmp/netboot/tree/boot/System.map -q -a -b ./tmp/netboot/tree/ 2.4.20-64-udeb; mv ./tmp/netboot/tree/boot/System.map ./tmp/netboot; else depmod -q -a -b ./tmp/netboot/tree/ 2.4.20-64-udeb; fi; depmod: QM_MODULES: Function not implemented joshk willy: QM_MODULES: Function not implemented? willy joshk: Indeed. bob2 known silly bug willy ... is there a workaround? bob2 no, I've been tagged wontfix *sigh* -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: Woody installer for PARISC
On Sun, Apr 08, 2001 at 05:05:05AM -0400, Adam Di Carlo wrote: Sounds like they should put their effort in debian-installer then? If they don't even have a basic toolchain and kernel, and boot-floppies will be obsoleted by end of year, is it worth it? we need to have something installable by end of May. -- Revolutions do not require corporate support. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
