Re: SVN problem: committing a file named s...@latin
On Sat, Jul 17, 2010 at 07:36:07PM +0200, Christian PERRIER wrote: I need to add such a file, but svn add apparently chokes on it: bubu...@mykerinos:~/src/debian/debian-installer/installer/build/needed-characters LC_ALL=C svn add s...@latin svn: warning: 'sr' not found bubu...@mykerinos:~/src/debian/debian-installer/installer/build/needed-characters LC_ALL=C svn add s...@latin svn: warning: 'sr' not found Try s...@latin@. For some reason, svn seems to use the @ in this case also for peg revision. Bastian -- ... freedom ... is a worship word... It is our worship word too. -- Cloud William and Kirk, The Omega Glory, stardate unknown -- 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/20100718071518.ga13...@wavehammer.waldi.eu.org
Bug#589528: installation-report: hurd-i386 d-i installation successful!
Package: installation-reports Severity: normal Tags: d-i Hello, This is just to report about a successful d-i installation of the hurd-i386 port using Jeremy Koenig's current image :D -- Package-specific info: Boot method: CD Image version: http://jk.fr.eu.org/debian/hurd-installer/mini.iso built on 17th july 18:15 Date: 18th July Machine: KVM Partitions: Disk /dev/hd0: 1049 MB, 1049624576 bytes 255 heads, 63 sectors/track, 127 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000cd140 Device Boot Start End Blocks Id System /dev/hd0p1 * 1 114 911360 83 Linux /dev/hd0p2 114 128 1105935 Extended /dev/hd0p5 114 128 110592 82 Linux swap / Solaris FilesystemSize Used Avail Use% Mounted on - 890M 269M 578M 32% / 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: [ ] Load installer modules: [ ] Detect hard drives: [O] Partition hard drives: [O] Install base system:[E] Clock/timezone setup: [ ] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: During debootstrap, at some point a find command starts a lot of translators, which fails a bit, I had to restart that step. At the very end (umount and reboot), pidof udevd was hanging. Reboot hadn't rebooted /etc/fstab is not generated. But apart from these, it went just fine within an hour. Samuel -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU installer DISTRIB_RELEASE=6.0 (squeeze) - installer build 20100717-14:33 X_INSTALLATION_MEDIUM=monolithic == Installer hardware-summary: == uname -a: GNU debian 0.3 GNU-Mach 1.3.99/Hurd-0.3 i686-AT386 GNU/Linux lspci -knn: Usage: lspci [switches] lspci -knn: lspci -knn: Basic display modes: lspci -knn: -mm Produce machine-readable output (single -m for an obsolete format) lspci -knn: -t Show bus tree lspci -knn: lspci -knn: Display options: lspci -knn: -v Be verbose (-vv for very verbose) lspci -knn: -x Show hex-dump of the standard part of the config space lspci -knn: -xxxShow hex-dump of the whole config space (dangerous; root only) lspci -knn: - Show hex-dump of the 4096-byte extended config space (root only) lspci -knn: -b Bus-centric view (addresses and IRQ's as seen by the bus) lspci -knn: -D Always show domain numbers lspci -knn: lspci -knn: Resolving of device ID's to names: lspci -knn: -n Show numeric ID's lspci -knn: -nn Show both textual and numeric ID's (names numbers) lspci -knn: -q Query the PCI ID database for unknown ID's via DNS lspci -knn: -qq As above, but re-query locally cached entries lspci -knn: -Q Query the PCI ID database for all ID's via DNS lspci -knn: lspci -knn: Selection of devices: lspci -knn: -s domain]:]bus]:][slot][.[func]] Show only devices in selected slots lspci -knn: -d [vendor]:[device]Show only devices with specified ID's lspci -knn: lspci -knn: Other options: lspci -knn: -i file Use specified ID database instead of /usr/share/misc/pci.ids.gz lspci -knn: -M Enable `bus mapping' mode (dangerous; root only) lspci -knn: lspci -knn: PCI access options: lspci -knn: -A method Use the specified PCI access method (see `-A help' for a list) lspci -knn: -O par=val Set PCI access parameter (see `-O help' for a list) lspci -knn: -G Enable PCI access debugging lspci -knn: -H mode Use direct hardware access (mode = 1 or 2) lspci -knn: -F file Read PCI configuration dump from a given file usb-list: Error: directory /sys/bus does not exist; is sysfs mounted? df: Filesystem 1K-blocks Used Available Use% Mounted on df: df: /proc/mounts: No such file or directory free: /usr/bin/report-hw: line 59: free: not found /proc/meminfo: MemTotal:393276 kB /proc/meminfo: MemFree: 94760 kB /proc/meminfo: Buffers: 0 kB /proc/meminfo: Cached: 0 kB /proc/meminfo: SwapCached: 0 kB /proc/meminfo: Active: 84876 kB /proc/meminfo: Inactive:195428 kB /proc/meminfo: HighTotal: 0 kB /proc/meminfo: HighFree:0 kB /proc/meminfo: LowTotal:0 kB /proc/meminfo:
Bug#589528: marked as done (installation-report: hurd-i386 d-i installation successful!)
Your message dated Sun, 18 Jul 2010 18:07:13 +0200 with message-id 20100718160713.gt3...@mykerinos.kheops.frmug.org and subject line Re: Bug#589528: installation-report: hurd-i386 d-i installation successful! has caused the Debian Bug report #589528, regarding installation-report: hurd-i386 d-i installation successful! 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.) -- 589528: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589528 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-reports Severity: normal Tags: d-i Hello, This is just to report about a successful d-i installation of the hurd-i386 port using Jeremy Koenig's current image :D -- Package-specific info: Boot method: CD Image version: http://jk.fr.eu.org/debian/hurd-installer/mini.iso built on 17th july 18:15 Date: 18th July Machine: KVM Partitions: Disk /dev/hd0: 1049 MB, 1049624576 bytes 255 heads, 63 sectors/track, 127 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000cd140 Device Boot Start End Blocks Id System /dev/hd0p1 * 1 114 911360 83 Linux /dev/hd0p2 114 128 1105935 Extended /dev/hd0p5 114 128 110592 82 Linux swap / Solaris FilesystemSize Used Avail Use% Mounted on - 890M 269M 578M 32% / 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: [ ] Load installer modules: [ ] Detect hard drives: [O] Partition hard drives: [O] Install base system:[E] Clock/timezone setup: [ ] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: During debootstrap, at some point a find command starts a lot of translators, which fails a bit, I had to restart that step. At the very end (umount and reboot), pidof udevd was hanging. Reboot hadn't rebooted /etc/fstab is not generated. But apart from these, it went just fine within an hour. Samuel -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU installer DISTRIB_RELEASE=6.0 (squeeze) - installer build 20100717-14:33 X_INSTALLATION_MEDIUM=monolithic == Installer hardware-summary: == uname -a: GNU debian 0.3 GNU-Mach 1.3.99/Hurd-0.3 i686-AT386 GNU/Linux lspci -knn: Usage: lspci [switches] lspci -knn: lspci -knn: Basic display modes: lspci -knn: -mm Produce machine-readable output (single -m for an obsolete format) lspci -knn: -t Show bus tree lspci -knn: lspci -knn: Display options: lspci -knn: -v Be verbose (-vv for very verbose) lspci -knn: -x Show hex-dump of the standard part of the config space lspci -knn: -xxxShow hex-dump of the whole config space (dangerous; root only) lspci -knn: - Show hex-dump of the 4096-byte extended config space (root only) lspci -knn: -b Bus-centric view (addresses and IRQ's as seen by the bus) lspci -knn: -D Always show domain numbers lspci -knn: lspci -knn: Resolving of device ID's to names: lspci -knn: -n Show numeric ID's lspci -knn: -nn Show both textual and numeric ID's (names numbers) lspci -knn: -q Query the PCI ID database for unknown ID's via DNS lspci -knn: -qq As above, but re-query locally cached entries lspci -knn: -Q Query the PCI ID database for all ID's via DNS lspci -knn: lspci -knn: Selection of devices: lspci -knn: -s domain]:]bus]:][slot][.[func]] Show only devices in selected slots lspci -knn: -d [vendor]:[device]Show only devices with specified ID's lspci -knn: lspci -knn: Other options: lspci -knn: -i file Use specified ID database instead of /usr/share/misc/pci.ids.gz lspci -knn: -M Enable `bus mapping' mode (dangerous; root only) lspci -knn: lspci -knn: PCI access options: lspci -knn: -A method Use the specified PCI access method (see `-A
Bug#589579: debian-installer: i386 kernel flavour selection is poor
Package: debian-installer
Tags: squeeze patch
There are several problems with the current selection:
1. 686-bigmem is not preferred when there is RAM above 4GB
2. 686-bigmem is not always offered where it is usable, and amd64 is
never offered
3. The 686 flavour is considered unsuitable for some AMD K7 processors
Problem 3 appears to be due to a workaround for an incorrect kernel
configuration. The comment on this exclusion is 'May not have SSE
support', but this has never been a requirement for the 686 flavour.
(The Pentium Pro and Pentium II don't have SSE either.)
This patch rewrites the flavour selection so that:
1. 686-bigmem is preferred when there is RAM above 4GB, otherwise 686 is
preferred
2. All usable flavours are offered
3. The 686 flavour is considered suitable for all K7 processors
It updates the tests accordingly, adding amd64 to the usable/unusable
flavours lists and adding a test case for RAM above 4GB.
Ben.
Index: packages/base-installer/kernel/i386.sh
===
--- packages/base-installer/kernel/i386.sh (revision 63990)
+++ packages/base-installer/kernel/i386.sh (working copy)
@@ -1,45 +1,94 @@
arch_get_kernel_flavour () {
- VENDOR=`grep '^vendor_id' $CPUINFO | head -n1 | cut -d: -f2`
- FAMILY=`grep '^cpu family' $CPUINFO | head -n1 | cut -d: -f2`
- MODEL=`grep '^model[[:space:]]*:' $CPUINFO | head -n1 | cut -d: -f2`
+ # Should we offer an amd64 kernel?
+ local HAVE_LM
+ if grep -q '^flags.*\blm\b' $CPUINFO; then
+ HAVE_LM=y
+ else
+ HAVE_LM=n
+ fi
- # Only offer bigmem if the system supports PAE and the
- # installer itself is already using a bigmem kernel.
- if grep '^flags' $CPUINFO | grep -q pae ; then
- case $KERNEL_FLAVOUR in
- 686-bigmem*) BIGMEM=-bigmem ;;
- *) ;;
- esac
+ # Should we offer a bigmem kernel?
+ local HAVE_PAE
+ if grep -q '^flags.*\bpae\b' $CPUINFO; then
+ HAVE_PAE=y
+ else
+ HAVE_PAE=n
fi
+ # Should we prefer a bigmem/amd64 kernel - is there RAM above 4GB?
+ local WANT_PAE
+ if [ -z $RAM_END ]; then
+ local MAP MAP_END
+ RAM_END=0
+ for MAP in /sys/firmware/memmap/* ; do
+ if [ $(cat $MAP/type) = System RAM ]; then
+ MAP_END=$(cat $MAP/end)
+ if [ $(($MAP_END $RAM_END)) = 1 ]; then
+ RAM_END=$MAP_END
+ fi
+ fi
+ done
+ fi
+ if [ $(($RAM_END 0x1)) = 1 ]; then
+ WANT_PAE=y
+ else
+ WANT_PAE=n
+ fi
+ # or is the installer running a 686-bigmem kernel?
+ case $KERNEL_FLAVOUR in
+ 686-bigmem*)
+ WANT_PAE=y
+ ;;
+ esac
+
+ case $HAVE_LM$HAVE_PAE$WANT_PAE in
+ yyy)
+ echo 686-bigmem amd64 686 486
+ return 0
+ ;;
+ yyn)
+ echo 686 686-bigmem amd64 486
+ return 0
+ ;;
+ yn?)
+ warning Processor with LM but no PAE???
+ ;;
+ nyy)
+ echo 686-bigmem 686 486
+ return 0
+ ;;
+ nyn)
+ echo 686 686-bigmem 486
+ return 0
+ ;;
+ nn?)
+ # Need to check whether 686 is suitable
+ ;;
+ esac
+
+ local VENDOR FAMILY MODEL
+ VENDOR=$(sed -n 's/^vendor_id\s*: //; T; p; q' $CPUINFO)
+ FAMILY=$(sed -n 's/^cpu family\s*: //; T; p; q' $CPUINFO)
+ MODEL=$(sed -n 's/^model\s*: //; T; p; q' $CPUINFO)
+
case $VENDOR in
-AuthenticAMD*)
+ AuthenticAMD*)
case $FAMILY in
-15| 16| 17) # k8
- echo 686$BIGMEM
- ;;
-6) # k7
- case $MODEL in
-0| 1| 2| 3| 4| 5)
- # May not have SSE support
- echo 486 ;;
- *) echo 686$BIGMEM ;;
- esac
- ;;
+ 6|15|16|17) echo 686 486 ;;
*) echo 486 ;;
esac
;;
-GenuineIntel)
+ GenuineIntel)
case $FAMILY in
-6| 15) echo 686$BIGMEM ;;
+ 6|15) echo 686 486 ;;
*) echo 486 ;;
esac
;;
-CentaurHauls)
+ CentaurHauls)
case $FAMILY in
Bug#589579: debian-installer: i386 kernel flavour selection is poor
On Sunday 18 July 2010, Ben Hutchings wrote: 3. The 686 flavour is considered unsuitable for some AMD K7 processors Problem 3 appears to be due to a workaround for an incorrect kernel configuration. The comment on this exclusion is 'May not have SSE support', but this has never been a requirement for the 686 flavour. (The Pentium Pro and Pentium II don't have SSE either.) This has been discussed, changed, and revisited several times. There have been long threads about it and IIRC also various bug reports from users. Can you really *guarantee* that 686 will work with *all* K7 processors? I've not checked the archives, but I'm not sure whether SSE support really was the reason for the current code, or whether there were also other factors. -- 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/201007182308.54119.elen...@planet.nl
Bug#589579: debian-installer: i386 kernel flavour selection is poor
On Sunday 18 July 2010, Ben Hutchings wrote: + if grep -q '^flags.*\blm\b' $CPUINFO; then Has this been tested with busybox shell? Does busybox' grep understand '\b'? I don't recall us using it anywhere else in 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/201007182311.27149.elen...@planet.nl
Bug#589579: debian-installer: i386 kernel flavour selection is poor
On Sun, 2010-07-18 at 23:08 +0200, Frans Pop wrote: On Sunday 18 July 2010, Ben Hutchings wrote: 3. The 686 flavour is considered unsuitable for some AMD K7 processors Problem 3 appears to be due to a workaround for an incorrect kernel configuration. The comment on this exclusion is 'May not have SSE support', but this has never been a requirement for the 686 flavour. (The Pentium Pro and Pentium II don't have SSE either.) This has been discussed, changed, and revisited several times. There have been long threads about it and IIRC also various bug reports from users. Can you really *guarantee* that 686 will work with *all* K7 processors? I've not checked the archives, but I'm not sure whether SSE support really was the reason for the current code, or whether there were also other factors. You introduced this behaviour shortly after the k7 flavour was removed and there has been no change to it since. The previous discussion appears to be in http://bugs.debian.org/490542. Dann disagreed with this exclusion and you said it was based on information from Max and Colin. So I'll cc all parties in the hope of clearing this up. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#589579: debian-installer: i386 kernel flavour selection is poor
On Sun, 2010-07-18 at 23:11 +0200, Frans Pop wrote: On Sunday 18 July 2010, Ben Hutchings wrote: + if grep -q '^flags.*\blm\b' $CPUINFO; then Has this been tested with busybox shell? Does busybox' grep understand '\b'? I don't recall us using it anywhere else in D-I. This works with 'busybox grep' from the busybox package, so unless it is an optional feature it should work in d-i. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#589579: debian-installer: i386 kernel flavour selection is poor
On Sunday 18 July 2010, Ben Hutchings wrote: On Sun, 2010-07-18 at 23:11 +0200, Frans Pop wrote: On Sunday 18 July 2010, Ben Hutchings wrote: + if grep -q '^flags.*\blm\b' $CPUINFO; then Has this been tested with busybox shell? Does busybox' grep understand '\b'? I don't recall us using it anywhere else in D-I. This works with 'busybox grep' from the busybox package, so unless it is an optional feature it should work in d-i. OK. Thanks for verifying. -- 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/201007190034.54576.elen...@planet.nl
