Re: [AMD/ATI graphics] Missing firmware not declared / kernel modules not included in initrd
Adding debian-x to CC. On 01/01/2021 16:52, Karl-Heinz Künzel wrote: For a crosscheck I installed 'debian-10.7.0-amd64-netinst.iso' Xfce. System working! sources.list buster -> bullseye, update, upgrade, dist-upgrade, reboot and after grub system crashes 'black screen'. Restart again, now with kernel 4.19.0-13. System working! br KH It strikes me that there are two parts to this issue. 1. How to make the installer find/install the firmware? 2. Why does X work without firmware on the buster kernel but not on the bullseye kernel? did the buster kernel accidentally include firmware that it should not have done? when running on the buster kernel is X and/or the kernel using a generic driver rather than a GPU specific driver?
state of shim and shim-signed.
I have noticed that there seem to be issues with shim and shim-signed, the former has a complaint from the gcc maintainers about being built with an old version of gcc, the latter depends on an old version of shim. Are their plans to fix this for bullseye? are their difficulties getting new versions signed by MS?
Re: Multiple console support
On 19/01/19 04:27, Wookey wrote: Arm64 (arm in general in fact) has a rather fundamental problem with D-I, which is that both serial and display are sensible default devices for the installer to run on. Which is 'correct' depends very much on the hardware and the circumstances. You may be installing a server in rack, or a dev board with no display, in which case serial is ideal, or you may have a chromebook or an ARM desktop machine with a screen plugged in and no easy access to the serial console. This problem doesn't arise on x86 where there is 'always' a screen (or some BIOs magic to reflect what would be on the screen to serial). Steve (McIntyre) and I have been thinking about what to do about this, so did some investigation and came up with a plan. Essentially it was to run d-i on both if they are configured/available. This way anyone looking at just one or the other will see D-I as they expect. The patch is not intrusive and essentially nothing changes if there is only one console so this should be a low-risk change. One concern I would have is preseeding or other more-automated install modes. Presumablly this works out ok on a "normal" install because the instance of the installer that the user is *NOT* interacting with just sits there doing nothing but I would question if that is a reasonable assumption in general.
Re: Installer: 32 vs. 64 bit
Why are they creating 32-bit virtual machines? At least with virtualbox 32-bit VMs can run on any host. 64-bit VMs require VT-x which is all too often disabled in the BIOS.
Bug#798885: Boot problems after installation on new self-build computer.
My original post to this bug report may have confused the issue I had with the main kernel to the issue I had with the backports kernel. When I came back to the system at a later date the monitor was turning off when booting with a the jessie kernel while the storage problem was happening with the backports kernel. The issue with the monitor seems to be graphics card related. I saw the same issue on a another machine where I had just upgraded the graphics card to a GTX 750 Ti. Some stuff I found online indicated that it was caused by the kernel's graphics card drivers incorrectly switching to the onboard graphics and could be fixed by disabling onboard graphics in the bios. That somewhat worked for the machine where I upgraded the graphics card but it did not work for the machine I filed this installation report for. The workaround I found that did work was renaming /lib/modules/version>/kernel/drivers/gpu so the kernel couldn't load any graphics card drivers. This lead to a system that was usable but with the screen stuck in a low resoloution (IIRC 1024x768, I guess X was using the vesa driver). The storage related issue seemed to go away with a newer backports kernel so I think we can consider that one resolved. To get the display working in it's native resoloution I installed the nvidia binary driver.
Bug#798885: Boot problems after installation on new self-build computer.
On 13/09/15 21:02, Peter Michael Green wrote: Unfortunately on reboot the system hung, attempting to boot with quiet removed from the kernel command line showd the last userland boot message as "Starting LSB: Prepare console". Trying to boot in recovery mode also hung showing ata related messages about "security freeze lock" and "Device configuration overlay" being filtered out being the last things displayed. I will post links to photographs of the screen during these freezes in a followup mail. Freeze screen from normal boot with queit parameter removed http://postimg.org/image/rfq3vj2sz/ Freeze screen from recovery mode boot http://postimg.org/image/4ordcxxlt/
Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.
Reopen 782976 Thanks. On 24/04/15 22:49, Jonathan Wiltshire wrote: On Mon, Apr 20, 2015 at 02:17:25AM +0100, peter green wrote: Release team: can you clarify whether you intend to actually remove kfreebsd from the jessie suite of the official archive before/during the jessie release? Yes. Which if my understanding of the code is correct means that debian-installer-netboot-images will ftbfs because it will no longer be able to retrive the kfreebsd images. It could presumablly be modified to look in an unofficial location but as I said in the initial mail of this bug I don't belive that complies with the rc policy. -- 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/553ac563.8060...@p10link.net
Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.
Release team: theres a question for you at the end of the mail. On 20/04/15 00:49, Cyril Brulebois wrote: peter green (2015-04-20): Package: debian-installer-netboot-images Severity: serious The RC policy states "Packages must be buildable within the same release.". In this context I interpret "buildable" as buildable from actual sourcecode (not just package together) and "the same release" as the collection of stuff that Debian will be officially releasing as jessie. So you meant to file a bug against debian-installer rather than d-i-n-i? AIUI the overall process goes as follows (please correct me if any of this is wrong). 1: various source packages in debian build udebs. Building the source package for architecture foo produces debs and udebs for archicture foo. 2: the "debian-installer" source package uses those udebs to build installer images, again building "debian-installer" for architecture foo produces installation images for architecture foo. The installation images are placed in a special place in the archive. 3: Building the "debian-installer-netboot-images" source package retrives some of those images from their special place in the archive and packs them up into arch all packages. If an architecture is removed from a release 1 and 2 will still be fine. 3 OTOH will need manual changes to avoid shipping packages that cannot be rebuilt "within the same release". AIUI if an architecture for which "debian-installer-netboot-images" packs the installer image in an arch all package is removed from the release then debian-installer-netboot-images will FTBFS. I was mistaken on one thing though, despite the release teams mail months ago [1] saying that "We are dropping it as an official release architecture" it would appear that kfreebsd has not actually been removed from jessie at this point. Release team: can you clarify whether you intend to actually remove kfreebsd from the jessie suite of the official archive before/during the jessie release? [1] https://lists.debian.org/debian-devel-announce/2014/11/msg5.html -- 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/553453a5.7000...@p10link.net
Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.
Package: debian-installer-netboot-images Severity: serious The RC policy states "Packages must be buildable within the same release.". In this context I interpret "buildable" as buildable from actual sourcecode (not just package together) and "the same release" as the collection of stuff that Debian will be officially releasing as jessie. kfreebsd was removed from the jessie release. AIUI this means it will not be possible to build the kfreebsd debian installer on any official jessie system. As such IMO kfreebsd images should not be included in this package. -- 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/55343c28.7060...@p10link.net
Re: [d-i manual] copyright declaration
On 22/03/15 13:36, Holger Wansing wrote: Hi, is there a reason why the year for copyright declaration should not be converted into an entity? Would ease the repeating changing. Patch attached, works for both xml and po based translations. Correct me if I'm wrong here but shouldn't the copyright year only be updated when there is an actual change? -- 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/550ef2ff.4060...@p10link.net
Re: Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
Karsten Merker wrote: Browse online: http://anonscm.debian.org/cgit/d-i/base-installer.git/tree/debian/templates-arch Adding -arm@ and -boot@ for possible comments/insight. I suppose the reason for MODULES=dep being the default on arm* might be that some armel systems boot their kernel and initrd directly from an onboard flash chip with a size of only a few MB, so an initramfs built with modules=most might be uninstallable on them due to lack of space. Which makes sense for armel, many load their boot files from fixed size blocks of flash and flash space is a MAJOR issue (and major thorn in the kernel teams side) and you will generally need a new kernel if you move to a different device anyway. On the other hand for armhf i'm not sure it makes sense, most armhf systems i'm aware of load their kernels/initrds from filesystems so space is not such and issue and with the new armmp kernels having a modules=most initrd would presumablly allow one to move to different hardware with just swapping out the bootloader. -- 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/54249535.5010...@p10link.net
Re: Support for sunxi-based ARM systems in d-i
Lennart Sorensen wrote: Why would you NOT use uImage? Why would you add an unnessacery conversion step if you have a bootloader capable of loading regular kernel images directly? -- 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/535d2840.1090...@p10link.net
busybox failing to build on raspbian due to text formatting differences, any thoughts on what the cause could be?
Busybox has been failing to build in raspbian with what appear to be text formatting differences. http://buildd.raspbian.org/status/fetch.php?pkg=busybox&arch=armhf&ver=1%3A1.22.0-4&stamp=1393285422 FAIL: expand with unicode characher 0x394 --- expected +++ actual @@ -1 +1 @@ -Δ 12345ΔΔΔ12345678 +Δ 12345ΔΔΔ 12345678 FAIL: fold -sw66 with unicode input --- expected +++ actual @@ -4,8 +4,13 @@ 2,500,000 light-years (1.58×10^11 AU) away in the constellation Andromeda. It is the nearest spiral galaxy to our own, the Milky Way. -Галактика або Туманність Андромеди (також відома як M31 за -каталогом Мессьє та NGC224 за Новим загальним каталогом) — -спіральна галактика, що знаходиться на відстані приблизно у 2,5 -мільйони світлових років від нашої планети у сузір'ї Андромеди. -На початку ХХІ ст. в центрі галактики виявлено чорну дірку. \ No newline at end of file +Галактика або Туманність Андромеди +(також відома як M31 за каталогом +Мессьє та NGC224 за Новим загальним +каталогом) — спіральна галактика, +що знаходиться на відстані +приблизно у 2,5 мільйони світлових +років від нашої планети у сузір'ї +Андромеди. На початку ХХІ ст. в +центрі галактики виявлено чорну +дірку. \ No newline at end of file And so on Does anyone have any idea what might be causing this? maybe some kind of locale issue that is causing different measurements of string length? (our buildds seem to be setup with LC_ALL=posix) -- 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/530bed32.1030...@p10link.net
armhf installer?
It seems there are some unofficial builds at http://people.debian.org/~zumbi/di-armhf/ but only for one particular peice of hardware (and it's not the one I have) I tried building d-i "mx5_netboot" following the instructioions on the wiki. However it failed with Reading package lists... Done Building dependency tree... Done Need to download: anna archdetect bogl-bterm-udeb busybox-udeb cdebconf-newt-terminal cdebconf-newt-udeb cdebconf-priority cdebconf-text-udeb cdebconf-udeb choose-mirror choose-mirror-bin console-keymaps-at debian-archive-keyring-udeb di-utils di-utils-reboot di-utils-shell di-utils-terminfo download-installer env-preseed ethdetect file-preseed gpgv-udeb hw-detect initrd-preseed installation-locale kbd-chooser kernel-image-3.1.0-1-mx5-di libblkid1-udeb libcrypto1.0.0-udeb libdebconfclient0-udeb libdebian-installer4-udeb libfribidi0-udeb libiw30-udeb libnl-3-200-udeb libnl-genl-3-200-udeb libnss-dns-udeb libtextwrap1-udeb libuuid1-udeb localechooser lowmemcheck main-menu mmc-modules-3.1.0-1-mx5-di module-init-tools-udeb nano-udeb net-retriever netcfg network-preseed nic-modules-3.1.0-1-mx5-di pciutils-udeb preseed-common rescue-check rootskel save-logs udev-udeb udpkg util-linux-udeb wpasupplicant-udeb zlib1g-udeb Reading package lists... Done Building dependency tree... Done E: Unable to locate package kernel-image-3.1.0-1-mx5-di E: Couldn't find any package by regex 'kernel-image-3.1.0-1-mx5-di' E: Unable to locate package mmc-modules-3.1.0-1-mx5-di E: Couldn't find any package by regex 'mmc-modules-3.1.0-1-mx5-di' E: Unable to locate package nic-modules-3.1.0-1-mx5-di E: Couldn't find any package by regex 'nic-modules-3.1.0-1-mx5-di' make[2]: *** [stamps/get_udebs-mx5_netboot-stamp] Error 100 make[1]: *** [_build] Error 2 make: *** [build_mx5_netboot] Error 2 root@debian:/debian-installer/installer/build# Further even if it were to build I couldn't test it as it doesn't match my hardware (i'm running a beagleboard xm). Are the errors i'm seeing just caused by ongoing kernel transitions in sid or are they indicative of a bigger problem? What needs to be done to get armhf d-i into the official daily builds system (and eventually into releases)? What needs to be done to support the beagleboard series in armhf d-i? -- 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/4f333dca.6090...@p10link.net
Bug#655841: Please remove Gnash from default Debian install, as it crashes
Joey Hess wrote: Alexey Eromenko wrote: Default Debian-6 KDE installs "gnash", an extremely unstable component, that constantly crashes KDE Konqueror, when user accesses any flash-enabled website (such as www.amd.com). Wouldn't that be a bug in konqueror-nsplugins? No plugin should be able to crash the browser it's running in; at least chromium and I think firefox/iceweasel deal with crashing plugins. Plugins conventionally run in-process which allows them to crash the application they run in. Some browsers have started running plugins in seperate processes to reduce the damage caused by crash prone plugins but it's not how the system was originally designed to work and I wouldn't call it a "bug" for a browser not to do it. -- 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/4f13b2ca.6030...@p10link.net
Re: [RFC] IMPORTANT: Cleaning l10n-sync damage from D-I SVN repository
3) The relevant versions are now no longer available anywhere [2]: they are no longer in the archive and we don't have a snapshot.d.n for that period. I don't think this statement is correct. snapshot.debian.net seems to have all dates up to and including 2009/03/28, that date is after the release of lenny rc1 afaict. Note: the search function on snapshot.debian.net stopped updating long before the actual archiving stopped, and also 2009 doesn't appear in the index of archives (but the early 2009 stuff is accessible through manually typing urls) don't display properly. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] Consequences for official CD/DVD images for Lenny
The i386/amd64/powerpc DVD is more problematic as having all desktops will completely fill the DVD leaving no room for other packages with a high popcon score. Proposal is therefore to drop powerpc support from this DVD. With only i386 and amd64 there is still room for the top ~2600 packages on the DVD. I'm not sure about this one, there are still quite a few powerpc macs out there and hopefully PS3 support will be coming to debian at some point. Dropping images that make no sense? === Somewhat unrelated. We have several architectures that don't support booting from CD (armel, mipsel, s390) which means we're building a number of images that nobody will ever use: - businesscard and netinst - KDE, XFCE aren't CD images also used to do hd-media installs? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363049: probably found the reason for this ...
The solution Sven has proposed can be improved, without all the mirror bloat, I think. The sane thing to do would be for debootstrap to default to what's in /etc/apt/sources.list when no mirror is given. This avoids the logistical nightmare of having to make and update $arch.ftp.debian.org foreach architecture. If you're using it in sources.list, it has your architecture. The thing is sources.list often contains things other than the debian mirror and it may be tricky to figure out what is the debian mirror and what is something else. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nano doesn't work in shell launched from D-I menu
I wanted to make some small tweaks to the setup before rebooting at the end of the install so I could run the system using qemu in nographic mode after installing it using the graphical mode. So I backed out to the menu and selected the option to launch a shell, chrooted into the target and tried to use nano. I was surprised to find this failed with the error message "Error opening terminal: bterm". Is this a known issue? or should I file a bug report (and if the latter against what?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497998: trying to install debian armel in qemu-system-arm fails to detect network
package: installation-reports Package: installation-reports Boot method: kernel and initrd passed to qemu on command line Image version: daily build downloaded on sat 6 sep 2008 from http://people.debian.org/~joeyh/d-i/armel/images/daily/versatile/netboot/ Date: sat 6 sep 2008 Machine: qemu-system-arm Processor: whatever qemu-system-arm emulates when using -M versatilepb Memory: whatever qemu-system-arm uses by default Partitions: blank virtual hard disk just created with qemu-img Output of lspci -knn (or lspci -nn): Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: D-I booted successfully but failed to detect network, since I was using a netboot image I could not proceed any further with the installation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Case sensitive path name in windows based installer
[EMAIL PROTECTED] wrote: I run the windows based installer but after reboot grub won't boot and shown his prompt. After a little investigation I discovered grub was asked to look for image files to load from a "debian" directory in the Windows disk but they were in "Debian" directory instead. This probably happened because there was already a "Debian" directory on that disk created by me for some reasons in the past. The windows based installer program then copied image files to that directory without being aware it was already existing but was having a different case in his name. To solve the problem I booted into Windows then renamed the "Debian" directory to "debian" using the Windows file manager, then I rebooted the system the installation process started and completed successfully. It seems like the proper way to fix this is to find out from windows what the file is actually called (including case) and use that information when writing the grub config. Maybe GetLongPathName will do what is required. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496981: win32-loader fails if a directory already exists who's name matches debian in windows case insenstive matching but not in grubs matching (Which I presume is case sensive)
package: win32-loader severity: important justification: renders the package unusable for some users. according to [EMAIL PROTECTED] win32-loader will use an existing directory that matches debian in the windows filesystem. Unfortunately grub's filename matching and windows are different leading to grub failing to find the files. I am filing a bug to track this issue -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492751: Lenny beta 2 dies on boot up
I have successfully loaded an earlier build of lenny on the same hardware. Checking Google, I found a long discussion of the problem at: http://www.gossamer-threads.com/lists/linux/kernel/949548 This suggests that the lenny beta 2 kernel may not work with my processor. Is this something that needs to be fixed by kernel team? Or, is there something I need to do to get around it Could you try installing in expert mode and explicitly selecting the 486 kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cant boot NSLU2 after successful installation
Mark Thommyppillai wrote: Is there anything else I could try? You could solder on a serial port so you can watch the boot process and see where it fails. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] floppies -> generic removable media
Joey Hess wrote: Works, with a gotcha. disk-detect doesn't care what kind of disk it finds, so if you have a USB stick with drivers plugged in while it's running, and no other disk is found, it will happily use the USB stick as the target disk. IMO there should be an option in the list of possible target disks along the lines of "load more disk drivers" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape Can either version of grub handle all the cases that lilo can? for example can either of them handle the situation where root is on lvm and there is not a seperate /boot partition? last I checked d-i defaulted to lilo in that situation. If not then removing lilo will leave d-i with no ability to install a bootloader in those situations and worse leave some users with no upgrade path. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475908: please support MBR+GPT hybrid partition tables
Does libparted have support for that kind of partition table? it doesn't look like it (both parted and gparted also detect the partition table type as GPT). If not, it would have to be implemented there first. ok -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475908: please support MBR+GPT hybrid partition tables
package: partman severity: wishlist On mutliboot intel based macs the normal partition table type is a MBR+GPT hybrid. Currently when used with such a partition table partman destroys the MBR parition table causing bootloader installation to fail and thus making installing debian on such machines considerablly more complex. It would be very helpfull to have proper support for this type of partition table in partman. It would also be usefull to ask the user of an intel based mac with a plain GPT parition table if they would like to convert to MBR+GPT hybrid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r50470 - trunk/packages/kbd-chooser/debian
But it would affect an 'aptitude reinstall' of the package. As the user did not _himself_ ask for a seen flag to be set here (as in the case of preseeding [2]), I did not consider this a very nice solution. The user has effectively seen the question, they were just asked it by d-i instead of by the package so setting seen seems like the obvious thing to do to me. It is rather weired for the user to be asked about keymaps the next time they happen to be upgrading the package when they already made thier preference clear as part of the install. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452695: d-i manual: please add some more info about using defrag on windows partitions
While preparing this, I noticed that there is no hint in the manual, that in such cases man should use the defrag program to put all data on the ntfs partition together to one block. (defrag program is only mentioned in chapter about non-debian partitioning, but using defrag is also important, when d-i ifself does the partitioning job, isn't it?) It shouldn't be nessacery with any reasonablly modern tools including those included in d-i. Indeed windows XP defrag does not consolidate free space anyway so using it before install is really just a waste of time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Criteria to activate languages in D-I?
Well, my reasoning was simple: if we drop a language, then the only solution for users is installing in English, right? Think of a user who speaks some minority language well and a major language other than english reasonablly but thier knowlage of english is very poor/nonexistant. Such a user is much better off knowing that thier favorite language is not properly supported and able to select another one they know reasonablly well than ending up with an install mostly in thier favorite language but with a few key screens in english. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lower priority for grub-installer/only_debian ?
Although, this needs proper documentation and warnings in the installer manual and future release notes: like Christian noted, this can be bad if os-prober fails to do its job. This is a bit like the issue of whether to prompt for which drive to use, IMO the risk if detection goes wrong is not worth the elimination of one screen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: USB-floppy install problem
peter green wrote: Greg Flynn wrote: Frans Pop wrote: On Monday 11 June 2007 02:51, Greg Flynn wrote: I'm trying to install debian 4.0r0 via the floppy images. The laptop is a Averatec 3200 series laptop with AMD Athlon XP-m 2000+, 256MB RAM, a dead DVD-ROM/CD-RW (will not work at all), Via chipset(not sure exactly which) and Via-rhine II ethernet. The floppy drive i'm trying to install from is an external USB floppy. Because of the size of the kernel, installing from a USB floppy drive is not supported for Etch (the USB driver modules just do not fit on the boot floppy anymore). If you have no alternatives, we suggest you try installing Sarge instead and upgrade afterwards. Note that installing Sarge is not really straightforward at the moment. The problem is that the installer does not really support installing "oldstable'. As far as we know, it should be possible to work around any problems. We are working to improve that with the next point release for Sarge. Cheers, FJP I tried sarge back in the day and it has the same issue with the usb, after the boot floppy, it won't be able to find any other one I have had recent reports of a sucessfull sarge install with a usb floppy drive. The suite switch issues were avoided by using an appropriate date from snapshot.debian.net as the source (i wouldn't rely on that method though given thier habit of losing stuff). There WERE a load of io errors trying to find the root floppy but it found it eventually. The net drivers floppy was also a pain to get in (required waiting for a timeout and manualy selecting a device that was marked as scsi). Sometime when i'm less busy with other stuff i intend to contact the isolinux guys about the possibility of reading in more than one floppy before booting linux and seeing if i can make a set of floppies that boot D-I that way. btw on a related note will the current plans for fixing up the sarge installer also allow for installing it after it is moved to archive? sorry that should have been syslinux not isolinux and i got the list address wrong -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: floppies, a radical proposal
> I wonder what program keeps track of all the data that comes from > the floppies. For this to work it would be nessacery to modify the bootloader (iirc the floppies use syslinux) to read the extra floppies and do something with them (say append them to the end of the initrd and pass some kernel parameters with information on where they are in the initrd) so d-i could find them later.
floppies, a radical proposal
the current setup for debian boot floppies requires to load enough stuff to boot the linux kernel and read further floppies to be on the first floppy, more kernel bloat is making this more and more difficult and resulting in reduced functionality (you can't install etch from a USB floppy drive whereas you can install sarge from one). Since we already know the bios can read the users floppy drive (or they wouldn't have been booting off it) it would seem to make sense to load all the floppies BEFORE loading linux and abandoning the bios's services. what do others think?
RE: nano-udeb: Depends: libc6 (>= 2.5)
> -Original Message- > From: Geert Stappers [mailto:[EMAIL PROTECTED] > Sent: 25 April 2007 22:15 > To: debian-boot@lists.debian.org > Subject: Re: nano-udeb: Depends: libc6 (>= 2.5) > > > Op 21-04-2007 om 16:40 schreef Frans Pop: > > On Saturday 21 April 2007 09:13, Geert Stappers wrote: > > > When is libc 2.5 expected to arrive? > > > > http://buildd.debian.org/~jeroen/status/package.php?p=glibc > > It did arrive:-) unfortunately it still seems to be backed up out of testing by a missing build-dep on gcc-4.2 :) No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.463 / Virus Database: 269.6.0/775 - Release Date: 24/04/2007 17:43
Bug#419211: d-i fails in fetching "Release.gpg" in netboot install of etch r0
> Of course, while this is the correct default behavior, it seems reasonable > to me that we should allow users to override it with preseeding > or the like, > so that's IMHO a valid wishlist request. a related issue is if you have a cd not loaded through the CD mechanism for whatever reason and you have internet sources then even if you tell apt to allow unauthenticated it will always preffer the authenticated source, this is annoying if you have CD contents availible through a fast mechanism but a full mirror only accessible over a slowish internet link -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.4.0/762 - Release Date: 15/04/2007 16:22
RE: the future of the netinst image
> http://www.debian.org/CD/netinst/ "A network install or netinst CD is a single CD which enables you to install the entire operating system. This single CD contains just the minimal amount of software to start the installation and fetch the remaining packages over the Internet." This is clearly not what the "netinst" CD contains. A minimal ammount of software to start the installer and get cd and networking up is under 5 floppies worth (proven by the fact that you offer such floppies for download) for i386, a bit more for some other platforms. the "netinst" CD on the other hand is much much bigger. the information further down the page is a bit more accurate but it still contains many issues. For example it compares the "netinst" to the full cd set but does not mention that you can use just CD1 of the full CD set and that doing so has distinct advantages for systems with awkward network setups. imo netinst falls uncomforablly between too stools. for those who want to install everything over the network and have a nice network setup floppies are a nicer option because you can remove them without disturbing the installation after a relatively short read process (i don't know if you can do this with buisnesscard or miniiso but i'm pretty sure you can't do it with netinst or full CD 1 since they will want to install the base system off the CD later). For those with awkward network setups full CD 1 is a much better option, especially as debians support for installing packages over a sneakernet is so terrible. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.18/733 - Release Date: 25/03/2007 11:07
Bug#415989: Debootstrap Warning : [...]/packages.gz was corrupt
> > PS: Is there a way to fix memory hardware issues ? if you can get the system working well enough to install and compile stuff (say by pulling out some of the memory) you can build a custom kernel with the badram patches. Then put the bad memory back in, run a memory test and use the addresses to confiure badram. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.17/732 - Release Date: 24/03/2007 16:36
Bug#416115: pitfal: no mention of /etc/modules
> There is no mention of updating /etc/modules. Without a network driver, > or something else equally critical, you may find your remote dedicated > box happily running while noone can ssh into it. afaict nowadays /etc/modules isn't really nessacery anymore and can even cause upgrade problems. If udev detected a device during installation and loaded the module it should also detect it in the running system. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.17/731 - Release Date: 23/03/2007 15:27
Bug#389881: RC-ness of this bug
> That it's not a persistent means of identifying a filesystem. for most users fstab has always identified by rough position (e.g. hda=ide primary master), changing to a system based on partition IDs would mean a lot of relearning for admins (e.g. its no longer ok to backup a partition by dding it to another one) >It > changes if > you move the PCI device true, not that i imagine people do that much. >, it changes if you change the SCSI/IDE bus address > of the drive the same applied in the old hd? and sd? days, drives names changing when you change thier IDE/SCSI ids is something admins expect and are used to. , it changes if the kernel changes the name of the storage > subsystem used to access the device (on kernel upgrades) true, i wish they'd stop behaving like that. >, it breaks down > miserably if you use fiberchannel. never used fiberchanel so can't comment on this. to clarify my position on the overall issue i agree that this is too late for etch (sadly) by-path and by-id each have some pros and cons over each other but both are far better than the old scheme now that multiple controllers and usb devices in sd? are becoming the norm. by-uuid and uuid's in fstab (which seem to achive the same) is a very bad idea, it means that using dd to back up a partition to another one could result in the wrong one being mounted with potentially disasterous consequences. It could also be a severe security issue with the help of a carefully crafted usb stick (especially in an environment where deployment is done by imaging). labels suffer from the problems given above for uuids users installing on expert and possiblly medium should be given the choice between traditional names and the various new options.
Bug#389881: RC-ness of this bug
> Personally I also feel that all possible solutions effectively make > /etc/fstab unreadable and unmaintainable. Maybe Debian should > lead the way > to make /etc/fstab a generated file (like e.g. modules.conf used to be). what is so bad about /dev/disk/by-path/pci-:00:07.1-ide-0:0-part1 ? it says exactly where the controller is on the PCI bus, which device it is on the controller and which partition it is. Someone seeing that pattern should easilly be able to add entries for other drives and partitions on the same controller and with a bit more work (e.g. reading lspci and/or looking through /dev/disk/by-path) for drives on other controllers. sure its a little on the long side and you might want to change the spacing in fstab to reflect that but we have editors with copy and paste. A bit of extra verbosity in device names seems a small price to pay to get device names that are stable and reliable. The hd? system was very nice when most people just had a single ide controller with all their (sd? was alwats nasty afaict but few enough people had scsi that it didn't hit too many newbies) but times have moved on and it simply isn't possible to reliablly indentify drives with an identifier that short anymore. i don't see what generating fstab would gain. you are still going to have to have a configuration file that contains all the information about what to mount where including a method for identifying drives even accross addition of new hardware.
Bug#414683: d-i RC2 installation report
> I am still not sure my failure was not due to a misconfigured > network/router but the D-Link DI-524 used usually works fine for me. can you check if the default gateway is set and if there is something sane in resolv.conf within the installer environment? failing that try starting the installer with the network cable unplugged, then select configure network manually when it prompts you, plug the cable in and set the network up.
Bug#407689: tasksel: Please consider adding a Development task for Etch
> I've added module-assistant to "forcd1". build-essential was already > included. are the kernel headers for the standard debian kernels on CD1 as well? module assistant isn't going to be much use without those.
Bug#413788: Daily Etch build fails to install on iMac G5 - Ethernet not detected
> -Original Message-
> From: Mike Hore [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2007 01:40
> To: Frans Pop
> Cc: [EMAIL PROTECTED]
> Subject: Bug#413788: Daily Etch build fails to install on iMac G5 -
> Ethernet not detected
>
>
> Hi again Frans,
>
> > On Thursday 08 March 2007 02:30, Mike Hore wrote:
> >> 0001:03:0f.0 Ethernet controller: Apple Computer Inc. Shasta (Sun GEM)
> >> [106b:0051]
> > According to this information, your NIC needs the sungem driver, which
> > _is_ included in the installer and should be loaded automatically.
> >
> > After the installer has failed to detect your NIC, please try the
> > following:
> > - switch to VT2
> > - check if the sungem module is loaded ('lsmod | grep sungem')
>
> No output.
>
> > - if it is, check dmesg for any messages about the NIC
>
> I didn't see any, but there were about 2 screenfuls of info and I didn't
> know how to stop it scrolling off.
>
> > - if it is not, try to load it manually ('modprobe sungem')
>
> FATAL: module sungem not found
>
>
> So it really looks to me like it isn't there, sorry!
have you checked the md5sum against the one for the day your image is dated?
(you can find older dailies by cutting back the image url to remove the current
and everything before it and browsing manually from there)
i'm thinking this may be another case of a half and half download (half one
days image half the next)
Bug#389881: RC-ness of this bug
> UUIDs certainly have their disadvantages (verbosity being the main one), > but they're a hell of a lot better than labels for automatic use like > this. UUIDs are suitable for automatic generation while labels should > only be set by the sysadmin. The fiasco with Red Hat's installer setting > labels which can then end up conflicting with itself if you do multiple > parallel installs should demonstrate this (and some of the people > involved in Anaconda development said to me in person that in hindsight > this was probably a mistake). We've already backed away from automatic > use of labels once (http://bugs.debian.org/310754) so let's not have to > do so again! i'd still be happier with hardware IDs or paths than partition UUIDs, UUIDs seem very prone to things breaking on filesystem or disk cloning which is not something a *nix admin would expect to break stuff (unlike changing hardware)
Bug#389881: RC-ness of this bug
> I don't believe this should be changed for etch at this point in > the release > process, and that's speaking as someone who's run into this problem myself > with SCSI device renumbering -- it's awkward and annoying to have to > manually fiddle your boot config because a USB device is no longer > registering as /dev/sda, and it's not in line with the quality of > experience > that our users have come to expect when installing Debian >:), but I don't > think that makes anything unreleasable. Changing the fstab > handling at this > point could break many other scenarios that we haven't thought of > and tested > for, whereas the USB issue can be documented in the errata. what about writing out a /etc/fstab.by-id file with the header below followed by a copy of thier normal fstab changed to use the /dev/disk/by-id/ syntax? that way we could instruct newbies who run into this problem to just boot in rescue mode and run "cp /etc/fstab.by-id /etc/fstab". that seems to be much simpler to explain to people than a manual fixup whilst not risking breakage for anyone who doesn't run into the device rearangement problem. header for /etc/fstab.by-id # /etc/fstab.by-id # # This file was generated by the debian installer. It represents the same # partition structure as the /etc/fstab that the installer generated but # references disks by thier "id" rather than by thier traditional unix names # which are prone to change on first boot after installation or on changing # hardware. # # This structure is not used by default for etch installations (but probablly # will be for lenny) because of the possibility of regressions from such a # major change late in the release process. If you wish to use it and have not # modified /etc/fstab after installation you may copy this file to "/etc/fstab" #
Bug#389881: RC-ness of this bug
> I don't know how invasive those changes might be. AFAIK Ubuntu already > does it (Colin?) and wouldn't be too hard to pick the changes from > them but we would also need RM and Frans approval :( ubuntu already does what? there are four possible soloutions proposed aren't there (labels in fstab and the 3 different /dev/by-* trees)
Bug#389881: RC-ness of this bug
> > by-uuid contains my two ext3 partitions but not my swap > partition, it also seems like it may be vulnerable to becoming confused. > > Only if the admin is a moron and keeps around multiple file systems > cloned with dd. are you calling it moronic to make a backup of a partition by dding to to a spare one? since this was a perfectly workable system of backup under the conventional way of doing things i'd call that pretty unexpected breakage. the fact it doesn't seem to work for all partition types would seem to rule it out anyway.
Bug#389881: RC-ness of this bug
> -Original Message- > From: Marco d'Itri [mailto:[EMAIL PROTECTED] > Sent: 07 March 2007 11:05 > To: Robert Millan [ackstorm] > Cc: Mike Hommey; [EMAIL PROTECTED]; debian-release@lists.debian.org > Subject: Bug#389881: RC-ness of this bug > > > On Mar 07, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: > > > Labels are not well tested and a source of problems indeed. > The /dev/disk/by-*/ devices are well tested and I do not know about > problems posed by them. but if we are going to use those which set should we use? by-path seems like a reasonable choice though it will break if users move anything (but then so would the old system in many cases) by-id seems to use the make/model of the drive and maybe some unique id of the drive, by-uuid contains my two ext3 partitions but not my swap partition, it also seems like it may be vulnerable to becoming confused. maybe an answer would be to use by-path if drives are presenent on multiple controllers during installation and use conventional names otherwise (possiblly with a way to override this behaviour for experts).
Bug#389881: RC-ness of this bug
> > > I urge you to reconsider severity of this problem. There's > another situation > > > that makes it much worse: > > The correct solution is to make d-i use labels in fstab and to find the > > root file system. udev has not much to do with this. > > Which will enable a whole lot of other broken setups. Even uuids would be > better to use, though I'm not sure all filesystem types expose one (ditto > for labels, actually). isn't udev supposed to provide persistant device naming avoiding this problem?
RE: [PATCH] make multi-arch CD/DVD images more visible
> This has certainly appened, *but* I have only see it happen with > downloads > of Sarge images as amd64 are not mentioned on the sarge pages (because it > was not a release arch). To the best of my recollection, I have never yet > seen this happen with Etch images. me neither but from the posts on the debian forms i get the impression that those that are out of the loop don't try etch until after they have been told they don't have an ia64 chip and that this is likely to change after etch release. I also see a lot of posts about this that don't mention either etch or sarge explicitly in the initial post (and of course people immediately tell them to try amd64 etch so the question of which ia64 image they were using doesn't come up). intel does not publicise the fact that they are now the cloners and amd the cloned so anyone who has been out of the techy loop for a while (or never been in it) is going to assume that amd64 is not going to run on an interl chip and anyone who has seen ia-32 used to reffer to 32 bit intel (not that uncommon). Also i belive there are many who won't remember macs are no longer powerpc. > > To prevent this an additional "note" about what to use with EM64T > processors could be useful. Or maybe a link "Confused about all these > images?" to a new page with a general overview of types of images and > arches would be good. another alternative would be to structure the page so that it could accomodate a short comment on what each architecture was for alongside the links for each architecture. currently it seems for the stable releases there isn't even a download page as such, i just get directed to a folder on the mirror and left to find my own way from there.
RE: Etch netinstaller has no eth0 in qemu
> Updating the links on a daily basis synchronised with CD builds is > unfortunately not possible given the design of the Debian website. would it be possible soloution to make the links on the debian-installer page point to a page hosted on the cdimage server (and therefore able to updated by the same scripts as the cd images themselves) listing the few most recent snapshots. It would mean one more click for users but i think that would be outweighed by the much greater chance of them sucessfully getting the complete file.
RE: (d-i) download improvements
> > This is a problem though, using symlinks for the downloads like this > > rather than just updating the links essentially means that any user who > > doesn't pay carefull attention to how things are done and has a long > > download containing resumes (e.g. a user who has a slow and unstable > > internet connection)will get a broken image. That seems to me to be > > a large loss for a relatively small gain. > > I do know what you mean. > And I think I have now a clue for failed installations who couldn't be > explained. I do feel sorry for those who did a download and the next day > again with the same outcome, because they got both times hit > by the daily build switch. who is responsible for http://www.debian.org/devel/debian-installer/ which seems to be the normal way to download snapshots and how hard would it be to make that page link to the appropriate dated build directly rather than linking to the "current" symlink? what matters if the website not pointing to the symlink, whether the symlink should be removed completely is a seperate consideration that can only really be made after the web page issue is fixed. > > btw are we ever likely to get a proper tool for downloading images > > in a peicewise fassion? jigdo-lite is really terrible (no progress > > indication, unclear if its resuming or starting again etc). Bittorrent > > is banned or highly throttled on many networks and even when it is > > availible is only suitable for the most popular images. > > Point seen, in fact "Good pointsss seen". > My advice is to split them in separate wishlist bugreports against > the (pseudo)package[1] ftp.debian.org i'm not sure how that package would be appropriate, one is an issue (in the first instance at least) with the D-I web page and the other is the issue that jigdo STILL hasn't been finished nor has any decent replacement for it come forward. I have filed an important bug against jigdo though.
Bug#413248: success with 'utf8' vfat mount option
> AFAICT this option is relevant not only for vfat, but also for ntfs and > iso9660, but _not_ for fat16. afaict it is not relavent for partitions mounted as dos (no long filenames) but it *is* relavent for fat12 and fat16 partitions mounted as vfat and using long filenames.
RE: Etch netinstaller has no eth0 in qemu
> > Be fscking intelligent and *leave* a download for everyone to > pick it up, > > before you replace it. > > Leave older versions in separate directories and just change > the link to it. > > Be fscking intelligent and try this: > > wget > http://cdimage.debian.org/cdimage/daily-builds/daily/20070304-1/i3 > 86/iso-cd/debian-testing-i386-netinst.iso This is a problem though, using symlinks for the downloads like this rather than just updating the links essentially means that any user who doesn't pay carefull attention to how things are done and has a long download containing resumes (e.g. a user who has a slow and unstable internet connection)will get a broken image. That seems to me to be a large loss for a relatively small gain. btw are we ever likely to get a proper tool for downloading images in a peicewise fassion? jigdo-lite is really terrible (no progress indication, unclear if its resuming or starting again etc). Bittorrent is banned or highly throttled on many networks and even when it is availible is only suitable for the most popular images.
Bug#413248: installation-reports: (etch) strangeness with non-ASCII-character filenames on vfat partition
> It could also be that there really is an issue with the display of VFAT > filenames if UTF-8 is used, but that would not be my first guess. > Anyway, I doubt this would be an installer issue as there is no real way > for the installer to determine the correct settings. VFAT stores filenames in UTF-16, the driver has to convert this to something byte-orientated for processes/users to see. i suspect the problem is that the driver is still defaulting to converting to a legacy encoding while the user interface is now UTF-8 can you try adding iocharset=UTF-8 to the mount options for the partitions and telling us if that makes stuff behave as you expect? if so then imo this option should be set by the installer when generating fstab as afaict newly installed debian systems are completely utf-8 based nowadays.
Bug#412982: installation-reports: Enabling 'sudo' in installer skips setting root password and breaks desktop root tasks
reopen 412982 reassign 412982 gnome thanks > The Gnome date/time applet asks for the root password. The user > password doesn't work. this sounds like a gnome bug then, it really should be able to handle the case with the root account disabled but sudo availible.
RE: Filesystem type survives formatting in debian installer?
> Looking for the signatures seem superflous, I was suggesting that because of the metion previously in the discussion that some systems apprently didn't like it being zero'd out, only nuking known problem partition signatures would be much less likely to cause other issues than nuking anything in that space. > Feel free to file a wishlist bug report on partman and I'll take a look at > it post-Etch. if this isn't going to be fixed for etch it imo needs to at least be documented in the release notes so people can sort it out manually.
Bug#412916: [EMAIL PROTECTED]
> I want to install the distribution debian for ia64 and when i > restart de the PC with the "bootable" installation CD inside it > does not work, the pc read from CD but the installation doesn't > start. What can i do?. With the distribution for i386 it works perfectly. The core 2 duo is not an ia64 processor. It is em64-t which is intels clone of amd64, therefore you should be using the amd64 version of debian.
RE: Filesystem type survives formatting in debian installer?
> >this sounds like a bug in mke2fs to me, it is not cleaning up > the sectors > >before its header and as a result the partition gets misrecognised. > > I think it's there because some arches and some partitioning schemes > actually have real data in the first sector which can't be overwritten > or bad things happen. > > sparc is one such example. right so why are lvm and this crypto thing storing stuff there then? maybe the answer is to write some kind of partition cleaner that is run before formatting a partition that looks for the signatures of things that don't leave a gap (lvm and this crypto thing, possiblly others) and if it finds them blow them away before formatting.
RE: Filesystem type survives formatting in debian installer?
oops forgot to send this to the list > The problem does not relate to d-i per se. What's happening is that luks > creates its header in the first bytes of the partition (so generally at > bytes 0 - 300 or so). > > ext3 any some other file systems create their header at an offset of 2 > blocks (or 1024 bytes). this sounds like a bug in mke2fs to me, it is not cleaning up the sectors before its header and as a result the partition gets misrecognised.
Bug#412249: please install resolvconf by default
> Unfortunately, adding good DNS via network-admin doesn't archieve the same > effect, because dhclient will overwrite /etc/resolv.conf whenever > it's run the most obvious question would be why doesn't network-admin know this and do something about it? >, > which is going to be quite often if you happen to run > network-manager (also > enabled by default). This means Joe had to reload his DNS every > 10 minutes > untill his friend Robert could debug the problem and figure out > that resolvconf > was needed. what exactly does resolvconf do? does installing it alter the behaviour of the dhcp client or will they just fight over resolv.conf?
Bug#411552: please set a timeout in syslinux screen
> -Original Message- > From: Joey Hess [mailto:[EMAIL PROTECTED] > Sent: 20 February 2007 08:36 > To: Robert Millan; [EMAIL PROTECTED] > Subject: Bug#411552: please set a timeout in syslinux screen > > > Here are some scenarios to consider: > > * Suppose that I'm blind. I put in the CD, reboot, and wait the 5 > minutes I generally wait to get it past post[1]. Then I carefully start > typing the necessary kernel options for my braille reader into the > syslinux prompt I expect to be there... > > Even once I learn about the timeout, installing Debian is going to > suck a lot more than before for me. As long as the timeout is much longer than normal POST times and the countdown stops as soon as a key is pressed (so slow typing is fine as long as the first key is pressed quickly i don't see this being a huge issue. > > * Suppose that the machine is being booted by a rack monkey at the data > center. If it's set up like my data center, this means they put the CD > in the front of the rack, power on the machine, then run 200 feet > around to the back of the rack -- only to find that the crash cart > with the display isn't hooked up to the right machine. So they switch > it to the right one. Meanwhile, I want them to boot with "auto=true" to > avoid walking them through the whole install over the phone, and am > subsequently quite confused when I tell them to type that, and they > say that it replies with "Elektu landon, teritorion au aeron" and some > other strange words. > > Can you figure out what happened based on the above description? :-) > Could you figure it out over the phone? While being charged $x/minute > for a call from Europe to the US? this is a legit one but its a pretty special use case imo > > * My grandnephew Kai Runyon[2] is here visiting. He's 2, and he likes to > pound on keyboards and flip switches. He finds my power switch. Then he > finds my keyboard. I come out of a programming haze to find my media > server formatting its home directory thanks to the d-i CD I just had > it burn. > > Ok, granted, the timeout only saved him one well-placed enter, but > it's not unheard of for my home network to have preseed setups enabled > that let this whole scenario happen with only a few keystrokes. otoh you could stretch that case to say that using the installer should require sufficiant arcane commands that a child can't cause trouble with it, i don't think that is a road we should go down. > > * My kiosk machine only has a user-accessible touchscreen, the keyboard > is locked away to avoid all those easily implantable keylogger chips, > and other problems. I leave an installation CD in it so that it can be > quickly reinstalled if something goes wrong, or weekly (just in case). > One day I decide to switch it to this new version of the lenny CD, > which happens to be the one where g-i becomes the default installer. > This also happens to be the one that a tricky user of the kiosk uses to > intercept a lot of credit card numbers, after running through the whole > g-i install using only the keypad, to get root. but if you are leaving the CD in and you want the machine to be usable then you are going to have had to disable CD booting anyway.
Bug#411552: please set a timeout in syslinux screen
> That is obviously a problem, but so is d-i booting unexpectedly. D-I doesn't touch anything until told to does it? i don't really see how unexpectedly ending up at the first screen of the installer is any worse than unexpectedly ending up at the syslinux boot prompt, either way you just remove the CD and reboot.
RE: RFC auth patch
> I think this is worth putting in because it's useful both when a key > expires and you still need to use old installation media, and when > installing from an unofficial, unsigned mirror, like the one the armel > port is using. > > I haven't tested the code yet, but I will before I commit, if people > like the idea of adding this. imo making this availible through preseeding while it will be helpfull for some is not going to help most people who run into this issue. the real fix imo would be to make apt/aptitude have an option to use debconf for this prompt. Failing that i belive the soloution would be to check for the key problem before installing anything (there must be a way to check for it programatically) and pop up a warning if an issue was discovered (and based on the users response add the configuration setting).
Bug#410218: etch RC1 release installation
> -Original Message- > From: Frans Pop [mailto:[EMAIL PROTECTED] > Sent: 08 February 2007 18:00 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Bug#410218: etch RC1 release installation > > > On Thursday 08 February 2007 18:21, peter green wrote: > > if so you are probablly hitting a known bug, > > No, that is not possible. That issue has been fixed. sorry i must have missed its migration to testing, > > > the easiest workaround for > > this known bug is to skip installing packages and install the software > > you want manually after installation. > > Working around the issue won't fix it for others. What we actually need > here is to know what package is causing the problem in this case. > > Could you try to reproduce the problem and send us the syslog (gzipped!) > for the installation. > If you have another computer connected to the system the easiest > way is to > use the "Save debug logs" option in the main menu of the installer after > configuring the network, but before the package installation is started. might also be an idea to look if there is anything of interest on the log vt (alt-f3) at the time of the hang
Bug#410218: etch RC1 release installation
> -Original Message- > From: Wojciech Zareba [mailto:[EMAIL PROTECTED] > Sent: 08 February 2007 16:28 > To: [EMAIL PROTECTED] > Subject: Bug#410218: etch RC1 release installation > > > Package: installation-reports > > Boot method: CD netinst default install > Image version: > http://cdimage.debian.org/cdimage/etch_di_rc1/i386/iso-cd/debian-t esting-i386-netinst.iso > Date: 2007-02-08 16:30 CET > > Machine: PC based on Gigabyte GA-8PE800 Pro matherboard (chipset 845PE) > Processor: Pentium 4 (2.2 GHz) > Memory: 512 MB > Partitions: default partitioning (all on one) with LVM - disk 120 GB > > Output of lspci -nn and lspci -vnn: I can't do it due to fatal errors > during installation > > Base System Installation Checklist: > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > Initial boot: [O] > Detect network card:[O] > Configure network: [O] > Detect CD: [O] > Load installer modules: [O] > Detect hard drives: [O] > Partition hard drives: [O] > Install base system:[O] > Clock/timezone setup: [O] > User/password setup:[O] > Install tasks: [E] > Install boot loader:[ ] > Overall install:[ ] > > Comments/Problems: > Main error: > System has hung during installing additional packages. I couldn't > install grub becouse of it. did you configure the network manually? if so you are probablly hitting a known bug, the easiest workaround for this known bug is to skip installing packages and install the software you want manually after installation.
Bug#410224: give the user the ability to answer conffile prompts during installation
package:debian-installer severity:wishlist conffile prompts should not happen during installation (unless of course the admin uses a vt to edit files manually), but sometimes they do due to bugs in packages or other issues. just freezing with the conffile prompt on another vt and worse no way to answer it is not good behaviour when they do.
Bug#408641: asks user to select disk to partition, even if there's only one disk
> Partman (guided partitioning) will still ask the user to select > which disk to > partition, even if there's only one disk. personally i think its better that it asks consider the situation where a user has two drives but the one they want to use for debian is not detected. then they select the use entire disk option.
Bug#407689: tasksel: Please consider adding a Development task for Etch
> The problem with adding a development task has always been, and > continues to be, that people do not use the same tools for development, > and that there are no good defaults beyond basic C-style development > tools. mind you a similar thing applies to say the file server task, there are at least 3 different types of server that someone could want that would fit the "file server" discription and its not at all clear which ones will be installed. I personally belive that tasksel needs a major overhaul and is practically useless in its present form, what i think is really needed is a set of categories each with a number of entries so you'd say have a desktop category (with gnome desktop, kde desktop, xfce desktop etc), a webserver category (with basic websever, lamp webserver etc), a fileserver category (with samba,nfs and ftp options), a development category (with basic development, kernel development, debian package development, java development etc) and so on. > This is why #266702 is still open. The fact that those default > C development tools are no longer in standard still doesn't make > "development" a sensible task. It's not the same class of thing as > running a web server or using a desktop, both of which can be > accomplished well, if not perfectly for everyone, with a predetermined > list of software. maybe development is the wrong name but even a task that just installed build-essential and the kernel headers would imo make things a lot easier for those stuck with unusual hardware or wanting to compile software that is not packaged off the bat (its not at all obvous to newbies that the package they need to make basic compilation work in one step is called build-essential and its pretty horrible getting compilation to work one package at a time).
Bug#407759: Set-up attempt failed.
> The install did not find the CDROM drives. As a workarround you might like to try installing using the boot, root, net-drivers 1 and net-drivers 2 floppies.
Bug#407696: add a guided partitioning option for resizing an existing partition
package: debian-installer currently to use guided partitioning on a system with no unpartitioned free space the user must go into manual partitioning, resize the existing partition and then go back out of manual partitioning and select guided using the largest free space, this is somewhat unintuitive. since resizing an existing partition to make room for debian is likely to be one of the most common ways of installing it i think it deserves a seperate option at the same level as the guided-use entire disk and guided-use largest free space options.
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
> However, when booting after the installation, the NPE driver seems to > assume control of the interface name eth0, which causes something to > rename the interface of the USB to ethernet adapter to eth1_rename. it sounds to me like the built in nic is getting detected first before the USB to ethernet adaptor, udev should then swap the names back to those used at install time. It looks like it is renaming the usb to ethernet to a temporary name (nessacery for a swap operation) but failing to rename the built in nic for some reason.
Bug#406399: installation-report: Dell Inspiron 6400: X server configuration problems
> The initial debootstrap doesn't have download speed reported, but then, > it's only a few dozen megabytes download. thats a pretty long wait for a dialup, isdn bri or very low end "broadband" user.
Bug#405549: installation-reports: Also ATI Rage
> My ATI Rage was also not configured after install -- gdm fails and X > reports no devices. Missing input and video drivers. ATI device is > configured as "agp". The desktop package doesn't seems to install the > correct driver or detect it I guess. Easy fix -- I added the video and > input tasks and ran dpkg-reconfigure xserver-xorg. xorg.conf was > correctly configured at this point though I had to specifically choose > the "ati" driver. its a known issue with the xserver-xorg package. It has already been fixed in unstable and the fix should hit testing in a couple of days.
Bug#404972: Minor problems with Notebook HP nc 6000
> In particular, it kept waiting at the fd0 lines, so what I think > is that it > had troubles with that. This notebook does NOT have a floppy drive, so I > guess that the long wait is related to fd0 timing out. is this by any chance one of those laptops where the bios thinks there is a floppy drive even when there isn't (i've seen this before with notebooks with hotswap drives)
Bug#377032: i'm thinking
> For experienced users, yes. For newbies, definitely not (IMNSHO). For > them, the only really variable part they understand is the hostname, the > rest is goobleycook. > Feel free to try to convince me otherwise. imho there are only two classes of people who are likely to be using the manual entry option: those with enough knowlage of urls to understand a request for a mirror url with an example and those being told to do it explicitly by a local expert (e.g. thier network administrator) who should just be able to give them a url that they can type without understanding it just as they do for websites already. for both of theese situations i'd think a single url would be less hassle than four seperate questions some of which are hidden in non-expert mode despite the need for them on some networks. though maybe if going with the url option it would be nice to make it auto-prepend a default protocol (like web browsers do) and try adding /debian to the end if it fails to find a valid debian mirror at the url given (this would mean that someone could still enter just ftp.uk.debian.org and it would still work).
Bug#377032: i'm thinking
wouldn't it be more sensible to combine the protocol, hostname, port (if such a question exists) and directory questions into a single request for a mirror url?
Bug#403890: installation successfull with some manual work
> Not sure what was wrong here, but it does not seem like something we can > fix in the installer. well ntfsfix cleared up the journal and made it work so it would presumablly be possible to do that, i dunno how safe ntfsfix is though. btw why do you ask for installation reports even on sucessfull installations?
Bug#403890: installation successfull with some manual work
> > This was possible in export installs and this is still possible in > expert installs. The behaviour has not changed with regard to that matter. > i'm pretty sure i've never intentionally booted d-i in expert mode, and when i did a sarge install i'm pretty sure i managed to skip creating a normal user account (i think it prompted me for one and i selected some kind of cancel option), unfortuntely i don't have any spare systems to test this on now. also is there any way to switch to expert mode mid install and if not why?
kde/gnome/xfce media other than full CDs
it has recently been announced that there will be seperate CDs for kde/gnome/xfce with different desktop tasks and package selections. but what is the plan for other means of installation (buisnesscard/netinst/floppies/netboot)? will there be 3 seperate desktop tasks listed? will there be one desktop task that installs all three? or will kde and xfce desktops simply not be availible from tasksel.
Bug#403890: oops forgot to finish off the report
it should have said and windows still booted fine afterwards.
Bug#403890: installation successfull with some manual work
Package: installation-reports Boot method: CD boot with nothing extra typed at boot prompt Image version: Etch RC1 full CD 1 Date: Machine: maxdata PC Processor: celeron D (at least according to the label on the front) Memory: 256MB Partitions: Output of lspci -nn and lspci -vnn: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The installer told me that my existing NTFS partition could not be resized due to an unknown error and to look at VC4 for more details (btw in errors like that you might wan't to give a brief description of how to switch virtual consoles). VC4 told me there were inconsistancies and to run "chkdsk -f" and then reboot windows twice. I followed its reccomendations and loaded the installer again. Resizing still failed but this time i was just dumped back in the manual partitioning window with no error. Checking vc4 told me the journal was not clean and to boot windows and shutdown cleanly to clean it. I did this and then back into the installer which promptly failed to resize again in exactly the same way. I decided to try ntfsfix but I could not seem to find any way to manually install/extract debs/udebs within the installer environment. Eventually i resorted to installing ntfsprogs on another debian system and transfering ntfsfix and libntfs into the installer environment using http. ntfsfix ran with no errors and resizing succeeded afterwards. once the resize was done i wen't into "guided partitioning" and told it to use the "largest free space" and put "everything in one big position". This created two partitions a root partition and a swap partition (since this option is aimed at people who don't wan't to tie themselves to particular allocations wouldn't it be more sensible and more consistant with the options name to create a swapfile instead?). user/password setup worked but i could find no way to bypass creation of a normal user account (i'm sure this was possible in the sarge installer). Installing tasks wen't ok, i selected "standard system" and desktop, it did seem to be downloading some stuff from the net as well as using the CD though (i belive this is a known issue with the standard tasks now being too big to fit on CD1) everything else went fine and.
Bug#402482: tried to reproduce and failed.
i've tried to reproduce this bug but failed btw in the process of trying this i discovered that busybox --install doesn't seem to work either i had to manually copy busybox and make a symlink for this test. debian:~/busyboxinstall# cp /bin/busybox . debian:~/busyboxinstall# ln -s gunzip busybox ln: creating symbolic link `busybox' to `gunzip': File exists debian:~/busyboxinstall# ln -s busybox gunzip debian:~/busyboxinstall# ./gunzip gunzip: compressed data not read from terminal. Use -f to force it. debian:~/busyboxinstall# echo foo | foo.txt bash: foo.txt: command not found debian:~/busyboxinstall# echo foo > foo.txt debian:~/busyboxinstall# echo bar > foo.txt debian:~/busyboxinstall# echo foo > foo.txt debian:~/busyboxinstall# echo foo > bar.txt debian:~/busyboxinstall# gzip foo.txt debian:~/busyboxinstall# gzip bar.txt debian:~/busyboxinstall# cat foo.txt.gz bar.txt.gz > baz.txt.gz debian:~/busyboxinstall# gunzip baz.txt.gz debian:~/busyboxinstall# cat baz.txt foo foo debian:~/busyboxinstall# cat foo.txt.gz bar.txt.gz > baz.txt.gz debian:~/busyboxinstall# ./gunzip baz.txt.gz debian:~/busyboxinstall# cat baz.txt foo foo debian:~/busyboxinstall# ls -l total 428 -rw-r--r-- 1 root root 32 2006-12-17 02:30 bar.txt.gz -rw-r--r-- 1 root root 8 2006-12-17 02:31 baz.txt -rwxr-xr-x 1 root root 418112 2006-12-17 02:29 busybox -rw-r--r-- 1 root root 32 2006-12-17 02:30 foo.txt.gz lrwxrwxrwx 1 root root 7 2006-12-17 02:29 gunzip -> busybox debian:~/busyboxinstall# _ Visit MSN Holiday Challenge for your chance to win up to $50,000 in Holiday cash from MSN today! http://www.msnholidaychallenge.com/index.aspx?ocid=tagline&locale=en-us -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395911: error mounting/creating filesystems windowswindow~1.log is 92k, but it has 41 clusters (164k)
> windowswindow~1.log is 92k, but it has 41 clusters (164k) > > ERROR !!! > > Ignore > Cancel > > dmesg -c on second console didnt showed anything relevant, only > information that swap was mounted/added. > > Perhaps the fat system there was damaged before and debian tried to > mount it? But if so then this windows-fault, not-our-business error > probably should be displayed in more "OMG, we failed, The Drama!" way > not to scare newbies? > > After ignoring it there was another error, > > FIle system is reporting the freee space as 409170 clusters, not 409199 > clusters. it sounds to me like the installer was running a filesystem check on the parition and found a couple of minor issues, thats nothing unusual with fat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
missing floppy images
http://mirror.ox.ac.uk/debian/dists/etch/main/installer-i386/current/images/ floppy/ the net drivers and cd drivers are there but boot and root are missing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Dropping 386 support
what about changing the 486 emulation kernel patch so that it completely disables itself on non 386 processors this way it would only have security issues on pure 386 which wouldn't be supported at all otherwise > -Original Message- > From: Martin Schulze [mailto:[EMAIL PROTECTED] > Sent: 04 October 2004 14:33 > To: Peter Green > Cc: Adeodato Simó; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Dropping 386 support > > > peter green wrote: > > calling stuff i386 when it will not run natively on a 386 seems > like asking > > for confustion to me > > True, but we're way to close to a release to fix *that*. And I'm not > sure that we could easily fix binary-i386 at all.. > > > why and when was this instruction emulation needed in the first > place (that > > is why and when was the userland changed to need it) > > > Looking in that archive, this was first discussed in April 2003: > > > <http://www.debian.org/News/weekly/2003/17/> > >Debian to drop Support for i386? Jochen Friedrich [30]noted that >due to GCC 3.2 the new libstdc++5 library requires an 80486 >processor or higher, the old 80386 on which Linux was started, is >no longer supported. Therefore Matthias Klose [31]wondered whether >Debian should further support the i386 target. > >30. http://bugs.debian.org/185662 >31. http://lists.debian.org/debian-devel-0304/msg01895.html > > <http://www.debian.org/News/weekly/2003/18/> > >Dropping Support for i386? Nathanael Nerode [17]investigated the >i386 problem and discovered that to maintain binary compatibility >with C++ packages from other distributions, Debian needs to use the >i486 version of atomicity.h supplied by GCC. Dagfinn Ilmari >Mannsåker [18]wrote a small [19]script that compares the speed of >OpenSSL code for i386 versus i486 on a P-III Mobile. > >17. http://lists.debian.org/debian-devel-0304/msg02112.html >18. http://lists.debian.org/debian-devel-0304/msg02134.html >19. http://ilmari.org/sslcmp > > Another URL that was inspired by and mentioned on the debian-release > mailing list: <http://people.debian.org/~joey/pr/3.1/i386.html> > > Hope that helps. > > Regards, > > Joey > > -- > Everybody talks about it, but nobody does anything about it! -- > Mark Twain > > Please always Cc to me when replying to me on the lists. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Dropping 386 support
calling stuff i386 when it will not run natively on a 386 seems like asking for confustion to me why and when was this instruction emulation needed in the first place (that is why and when was the userland changed to need it) > -Original Message- > From: Adeodato Simó [mailto:[EMAIL PROTECTED] > Sent: 03 October 2004 23:19 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: Dropping 386 support > > > * Joey Hess [Sun, 03 Oct 2004 12:54:21 -0400]: > > Andres Salomon wrote: > > > Given d-i's memory requirements, and the fact that you'd be > hard-pressed > > > to find a (desktop) 386 system with more than 16 megs of > memory, I don't > > > consider debian 3.1 to be a viable candidate for installing > onto a 386. > > > Also, note that if we do drop 386 support, I will rename > > > kernel-image-2.6.8-386 to kernel-image-2.6.8-486, and update > > > optimizations accordingly. > > > I have no opinion on 386 support, but it's too late to go changing > > kernel package names for sarge. d-i relies on the current names, and > > this sort of transition will likely set us back days or weeks on our > > release schedule. > > would it be a problem to actually update optimizations as Andres > proposes, but without changing packages? that is, *if* finally sarge > ships without plain i386 support and that is clearly noted in the > release notes. > > -- > Adeodato Simó > EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 > Listening to: Aphex Twin - Xtal > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. > -- George Bernard Shaw > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#274615: Add CDROM fails due to broken symlink and no error notification
i had a similar problem once when installing sarge on vmware
the vmware system crashed very dirtily during base config (this was nothing
to do with debian it was an external usb hard drive on the windows side that
decided to hang it has done this several times usring other things)
anyway after vmware did its consitancy checks on the virtual disc files i
booted the virtual machine again and got into base config
but i couldn't do any of the apt setup stages
once i realised what the problem was i managed to fix it by following the
instructions in the error but im pretty sure the error was not visible for
long (this was a while ago)
in summary base config needs a waqy to avoid obliterating such output from
child processes
> -Original Message-
> From: Jason Wies [mailto:[EMAIL PROTECTED]
> Sent: 03 October 2004 03:05
> To: [EMAIL PROTECTED]
> Subject: Bug#274615: Add CDROM fails due to broken symlink and no error
> notification
>
>
> Package: base-config
>
> Version: d-i pre-rc2
>
> During an install of d-i pre-rc2. The symlink issue may be d-i's
> fault; the error notification is not. I'll include the symlink issue
> in my installation report, no need to reassign if it's d-i's fault.
>
> After completing the initial install and rebooting into base-config.
>
> On the initial apt configuration screen, I chose CDROM. A message
> stating that the CDROM device could not be found was displayed, along
> with a text field to enter the path to the device ("Enter the
> device...").
>
> I entered /dev/cdrom and pressed Enter, and was returned to the same
> screen with no change whatsoever. Repeated about five times, same
> result.
>
> The problem was that the /cdrom symlink was broken. The other problem
> was that I was not presented with any indication that there was an
> error, only returned to the same screen. I was able to read the
> /cdrom symlink error message when it flashed at the bottom of the
> screen for a split second, but that's not good enough.
>
> About the symlink:
>
> "mount: /cdrom is a symbolic link to nowhere"
>
> /cdrom -> media/cdrom
> /media/cdrom -> cdrom0
>
> 'find /dev -name cdrom0' yielded no results.
>
> Jason
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: NTFS resize in partman
sarge release seems to be delayed indefinately by some issue with the testing-secuirty autobuilders noone seems to be reavealing just what is wrong with them though?! a little offtopic i know but does anyone know what is holding them up? > -Original Message- > From: Kenshi Muto [mailto:[EMAIL PROTECTED] > Sent: 30 September 2004 01:22 > To: [EMAIL PROTECTED] > Subject: Re: NTFS resize in partman > > > At 29 Sep 04 19:51:20 GMT, > Joey Hess wrote: > > Anton Zinoviev wrote: > > > Yesterday I made some changes in partman and partman-partitioning to > > > allow resizing of NTFS partitions. > > > > > > There is no progress bar and in the file > > > partman-partitioning/active_partition/resize/choices we have to > > > replace "/usr/sbin/ntfsresize" by "/usr/bin/ntfsresize". Today there > > > were rainstorms and I am again without Internet so I am unable to add > > > progress bar to inform the user that something is going on and to > > > replace this string. Otherwise I think that the NTFS resizing already > > > works and the packages can be uploaded. > > > > I think this was just too late for tc2. I considered waiting tc2 for it > > but I'd rather not spend more time on tc2 than I must. > > > > Kinda annoying though, we seem to be getting two important features, > > ntfs resize and raid 5, right after our big featureful release.. > > Good feature, but really too late. Please don't make our release late > and late. > > I hope this feature will be treated as experimental; partman should notice > it's not well tested (and don't treat a bug of this feature as RC.) > > Thanks, > -- > Kenshi Muto > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: bypassing partman
> One way to cheat is to configure some partition sheme by partman and > then to change it manualy acording to your needs. Then the system > will know that partman is configured and will not restart it. this assumes that your system has block devices that patman recognises at all -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: bypassing partman
that assumes that partman lists the block device in quesion at all ;) i have discovered how to force it though mount block device on /target cd to /target to make it impossible to unmount proceed with the install as normal it will try to start partman fail and dump you in the main menu from here you can move on to install the base system it will try to start partman a couple more times then proceed to install the base system > -Original Message- > From: Anton Zinoviev [mailto:[EMAIL PROTECTED] > Sent: 23 September 2004 13:06 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: bypassing partman > > > On Sat, Sep 18, 2004 at 02:19:10AM +0100, peter green wrote: > > for various reasons i want to be able to use debian installer > to install on > > a block device that is not a partition > > > > is there any way to bypass partman and set up the mappings between > > mountpoints and block devices manually? > > I can not answer your question but unsell some new bug was introduced > you don't need to bypass partman. > > 1. Start the installer in the expert mode so all questions will be asked > 2. Choose to create by partman a new partition table on your block device. > 3. You will be asked about its type. Choose "loop". > 4. Create one partition that ocupies the whole disk and use it. > > The "loop" partition table type is some hack provided by parted > meaning that the storage device has only one partition and it ocupies > the whole device. > > Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bypassing partman
for various reasons i want to be able to use debian installer to install on a block device that is not a partition is there any way to bypass partman and set up the mappings between mountpoints and block devices manually? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: is this a bug
sounds like it the boot floppy was still in the first floppy drive at the time > -Original Message- > From: Joey Hess [mailto:[EMAIL PROTECTED] > Sent: 18 September 2004 01:24 > To: peter green > Cc: [EMAIL PROTECTED] > Subject: Re: is this a bug > > > peter green wrote: > > debain installer seems unable to load net drivers from the second floppy > > drive > > > > is this a bug and if so where should it be reported > > Does this describe your problem? http://bugs.debian.org/225220 > > -- > see shy jo > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
is this a bug
debain installer seems unable to load net drivers from the second floppy drive is this a bug and if so where should it be reported -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RE/FW: Please stop sending me emails
it may have been caused by admin action on his side during the height of the problem i sent a rather strongly worded email to [EMAIL PROTECTED] about the issue and it may be that they have taken action to disable his broken mail system > -Original Message- > From: John Summerfield [mailto:[EMAIL PROTECTED] > Sent: 29 August 2004 04:12 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: RE/FW: Please stop sending me emails > > > Frank Carmickle wrote: > > >I apologize. But I did remove myself twice from this list in > the last few > >days. Then I removed the whitelist entry for this list. I > thought that I > >was unsubscribed when I removed the entry but no such luck. Someone > >should look in to this problem. Neither the web form or the message I > >sent removed me from the list. > > > > > > > Frankie's mail is still broken. I tried to send him this message: > > I believe the author of ASK would like you to discuss the problem > with you. > > > with this result: > > This message was created automatically by mail delivery software (Exim). > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) failed: > > pipe to |/usr/bin/ask.py --loglevel=5 > --logfile=/usr/friends/frankiec/ask.log --home=/usr/friends/frankiec > generated by [EMAIL PROTECTED] > Child process of address_pipe transport returned 100 from command: > /usr/bin/ask.py > > The following text was generated during the delivery attempt: > > -- pipe to |/usr/bin/ask.py --loglevel=5 > --logfile=/usr/friends/frankiec/ask.log --home=/usr/friends/frankiec >generated by [EMAIL PROTECTED] -- > > ERROR: /usr/friends/frankiec/.askrc does not exist or is > unreadable. Exiting... > Attention: > > The system could not deliver your message due to a technical problem. > Information about the problem has been recorded locally for analysis. > > --- Problem Details --- > > Traceback (most recent call last): > File "/usr/bin/ask.py", line 65, in ? > config = askconfig.AskConfig(sys.argv) > File "/usr/lib/ask/askconfig.py", line 91, in __init__ > self.__read_config(self.home + "/.askrc") > File "/usr/lib/ask/askconfig.py", line 104, in __read_config > sys.exit(self.RET_PROCMAIL_CONTINUE) > SystemExit: 0 > > --- > > -- This is a copy of the message, including all the headers. -- > > > > -- > > Cheers > John > > -- spambait > [EMAIL PROTECTED] [EMAIL PROTECTED] > Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RE/FW: Please stop sending me emails
may i ask why [EMAIL PROTECTED] doesn't go straight to the listmasters? > -Original Message- > From: Martin Schulze [mailto:[EMAIL PROTECTED] > Sent: 28 August 2004 08:08 > To: Peter Green > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: RE/FW: Please stop sending me emails > > > peter green wrote: > > can someone please remove this guy from the list before his bloody > > autoresponders drive us all crazy > > He's removed from all lists and his mail address has been blocked > from sending to any list. A mail to listmaster@ or some listmasters > personally should have been faster. > > Regards, > > Joey > > -- > Have you ever noticed that "General Public Licence" contains the > word "Pub"? > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#268484: Installation report
sounds like it didn't pick up the default gateway what if anything does the route command output after the network is brought up > -Original Message- > From: Tim Douglas [mailto:[EMAIL PROTECTED] > Sent: 28 August 2004 01:27 > To: [EMAIL PROTECTED] > Subject: Bug#268484: Installation report > > > Package: installation-reports > > Debian-installer-version: rc1 > uname -a: Linux fox 2.4.26-sparc64 #1 Fri Jun 18 02:04:50 PDT 2004 > sparc64 unknown > Date: 2004-08-26 > Method: Boot from the businesscard CD image. Download packages from > home-firewall'd (NETGEAR MR814v2) DSL connection. Control computer by > serial connection. > > Machine: Sun Ultra 1 UPA/SBus > Processor: UltraSPARC 200MHz > Memory: 768 MB > Root Device: SCSI HD. > Root Size/partition table: no idea > Output of lspci and lspci -n: sh: lspci: not found > > 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: [E] > Detect CD: [O] > Load installer modules: [O] > Detect hard drives: [ ] > Partition hard drives: [ ] > Create file systems:[ ] > Mount partitions: [ ] > Install base system:[ ] > Install boot loader:[ ] > Reboot: [ ] > > Comments/Problems: > > The network got configured properly, IP address and all (using DHCP). > Then after setting up the Debian mirror, the Release file would not > download. Going to a command prompt, ifconfig showed everything was in > working order. The machine could be pinged (couldn't ping out, no ping > command). It could wget files from my internal ftp and http servers. > But it couldn't download anything from any external servers. Neither > domain names or IP addresses would work. Nor connecting via a static > IP. Even a different network card would not work. The network port did > work with other computers though. > > I'm going to try a new daily build from today to see if it > changes anything. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RE/FW: Please stop sending me emails
yes i kinda figured mails have been sent to him the list administrators and the abuse address of the university his e-mail address is under hopefully one of the 3 will stop this shit sometime soon > -Original Message- > From: Andrew Pollock [mailto:[EMAIL PROTECTED] > Sent: 28 August 2004 01:39 > To: peter green > Cc: Frank Carmickle; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: RE/FW: Please stop sending me emails > > > On Fri, Aug 27, 2004 at 09:48:14PM +0100, peter green wrote: > > can someone please remove this guy from the list before his bloody > > autoresponders drive us all crazy > > It's getting into a loop :-( > His emails go to the list, back to him and around again... > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
