Re: help - vanishing keyboard
On Tue, Nov 21, 2006 at 10:24:37AM +0100, sferriol wrote: > Chris Dunn a ?crit : > >I'm trying (hard) to install Testing or Etch on a Stylistic 3500 tablet. > > > >Sarge installed successfully, but I'm having problems with the boot / > >root diskettes on Testing / Etch. > > > >The Stylistic has an external Fujitsu floppy drive connected, and I > >have a USB keyboard connected. > > > etch installer uses 2.6 kernel instead of sarge (2.4) > and the 2.6 kernel is really bigger than 2.4 so we can not put usb > keyboard drivers on the boot floppy. > So etch installer with floppies does not longer support usb keyboard and > usb floppy driver, sorry :( > may be we will try to find a solution but i think it will be after etch > release > > for you, the only solution is to install a minimal sarge and after > upgrade to etch > Does the tablet have a serial port which you could use as a serial console (using either a terminal or other computer) for the install? Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#399737: Installation Report - Etch RC1 DVD does not install Desktop
Package: installation-reports Boot method: Debian GNU/Linux testing "Etch" - Official Snapshot i386 Binary-1 (20061110), and used installgui Image version: 20061110 Date: 20061120 evening Machine: ASUS P4C800-Deluxe Processor: P4 3.0GHz Memory: 1035944 kB Partitions: P4C800Deluxe:~# fdisk -l /dev/hda Disk /dev/hda: 122.9 GB, 122942324736 bytes 255 heads, 63 sectors/track, 14946 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 63 506016 83 Linux /dev/hda2 64 318 2048287+ 82 Linux swap / Solaris /dev/hda3 * 319 638 2570400 83 Linux /dev/hda4 639 14946 1149290105 Extended /dev/hda5 639307119543041 83 Linux /dev/hda630723084 104391 83 Linux /dev/hda730853097 104391 83 Linux /dev/hda830983110 104391 83 Linux /dev/hda931113123 104391 83 Linux /dev/hda10 31243136 104391 83 Linux /dev/hda11 31373149 104391 83 Linux /dev/hda12 31503162 104391 83 Linux /dev/hda13 31633175 104391 83 Linux /dev/hda14 31763188 104391 83 Linux /dev/hda15 31893201 104391 83 Linux /dev/hda16 32023214 104391 83 Linux /dev/hda17 32153227 104391 83 Linux /dev/hda18 32283240 104391 83 Linux /dev/hda19 3241909347014191 83 Linux /dev/hda20 90949337 1959898+ 83 Linux /dev/hda21 93389580 1951866 83 Linux /dev/hda22 95819823 1951866 83 Linux /dev/hda23 9824 10066 1951866 83 Linux /dev/hda24 10067 10309 1951866 83 Linux /dev/hda25 10310 10552 1951866 83 Linux /dev/hda26 10553 1273017494753+ 83 Linux /dev/hda27 12731 1494617799988+ 83 Linux P4C800Deluxe:~# fdisk -l /dev/sda Disk /dev/sda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 14593 117218241 fd Linux raid autodetect P4C800Deluxe:~# fdisk -l /dev/sdb Disk /dev/sdb: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 14593 117218241 fd Linux raid autodetect P4C800Deluxe:~# fdisk -l /dev/sdc Disk /dev/sdc: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdc1 * 1 14593 117218241 fd Linux raid autodetect /dev/sdc2 14594 29186 117218272+ fd Linux raid autodetect /dev/sdc3 29187 30401 9759487+ fd Linux raid autodetect P4C800Deluxe:~# fdisk -l /dev/sdd Disk /dev/sdd: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdd1 * 1 14593 117218241 fd Linux raid autodetect /dev/sdd2 14594 29186 117218272+ fd Linux raid autodetect /dev/sdd3 29187 30401 9759487+ fd Linux raid autodetect P4C800Deluxe:~# df -Tl FilesystemType 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup1-etch20061102 ext320642428 2668800 16925052 14% / udev tmpfs 10240 224 10016 3% /dev devshm tmpfs 517972 0517972 0% /dev/shm /dev/hda22ext3 1921156 42848 1780716 3% /boot /dev/mapper/VolGroup0-DebianHomes ext320642428179096 19414756 1% /home /dev/hda1 ext3 474244 44138404806 10% /mnt/hdaboot /dev/hda5 ext319236308 9345952 8913204 52% /var/seti P4C800Deluxe:~# mdadm --detail /dev/md* | egrep '/dev|Level|State|UUID' mdadm: /dev/md does not appear to be an md device /dev/md0: Raid Level : raid5 State : clean UUID : cd879c12:f5a85ca8:f5f2f808:03584f68 Number Major Minor RaidDevice State 0 8 330 active sync /dev/sdc1 1 8 491 active sync /dev/sdd1 2 812 active sync /dev/sda1 /dev/md1: Raid Level : raid5 State : clean UUID : 8c357f63:b2e9b928:b1bcd013:ea7c2fe7 Number Major Minor
Re: other fallback languages Re: Deactivated languages
> And until etch+1 you'll even have enough time :) > > Fallback to french instead of english would be very useful in many parts of > africa, not sure about other sensible fallback languages... The mechanism for fallback languages is already here. This is one of the fields of languagelist in localechooser: Northern Sami;1;se;NO;se_NO.UTF-8;se_NO:nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en;kbd=lat0-sun(utf8) However, experience has shown that these fallback languages are usefule for very few languages and, sometimes, things that sound like a good idea initially turn out to be confusing to users (e.g. using Russian as fallback for Ukrainian, or things like this...). And, guess what, even this can lead to political-style problems... So, well, the fallback language is a possible option in a few cases such as Northern Sami abovebut this is not a definitive solution for most of the currently incomplete languages ?
Bug#373145: This seems to be resolved
Hi, I just tested the etch installer rc1 on MS Virtual PC, with two virtual hard disks, partitioned as: hda1, hdb1 = 64MB swap hda2, hdb2 = 1GB RAID The partitioner is still awesome :-) and GRUB is now properly configured: root (hd0,1) So at least I can say that the installer seems to work properly with clean hard disks. Also, I no longer see the "device is already open" error messages that I mentioned previously. I doubt that I can reproduce the conditions that originally resulted in this bug report. -- graham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of glantank_1.1_arm.changes
glantank_1.1_arm.changes uploaded successfully to localhost along with the files: glantank_1.1.dsc glantank_1.1.tar.gz glantank-utils_1.1_arm.deb glantank-installer_1.1_arm.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364650: HTTP timeout is still a problem
Hi, I have just tried the etch installer rc1, and this problem still exists. I still think that the best solution would be to allow me to enter the security URL manually, if I already chose to enter the main archive URL manually. If you can't do that, then please at least reduce the timeout. It is excessively long. I timed 20 minutes on my wristwatch while running the installer inside MS Virtual PC today. Oddly, /var/log/installer/syslog only shows about 9 minutes elapsed, but even that is far too long. Thanks -- graham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392480: debian-installer: add support for "cleaning" hard drives
David =?iso-8859-1?Q?H=E4rdeman?= writes... > If you are concerned with the safety of your personal data being left > from a previous installation, I assume you're also (and even more so) > worried about your personal data being kept safe in the new > installation? > > If so, I'd assume that you'd do an install to an encrypted > partition...and if you do, debian-installer (or partman-crypto to be > more precise) will already wipe the disk with one round of random data. > > That should be sufficient for anything but the worst tin foil hat > scenarios. I recently discovered that Peter Gutmann added an Epilogue to his original paper, http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html (search for Epilogue) or reprinted at http://www.forensicswiki.org/wiki/Epilogue_to_Gutmann's_1996_paper in it he explains that with modern drives, a few passes of random data is the best you can hope to do. I think your suggestion of using partman-crypto to wipe the disk with one round of random data is probably OK. I haven't tried using it yet, can you do this step without also creating a new crypto filesystem on the disk as well? Ideally you could just do the wipe only so if you were just trying to clean the disk you could stop there and not bother to put anything else on it(for cleanliness reasons, not because of the time/cpu it takes to generate the new filesystem). So I consider the wishlist to be able to wipe the disk closed, but I'd like to be able to do it without also creating a new filesystem if possible (this could be in expert mode of course). Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#399805: partman: ability to run outside of d-i
Package: partman Version: 63 Severity: wishlist I had a user ask me the other day if it was possible to run the d-i partitioning tool after the install to setup additional disks. I told him I didn't think so and asked why he didn't use parted or gparted. He replied that this was on his server(so no graphics libs installed) and that he really preferred the d-i interface anyway. That seemed like a reasonable answer to me. So that's what you get for doing such a good job on the partitioner :) This is a wishlist request for the d-i partitioner to be made to run stand-alone outside of d-i on the normal system. (This might also be nice for other things that d-i does as well, joeyh mentions that kamion did this already for user-setup.) Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Archive Automatic Signing Key (4.0/etch)?
On Tue, 21 Nov 2006, Kurt Roeckx wrote: On Tue, Nov 21, 2006 at 04:50:29PM -0600, Peter Samuelson wrote: [Martin Zobel-Helas] gpg --recv-keys A70DAF536070D3A1 && (gpg --export -a A70DAF536070D3A1 | apt-key add -) Uh, don't forget the part about verifying that the key is actually signed by the ftpmasters. Skipping that step pretty much defeats the entire point. gpg --list-sigs A70DAF536070D3A1 Try gpg --check-sigs A70DAF536070D3A1 instead. But Hendrik Sattler is perfectly right and this knowledge has to be stored at prominant places like: a) installation manual b) apt-key.8 c) perhaps somewhere else Could maintainers of a) and b) (and perhaps c) ;-)) acknowledge, that this will be done or should we rather file bug reports (IMHO with severity "important") to these packages? Kind regards Andreas. PS: debian-boot@lists.debian.org in CC because of the installation manual issue. Forgive me if this should be off-topic there. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373145: marked as done (Installation on software RAID fails to boot)
Your message dated Wed, 22 Nov 2006 06:37:58 +0100 with message-id <[EMAIL PROTECTED]> and subject line Bug#373145: This seems to be resolved has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: installation-reports Boot method: Daily i386 netinst CD Image version: downloaded 2006 June 11 Date: 2006 June 12 Machine: Asus P2L-B Processor: Celeron 500MHz Memory: 384MB Partitions: hda1, ~128MB, swap hda2, ~64MB, ext3, /boot hda3, extended partition hda5, ~2GB, software RAID hdb looks identical except that hdb2 isn't mounted. hda5 + hdb5 = md0, RAID 0, root filesystem. I've read that it's now possible to boot from RAID, and I can try that later. The installer was a pleasure to use. It really made the RAID setup process easy. Good job! Output of lspci and lspci -n: Let me know if you need this. Base System Installation Checklist: All OK except for booting from hard disk. Comments/Problems: I'll attach a boot log. Please let me know if I've just done something wrong. Thanks. -- graham Linux version 2.6.15-1-486 (Debian 2.6.15-8) ([EMAIL PROTECTED]) (gcc version 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)) #2 Mon Mar 6 15:19:16 UTC 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 17ffd000 (usable) BIOS-e820: 17ffd000 - 17fff000 (ACPI data) BIOS-e820: 17fff000 - 1800 (ACPI NVS) BIOS-e820: - 0001 (reserved) 383MB LOWMEM available. DMI 2.0 present. ACPI: PM-Timer IO Port: 0xe408 Allocating PCI resources starting at 2000 (gap: 1800:e7ff) Built 1 zonelists Kernel command line: root=/dev/md0 ro console=tty0 console=ttyS1,38400n8 Local APIC disabled by BIOS -- you can enable it with "lapic" Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 501.181 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 381808k/393204k available (1516k kernel code, 10788k reserved, 574k data, 228k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1002.86 BogoMIPS (lpj=501432) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K mtrr: v2.0 (20020519) CPU: Intel Celeron (Mendocino) stepping 05 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0a00) checking if image is initramfs... it is Freeing initrd memory: 4705k freed NET: Registered protocol family 16 EISA bus registered ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=1 PCI: Using configuration type 1 ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (:00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 PCI quirk: region e400-e43f claimed by PIIX4 ACPI PCI quirk: region e800-e80f claimed by PIIX4 SMB PIIX4 devres B PIO at 0290-0297 Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 12 devices PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: 00:01: ioport range 0xe400-0xe43f could not be reserved pnp: 00:01: ioport range 0xe800-0xe80f has been reserved pnp: 00:01: ioport range 0x294-0x297 has been reserved PCI: Bridge: :00:01.0 IO window: disabled. MEM window: d600-d7df PREFETCH window: d7f0-e3ff Simple Boot Flag at 0x46 set to 0x1 audit: initializing netlink socket (disabled) audit(1150152862.306:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io
Translation for Bahasa Malaysia (BM)
Hi all, I would like to announce that we'll be translating Debian-Installer (and possibly other Debian packages) into Bahasa Malaysia (BM). We are a group of open source supporter in Kuching, Sarawak, Malaysia and we promote the usage and adoption of open source to the public, businesses and government in our area. We involve in various activities such as distributing Linux, creating awareness that there are alternatives free and open source software to the existing proprietary software, and so forth. For more information about us, please visit our website at http://www.kuchingosc.org. Thank you. With best regards, Nicholas Ng Kuching Open Source Community Kuching, Sarawak, Malaysia Homepage: www.kuchingosc.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
