Bug#1034814: debian-installer: bootable flag not toggling
On 4/25/23 01:59, Pascal Hambourg wrote: On 25/04/2023 at 03:24, Matt Taggart wrote: When in the partitioning and editing a partition, if I am on the "bootable" option and select, it does not toggle but remains "no". The screen flashes, bot no change. I have not yet checked what ends up in the partition table after the install. Is it a GPT partition table ? Yes, GPT and EFI, 512gb nvme drive. GPT is the default partition table type with EFI boot or disk size above 2 TiB. In GPT, "boot" and "esp" parted flags are equivalent and both represent the "EFI system partition" type (IMO this is a big mess). Being used to doing non-GPT/EFI installs for so long, I did what I have always done and toggled the bootable flag on the /boot partition. When it didn't change, I tried again and it still didn't change. So it was less a bug of it not functioning that it was confusing for the user. If this should be fixed, not sure how. - Set/unset the "esp" flag at the same time as the "boot" flag if GPT ? - Hide the "bootable" option if GPT > - Map the "bootable" option to the "legacy_boot" parted flag instead of "boot" if GPT ? (AFAIK only syslinux/extlinux uses this flag) IMO "hide the bootable option if GPT" (but maybe that is non-trivial). Alternatively the value could be displayed as "GPT" and not change when toggled. Thanks, -- Matt Taggart m...@lackof.org
Bug#1034814: debian-installer: bootable flag not toggling
Package: debian-installer Version: bookworm-DI-rc1 When in the partitioning and editing a partition, if I am on the "bootable" option and select, it does not toggle but remains "no". The screen flashes, bot no change. I have not yet checked what ends up in the partition table after the install. Sorry for the crappy report, I will try to provide more details when I get a chance to repeat it. -- Matt Taggart m...@lackof.org
Bug#792456: encrypted swap broken in last several debian releases
The last few debian releases (buster and bullseye at least) configuring encrypted swap has been broken for me. I don't know if it's the same as what the user in #792456 is seeing, but likely. I have most recently tested it in Bookworm RC1 and here is what I did: * run by hand partitioning * create 3 partitions: boot, swap, lvm * configure encryption: enable encryption for swap and lvm partitions * configure swap to use serpent and random passphrase * configure lvm partition to use serpent and key * finish * mark lvm encrypted partition to be used for lvm, configure lvm, setup root and var partition * configure boot partition to be ext4 mounted at /boot * finish partitioning * receive error about failure to setup swap Sorry for the short report, I will try to redo it and capture logs, but I wanted to report this ASAP. My workaround has been to allocate the partition but mark it do not use and then finish the setup by hand after install. Thanks, -- Matt Taggart m...@lackof.org
Bug#897931: preseed: add tests for additional url= bare host cases
Package: preseed Version: 20180504 Severity: wishlist The preseed file I have been using (for quite a few releases now) relies on the behavior documented at https://www.debian.org/releases/stable/i386/apbs02.html.en#preseed-auto where if url= does not list a protocol then http is assumed, and does not end in / then default path is added. I was trying to debug something and was looking through the preseed source and realized that package/preseed/01-auto-install.t could use a couple more test cases: 1) url= with a bare hostname like "url=server.example.org" 2) url= with a bare IP like "url=10.0.0.5" 3) I guess IPv6 is possible too? "url=fd00:9:152:48:1822::162:199" (or maybe it's "url=[fd00:9:152:48:1822:ffff:162:199]"?) Thanks, -- Matt Taggart tagg...@debian.org
Bug#892803: di-netboot-assistant: unsigned daily images
On 03/13/2018 10:28 PM, Cyril Brulebois wrote: What extra security would signing images bring here? For me, assurance that nobody had interfered with the daily image that I will use to install a system. Many systems I install with a daily are for testing and get thrown away rather quickly (although often I don't know in advance which ones will end up sticking around longer). One reason in the past I have installed systems with a daily build that I know will stick around is due to needing support for new hardware at install time, where I couldn't just get an older install on the system with a stable d-i and then upgrade the kernel post-install. Usually things like drivers for a disk controller, newish filesystem features, or network drivers for doing a network install. The testing alpha/beta/rc releases _do_ get signed right? Maybe that's a better solution for the above case where I need something newer than stable, but testing would in most cases be "new enough". But still thinking about daily... d-i.d.o does use https and has it's own Let's Encrypt issued cert, I think I could verify the cert and then check that the netboot.tar.gz matches the one published in https://d-i.debian.org/daily-images/amd64/daily/SHA256SUMS Looking at the code, it looks like d-n-a already does the latter part I guess to prevent cases of download corruption, broken mirrors, etc. The default di-sources.list uses https for the daily images. And the code uses either wget or curl, both of which default to verifying certs via the normal system ca list. So it's already doing quite a bit to verify even the daily image sources. That's good, but if I was an attacker trying to mitm, I'd just need to find the weakest link in the CA cartel to issue me a d-i.d.o cert I could use for my mitm mirror. This is a corner case for sure and if there is no reasonable way to solve it I think that's OK. I think if I wanted to prove to myself the daily image came from debian, I could verify the cert used for d-i.d.o was indeed the known debian owned one, download the netboot.tar.gz/SHA256SUMS and stick them in the cache, and then use the --offline flag. -- Matt Taggart tagg...@debian.org
Bug#892803: di-netboot-assistant: unsigned daily images
Package: di-netboot-assistant Version: 0.51 Severity: minor When attempting to install a daily image I get the following # di-netboot-assistant install daily --arch=amd64 I: Processing daily/amd64. I: Downloading 'SHA256SUMS'. E: Could not download 'https://d-i.debian.org/daily-images/amd64/daily/../../../../Release' and/or 'Release.gpg'. * * * * * * * * * * * * WARNING * * * * * * * * * * * * * * * * Could not verify/find the signature of the release. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Download and install the image anyway? [y|N]: In the package provided di-sources.list file, in the daily section, there are the following comments, ## Daily netboot DI images (not signed?!?). Read: # https://d-i.debian.org/daily-images/build-logs.html # http://wiki.debian.org/DebianInstaller/Today which is a hint that this is likely to fail. It would be nice if the d-i daily's were signed, even if they had to use a different key that I would then need to install on the system so that this di-netboot-assistant check could use. Is there already a bug open requesting daily image signing? If not then maybe this one can be cloned and reassigned to the right place. But until something like that is possible I suggest a couple things: * add something to the error message detecting when installing daily and explaining it's known that daily images currently aren't signed * add some sort of override option for daily images to skip the check, printing a warning. This would allow for calling di-netboot-assistant from other tools (scripts, puppet, etc) * update the comments in di-sources.list explaining dailys aren't signed and will result in the warning prompt * the 'Today' URL in the comments no longer exists, I couldn't find a good replacement -- Matt Taggart m...@lackof.org
Bug#892800: di-netboot-assistant: errors when $HOME not set
Package: di-netboot-assistant Version: 0.51 Severity: minor I have a puppet module that calls di-netboot-assistant to setup d-i images. When puppet runs the command, $HOME is not set. Because di-netboot-assistant uses "set -u" (line 3) when it attempts to use $HOME (line 56), the script exist with an error /usr/bin/di-netboot-assistant: line 56: HOME: unbound variable It's easy to repeat, just 'unset HOME'. Removing the -u from the set allows it to work fine (since the if on line 56 is just false when $HOME isn't set). -- Matt Taggart tagg...@debian.org
Bug#789247: di-netboot-assistant: broken deb.d.o urls
On 03/10/2018 04:22 AM, Andreas B. Mundt wrote: Hm, the /debian/ should be inserted by the following in '/etc/di-netboot-assistant/di-netboot-assistant.conf' [1]: #Download Mirror # The variable MIRROR_REGEXPS contain a list of space separated sed # regular expression, to rewrite di-sources.list URLs, to match your # prefered mirror. For example: MIRROR_REGEXPS="s=://deb.debian.org/=://deb.debian.org/debian/=" I was already wondering why not to use the correct URL in 'di-sources.list', but kept that as it works fine for me. Can you check if you have the line in 'di-netboot-assistant.conf'? Perhaps it's there for historical reasons and we can/should remove it. Oh... I had just grabbed the latest di-sources.list to use on an older version of the package, I didn't know about that regexp thing in the config file... It's sort of a nice feature, it makes using a local mirror/proxy easier (assuming you know you can use that). But I suspect most mirrors would have a debian/ dir and if a user had one that _didn't_ then the regexp could be setup the other way to strip it out. So my vote would be fix the URLs in di-sources.list, comment out MIRROR_REGEXP in the conf, change it's regexps to provide an example of how it could be used. I guess the only concern is the existing conffiles that are out there and if that would break existing installs. If you changed both sources and conf at the same time, hopefully it would be clear. I guess if you go that route, wait until one of them needs another change anyway? -- Matt Taggart tagg...@debian.org
Bug#789247: di-netboot-assistant: broken deb.d.o urls
It looks like the deb.debian.org URLs in di-sources.list need to be updated E: Can't download 'stretch' for 'amd64' (http://deb.debian.org/dists/stretch/main/installer-amd64/current/images/MD5SUMS). The URL should have a leading 'debian/' in the path, ie http://deb.debian.org/dists/stretch/main/installer... I don't know if this is just some mirrors or everywhere, but not having it resulted in an error for me (it resolved to cdn-aws.deb.debian.org) Thanks, -- Matt Taggart tagg...@debian.org
Bug#775904: di-netboot-assistant should verify the downloaded files
I added this bug to the list of issues with securely downloading things from the archive at https://wiki.debian.org/Hardening/RepoAndImages It might be interesting to think about these problems together, maybe some of them can be solved in more general (or at least consistent) ways. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150703003923.b0597...@taggart.lackof.org
Bug#789247: di-netboot-assistant: consider using httpredir service
Package: di-netboot-assistant Version: 0.38a+nmu1 Severity: wishlist Now that the httpredir service exists, http://httpredir.debian.org/ it might be nice to have d-n-a's di-sources.list point at that by default. I tried changing http://ftp.debian.org/ to http://httpredir.debian.org/debian/ and it worked fine for me. I also asked Raphael Geissert if this would be an appropriate use and he said, Yes, all mirrors are expected to have the installer dirs for a given arch whenever they claim they mirror that architecture. If you ever encounter any such mirror it should be considered a bug and a reason enough to take them off the pool until they fix it. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150619061528.6e34e...@taggart.lackof.org
Bug#773274: more d-i encryption testing
I had some time to try a couple more tests for #773274 and observed a few more things. * In my set of steps to repeat the bug I said to setup two partitions for encryption. I just tested and it doesn't seem to matter if one of them is going to be for swap (which d-i defaults to if you choose random passphrase). I'm not sure if that's relevant but I thought it was worth mentioning. * If I only initially create one encrypted partition, set it up and mark it for LVM, then set LVM up, there is no segfault upon returning from LVM. Then I can proceed to setup additional encrypted volumes and it appears to work until I finish partitioning and then I get the segfault. So I think this means it has something to do with whatever parted_server is doing when it reinitializes while more than one encrypted partition is present. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141219110523.1c2e1...@taggart.lackof.org
Bug#773274: installation-reports: parted_server segfault
Package: installation-reports Version: 20141216-00:08 When attempting an install using a daily image, I ran into a case where parted_server segfaults with the following: parted_server[29651]: segfault at 8 ip 0040b4b1 sp 7fff5d7c54c0 error 4 in parted_server[40+12000] I tried it several times and attempted to distill it down to the simplest case I could. To repeat: 1) create a partition and mark it for encryption 2) configure encryption, set it up (don't erase to save time, but that doesn't matter), finish encryption 3) mark newly created encrypted volume as for LVM 4) configure LVM, create a volume group and a logical volume, finish The menu will freeze at Detecting filesystems and the above error is in syslog. Setting up LVM on a non-encrypted disk works just fine, I didn't see the problem unless it was encrypted. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216102441.e06e5...@taggart.lackof.org
Bug#773274: parted_server segfault
I spent some more time repeating the bug and realized I was missing a detail and I also distilled the test further. Here are the new steps: 1) create two partitions, mark them both for encryption, accept their encryption settings 2) run Configure encrypted volumes, create the 2 volumes, finish 3) After returning from #2, mark the first encrypted volume as for LVM, leave the second to it's default of ext4 4) Configure LVM, create vg, mark the first encrypted volume as a pv, finish. It attempts to go back to the partitioner and then the partman_server segfault happens with the menu hung on Detecting file systems. Also, I determined a few other things * It's not necessary to create an lvol, just the vg with the encrypted pv is enough. * Encryption settings don't seem to matter * I tried erasing the partition contents in case something in them was causing problems Hopefully that is clear and someone is able to repeat the bug, let me know if I need to explain more or if you have questions. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216113256.5fb38...@taggart.lackof.org
Bug#773274: installation-reports: parted_server segfault
Cyril Brulebois writes: Please specify the image you used, and please attach your syslog. amd64 netboot Debian version: 8 (jessie) Installer build: 20141216-00:08 I don't have syslog right now, I'll have to repeat the problem again and send it later. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216172940.821e9...@taggart.lackof.org
Re: di-netboot-assistant_0.38a~bpo70+1_amd64.changes is NEW
Cyril Brulebois writes: I don't see any wheezy-backports branch in git, please push. No changes were necessary other than the changelog. Do you want me to make a branch with just that? Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929221623.d1d47...@taggart.lackof.org
Bug#756275: testing pxe d-i in different cases
Hi, I did some testing with the daily build from 2014-09-29 which includes the changes KiBi committed for this bug. 1) unpacked daily case wheezy server unpacked daily tarball in foo/ ldlinux.c32 symlinux present boot foo/pxelinux.0 everything works as expected 2) di-netboot-assistant daily case wheezy server di-netboot-install installed daily, which does * moves debian-installer/amd64 to debian-installer/daily/amd64 * copies debian-installer/amd64/pxelinux.0 to debian-installer/pxelinux.0 * no ldlinux.c32 symlinux boot debian-installer/pxelinux.0 gets 'Failed to load ldlinux.c32' (as expected) 3) chain wheezy to d-n-a daily case wheezy server, syslinux-common 2:4.05+dfsg-6+deb7u1 installed cp /usr/lib/syslinux/pxelinux.0 tftpboot/ have a pxelinux.cfg/default that also contains: INCLUDE debian-installer/pxelinux.cfg/default boot pxelinux.0, select daily-amd64 gets ::/debian-installer/daily/amd64/boot/screens/vesamenu.c32: not a COM32R image (this is a known failure mixing 4.x with 6.x, see #759424) 4) chain wheezy+6.03 to d-n-a wheezy server, setup 6.03+ldlinux.c32 in tftpboot have a pxelinux.cfg/default that also contains: a menu section that uses menu.c32 INCLUDE debian-installer/pxelinux.cfg/default I ran into problems with menu.c32/vesamenu.c32 not being able to find libutil.c32 and libcom32.c32. It seems that sometime after wheezy (probably 6.0x?), syslinux-common (and d-i) switched to using dynamic versions of these things, so you can't just point at things like you used to be able to. You can use the new PATH variable (introduced in 5.00+) to set the search path and it looks like debian-installer/amd64/boot-screens/syslinux.c fg is doing this which is good (but that hadn't loaded yet in my chaining experiment). That solves loading modules after pxelinux loads and reads it's config, but it can't solve finding ldlinux.c32. Would it be too much to ask to have ldlinux.c32 static like before? The current pxelinux.0 is 43k and ldlinux.c32 is 117k, so while it would more than triple the size, it's still not big (I'm not sure what the space constraints are, if any). di-netboot-assistant is probably going to need to be fixed (unless pxelinux.0 is switched to contain ldlinux.c32). -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140930010653.e0453...@taggart.lackof.org
Bug#763021: di-netboot-assistant: support for use in a build environment
Package: di-netboot-assistant Version: 0.38a Severity: wishlist Related to #503359 which added support for running d-n-a as a non-privileged user, I would like support for running as part of a build environment that creates a root of d-i images to be used on a tftp server, usb stick, etc. My goal is to have this build environment in a git repo and have a user clone it on their system and do a build. dkg's original patch using a DI_NETBOOT_ASSISTANT_CONFIG environment variable was actually better in that regard since one could easily override it in build scripts. But I do also like the way #503359 was implemented to look for a ~/.di-netboot-assistant. But the other issue I am running into when trying to create this build environment is absolute paths for things like DL_CACHE and STATUS_LIB. Since I can't know what directory the build will be in, I need some way for these to be relative (or have to resort to complicated hacks). So how about this? 1) a way to override the root of d-n-a variables * if an environment variable is set (DNA_ROOT?), use that as the root for other variables, otherwise check for ~/.di-netboot-assistant and then /etc/di-netboot-assistant * if the variable was set or ~/.di-netboot-assistant was found have the following change to be relative to the root DISOURCELIST, DL_CACHE, STATUS_LIB, and possibly TEMPLATES, and TFTP_ROOT 2) a way to override just the config, like dkg's DI_NETBOOT_ASSISTANT_CONFIG and that would allow for other overrides in addition to the above Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927073338.80322...@taggart.lackof.org
Bug#725750: works in rescue
Regarding the udev claiming NICs twice problem I reported in #725750.. I booted d-i in non-preseed mode (in rescue to be specific) and the problem didn't happen. So it seems to be preseed specific, but I think it has to be specific to the boot cmdline because the network fails to come up so it hasn't yet fetched the preseed file. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131009002838.6587f...@taggart.lackof.org
Bug#725750: installation-reports- daily claiming NICs twice
Package: installation-reports
Version: 20131007
I booted a d-i daily on a system and it fails automatically setup the
network with DHCP. When I drop to a shell and look around I found that
udev is claiming the NICs twice.
Here is the contents of 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x1533 (igb)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:25:90:XX:XX:1c, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth0
# PCI device 0x8086:0x153a (e1000e)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:25:90:XX:XX:1d, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth1
# PCI device 0x8086:0x153a (e1000e)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:25:90:XX:XX:1d, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth2
# PCI device 0x8086:0x1533 (igb)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:25:90:XX:XX:1c, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=eth3
(MACs modified with XXs, but those are the same across entries).
The first port (MAC :1c, DID 1533) is handled by igb and second port
(MAC :1d, DID 153a) by e1000e, but udev duplicated the entries.
Thanks,
--
Matt Taggart
tagg...@debian.org
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131007233458.5ce8f...@taggart.lackof.org
Bug#725750: more info
Oh I forgot to include some important details. The image I am using is an amd64 netboot daily image from 20131002. The system uses a Supermicro X10SLM-F mainboard, details at http://www.supermicro.com/products/motherboard/Xeon/C220/X10SLM-F.cfm I PXE boot the image with the following options append auto locale=en_US keymap=us interface=eth0 \ console=ttyS1,115200n8 url=10.0.1.XX preseed-md5=deleted -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131007235319.7a2f9...@taggart.lackof.org
Bug#716978: initramfs not setting up crypto
Ben Hutchings writes: That's strange. The LVM tools are added by /usr/share/initramfs-tools/hooks/lvm2 which is part of the lvm2 package. So this implies lvm2 wasn't installed either, though that seems unlikely. I found the LVM problem (and possibly the crypt problem). My preseed setup was installing a sources.list that pointed to squeeze rather than wheezy and I think that prevented lvm2 from getting installed. It may have also caused the initramfs to not get the crypto modules, but I suspect it's more likely that using the minimal module setting caused that. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130816220212.3887b...@taggart.lackof.org
Bug#716978: initramfs not setting up crypto
Ben Hutchings writes: On Mon, 2013-08-05 at 16:31 -0700, Matt Taggart wrote: I think I am seeing the same bug reported in #716978... =20 I just did an install of wheezy using a d-i daily (updated today 2013-08-05). The root is md raid-crypt-lvm. Upon boot the initramfs started up the md raid devices properly, but failed to setup the crypto and dropped to an initramfs shell. When I poke around I see that =20 /lib/modules/3.2.0-4-amd64/kernel/crypto/ =20 is lacking most of the crypto modules (including the xts/serpant/etc that my system needed). So I am unable to bring things up by hand either. =20 During the install, for the question about how much to include in the initramfs, I picked the just what's needed by this system answer, although I think that should have been OK. I doubt we'll ever be able to get it completely right. That option should be warned against in general. It is useful for machines with limited memory or space for the initramfs (e.g. ARM systems where the bootloader looks for it in a specific flash partition). Otherwise it just saves a fraction of a second of boot time, or fails to boot. I used d-i rescue mode to mount the disks and switch from dep to most mode for update-initramfs and that pulled the crypto modules in. But now the problem is that the LVM tools aren't in the initramfs so it gets stuck at that point. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130806171758.2a97e...@taggart.lackof.org
Bug#716978: initramfs not setting up crypto
I think I am seeing the same bug reported in #716978... I just did an install of wheezy using a d-i daily (updated today 2013-08-05). The root is md raid-crypt-lvm. Upon boot the initramfs started up the md raid devices properly, but failed to setup the crypto and dropped to an initramfs shell. When I poke around I see that /lib/modules/3.2.0-4-amd64/kernel/crypto/ is lacking most of the crypto modules (including the xts/serpant/etc that my system needed). So I am unable to bring things up by hand either. During the install, for the question about how much to include in the initramfs, I picked the just what's needed by this system answer, although I think that should have been OK. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130805233139.23204...@taggart.lackof.org
Bug#505738: di-sources.list for recent ubuntu release
I talked with dannf@canonical and I _think_ this is a good list of ubuntu releases to go in di-sources.list. I split them into LTS and normal sections as I think that will make it easier to maintain. (but feel free to reorder if you like) Patch against 0.37 attached. Thanks, -- Matt Taggart tagg...@debian.org --- di-sources.list 2011-05-10 18:00:32.0 -0700 +++ di-sources.list.new 2013-06-28 11:51:36.0 -0700 @@ -77,20 +77,34 @@ #Â Some Debian Derivatives # -#Ubuntu Dapper Drake 6.06 -dapper i386 http://archive.ubuntu.com/ubuntu/dists/dapper/main/installer-i386/current/images/ netboot/netboot.tar.gz -dapper amd64 http://archive.ubuntu.com/ubuntu/dists/dapper/main/installer-amd64/current/images/ netboot/netboot.tar.gz - -#Ubuntu Hardy Heron 8.04 +## Ubuntu LTS Releases +# Hardy Heron 8.04 hardy i386 http://archive.ubuntu.com/ubuntu/dists/hardy/main/installer-i386/current/images/ netboot/netboot.tar.gz hardy amd64 http://archive.ubuntu.com/ubuntu/dists/hardy/main/installer-amd64/current/images/ netboot/netboot.tar.gz -#Ubuntu Intrepid Ibex 8.10 -intrepid i386 http://archive.ubuntu.com/ubuntu/dists/intrepid/main/installer-i386/current/images/ netboot/netboot.tar.gz -intrepid amd64 http://archive.ubuntu.com/ubuntu/dists/intrepid/main/installer-amd64/current/images/ netboot/netboot.tar.gz - -#Ubuntu Jaunty Jackalope 9.04 -jaunty i386 http://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/ netboot/netboot.tar.gz -jaunty amd64 http://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-amd64/current/images/ netboot/netboot.tar.gz +# Lucid Lynx 10.04 +lucid i386 http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-i386/current/images/ netboot/netboot.tar.gz +lucid amd64 http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/ netboot/netboot.tar.gz + +# Precise Pangolin 12.04 +precise i386 http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-i386/current/images/ netboot/netboot.tar.gz +precise amd64 http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/ netboot/netboot.tar.gz + +## Ubuntu Normal Releases +# Saucy Salamander 13.10 +saucy i386 http://archive.ubuntu.com/ubuntu/dists/saucy/main/installer-i386/current/images/ netboot/netboot.tar.gz +saucy amd64 http://archive.ubuntu.com/ubuntu/dists/saucy/main/installer-amd64/current/images/ netboot/netboot.tar.gz + +# Raring Ringtail 13.04 +raring i386 http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-i386/current/images/ netboot/netboot.tar.gz +raring amd64 http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-amd64/current/images/ netboot/netboot.tar.gz + +# Quantal Quetzal 12.10 +quantal i386 http://archive.ubuntu.com/ubuntu/dists/quantal/main/installer-i386/current/images/ netboot/netboot.tar.gz +quantal amd64 http://archive.ubuntu.com/ubuntu/dists/quantal/main/installer-amd64/current/images/ netboot/netboot.tar.gz + +# Oneiric Ocelot 11.10 +oneiric i386 http://archive.ubuntu.com/ubuntu/dists/oneiric/main/installer-i386/current/images/ netboot/netboot.tar.gz +oneiric amd64 http://archive.ubuntu.com/ubuntu/dists/oneiric/main/installer-amd64/current/images/ netboot/netboot.tar.gz # vim: ft=disources
Bug#714397: di-netboot-assistant: update di-sources.list
Package: di-netboot-assistant Version: 0.37 di-sources.list needs to be updated: * remove etch (and probably lenny too) * add squeeze and wheezy * not sure if jessie should be added yet, but probably soon * drop some archs that aren't supported anymore Also, once it's updated (and maybe if #505738 is fixed too) it would be nice to have backports to squeeze and wheezy, I can do those if you like just let me know. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130628200751.96c12...@taggart.lackof.org
Bug#709648: netcfg: rerunning netcfg after preseeding no longer works as expected
Package: netcfg Version: 1.108 As described in the install guide section B.4.2 http://www.debian.org/releases/wheezy/amd64/apbs04.html.en#preseed-network if you want to change the network settings after the initial boot and preseed loading, then you can use the work-around of kill-all-dhcp; netcfg I successfully used this method with squeeze d-i in the past, but in attempting to use it with wheezy I have run into problems. The system in question has multiple NICs plugged into multiple networks. The device 'eth0' is the public facing network, while my DHCP/tftp/PXE/http server for preseeding is on a private network (in this case 'eth4'). I am using 'interface=eth4' as a boot parameter and d-i successfully boots, brings up that interface with DHCP, loads the preseed and early_script and runs the work-around. On the console netcfg restarts. But rather than attempting to configure eth4, it configures the first NIC that it detected link for which is eth0. So the result is both eth4 and eth0 are up (and on the same subnet, which is wrong for eth0). In squeeze this worked, after netcfg restarted it would prompt me for the IP address (which I deliberately did not set) and properly preseeds the netmask/gateway/etc (which I did). Maybe the recent changes for link detection are causing this? Long term I'd like to see this fixed, but if there is any way to work around the problem that would be acceptable for the time being. Maybe there is some way of giving netcfg a hint of which device to use, or to disable the link detection stuff to prevent it using eth0. Let me know if I can test anything or help in any other way. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130524183714.5fa9e...@taggart.lackof.org
Bug#709648: netcfg: rerunning netcfg after preseeding no longer works as expected
More info on #709648 ... I discovered that both my squeeze and wheezy preseed files contained d-i netcfg/choose_interface select auto Maybe this is why, after loading the preseed file, wheezy decides to use eth0. I guess the behavior in squeeze was to keep the value set on the boot line and in wheezy it can be changed with preseed (which I guess is an improvement). So I don't think there is a bug here after all, just a behavior change that caught me. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130524190503.7c794...@taggart.lackof.org
Bug#505738: ubuntu sources out of date
The di-netboot-assistant ubuntu sources are out of date. Please add the latest and clean up the old (non-still-in-support-LTS) ones. (I'd have provided a patch, but I don't know what they are but I am guessing an ubuntu person could fill them in quickly) Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130515194935.860ed...@taggart.lackof.org
Bug#482092: partman-crypto: xts support
Bastian Blank writes: We only want to support plain64 for Wheezy. I assume you mean for wheezy we just want the d-i partman-crypto UI to support selecting xts-plain64 and not xts-plain? The kernel support will still be there and you'll be able to mount an existing xts-plain based filesystem (or create one by hand in a shell) right? The ability to do so is still interesting for rescue purposes. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628202702.96db...@taggart.lackof.org
Bug#482092: partman-crypto: xts support
Hi #482092, I am pinging this bug because I would really like to see xts in wheezy. We (riseup.net) have been using serpent:xts-plain for our systems for both lenny and squeeze and it works great. Until now we have had to do some hacking to get d-i to set it up, * drop to a shell * wget the xts.ko and gf128mul.ko modules in the right dir * verify the md5sums of the modules * depmod -a;modprobe xts * echo cbc-essiv:sha256 cbc-plain plain ecb xts-plain /lib/partman/ciphers/dm-crypt/ivalgorithm We even hacked up a preseed early command hack to set this up because it was such a hassle. I think the xts kernel module (and hopefully the gf128mul module since it's a dependency?) are already included if I read this right, http://anonscm.debian.org/viewvc/kernel/dists/sid/linux/debian/installer/modules/crypto-modules?revision=19065view=markup If so, then I think all that's needed is to add xts-plain to debian-installer/packages/partman-crypto/ciphers/dm-crypt/ivalgorithm Sound correct? Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120622233011.94677...@taggart.lackof.org
Bug#436785: partman: relatime default
According to #481653, relatime became the default option starting in 2.6.30. So hopefully partman desn't need to do anything. There is the page in manual partitioning that let you select options. Probably that page should indicate relatime is the default and also have the atime and noatime options available (I don't know if strictatime and nostrictatime are needed). -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120424204041.94e4...@taggart.lackof.org
Bug#436785: partman: mount options
Thanks to elmig in #debian-boot here is a list of current mount options
on the manual partitioning page
noatime, relatime, nodev, nosuid, noexec, ro, sync, usrquota,
grpquota, user_xattr
Since relatime is the default now, I think at least having an atime
to override that is needed. relatime could also go away given that
there is no async, exec , etc.
Here are some other things that might be useful to adjust (but some
might give users enough rope to hang themselves and be better changed
by editing fstab)
nodiratime - this option is implied by noatime (but I don't know if
it's implied by relatime). I don't know what the default is.
nobarrier - Barriers are on by default, and you'd probably only disable
them if you don't care about your data (which you might not depending
on what the server is used for)
data={journal|ordered|writeback} - ordered is the default
commit - number of seconds data/metadata should be sync'd, default is 5.
(variable, not a on/off thing)
{min|max}_batch_time - controls how ext4 batches up writes. (variable,
not an on/off thing)
For some of these it might not make sense to have them on the same
checklist page, and maybe some are only available via preseeding.
--
Matt Taggart
tagg...@debian.org
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120424213350.9fd4...@taggart.lackof.org
Bug#623273: netcfg: way to start web and ssh via preseed
Package: netcfg Version: 1.59 Severity: wishlist I am filing this against the netcfg package, but it might be more appropriate elsewhere, please clone/forward as needed, thanks. I am attempting to debug a preseed install on serial console and I can't just switch to another VC to get the log or run a shell. If I could access the built-in webserver to access the logs or ssh to run a shell and poke around, that would help a lot. I would like a way from the cmdline (or in a preseed file) to start the webserver and/or ssh. I guess if set it should start these things as soon as the network is available. Although in my case I use a dhcp config to grab the preseed and then I use the trick documented in the manual to rerun netcfg so I can specify a static config. So I guess maybe these things should be (re)started at the end of each netcfg run? For ssh you might still want to display the host fingerprint on the screen and have the user ack that (which could maybe be skipped by setting a seen variable to true?). Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418214959.986b2d6...@taggart.lackof.org
Bug#623273: ways to preseed web/ssh
Some hints from #debian-boot joeyh taggart: you can use preseed/early_command -- when doing url preseeding the network will be up then joeyh just anna-install save-logs joeyh and also, preseed save-logs/menu=web joeyh and that should do it -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418221140.30bd5d6...@taggart.lackof.org
Bug#267838: netcfg: DHCP installer - STATIC target
This wishlist bug seems like a pretty small corner case. First let me restate it to make sure I understand correctly. You want d-i to do a dhcp request but then use the answers to define a static config. Does that sound right? I guess I can understand wanting to do that, maybe you don't want to depend on the dhcp server being up all the time. But if implemented in the way you mention Do you want to use the dynamic answers you received as static values? seems like a violation of the nature of DHCP and would hurt more users than it would possibly help. I have a similar use case, I want to use a throw away dhcp assigned address during boot and to load the preseed, but then I want to switch to a static config. I use the preseed_run script idea documented in the d-i manual to cause netcfg to rerun. Then later in the preseed I define the network parameters. http://d-i.alioth.debian.org/manual/en.amd64/apbs04.html#preseed-network This could work for your case, but normally this would then mean you would need one preseed per system, but maybe you could use the early_command or include_command functions to save the dhcp answers and set them? http://d-i.alioth.debian.org/manual/en.amd64/apbs05.html#preseed-hooks I think this bug might be wontfix. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110411230419.5c24a1a9...@taggart.lackof.org
Bug#257883: netcfg: Please offer to configure all network interfaces
Regarding #257883, netcfg: Please offer to configure all network interfaces (wow old bug!) I would also like d-i to let me configure multiple network interfaces. It would be nice if it prompted in expert mode, but since I'm already using preseeding I'd settle for a way to configure additional interfaces using late_command or something. Maybe netcfg could have a flag to indicate you were configuring an additional interface and not to step on the original config? In case it's useful here's my use case: All our machines have two networks, a public network and a private network. To install I pxe boot a machine using the private network and it gets a throw-away dhcp IP, then loads the preseed file. Then I use the preseed/run trick mentioned in the manual to cause netcfg to run again and prompt me for the real static config of the private network. Then it finishes the install using that new config, but I'd also like to configure the public network before rebooting. Also potentially tricky is after configuring the public network I want the default gateway to be on the public network. Work-arounds welcome. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110411234440.bd8031a9...@taggart.lackof.org
Bug#621393: debian-installer: checksum cmdline alias
Quoting Otavio Salvador (ota...@ossystems.com.br): maybe; the problem of using checksum is the many possibilities it has as: =20 - preseed file checksum; - initrd checksum; - iso checksum; - ??? checksum? Matt, any comment? How about something like preseed-md5 or di-md5? -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110409041615.d800c1b1...@taggart.lackof.org
Bug#621393: debian-installer: checksum cmdline alias
Package: debian-installer Version: 20110406 Severity: wishlist I would like a kernel command line alias named checksum that does the same thing as preseed/file/checksum. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110406224935.957371a9...@taggart.lackof.org
Bug#621400: debian-installer: keymap alias
Package: debian-installer Version: 20110406 Severity: wishlist Hi, I would like a kernel command line alias named keymap that means the same as console-keymaps-at/keymap. In particular this one (AFAIK) has to be specified when using preseeding since this question gets asked before the preseed loads. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110406231552.e053d1a9...@taggart.lackof.org
Bug#286578: coexisting d-i
Regarding the coexisting of different archs and versions in the netboot tarballs (#286578), I just discovered the existence of the di-netboot-assistant package. Among other things it appears to work around the problem of netboot tarballs not existing by creating it's own top level hierarchy. I think this bug should still be fixed in the netboot tarballs produced by d-i. Once it is then di-netboot-assistant (and any other netboot management code/wetware working around this problem) can be simplified. I was shocked to see this bug recently celebrated it's 6th anniversary! -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110119205144.b0119d6...@taggart.lackof.org
Bug#434034: memtest boot options
Regarding Russell's previous comment in #434034 about memtest86+ boot options 1) The memtest86+ ships with two versions, one for grub2. See /usr/share/doc/memtest86+/README.Debian for more info. 2) It does support some options, for example to boot serial console=ttyS0,115200n8 I use d-i in serial mode often and it works well, it would be nice to also be able to boot memtest86+ in serial mode as well. For me 95% of the time the above console line is what I need, but I do have some cases where I need different settings, so being able to specify them would be good. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110119225427.c0422d6...@taggart.lackof.org
Bug#392480: debian-installer: add support for cleaning hard drives
Well this assumption (to encrypt the disc afterward) is not necessarily valid. A company is giving away computers to a school or for use for children, where no encryption is needed. They require you to wipe the drive. (Ok, they should do it themselves to be on the safe side of things, but in reality things are different.) BTW something like Dan's Boot and Nuke is an option for this case too. But like I said in a previous mail it would be convenient if d-i could do this as I usually have d-i disks laying around :) If such a udeb exists and the additional option is too much work, could you please point me to a howto where the handling of udeb-files is described, so I can unpack it manually. BTW, not a udeb but I did publish instructions on how to use shred http://lackof.org/taggart/hacking/d-i-tricks/#shred -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481653: debian-installer: relatime status?
What is the status of having d-i install systems with relatime? Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286578: netboot tar paths
Having versioned paths in the netboot tarball, as described in #286578 would still be useful and I'd like to see it in lenny. In addition maybe there is a way of setting up the pxe symlinks so that multiple arches can coexist. Thus the end goal is to be able to unpack multiple versions of multiple arches on the same tftpboot and have them coexist cleanly and only need slightly different lines in the dhcp config. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481653: use relatime for default install
Package: debian-installer Version: 20080517 It is rumored that Colin Watson is working on adding support for using relatime to d-i. I couldn't find anything in the bts, so I am filing this bug to track the progress of this support and namely using relatime for the _default_install_. Here is the info I've been able to find on the subject LWN summary of lkml thread http://lwn.net/Articles/244829/ Kerneltrap summary of lkml thread http://kerneltrap.org/node/14148 ubuntu installer work https://bugs.launchpad.net/ubuntu/+source/linux/+bug/199427 busybox relatime work http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460824 relatime support was listed as added but broken in the lenny beta 1 announcement http://www.debian.org/devel/debian-installer/News/2008/20080317 and errata page http://www.debian.org/devel/debian-installer/errata mount support for relatime http://lkml.org/lkml/2006/8/25/380 I'm not sure if the improved relatime patch is in upstream/debian kernels yet. HTH, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292513: grub-installer: installing grub to multiple disks
The request in #292513 to be able to install on both disks in a raid1 array can be accomplished with preseeding. Here are the relevant lines from the example preseed (http://www.debian.org/releases/etch/example-preseed.txt) # To install grub to multiple disks: #d-i grub-installer/bootdev string (hd0,0) (hd1,0) (hd2,0) There are several methods of preseeding this variable including just setting it on the boot line. More info in the installation-guide (appendix B) at http://www.debian.org/releases/stable/i386/apb.html.en It might still be nice if, in the case of doing raid installs, d-i could prompt the user to ask if they wanted to install grub on multiple disks. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317606: grub-installer: determining drive to install to
I have just merged 7 bugs (#283312 #226758 #418535 #306977 #275262 #249049 #317606) that all have to do with grub-installer installing to the disk it determines is (hd0) even though that might not be the disk the user installed Debian on, or they wanted to install it to some other location. Of these bugs #283312 appears to have to most useful info, that's probably the best place to send future info. There was one bug that was related, but different enough that I decided not to merge it. Anyone looking at implementing a fix for this bug should also check out, #292513 - install to multiple disks in raid installs maybe that could be fixed at the same time. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283312: grub-installer: way to specify same drive as install
Similar to this bug and the 6 others merged with it, I also have a situation where grub-installer picking (hd0) is not what I want. Here are some details: I am using d-i preseeding on a system that has both a cciss raid controller and a fiber channel controller (appears as scsi). I specify which disk I want to be partitioned/installed using something like: d-i partman-auto/disk string /dev/cciss/c0d0 But when grub enumerate the disks (hd0) ends up being one of the scsi disks and grub tries to install there (and fails in my case since the disk isn't setup). I would like a way to tell grub please install to the same disk as was partitioned and used for the install. Now of course you might be partitioning and installing to multiple disks, so I guess maybe you want to be able to say install on whatever disk /boot is on or something like that. For now the work around for this problem (at least using preseeding) is to hardcode the device grub installs to with something like: d-i grub-installer/bootdev string (hd4) or d-i grub-installer/bootdev string /dev/cciss/c0d0 but that is problematic since if you are trying to use the same preseed on machines of differing hardware, differing amounts of controllers/disks will cause those names to change. Better for d-i to record what did it used and then use that. I don't know what the patch to do this would look like but I expect that the interface to use it would look something like: d-i grub-installer/bootdev string bootdisk d-i grub-installer/bootdev string rootdisk or if you didn't want to overload that existing variable, invent a new one. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433875: example preseed, grub info
Package: installation-guide Version: 20070319 Severity: wishlist Due to the way grub does device ordering (see my comments sent to #283312), I needed a way with preseeding to hard code the device that grub installs to, rather than count on grub's (hd#) naming. The existing example preseed file has the following: #d-i grub-installer/bootdev string (hd0,0) # To install grub to multiple disks: #d-i grub-installer/bootdev string (hd0,0) (hd1,0) (hd2,0) After reading the code I discovered that you can just as easily use a device instead of the grub naming. Can you please add an additional example to the example preseed file, maybe something like # To hard code to a particular device: #d-i grub-installer/bootdev string /dev/sda Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288034: #288034 dl360g3 2.6 booting problem
Tyler, In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288034 you report problems booting the 2.6.8 kernel on an older d-i on a dl360g3. This is known to be working in more recent kernels/d-i's so you might want to try it again and report back if it works. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369048: 369048 ping
Hi Olivier, As you requested this is a ping regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369048 Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#269446: #269446 installing on proliant dl360g1
Hi Clint,
Since this bug was filed there have been fixes in both grub/lilo and in the
kernel that should fix this.
* There were a couple grub bugs, I don't have the references offhand. IIRC
there was one with the device.map not getting written with the proper
/dev/{ida,cciss}/ path and another about some weird s:!:/: thing. Maybe more,
anyway all should be working now.
* Based on the fact that a 2.6.8 with the raid driver built-in fixed it, I
think you were seeing #380272 which was fixed in linux-2.6/2.6.17-8. This fix
is also now in the lastest d-i builds so installs work fine. I filed an
installation report for a similar machine at #404999.
* I'm not sure if the 2.4 thing is fixed. IIRC you can work around it with
noapic/nolapic/noacpi/nosmp or something like that. But who cares about 2.4
these days... Anyway those that do should install with 2.6 and try a newer 2.4
kernel in the archive.
--
Matt Taggart
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392480: debian-installer: add support for cleaning hard drives
David =?iso-8859-1?Q?H=E4rdeman?= writes... If you are concerned with the safety of your personal data being left from a previous installation, I assume you're also (and even more so) worried about your personal data being kept safe in the new installation? If so, I'd assume that you'd do an install to an encrypted partition...and if you do, debian-installer (or partman-crypto to be more precise) will already wipe the disk with one round of random data. That should be sufficient for anything but the worst tin foil hat scenarios. I recently discovered that Peter Gutmann added an Epilogue to his original paper, http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html (search for Epilogue) or reprinted at http://www.forensicswiki.org/wiki/Epilogue_to_Gutmann's_1996_paper in it he explains that with modern drives, a few passes of random data is the best you can hope to do. I think your suggestion of using partman-crypto to wipe the disk with one round of random data is probably OK. I haven't tried using it yet, can you do this step without also creating a new crypto filesystem on the disk as well? Ideally you could just do the wipe only so if you were just trying to clean the disk you could stop there and not bother to put anything else on it(for cleanliness reasons, not because of the time/cpu it takes to generate the new filesystem). So I consider the wishlist to be able to wipe the disk closed, but I'd like to be able to do it without also creating a new filesystem if possible (this could be in expert mode of course). Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399805: partman: ability to run outside of d-i
Package: partman Version: 63 Severity: wishlist I had a user ask me the other day if it was possible to run the d-i partitioning tool after the install to setup additional disks. I told him I didn't think so and asked why he didn't use parted or gparted. He replied that this was on his server(so no graphics libs installed) and that he really preferred the d-i interface anyway. That seemed like a reasonable answer to me. So that's what you get for doing such a good job on the partitioner :) This is a wishlist request for the d-i partitioner to be made to run stand-alone outside of d-i on the normal system. (This might also be nice for other things that d-i does as well, joeyh mentions that kamion did this already for user-setup.) Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355713: hp ml350 install report
Hi Swen, Thanks for filing the Debian installation report for the HP ML350 system http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355713 You mention in the report that you were using a sarge version of the installer. I think the grub install on smartarray drive failure you are seeing is a known one that got fixed after the sarge release. Unfortunately I'm not sure if the official sarge installer will ever be fixed to work on this system :( You do have some other options though, 1.) If you need sarge... a.) dann frazier has been producing a custom version of the sarge debian-installer that works for more ProLiant systems(including newer systems). See http://wiki.debian.org/HP/ProLiant#hpde b.) There were a couple smartarray related bugs and I can't remember which you are seeing, but for some systems (mainly older ones that don't also require a newer kernel driver) there might be a workaround you can do at install time by dropping to a shell at the right time and fixing by hand. ISTR in one case you just needed to tweak a path in /boot/grub/device.map to be /dev/cciss/c0d0. Maybe dannf remembers if there is a workaround for making the sarge installer work on ml350? 2.) If you can use etch, I think all recent versions of d-i should work. If you try one please submit an installation report and add your system to the wiki page listed above. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392480: debian-installer: add support for cleaning hard drives
Package: debian-installer Version: 20061011 Severity: wishlist I would like to see the ability to clean hard disks (by securely overwriting all blocks) added to debian-installer. When I reuse a hard disk (or before I get rid of one), before I install I like to clean all data off the drive by overwriting it. My reasons for doing so are, 1.) There may be sensitive data still on the disk, that if someone compromised the system or physically obtained the disk (especially in the case of laptops) they might be able to collect. It is good to start from a known clean state knowing that only the data you put on the drive is there and you can take precautions to protect it. 2.) If a system is compromised (either by an attacker, a user error, or a partial drive failure), any remnants of old data will hinder any forensics analysis of the drive. If you are starting from a state of known contents (all the blocks set to a particular pattern or at least random) then you can find deleted logs/files/etc. The ability to do this is becoming increasing more important as we are beginning to see with the problems of large companies/institutions losing people's personal data and the resulting identity theft and fraud. This could be a neat feature that Debian introduces first. I recently did some searches to determine the best way of doing this. While a simple dd might work for most cases, I had heard that some attackers currently have the ability to read up seven writes back, so I thought there might be a better way. Most things I found while searching cited a canonical paper, Secure Deletion of Data from Magnetic and Solid-State Memory Peter Gutmann [EMAIL PROTECTED] https://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutma nn/ There are also some government standards for wiping disks, American DoD 5220-22.M ( http://www.dss.mil/isec/nispom_0195.htm ) Canadian RCMP TSSIT OPS-II I found a few good solutions available in Debian already * shred - part of coreutils package, doesn't mention the Gutmann paper, but seems to use a similar technique. * wipe - Uses the techiniques recommended by Gutmann, read the man page for fun, it's pretty tin-foil-hat which frankly is how I like my security tools authors :) Just for those interested a few additional data points, * Darik's Boot and Nuke is a bootable iso that supports all the best methods of doing this. http://dban.sourceforge.net/ * MacOSX includes a secure deletion utility called srm. Their recycle basket desktop feature has the ability to do a secure empty I have been using d-i to do this already by bringing up the network and then dropping to a shell and wget'ing shred. Then I run something like, ./shred -v -u -n 10 /dev/sda That takes maybe an hour for an 18gb u160 10k rpm scsi disk and scales linearly as you go up (ie 4x that for a 72gb disk). If the machine has multiple disks I run several of them in parallel, and that seems to run in the same time it takes one (ie they are disk bound). I think this feature could be really useful for a lot of people, although probably only available in expert mode. What do you think? Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391513: installation-report: hp lp1000r
Matt Taggart writes... * This machine uses a PCI NetRAID 2m hardware raid controller (megaraid card). I will also try to install without this card using the integrated scsi controller and will file a separate report. That report is #391645. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369048: lp1000r keyboard freeze
Hi Olivier, In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369048 you report seeing keyboard freezes on an lp1000r. I have just done a couple installs of an lp1000r using a PS2 keyboard (the reports are at #391513 and #391645) and it seemed to work for me. Maybe there was a bug in grub that has been fixed now? If you still have the machine can you try again and see if the problem is gone? Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334402: install report: Compaq Evo
The Compaq Evo installation-report in #334402 seems like a successful installation report other than the system clock thing, which isn't a problem with other current installs right? Anything else still pending in this bug or can it be closed? -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307324: Installation problems with a Compaq Proliant and a Dell Latitude...
Carlo, Thanks for submitting the installation reports in, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307324 Do you still have access to the hardware to test again? (HP ProLiant 1600, Dell Latitude D600, and the laptop you mention in the report) I believe the problems you reported should be fixed and it would be nice to confirm so we can close this bug. If you can, please give it a try and submit new installation-reports (and cc [EMAIL PROTECTED]). Maybe this time do separate reports for each machine as it makes it easier to understand and track any bugs. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307324: duplicate installation-reports for HP Proliant 1600 and Dell Latitude D600
After more investigation, it looks like there are duplicate installation-reports filed by the submitter for the machines mentioned in the still open #307324. HP ProLiant 1600: broken in #304002 using d-i 20050323 and 20050318, closed HP ProLiant 1600: working in #304005 using d-i 20050318, closed Dell Latitude D600: working in #304031 using d-i 20050318, closed Both: broken in #307324 using d-i 20050429, open So at one point both were working and then broke in newer builds. These reports are all so old that I guess we just have to see if the submitter can try something newer. If anyone reading this has access to those machine types and can try an install and file an installation-report and email a pointer to this bug, that would be greatly appreciated. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370398: debian-installer: support testing memory
Package: debian-installer Version: 20060604 Severity: wishlist One of the first things I do before installing a new debian system is run memtest86+ on it for a while. I read somewhere that Ubuntu dapper's new installer has some sort of memory tester (I guess they have isolinux/syslinux launch memtest86+). Has this been considered for d-i? The memtest86+ option is one possibility, but it's i386 specific. Another option might be providing a udeb of the memtester utility. I haven't used it but it appears to be a Linux userspace app and not i386 specific. So that might be a better fit for Debian. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295479: cdrom-detect: change eject to be after the user is told
joeyh, In #295479 you mention remembering writing about a way to not eject the CD at the end of the install. I think maybe you are remembering #295476 which has been implemented and closed? What do you want to do about #295479? Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308894: naming net devices
When I first filed #308894 I was using nameif (from the net-tools package) and /etc/mactab to do my net device naming. But I just learned about the ifrename package (which uses /etc/iftab). Maybe that's the latest way to do it. Or maybe there's yet another method driven by all this new fancy hotplug/udev/dbus/blah type stuff. We should probably look and see what other distros are using. It would be nice to solve this and also get it integrated into d-i. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286578: netboot tarballs should have version in the path somewhere
Package: debian-installer
Severity: wishlist
If netboot tarballs included a version string in the path somewhere then
it would be possible to install several in parallel without extra work.
Maybe something like
debian-installer/i386/${VERSION}/
or
debian-installer/${VERSION}/i386/
where $VERSION could be things like
rc2
daily-20041220
taggart-1.23
etc.
Then you could also have a current symlink a la boot-floppies.
Hmm, the tarball has symlinks that point back into the structure (like
pxelinux.cfg) so those would need to change too, but shouldn't be a
problem. There are probably other issues but they should be easily
found by just trying it.
Thanks,
--
Matt Taggart
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286178: debian-installation-manual: md/lvm partitioning
Package: debian-installer-manual Version: 20041217 Some MD/LVM suggestions 1) The manual (probably in Chapter 6) should explain what order of operations you would probably want to do certain things when partitioning. Operations like, * creating physiscal partitions on the disk * creating MD devices * creating LVM devices Some examples, * While the installer will let you create an MD device out of some existing partitions and then try to re-partition it, it doesn't work. joeyh said there's a bug open for this since d-i shouldn't let you do this. Even if d-i is changed to disallow that, it would be nice to explain that the proper way to use MD arrays is one per filesystem (or possibly LVM on top of an MD array). * Can MD go straight on a raw disk? On a partition? On an LVM device? * Can LVM go straight on a raw disk? On a partition? On an MD device? If d-i ever adds support for crypto layers, that will need to be considered too. 2.) I'm not sure if all combinations of the above work for /boot. It would be good to document what works and explain why you might want to make /boot (and maybe even / ) non-MD/non-LVM partitions. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#269163: Documentation for management devices
As mentioned earlier in this bug, the Compaq integrated Lights Out (iLO) management device can't display the initial isolinux vga framebuffer splash screen, and you have to blindly hit F1 to get back to text. I have also encountered this problem on HP's Integrated Remote Assistant (IRA) management device. Rather than get rid of the splash screen I think we can just document this problem. I propose the following text, If you are installing the system via a remote management device that provides a text interface to the VGA console you may not be able to see the initial framebuffer splash screen upon booting the installer. Examples of these devices include the text console of Compaq's integrated Lights Out (iLO) and HP's Integrated Remote Assistant (IRA). You can blindly press F1 to bypass this screen and view the help text. In some cases these devices will require special escape sequences to enact this keypress, for example the IRA uses Ctrl-F + 1. Once you are past the splash screen and at the help text your keystrokes will be echoed at the prompt as expected. To prevent the installer from using the framebuffer for the rest of the install, you will also want to add debian-installer/framebuffer=false to the boot prompt, as described in the help text. If specified, this setting will also be added to the bootloader config so that future boots will behave in the same manner. Feel free to modify and use that whereever you like, maybe Chapter 5 or 6 of the install manual? Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#269163: base install fails on HP ProLiant dl360g3 (using 20040830/netinst)
complains that eth0 does not seem to be connected to any sort of network. even though a working network cable is connected (I know this because it worked with the previous woody install). Looking on the dhcp server I don't see a dhcp request. I'm given the options Go Back, Yes, and No. The option Go Back doesn't and proceeded to ask me for the hostname. Yes allows me to configure statically and that works fine. If I configure statically when I get to the hostname/domain config screens the hostname and domain are pre-inserted so I know the networking is working and it was able to do a lookup. 3.) This system uses a Compaq SmartArray controller which uses the cciss driver and weird /dev names. It found the single controller and worked great! So good job on that. I will try to test with multiple configured arrays and multiple controllers if I get a chance. 4.) I tried the guided partitioning thing and it looks like single, one partition for /home, and multiuser all picked reasonable partition sizes. If you know what you're doing this works fine but I predict that these screens will be scary to people without Debian experience (like reviewers). 5.) During the base install, the installer complained debootstrap exited with an error (return value 1) /var/log/messages says === Errors were encountered while processing: exim4-daemon-light at exim4 exim4-config mailx exim4-base === looking in the logs it appears to be exim4-config with the problem, === Setting up exim4-config (4.34-4) ... hostname: Host name lookup failure Adding system-user for exim (v4) /usr/sbin/exim4: error while loading shared libraries: libgnutls.so.10: cannot $ Invalid new configfile /var/lib/exim4/config.autogenerated.tmp not installing /var/lib/exim4/config.autogenerated.tmp to /var/lib/exim4/config.autogenerated dpkg: error processing exim4-config (--configure): subprocess post-installation script returned error exit status 1 === (The hostname: Host name lookup failure shows up if I didn't configure the network by hand when it failed in #2. If I do then it goes away. The rest is the same regardless) If I attempt to proceed with installing grub it tries to run the base install again with the same result. I used a shell to chroot into /target but the system is not yet self aware dpkg-wise so I couldn't install anything. Installation failed :) -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#269163: base install fails on HP ProLiant dl360g3 (using 20040830/netinst)
Joey Hess writes... That's nasty, whoever designed that should be spanked. If the system doesn't want to work in graphics mode, it should not pretend there's a graphics capable card there, then syslinux would not use graphics mode... Well it's displaying on the vga console at the same time as this remote management device and you can interact with either. This design means you can interact with the bios and any bootloader/OS/software without the management device needing to know anything about it, which is pretty nice. So I understand the design from that standpoint. I don't think we have plans for a non-splash-enabled CD right now. Maybe we should make the second cd in a full CD set bootable and make it not use a splash screen. Either way we'd need documentation telling users of these systems what to do either, If using the iLO text console, when the system goes into graphics mode hit F1 or If using the iLO text console, boot with the second Debian CD While the latter might be a more general answer since there might be other systems that need it, I think CD#1 is going to much more widely available so I'd vote for that. debootstrap was broken a few days ago and you got a CD with the broken debootstrap on it. OK, I'll try again when a new nightly shows up. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
multiple report templates
hi debian-boot, I want to be able to submit proper installation report details. However, there are multiple differing installation report templates, http://www.debian.org/devel/debian-installer/report-template http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#problem-report The latter also claims that reportbug knows to do the right thing but looking at reportbug I'm not so sure. Can one template be agreed on and these be made consistant? I would have filed this as a bug but there's no obvious(for me at least) package to file it against. If you know where is should go please submit it. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
