Bug#719040: marked as done (installation-report: debian 7.1 wheezy installation success on PS3)
Your message dated Thu, 8 Aug 2013 12:47:35 +0200 with message-id 20130808104735.gv5...@mykerinos.kheops.frmug.org and subject line Re: Bug#719040: installation-report: debian 7.1 wheezy installation success on PS3 has caused the Debian Bug report #719040, regarding installation-report: debian 7.1 wheezy installation success on PS3 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 this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 719040: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719040 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-reports Version: 2.49 Severity: normal Dear Maintainer, Installed from CD-ROM media. Install went as expected. Followed the PS3 install instructions here: https://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-howto/ps3-debian-install-howto.txt -- Package-specific info: Boot method: network Image version: debian-7.1.0-powerpc-netinst.iso Date: August 7, 2013 Machine: Sony PS3 Game Console Partitions: df -Tl will do; the raw partition table is preferred 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] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[O] Comments/Problems: Needed to add /etc/kboot.conf manually after install finished as described in ps3-debian-install-howto.txt. -- == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=7 (wheezy) - installer build 20130613 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux ps3 3.2.0-4-powerpc64 #1 SMP Debian 3.2.46-1 ppc64 GNU/Linux usb-list: usb-list: Bus 01 Device 01: PS3 EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 3.2.0-4-powerpc64 ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 01 Device 02: USB2.0 Hub [05e3:0607] usb-list:Level 01 Parent 01 Port 01 Class 09(hub ) Subclass 00 Protocol 02 usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 02 Driver hub usb-list: usb-list: Bus 01 Device 03: Generic USB Hub [04fe:0008] usb-list:Level 02 Parent 02 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Chicony usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 01 Device 04: PFU-65 USB Keyboard [04fe:0006] usb-list:Level 03 Parent 03 Port 00 Class 00(ifc ) Subclass 00 Protocol 00 usb-list:Manufacturer: Chicony usb-list:Interface 00: Class 03(HID ) Subclass 01 Protocol 01 Driver usbhid usb-list: usb-list: Bus 01 Device 05: USB Optical Mouse [192f:0416] usb-list:Level 03 Parent 03 Port 02 Class 00(ifc ) Subclass 00 Protocol 00 usb-list:Interface 00: Class 03(HID ) Subclass 01 Protocol 02 Driver usbhid usb-list: usb-list: Bus 02 Device 01: PS3 EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 3.2.0-4-powerpc64 ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 02: Bluetooth Transceiver [054c:0267] usb-list:Level 01 Parent 01 Port 01 Class e0(wlcon) Subclass 01 Protocol 01 usb-list:Manufacturer: Sony usb-list:Interface 00: Class e0(wlcon) Subclass 01 Protocol 01 Driver none usb-list:Interface 01: Class e0(wlcon) Subclass 01 Protocol 01 Driver none usb-list:Interface 02: Class e0(wlcon) Subclass 01 Protocol 01 Driver none usb-list:Interface 03: Class fe(app. ) Subclass 01 Protocol 00 Driver none usb-list: usb-list: Bus 03 Device 01: PS3 OHCI Host Controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 3.2.0-4-powerpc64 ohci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 04 Device 01: PS3 OHCI Host Controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass
Bug#719101: netcfg: provide a clean way to change default hostname (for derivatives)
Package: netcfg Version: 1.110 Severity: wishlist For Kali, we obviously wanted to have kali as the default hostname. Up to now we just used to add this in preseed.cfg in our installer initrd: # Change default hostname d-i netcfg/get_hostname string kali d-i netcfg/get_hostname seen false Unfortunately this has bad side-effects such as the impossibility to actually automate a PXE install because the seen flag is always reset to false (even if we pass hostname=kali on the kernel command line). That's because the preseed in the initrd is evaluated after the preseed for the kernel command line and takes precedence over it. Thus I would suggest to add another preseed_variable netcfg/default_hostname that would be used as default value when asking the question for netcfg/get_hostname. The derivatives could preseed netcfg/default_hostname to adjust the default hostname and the end-users still have the possibility to preseed netcfg/default_hostname to automate installs. Would this be possible? Cheers, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20130808131112.2224.3579.report...@x230-buxy.home.ouaza.com
Bug#719101: netcfg: provide a clean way to change default hostname (for derivatives)
Raphaël Hertzog hert...@debian.org (2013-08-08): Package: netcfg Version: 1.110 Severity: wishlist For Kali, we obviously wanted to have kali as the default hostname. Up to now we just used to add this in preseed.cfg in our installer initrd: # Change default hostname d-i netcfg/get_hostname string kali d-i netcfg/get_hostname seen false Unfortunately this has bad side-effects such as the impossibility to actually automate a PXE install because the seen flag is always reset to false (even if we pass hostname=kali on the kernel command line). Use hostname?=kali on the kernel command line instead? Mraw, KiBi. -- 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/20130808140947.ga27...@mraw.org
Bug#719101: netcfg: provide a clean way to change default hostname (for derivatives)
On Thu, 08 Aug 2013, Cyril Brulebois wrote: Unfortunately this has bad side-effects such as the impossibility to actually automate a PXE install because the seen flag is always reset to false (even if we pass hostname=kali on the kernel command line). Use hostname?=kali on the kernel command line instead? That goes in the opposite direction. This ensures that the seen flag stays at false. I really want seen=true so that the question is not displayed but since the initrd contains seen=false, the seen=true set by the early preseed from the kernel command line is reverted... At least that's my understanding of the problem I have been experiencing. Another solution would be to have a two-step parsing of kernel command line preseeds, we could add !hostname=kali or something like that would be only parsed after the initrd preseed and would thus override those set there. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130808154233.ga17...@x230-buxy.home.ouaza.com
Re: your mail
On Wed, Aug 07, 2013 at 07:36:28PM -0700, Alan Hutchinson wrote: Hi there My name is Alan Hutchinson and I would like to install Debian on a raid 0 system that I have at home , on my home network that I created, I have bean reading up on some of the things that I will need to complete a successful install, for example the raid manager (MDADM) and you also mentioned DebianInstaller does not include a driver for my xyz network card, but I have (tarball) driver sources. What are the steps for building that driver? My home server has a RAID for most of its storage. It's a software RAID. WHen I bought the controller card for my machine (so I could get more SATA drives on it) it turned out to be a RAID controller. I completely ignored its RAID capabilities, opting to use Debian's excellent md support instead. I created large primary partitions on my IDE hard drives to contain one RAID, and large partitions on my 3-terabyte drives for the second RAID. Yes, that's right, two independent RAIDS -- the IDE drives for legacy stuff, the new 3T drives for newer (ald larger) stuff. My long-term plans are for the IDE drives to be replaced by still bigger drives in a year or two when they become necessary. And within those RAIDs I used LVM for flexibility in allocating partitions of flexible size. To make everything work smoothly, hpwever, it helped to (a) use gdisk instead of fdisk onthe new huge drives. fdisk doesn't work anh more in 3T drives -- they're too big. (b) make sure that there was a working boot partition outside of the RAID. Some bootloaders had problems with boot partitions on LVM on RAID. (c) made sure that the first physical partition on the drive contianing /boot starte *after* the first cylinder. Apparently LILO now needed more space than it used to, and it needs to invade the first cylinder. (d) I use the badblocks program to do a full-surface destructive read-write test of every disk drive I buy. Yes, it can take longer than a week, so I buy them one at a time, even if I plan to use them in pairs. But about 20% of them fail the test, and are immediately exchanged. I no longer worry that I'm being excessively paranoid. I'm now testing my second USB backup drive. My plan it to keep at least one backup drive off-site at all times. I use rdiff-backup; it keeps history. Also, I made sure I could boot from either grub2 in the usual manner, or from LILO on a floppy. I test them regularly to make sure they both work. If either ever fails during an upgrade, I still have the other. Finally, I'm doing the whole thing using wheezy. It seems to be the first Debian release that fully supports disk hardware write blocks -- even through LVM -- so that file systems like ext3 and ext4 have a reasonable chance of processing their journals properly even in the presence of unexpected power failures. -- hendrik A: It's possible to do this, but we do not yet have good end-user docs explaining how to do so. We're waiting for an end user to accomplish it and write them from experience. We're glad to help you through the process, I have a brand new D-LINK 2320 that I would like to install with Debian installation, I have not tried to do an LSPCI-V on the raid hardware as yet, I can do that with PUREDYNE, and send you the data , B.F.N Alan Hutchinson . -- hendrik -- 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/20130808172627.ga24...@topoi.pooq.com
Debian installer build: failed or old builds
Debian installer build overview --- Failed or old builds: * OLD BUILD:ia64 May 26 00:12 buildd@alkman build_cdrom http://d-i.debian.org/daily-images/ia64/daily/build_cdrom.log * OLD BUILD:ia64 May 26 00:16 buildd@alkman build_netboot http://d-i.debian.org/daily-images/ia64/daily/build_netboot.log * FAILED BUILD: kfreebsd-amd64 Aug 08 00:32 buildd@fano build_netboot http://d-i.debian.org/daily-images/kfreebsd-amd64/daily/build_netboot.log * FAILED BUILD: kfreebsd-amd64 Aug 08 00:34 buildd@fano build_netboot-9 http://d-i.debian.org/daily-images/kfreebsd-amd64/daily/build_netboot-9.log * FAILED BUILD: kfreebsd-amd64 Aug 08 00:37 buildd@fano build_netboot-gtk http://d-i.debian.org/daily-images/kfreebsd-amd64/daily/build_netboot-gtk.log * FAILED BUILD: kfreebsd-amd64 Aug 08 00:40 buildd@fano build_netboot-gtk-9 http://d-i.debian.org/daily-images/kfreebsd-amd64/daily/build_netboot-gtk-9.log * FAILED BUILD: kfreebsd-i386 Aug 09 00:33 buildd@finzi build_netboot http://d-i.debian.org/daily-images/kfreebsd-i386/daily/build_netboot.log * FAILED BUILD: kfreebsd-i386 Aug 09 00:36 buildd@finzi build_netboot-9 http://d-i.debian.org/daily-images/kfreebsd-i386/daily/build_netboot-9.log Totals: 158 builds (6 failed, 2 old) -- 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/e1v7b3o-0002b0...@ravel.debian.org
