Re: Structural changes needed for switch to 2.6.25 kernels
On Wed, 2008-05-28 at 02:14 +0200, Frans Pop wrote: Today I have done the initial work to prepare the switch to 2.6.25 for D-I. Now seems like a good time to remind you that I would like to add -686-bigmem kernel udebs to the mix to support running D-I under PAE Xen. http://lists.debian.org/debian-boot/2008/05/msg00271.html Cheers, Ian. -- Ian Campbell Most people's favorite way to end a game is by winning. signature.asc Description: This is a digitally signed message part
Beta2 ready for testing (was: debian-installer source upload scheduled for 05/22/2008 and updated timeline)
On Thursday 22 May 2008, Otavio Salvador wrote: Date What happens May 22, 2008 debian-installer is uploaded May 26, 2008 daily images are changed to use lenny installer May 28, 2008 test of images starts Weekly built CD images based on D-I beta2 are now available. I've also asked Steve to switch the daily CD images over to lenny_d-i. CD images can be downloaded using the weekly/daily images sections on: http://www.debian.org/devel/debian-installer/ The beta1 links on that page should *not* be used. Other images (netboot etc.) can be found at: http://ftp.nl.debian.org/debian/dists/testing/main/installer-arch/images/ Please help test the installer, especially on the not-so-common architectures and let us know the result! Cheers, FJP P.S. Note that the sid_d-i daily CD images are still outdated for a number of arches due to the ssl security issue. signature.asc Description: This is a digitally signed message part.
Re: wpasupplicant udeb
On Monday 26 May 2008, Kel Modderman wrote: Trying to associate with 00:13:10:41:7e:1f (SSID='kelnet' freq=2412 MHz) Associated with 00:13:10:41:7e:1f WPA: Key negotiation completed with 00:13:10:41:7e:1f [PTK=TKIP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 00:13:10:41:7e:1f completed (auth) [id=6 id_str=kelnet] OK. These definitely look useful to have. The debugging may not be useful per default, but it could just be worth keeping so that there is an attack vector for people reporting problems about using a wpa enabled netcfg, so that they be able to manually invoke wpa_supplicant on another terminal to capture output for analysis (eg. to find out why association to desired access point failed). It just depends if this need is valid and able to offset the desire for very small binary size. It would be really great if we could keep the standard messages, but drop the lower level ones. But I guess that would require an upstream change. Any chance of that do you think? IMO the size of the udeb is quite reasonable already. Reducing it further would be nice, but is not a hard requirement for implementing WPA support for default installations. Note: please do not upload yet. One thing I'm not yet certain of is what priority the udeb should have and how it should be loaded. This will need some discussion. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#483047: marked as done (installation-report: missing modules)
Your message dated Wed, 28 May 2008 12:49:55 +0200 with message-id [EMAIL PROTECTED] and subject line Re: Bug#483047: installation-report: missing modules has caused the Debian Bug report #483047, regarding installation-report: missing modules 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 [EMAIL PROTECTED] immediately.) -- 483047: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483047 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: installation-reports Version: 2.35 Severity: normal -- Package-specific info: Boot method: DVD Image version: http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso Date: Date and time of the install Machine: AMD64 2800+ 1.8Ghz 500MB ram Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[ ] Configure network: [ ] Detect CD: [O] Load installer modules: [E] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: I can't install lenny using the current weekly build dated May 26/08 (also May 22/08). The install was going fine until load installer components from CD. The DVD's pass the integrity check so I think the media is OK. -- 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 [EMAIL PROTECTED] == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=lenny (installer build 20080513-10:57) X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == umame -a: Linux office 2.6.24-1-amd64 #1 SMP Fri Apr 18 23:08:22 UTC 2008 x86_64 unknown lspci -knn: 00:00.0 Host bridge [0600]: nVidia Corporation nForce3 250Gb Host Bridge [10de:00e1] (rev a1) lspci -knn: Kernel driver in use: agpgart-amd64 lspci -knn: 00:01.0 ISA bridge [0601]: nVidia Corporation nForce3 250Gb LPC Bridge [10de:00e0] (rev a2) lspci -knn: 00:01.1 SMBus [0c05]: nVidia Corporation nForce 250Gb PCI System Management [10de:00e4] (rev a1) lspci -knn: 00:02.0 USB Controller [0c03]: nVidia Corporation CK8S USB Controller [10de:00e7] (rev a1) lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: Kernel modules: ohci-hcd lspci -knn: 00:02.1 USB Controller [0c03]: nVidia Corporation CK8S USB Controller [10de:00e7] (rev a1) lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: Kernel modules: ohci-hcd lspci -knn: 00:02.2 USB Controller [0c03]: nVidia Corporation nForce3 EHCI USB 2.0 Controller [10de:00e8] (rev a2) lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: Kernel modules: ehci-hcd lspci -knn: 00:05.0 Bridge [0680]: nVidia Corporation CK8S Ethernet Controller [10de:00df] (rev a2) lspci -knn: Kernel driver in use: forcedeth lspci -knn: Kernel modules: forcedeth lspci -knn: 00:06.0 Multimedia audio controller [0401]: nVidia Corporation nForce3 250Gb AC'97 Audio Controller [10de:00ea] (rev a1) lspci -knn: 00:08.0 IDE interface [0101]: nVidia Corporation CK8S Parallel ATA Controller (v2.5) [10de:00e5] (rev a2) lspci -knn: Kernel driver in use: AMD_IDE lspci -knn: Kernel modules: generic, amd74xx lspci -knn: 00:0a.0 IDE interface [0101]: nVidia Corporation CK8S Serial ATA Controller (v2.5) [10de:00e3] (rev a2) lspci -knn: Kernel driver in use: sata_nv lspci -knn: Kernel modules: sata_nv, generic lspci -knn: 00:0b.0 PCI bridge [0604]: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge [10de:00e2] (rev a2) lspci -knn: 00:0e.0 PCI bridge [0604]: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge [10de:00ed] (rev a2) lspci -knn: 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] lspci -knn: 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] lspci -knn: 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] lspci -knn: 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
Re: d-i status wrt i386 amd64 EFI machines
On Sunday 25 May 2008, Julien BLACHE wrote: Which brings us to the core of the issue. Installing rEFIt means: - copying rEFIt to the EFI system partition (first partition on the disk, FAT32, ca. 200 MB on Apple machines) This may also require changes in partman, especially in guided partitioning if it should be possible to reuse a pre-existing EFI system partition. There already is code to recognize Intel Macs as a separate subarch which allows to use separate partitioning recipes that could include a EFI system partition, but currently that means the existing one would probably be lost. Not sure how EFI based servers (when booted as pure EFI) should be recognized. Also as a separate subarch? By special casing them? OTOH, I would expect most sysadmins of servers to do manual partitioning anyway. signature.asc Description: This is a digitally signed message part.
Re: d-i status wrt i386 amd64 EFI machines
On Sunday 25 May 2008, Julien BLACHE wrote: Yes, it seems we can add EFI support to the current CD images and don't need additional CD images. Adding an alternative El Torito boot image is enough. The firmware is required by the spec to ignore legacy boot entries. The Apple firmware presents the legacy entries and the EFI entries, labelled as such. Note that we also have a combined i386/amd64/powerpc CD. We'd need to check that EFI support can coexist with that, or else somehow exclude it from that image. signature.asc Description: This is a digitally signed message part.
Bug#482854: marked as done (debian installation report)
Your message dated Wed, 28 May 2008 12:50:40 +0200 with message-id [EMAIL PROTECTED] and subject line Re: Bug#482854: debian installation report has caused the Debian Bug report #482854, regarding debian installation 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 this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 482854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482854 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: installation-reports Boot method: CD Image version: http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-kde-CD-1.iso of 2008.05.22 Date: 25 May 2008 Machine: Virtualbox Base System Installation Checklist: Initial boot: [O] Detect network card:[ ] Configure network: [ ] Detect CD: [O] Load installer modules: [E] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Got this message : No kernel modules were found. This probably is due to a mismatch between ther kernel used by this version of the installer and the kernel version available in the archive. (...) It's not the first time I have this issue, I remember of many weekly builds which had the same problem in 2007. ---End Message--- ---BeginMessage--- On Sunday 25 May 2008, Frans Pop wrote: The weekly builds should be fine again after debian-installer (20080522) migrates to testing. New weekly images based on beta2 are now available. Cheers, FJP ---End Message---
Re: wpasupplicant udeb
On Wednesday 28 May 2008 20:59:15 Frans Pop wrote: On Monday 26 May 2008, Kel Modderman wrote: Trying to associate with 00:13:10:41:7e:1f (SSID='kelnet' freq=2412 MHz) Associated with 00:13:10:41:7e:1f WPA: Key negotiation completed with 00:13:10:41:7e:1f [PTK=TKIP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 00:13:10:41:7e:1f completed (auth) [id=6 id_str=kelnet] OK. These definitely look useful to have. Yep. Especially if the pkg-wpa maintainers are responsible for answering to failure reports from wpa_supplicant in debian installer environment, this is the kind of information that will be needed for any clue. The debugging may not be useful per default, but it could just be worth keeping so that there is an attack vector for people reporting problems about using a wpa enabled netcfg, so that they be able to manually invoke wpa_supplicant on another terminal to capture output for analysis (eg. to find out why association to desired access point failed). It just depends if this need is valid and able to offset the desire for very small binary size. It would be really great if we could keep the standard messages, but drop the lower level ones. But I guess that would require an upstream change. Any chance of that do you think? I doubt that. At least not in this upstream development cycle. Not sure how sane it would be to do that either, but it cannot hurt for me to ask if it would be a consideration in the future. IMO the size of the udeb is quite reasonable already. Reducing it further would be nice, but is not a hard requirement for implementing WPA support for default installations. Note: please do not upload yet. One thing I'm not yet certain of is what priority the udeb should have and how it should be loaded. This will need some discussion. No problems. Thanks for the comments. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wpasupplicant udeb
On Wednesday 28 May 2008 20:59:15 Frans Pop wrote:
Note: please do not upload yet.
One thing I'm not yet certain of is what priority the udeb should have and
how it should be loaded. This will need some discussion.
Just for completeness, I have adapted the patch to allow possibility for
kfreebsd udeb to be possible should it ever be needed.
Thanks, Kel.
---
--- a/debian/control
+++ b/debian/control
@@ -38,3 +38,16 @@
to connect to. It also provides a method for browsing 802.11 SSID scan
results, an event history log of messages generated by wpa_supplicant,
and a method to add or edit wpa_supplicant networks.
+
+Package: wpasupplicant-udeb
+Section: debian-installer
+Architecture: any
+XC-Package-Type: udeb
+Depends: ${shlibs:Depends}
+Description: Client support for WPA and WPA2 (IEEE 802.11i)
+ WPA and WPA2 are methods for securing wireless networks, the former
+ using IEEE 802.1X, and the latter using IEEE 802.11i. This software
+ provides key negotiation with the WPA Authenticator, and controls
+ association with IEEE 802.11i networks.
+ .
+ This is a udeb of wpasupplicant for use by the Debian installer.
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,7 @@
WPAGUI=wpa_gui-qt4
CFLAGS = -Wall -g
+UDEB_CFLAGS = -Wall -g -Os
LDFLAGS = -Wl,--as-needed
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -21,8 +22,10 @@
ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
CONFIG := debian/config/kfreebsd
+ CONFIG_UDEB := debian/config/kfreebsd.udeb
else
CONFIG := debian/config/linux
+ CONFIG_UDEB := debian/config/linux.udeb
endif
@@ -62,6 +65,13 @@
dh_testroot
dh_clean -k
dh_installdirs
+ dh_install
+
+ # udeb for debian installer
+ $(MAKE) -C wpa_supplicant clean; $(RM) wpa_supplicant/.config
+ cp -v $(CONFIG_UDEB) wpa_supplicant/.config
+ CFLAGS=$(UDEB_CFLAGS) $(MAKE) -C wpa_supplicant wpa_supplicant
+ dh_install -pwpasupplicant-udeb wpa_supplicant/wpa_supplicant sbin/
# ifupdown
install --mode=755 -D debian/ifupdown/ifupdown.sh \
@@ -94,7 +104,6 @@
dh_installchangelogs wpa_supplicant/ChangeLog
dh_installdocs
dh_installexamples
- dh_install
dh_installlogrotate --package=wpasupplicant --name=wpa_action
dh_installlogrotate --package=wpasupplicant --name=wpa_supplicant
dh_installinit --package=wpasupplicant --name=wpa-ifupdown --no-start
-- start 15 0 6 .
--- /dev/null
+++ b/debian/config/kfreebsd.udeb
@@ -0,0 +1,13 @@
+# Debian Installer's wpa_supplicant build time configuration
+CONFIG_DRIVER_BSD=y
+LIBS += -lbsd
+CONFIG_BACKEND=file
+#CONFIG_NO_STDOUT_DEBUG=y
+CONFIG_DEBUG_FILE=y
+CONFIG_NO_AES_EXTRAS=y
+CONFIG_NO_CONFIG_WRITE=y
+CONFIG_NO_CONFIG_BLOBS=y
+CONFIG_MAIN=main
+CONFIG_OS=unix
+CONFIG_ELOOP=eloop
+CONFIG_L2_PACKET=freebsd
--- /dev/null
+++ b/debian/config/linux.udeb
@@ -0,0 +1,12 @@
+# Debian Installer's wpa_supplicant build time configuration
+CONFIG_DRIVER_WEXT=y
+CONFIG_BACKEND=file
+#CONFIG_NO_STDOUT_DEBUG=y
+CONFIG_DEBUG_FILE=y
+CONFIG_NO_AES_EXTRAS=y
+CONFIG_NO_CONFIG_WRITE=y
+CONFIG_NO_CONFIG_BLOBS=y
+CONFIG_MAIN=main
+CONFIG_OS=unix
+CONFIG_ELOOP=eloop
+CONFIG_L2_PACKET=linux
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New speakup-udeb component
(No need to CC me on replies. Thx.) Hi Mario, Samuel, others, The FTP-masters alerted us to the fact that you uploaded a new D-I component to the archive: speakup-udeb. We have an agreement with them that they check with us before approving packages with new udebs. It seems that this is only a very minimal udeb (only three hook scripts) and we're wondering if there is really a justification to have a separate udeb for that. 1) The scripts would possibly fit fine in the rootskel and/or finish-install udebs. 2) There would be a change in D-I needed anyway to get your udeb included in images. 3) Having a udeb in a source package has a cost: it is blocked by default for migrations to testing and causes some release management overhead. So, our questions are: - can you please send us the scripts so we can review them - is there a real reason these scripts need to be in a separate udeb (one reason could be because they may need to be updated with upstream changes in the same source package; another could be that they should not be included for all installation methods) - how were you planning to use these scripts: what images and what architectures; did you already have a patch for D-I to include them Until we have reached agreement on this, the package will not be accepted from NEW. For a next time: please check with us before uploading. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: d-i status wrt i386 amd64 EFI machines
Frans Pop [EMAIL PROTECTED] wrote: Hi, Note that we also have a combined i386/amd64/powerpc CD. We'd need to check that EFI support can coexist with that, or else somehow exclude it from that image. Shouldn't be a problem at first glance; maybe the EFI boot image will need to be the first one on the disk. Anyway, I have all those CD images on the radar. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i status wrt i386 amd64 EFI machines
Frans Pop [EMAIL PROTECTED] wrote: Hi, Which brings us to the core of the issue. Installing rEFIt means: - copying rEFIt to the EFI system partition (first partition on the disk, FAT32, ca. 200 MB on Apple machines) This may also require changes in partman, especially in guided partitioning if it should be possible to reuse a pre-existing EFI system partition. Yes, that's part of the plan. There already is code to recognize Intel Macs as a separate subarch which allows to use separate partitioning recipes that could include a EFI system partition, but currently that means the existing one would probably be lost. Which is not a good idea :) So if Mac 1st partition is FAT32 - mark the partition as being the EFI partition (can be generalized to all the EFI machines I think). Not sure how EFI based servers (when booted as pure EFI) should be recognized. Also as a separate subarch? By special casing them? (i386 || amd64) !Mac efivars loaded - EFI machine OTOH, I would expect most sysadmins of servers to do manual partitioning anyway. So do I. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suboptimal cat usage
On Tue, May 27, 2008 at 05:15:04PM +0200, Frans Pop wrote: On Tuesday 27 May 2008, Philip Hands wrote: I thought I'd have a look through the d-i code for instances of: cat ... | to see if I could find any code with room for improvement, and came up with the attached patch. Any comments before I commit these? (along with relevant changelog entries, of course, and removing the comment about removing a space from the disk name that's only there to annotate the patch) I've had a quick look, but after only a few items I have some doubts... - [ $(cat $file | wc -l) -gt 1 ] || continue + [ $(wc -l $file) -gt 1 ] || continue This is plain broken: $ cat massbuild.versions | wc -l 3 $ wc -l massbuild.versions 3 massbuild.versions Ah, well spotted -- typical that the one that I thought was _so_ obvious that it didn't need testing, did need testing -- Doh! That should be this instead: wc -l massbuild.versions cat file | foo can always be done more efficientlyi as foo file but I generally leave out the redirection if I can get away with it (which of course in this case, I could not :-/ ) I happen to know this one, but I bet there are there other commands that have subtle differences in output when using a file argument versus a pipe. well, we could go for the redirection approach instead, but I'd be very surprised if you found any more such errors, as I'm pretty sure that the other examples were well tested (except that I'll admit to having tested them under busybox on a full Debian system, rather than in a d-i system -- I'll test them all again under d-i proper if you think that there's a danger that busybox varies in its behaviour (which I _seriously_ hope it doesn't) - for dir in $( (cat /tmp/mount.pre /tmp/mount.pre; mountpoints ) | \ -sort -r | uniq -c | grep ^[[:space:]]*1[[:space:]] | \ -sed s/^[[:space:]]*[0-9][[:space:]]//); do + for dir in $(mountpoints | sort -r /tmp/mount.pre /tmp/mount.pre - | uniq -u); do 1) I find the combination of using a pipe _and_ named files for sort unintuitive and less readable Yeah, I'll give you that -- I was wondering if that was such a good idea. 2) Where did the grep and sed statements disappear to? they're a somewhat log-winded reimplementation of uniq -u What they do is: uniq -c --- list each unique line, prefixed with a count of occurrences grep ... --- grep out all the lines that start with a count of 1 sed ... --- strip off the 1 i.e. list all the lines that only occur once, which as uniq(1) says: -u, --unique only print unique lines For improved readability, how about: for dir in $( (cat /tmp/mount.pre /tmp/mount.pre; mountpoints) | \ sort -r | uniq -u); do Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Missing glyphs
On Tue, May 27, 2008 at 1:12 PM, Davide Viti [EMAIL PROTECTED] wrote: Hi Jamil, On Tue, May 27, 2008 at 12:49:13AM +0600, Jamil Ahmed wrote: On Mon, May 26, 2008 at 12:21 AM, Davide Viti [EMAIL PROTECTED] wrote: On Thu, May 22, 2008 at 09:39:57AM +0200, Davide Viti wrote: For bn [2], it seems DOTTED CIRCLE (U+25CC) glyph [4] is missing. [1] http://d-i.alioth.debian.org/gtk-frontend/screenshots/ [2] http://d-i.alioth.debian.org/gtk-frontend/screenshots/2.24-2_vs_2.25-1/common/bn.png [3] http://d-i.alioth.debian.org/gtk-frontend/screenshots/2.24-2_vs_2.25-1/common/zh_CN.png [4] http://www.fileformat.info/info/unicode/char/25cc/index.htm thanx, it has to be a ttf-freefont bug then, will check that. the glyph is definitely not included in current ttf-freefont. Is it a glyph normally found in Bengali text? This glyph is used to indicate combining characters. So I guess all Indic language use it. Actually in your screenshot [2] that part shows wrong spelling. Check my attachment for details. :) thanx for clarifying, does that mean that the problem goes away fixing a typo? No, that glyph will be still missing! :) Caould you please fix that? Yes, I will try to fix the typo shortly. thanx alot, Davide -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIO7RNax2slmJA7HoRAoO1AJ9hXDmm+2cXTwa8bvaZIow43r+uXACg9lwj oXRjSEvrBeUFg95VE1Wm5a0= =P75K -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problems netbooting with 4.0r3 DVDs
Hi - I had some trouble installing the latest stable Debian 4.0r3 on an Intel Pentium platform, though it was a non-standard install. I downloaded the 3 ISO DVD images, put them on a local web server, and loopback mounted them to where I could get at them from an http: URL. I then downloaded netboot.tar.gz from the Debian website and unpacked it into my server's /tftpboot. I was able to netboot fine, but when I tried to point the netboot installer at the loopback mounted ISO images, it just wouldn't take them. It was looking for a Release.gpg file that didn't exist, but even after I copied the one from the website, it still wouldn't take it. I prefer to install this way for two reasons: 1. I've had to install on a machine without a working CD/DVD drive, and 2. I don't have to burn images out to disks this way But it doesn't seem to be supported. Maybe it should be? The basic idea is to loopback mount the ISO images on a local webserver and point everything (apt and friends) at them. -bwb Brent Baccala [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems netbooting with 4.0r3 DVDs
On Wednesday 28 May 2008, Brent Baccala wrote: It was looking for a Release.gpg file that didn't exist, but even after I copied the one from the website, it still wouldn't take it. Of course that won't work. The signature file won't match the contents of the DVD! Try booting the installer with 'debian-installer/allow_unauthenticated=true' as documented in [1]. This skips the authentication check for which the .gpg file is used. But it doesn't seem to be supported. Maybe it should be? The basic idea is to loopback mount the ISO images on a local webserver and point everything (apt and friends) at them. You still won't be able to use more that a single DVD during the installation though. You cannot magically merge them. Cheers, FJP [1] http://www.debian.org/releases/etch/i386/ch05s02.html.en#installer-args signature.asc Description: This is a digitally signed message part.
Re: New speakup-udeb component
Hello,
Ok, I'm the culprit, I should have talked about it with debian-boot.
I thought about putting the scripts (attached to this mail) in a
separate speakup-udeb package because it makes the integration to
the debian installer extremely simple: just add speakup-deb to
installer/build/pkg-list/something/somearchs.cfg and voilà. The idea
was also that in case we needed to change anything, we just had to
upload a new speakup source package.
Frans Pop, le Wed 28 May 2008 18:07:37 +0200, a écrit :
It seems that this is only a very minimal udeb (only three hook scripts) and
we're wondering if there is really a justification to have a separate udeb
for that.
Possibly not, see attached files: speakup-udeb.startup gets run early,
sees the speakup statement on the kernel command line, and in that
case modprobes speakup and disables the framebuffer. In addition to
that, speakup-udeb.debinst selects the text frontend. Eventually,
speakup-udeb.finish-install installs the module on the target system,
and sets the module to be auto-loaded on reboot.
1) The scripts would possibly fit fine in the rootskel and/or finish-install
udebs.
Yes.
2) There would be a change in D-I needed anyway to get your udeb included in
images.
Right.
3) Having a udeb in a source package has a cost: it is blocked by default
for migrations to testing and causes some release management overhead.
And that's where I indeed think I was wrong. That would make the
upcoming git speakup releases a burden, while the udeb scripts will
probably not change.
- is there a real reason these scripts need to be in a separate udeb (one
reason could be because they may need to be updated with upstream changes
in the same source package;
These scripts will actually probably just stay the same.
another could be that they should not be included for all installation
methods)
The scripts by themselves should be fine. The problem is more about
room. Speakup modules need a total of 160KB. If that's fine with any
installation medium, then great, we can just always enable it. We could
also always have the script, and include the modules only in the cases
where we can afford it. Scrips will just not work when the modules are
not available.
- how were you planning to use these scripts: what images and what
architectures; did you already have a patch for D-I to include them
Attached is the patch I've been using for tests, just adding the udeb to
a few archs. In principle, there is no reason to restrain from shipping
speakup to all archs. It's rather about the room constraints.
Samuel
SYNTH=`sed /proc/cmdline -n -e 's/.* speakup\.synth=\([^ ]*\).*/\1/p'`
if [ -n $SYNTH ]
then
modprobe speakup_$SYNTH
debconf-set debian-installer/framebuffer false
fi
SYNTH=`sed /proc/cmdline -n -e 's/.* speakup\.synth=\([^ ]*\).*/\1/p'`
if [ -n $SYNTH ]
then
DEBIAN_FRONTEND=text
export DEBIAN_FRONTEND
fi
SYNTH=`sed /proc/cmdline -n -e 's/.* speakup\.synth=\([^ ]*\).*/\1/p'`
if [ -n $SYNTH ]
then
if apt-install speakup-modules 12
then
echo speakup_$SYNTH /target/etc/modules
fi
fi
Index: build/boot/x86/f8.txt
===
--- build/boot/x86/f8.txt (r�vision 53132)
+++ build/boot/x86/f8.txt (copie de travail)
@@ -12,6 +12,7 @@
Force static network config 0fnetcfg/disable_dhcp=true07
Set keyboard map0fbootkbd=es07
Use Braille tty 0fbrltty=driver,device,texttable07
+Use Speakup 0fspeakup.synth=driver07
Use high contrast accessibility theme 0ftheme=dark07
Select the kde or xfce desktops 0fdesktop=kde07
Index: build/pkg-lists/netboot/alpha.cfg
===
--- build/pkg-lists/netboot/alpha.cfg (r�vision 53132)
+++ build/pkg-lists/netboot/alpha.cfg (copie de travail)
@@ -26,3 +26,5 @@
brltty-udeb
serial-modules-${kernel:Version} ?
usb-serial-modules-${kernel:Version} ?
+
+speakup-udeb
Index: build/pkg-lists/netboot/i386.cfg
===
--- build/pkg-lists/netboot/i386.cfg(r�vision 53132)
+++ build/pkg-lists/netboot/i386.cfg(copie de travail)
@@ -37,3 +37,5 @@
brltty-udeb
serial-modules-${kernel:Version}
usb-serial-modules-${kernel:Version} ?
+
+speakup-udeb
Index: build/pkg-lists/netboot/ppc64.cfg
===
--- build/pkg-lists/netboot/ppc64.cfg (r�vision 53132)
+++ build/pkg-lists/netboot/ppc64.cfg (copie de travail)
@@ -25,5 +25,7 @@
serial-modules-${kernel:Version}
usb-serial-modules-${kernel:Version} ?
+speakup-udeb
+
# IBM Power hypervisor modules, only available on powerpc64.
hypervisor-modules-${kernel:Version} ?
Index: build/pkg-lists/netboot/ia64.cfg
Bug#483469: tasksel: errors during D-I installation
Package: tasksel Version: 2.74 During an installation today I noticed the following errors in the syslog: in-target: my variable @deps masks earlier declaration in same scope at /usr/bin/tasksel line 535. in-target: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. in-target: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. in-target: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. [... loads of repeats ...] in-target: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. in-target: Reading package lists... Note there are two errors: the first in 535 and a lot of repeats for 529. The errors happen at the beginning of tasksel, in the syslog they are shown right after popcon has been purged. The first probably happens before the task dialog, the rest may happen after (6 seconds between first and second). As I already had perl installed at that point, this looks unrelated to the perl-base issue. IMO it would be nice to have this fixed in time for Beta2. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: New speakup-udeb component
On Wednesday 28 May 2008, Samuel Thibault wrote: I thought about putting the scripts (attached to this mail) in a separate speakup-udeb package because it makes the integration to the debian installer extremely simple: just add speakup-deb to installer/build/pkg-list/something/somearchs.cfg and voilà. The idea was also that in case we needed to change anything, we just had to upload a new speakup source package. OK. Given your replies it looks like including it in existing udebs is the better way to go. Based on that I've asked FTP-masters to reject your upload, which clears the way for a new upload without the udeb (if you want, you can use the same version). I'll look at the scripts in detail tomorrow and we can discuss details then. Thanks for the quick response. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: New speakup-udeb component
Samuel Thibault [EMAIL PROTECTED] writes: another could be that they should not be included for all installation methods) The scripts by themselves should be fine. The problem is more about room. Speakup modules need a total of 160KB. If that's fine with any installation medium, then great, we can just always enable it. We could also always have the script, and include the modules only in the cases where we can afford it. Scrips will just not work when the modules are not available. Floppy wouldn't fit them probably. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Structural changes needed for switch to 2.6.25 kernels
On Wednesday 28 May 2008, Frans Pop wrote: If there are no comments I'll commit in about 2 days. After acks from Otavio, Joey and Max I have committed my changes. This means that now porters can start checking for changes in modules. As I said in the last mail, I'm going to leave that to others. It would be good if i386/amd64 got done first and soon as they provide the base for kernel-wedge, but that is no hard requirement. Note that kernel-wedge from SVN is required to do builds for .25. A good command to do test builds is: ./massbuild kbuild -k arch The -k means that the needed kernel images are only downloaded once and get reused. With massbuild there is no need to have the kernels installed. If 25-4 is not yet available for your arch, you can change the version in the massbuild.versions file to -3. Please do not upload .25 kernel udebs yet! Cheers, FJP P.S. I have kept one change back: the addition of isofs-modules to hd-media. Reason is that there is still a (small) chance of an extra upload for Beta2 and this is a post-beta2 change. I'll commit that once Beta2 is final. signature.asc Description: This is a digitally signed message part.
[RFC] Adding a 686-bigmem netboot image for PAE/Xen (was: Structural changes needed for switch to 2.6.25 kernels)
On Wednesday 28 May 2008, Ian Campbell wrote: On Wed, 2008-05-28 at 02:14 +0200, Frans Pop wrote: Now seems like a good time to remind you that I would like to add -686-bigmem kernel udebs to the mix to support running D-I under PAE Xen. I don't see any real objection to adding only a netboot image, except maybe that it may proof too hard to find for users. So at the very least a very good wiki page should be written that includes a link. If anybody else has fundamental objections, I guess this would be a good time to voice them! The fairly trivial patch below is required to add 686-bigmem udebs. Not sure why generic_serial is missing in 686-bigmem. Could be a minor config error in linux-2.6. Instead of the first patch (for testing) you can also just do: rm linux-kernel-di-i386-2.6/modules/i386/serial-modules It would be nice if you could build those, dump them in localudebs, and see if you can figure out what changes are needed in the config dir to add only netboot images for that kernel (if you've never really looked at that it can be a nice challenge; AFAICT changes should only be needed below the installer/build/config dir). Feel free to ask for help if needed. Cheers, FJP diff --git a/packages/kernel/kernel-wedge/modules/serial-modules b/packages/kernel/kernel-wedge/modules/serial-modules index 44de44e..5b2036c 100644 --- a/packages/kernel/kernel-wedge/modules/serial-modules +++ b/packages/kernel/kernel-wedge/modules/serial-modules @@ -1,2 +1,2 @@ -generic_serial +generic_serial ? serial_cs ? diff --git a/packages/kernel/linux-kernel-di-i386-2.6/kernel-versions b/packages/kernel/linux-kernel-di-i386-2.6/kernel-versions index 808bf40..5b415dd 100644 --- a/packages/kernel/linux-kernel-di-i386-2.6/kernel-versions +++ b/packages/kernel/linux-kernel-di-i386-2.6/kernel-versions @@ -1,2 +1,3 @@ # arch version flavour installednamesuffix build-depends i386 2.6.25-2 486 2.6.25-2-486 - linux-image-2.6.25-2-486 +i386 2.6.25-2 686-bigmem2.6.25-2-686-bigmem - linux-image-2.6.25-2-686-bigmem signature.asc Description: This is a digitally signed message part.
Debian installer partitioner confused by USB memory stick
I just installed Debian 4.0r3 on a Linksys NSLU2 (arm-based tiny NAS box), installing the root filesystem onto a 256MB USB flash thumb drive. I ran into an annoying Debian installer issue where the installer appears to try to use the device for the entire thumb drive (rather than a partition), but mkfs.ext3 blocks the process by asking for confirmation. The Debian installer I'm using is from: http://www.slug-firmware.net/d-dls.php. This is the same as the official installer, but include proprietary microcode for the ethernet hardware, which is necessary since I'm installing over the network. My setup: NSLU2 with 256MB thumb flash drive drive on USB port 2 and 1TB hard drive on USB port 1. The hard drive has 512MB of swap set up as /dev/sda1, and the rest as a partition I'll use for user data on /dev/sda2. I want to install Debian's root on the flash drive (/dev/sdb) to avoid accessing the disk too much, so it can spin down when idle. My procedure: - Flash Debian 4.0r3 firmware from http://www.slug-firmware.net/d-dls.php - Boot slug. - ssh in as installer. - Proceed to partitioning step. - Because the NSLU2 has too little RAM, we need to create a swap partition early. In another terminal, ssh in, go to shell, run 'mkswap /dev/sda1' and 'swapon /dev/sda1'. - Choose manual partitioning in installer. - Set up /dev/sdb1 as ext3, mounted on '/'. Oddly, it doesn't show the partitions on /dev/sda (SCSI1): ┌┤ [!!] Partition disks ├─┐ │ │ │ This is an overview of your currently configured partitions and mount │ │ points. Select a partition to modify its settings (file system, mount │ │ point, etc.), a free space to create partitions, or a device to │ │ initialise its partition table. │ │ │ │Guided partitioning │ │Help on partitioning │ │ │ │/dev/mtdblock0 - 262.1 kB Unknown │ │/dev/mtdblock1 - 131.1 kB Unknown │ │/dev/mtdblock2 - 131.1 kB Unknown │ │/dev/mtdblock3 - 1.4 MB Unknown │ │/dev/mtdblock4 - 6.3 MB Unknown │ │/dev/mtdblock5 - 131.1 kB Unknown │ │SCSI1 (0,0,0) (sda) - 1.0 TB PI-202US SATA/USB20 Drive │ │SCSI2 (0,0,0) (sdb) - 259.5 MB LEXAR JUMPDRIVE PHOTO │ │ #1 259.5 MB F ext3 / │ │ │ │Undo changes to partitions │ │Finish partitioning and write changes to disk │ │ │ │ Go Back │ │ │ └─┘ - Continue. It hangs on this screen: ┌┤ Partitions formatting ├┐ │ │ │ 33% │ │ │ │ Creating ext3 file system for / in partition #1 of SCSI2 (0,0,0) │ │ (sdb)... │ └─┘ Running ps in a shell reveals: 11321 root564 S udpkg --configure --force-configure partman-base 11322 root492 S /bin/sh /var/lib/dpkg/info/partman-base.postinst conf 11323 root680 S /bin/sh /bin/partman 11599 root876 S parted_server 16361 root672 S /bin/sh /lib/partman/commit.d/50format_ext3 16480 root484 S log-output -t partman --pass-stdout mkfs.ext3 /dev/sc 16481 root556 S mkfs.ext3 /dev/scsi/host1/bus0/target0/lun0/disc If I manually run the mkfs.ext3 command, I get: /var/log # mkfs.ext3 /dev/scsi/host1/bus0/target0/lun0/disc mke2fs 1.40-WIP (14-Nov-2006) /dev/scsi/host1/bus0/target0/lun0/disc is entire device, not just one partition! Proceed anyway? (y,n) n Looks like partman is invoking mkfs for the whole device and hanging while mkfs asks for confirmation! Here's my crude workaround: / # mkfs.ext3 /dev/sdb mke2fs 1.40-WIP (14-Nov-2006) /dev/sdb is entire device, not just one partition! Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 63488 inodes, 253440 blocks 12672 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67371008 31 block groups 8192 blocks per group, 8192 fragments per group 2048 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 33 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. / # cd /sbin /sbin # mv mkfs.ext3 mkfs.ext3.real /sbin # echo '#!/bin/sh' mkfs.ext3 /sbin # chmod +x mkfs.ext3 Then I kill the hung mkfs.ext3 process with 'kill 16481'. The partitioner fails, and I go back through the process again. This time it succeeds (since mkfs.ext3 is a no-op). It turns out a basic install of Debian (without the standard system task) just barely fits: ~ # df -h FilesystemSize Used Available Use% Mounted on tmpfs14.6M388.0k 14.3M 3% /dev
