Bug#847267: Updating the discover-data Uploaders list

[Gaudenz Steinlin]

Package: discover-data
Version: 2.2013.01.11
Followup-For: Bug #847267

Please also remove myself from the uploaders list. I have not done any
work on the package in recent years.

Thanks,
Gaudenz

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

discover-data depends on no packages.

Versions of packages discover-data recommends:
ii  pciutils  1:3.5.2-1

discover-data suggests no packages.

-- no debconf information

Bug#848424: Please remove me from uploaders

[Gaudenz Steinlin]

Package: discover
Version: 2.1.2-7
Severity: wishlist

Please remove my name from the uploaders filed. I haven't done any work
on this package for years. As I have been removed from the pkg-discover
alioth group I cannot do this myself.

Thanks,
Gaudenz

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages discover depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  libdiscover2   2.1.2-7
ii  libexpat1  2.2.0-1
ii  libusb-0.1-4   2:0.1.12-30

discover recommends no packages.

Versions of packages discover suggests:
ii  lsb-base  9.20161125

-- debconf information excluded

Bug#799976: wish: support passwd/root-login=false AND passwd/make-user=false

[Gaudenz Steinlin]

Simon Josefsson  writes:

>> Simon Josefsson  writes:
>> 
>> > Package: debian-installer
>> > Severity: wishlist
>> >
>> > On some system that I preseed-install, I don't want any root
>> > password set nor do I want a normal user account.  I get access to
>> > the system via SSH, using a public-key that I populate using a
>> > late_command.
>> 
>> If you want a work-around for this in the meantime, have a look at:
>> 
>>   http://hands.com/d-i/jessie/start.cfg
>>   http://hands.com/d-i/jessie/classes/late_script
>> 
>> and search for ERASEME
>> 
>> I preseed the crypted password, which satisfies the scripting, and
>> then blank it in the late script if it's still set to the magic
>> string.
>
> Nice trick, thanks for sharing.  I still believe it would be useful to
> support this behaviour out of the box, it should be what most people
> preseeding machines that never will be used through a console wants.

This is already supported but probably not documented. Just use the
following settings in your preseed file:

d-i passwd/make-user boolean false
d-i passwd/root-password-crypted password *

This sets the entry for root in /etc/shadow to '*' which effectively
means the password is disabled. You can still log in with an ssh key
though.

Gaudenz


signature.asc
Description: PGP signature

Bug#799976: wish: support passwd/root-login=false AND passwd/make-user=false

[Gaudenz Steinlin]

Lennart Sorensen  writes:

> On Thu, Sep 24, 2015 at 11:50:59PM +0200, Simon Josefsson wrote:
>> Package: debian-installer
>> Severity: wishlist
>> 
>> On some system that I preseed-install, I don't want any root password
>> set nor do I want a normal user account.  I get access to the system via
>> SSH, using a public-key that I populate using a late_command.
>
> So you want a system that you can not fix if it needs to prompt for a
> root password to manually run fsck?  There are after all a few times
> where being able to login as root directly on the console is required.
> Not allowing ssh with a pasword as root is a good diea (and the default
> these days), but that does not mean you don't still need a root
> password.

This is not true. If you boot a system with a disabled root account into
single user mode this is detected and you get a root shell without
entering a password. At least for jessie and earlier systems. See man
sulogin. For testing and up the manpages says that the --force option to
sulogin is needed for this, but this is not invoked by sysvinit or the
systemd emergency service.

And if everything else fails, you can still use init=/bin/bash as long
as you have console and boot loader access.

Gaudenz


signature.asc
Description: PGP signature

Re: Installationsproblem on a nvidia system

[Gaudenz Steinlin]

Hi Thomas

Thomas Schler schl...@id.ethz.ch writes:

 Hi Geert and Gaudenz,

 thank you very much for answering. I apologize for not having written my text 
 in english. I was on a debian web page written in excellent german when I got 
 the hint to write an installation report to debian-boot@lists.debian.org. So, 
 I didn't think further and just wrote the text in german.

 The problem was that my laptop didn't boot after installation processes 
 succeeded. drm tried to execute a command, but put out this text instead:

 Init table comand not found: 0xA9

 Nothing more happened, the system hung.

 Geert gave the hint to set this:

 nouveau.modeset =0

 Thank you!

 Because, I didn't know in which file this setting has to be written, I 
 checked for some more hints on the web. I found a web page telling to create 
 this file:

 /etc/modprobe.d/disable-nouveau.conf

 I put in just one line:

 # cat /etc/modprobe.d/disable-nouveau.conf
 options nouveau modeset=0

 The web page also says to blacklist nouveau, but I didn't because I don't 
 know the additional side effects when doing so.

 But, it helped. My system is booting, now, and it seems to run fine.

 My next problem is the network card, because it was not recognized by the 
 installation process.

 The installed network card is Intel (R) Ethernet Connection I217-LM.
 It is not configured/running. Do you know, how to get the network card
 configured the right way?

I suspect that your device is simply to new for the kernel in the
current Debian stable release and that some 

 Best regards, Thomas



 On Friday 05 December 2014 07:59:56 am Geert Stappers wrote:
 On Thu, Dec 04, 2014 at 07:26:49PM +, Schler  Thomas (ID SD) wrote:
  Hallo,
  
  zu Debian 7 will ich ein Installationsproblem berichten.
  
  Verwendetes System:
  Lenovo W540 mit vorinstalliertem Windows 7;
  Grafikkarte: NVIDIA Quadro K2100M.
  
  Verwendete Debian-Quelle: Buch-DVD, Autor: Heike Jurzik
  Debian GNU/Linux 7.1.0 Wheezy für i386 und amd64
  
  Verwendete Installationmethode:
  64bit, graphisch, KDE als Oberfläche;
  geführte Installation (nicht expert mode).
  
  Momentaner Zustand: Debian System ist nicht nutzbar. Boot-Vorgang
  bleibt hängen. Windows ist nutzbar.
  
  Mein Ziel ist, am Ende eine dual boot-Maschine zu haben (Windows,
  Debian).
  
  Bei der Installation musste ich schon mal die Netzwerkkarte (Intel
  Ethernet Connection I217-LM) von der Konfiguration ausschliessen,
  weil diese von Debian nicht erkannt wurde.
  
  Die Installation verlief ansonsten fehlerfrei. Jeder boot-Versuch
  schlägt aber fehl. Folgende Meldung kommt bereits nach ca. zehn
  Zeilen output:
  
  Init table comand not found: 0xA9
  
  Was ist der Fehler?
 
 [1]
 
 
  Wie kann ich den Fehler beheben, ohne eine Netzwerkverbindung besitzen
  zu können?
 
 My result from a web search
 
   I added 'nouveau.modeset =0' to the end of the line that ended in quiet
   and that seems to allow me to boot into the os.
 
 
  Viele Grüsse, Thomas
 
 
 Groeten
 Geert Stappers
 
 Notes:
 [1] Your hardware sadly still being owned by Nvidia. You as customer
 are insulted by Nvidia, they don't tell you what they selling.
  http://www.geekosystem.com/wp-content/uploads/2012/06/v40g6.gif
 


--
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/87y4qku9uo@meteor.durcheinandertal.bofh

Re: Installationsproblem

[Gaudenz Steinlin]

Hi Thomas

The language on the debian-boot mailinglist is english. Most people here
don't understand German. You might have more luck with your questions by
either reposting your mail to debian-user-ger...@lists.debian.org, our
German support mailinglist or to ask your question here in English.

Gaudenz

Schler  Thomas (ID SD) thomas.sch...@id.ethz.ch writes:

 Hallo,

 zu Debian 7 will ich ein Installationsproblem berichten.

 Verwendetes System:
 Lenovo W540 mit vorinstalliertem Windows 7;
 Grafikkarte: NVIDIA Quadro K2100M.

 Verwendete Debian-Quelle: Buch-DVD, Autor: Heike Jurzik
 Debian GNU/Linux 7.1.0 Wheezy für i386 und amd64

 Verwendete Installationmethode:
 64bit, graphisch, KDE als Oberfläche;
 geführte Installation (nicht expert mode).

 Momentaner Zustand: Debian System ist nicht nutzbar. Boot-Vorgang bleibt 
 hängen. Windows ist nutzbar.

 Mein Ziel ist, am Ende eine dual boot-Maschine zu haben (Windows, Debian).

 Bei der Installation musste ich schon mal die Netzwerkkarte (Intel Ethernet 
 Connection I217-LM) von der Konfiguration ausschliessen, weil diese von 
 Debian nicht erkannt wurde.

 Die Installation verlief ansonsten fehlerfrei. Jeder boot-Versuch schlägt 
 aber fehl. Folgende Meldung kommt bereits nach ca. zehn Zeilen output:

 Init table comand not found: 0xA9

 Was ist der Fehler?

 Wie kann ich den Fehler beheben, ohne eine Netzwerkverbindung besitzen zu 
 können?

 Viele Grüsse, Thomas


signature.asc
Description: PGP signature

Bug#761815: wow, huh

[Gaudenz Steinlin]

Control: severity -1 serious
Control: tags -1 +patch

[CCing Ansgar as the original bug submitter]

Just to give some context: This bug is about adding entries for USB mass
storage devices to /etc/fstab on installation.

Olliver Schinagl oli...@schinagl.nl writes:

 I just got bitten by this bug myself.

 As a long time gentoo + ubuntu user, I was baffled after getting the 
 solution to this problem. I have worked through several different kind 
 of fstab files, but this was a serious wtf. Why wasn't removable storage 
 working for me? I just couldn't figure it out, everything 'looked' normal.

 I'd increase the severity of this report, as it is far far from
 obvious.

I just had a look at the relevant code in partman-target
finish.d/fstab_removable_media_entries. As far as I understand it (no
testing done) these entries are added if a USB device is currently
plugged in. The code is from 2004 (commit
af81206d02f8d668dab382e5ec8483ccbc90a506) when this probably made sense.

Does it make any sense anymore to keep this code? IMO the fstab entries
should at least not be added when udisks is installed. I attached a
patch (not yet tested) which does this.

My patch currently only prohibits adding of USB device entries. Should
this be extended to floppies and CD-ROMs? What about kfreebsd and hurd?

IMO this should be fixed before the release as it causes unexpected and
inconsistent behavior. For example udisks will just mount the usb device
as normal if it does not have the same device node as the one used
during installation, but devices that happen to get the same device node
won't be accessible and mounted on a different path. This will lead to
things like one device being accessible and the other not if you plug in
two usb mass storage devices.

I raised the severity of the bug to serious as I think this should be
RC, but if members more involved with d-i than I am currently disagree,
feel free to downgrade again.

Gaudenz

From ec9b2cc840412863499c10854926f7328d6c9cc0 Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin gaud...@debian.org
Date: Thu, 4 Dec 2014 10:22:32 +0100
Subject: [PATCH] Only add USB entries to fstab if udisks is not installed

In combination with udisks these entries cause USB mass storage devices
to be mounted with options that prohibit the current user from accessing
the data. The also change the mount point to always be /media/usb0.

The fstab entries also only work if the USB device has the same device
node as the device that was used on installation. Which is not
guaranteed at all.
---
 finish.d/fstab_removable_media_entries | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/finish.d/fstab_removable_media_entries b/finish.d/fstab_removable_media_entries
index 813873d..5e209b5 100755
--- a/finish.d/fstab_removable_media_entries
+++ b/finish.d/fstab_removable_media_entries
@@ -159,7 +159,10 @@ done
 
 case `udpkg --print-os` in
 	linux)
-		populate_media usb auto rw,user,noauto $USBDEVICES
+		# Only add USB entries if udisks or udisks2 are not installed
+		if ! in-target sh -c dpkg-query -s udisks udisks2 2/dev/null | grep -q '^Status: install ok installed' ; then
+			populate_media usb auto rw,user,noauto $USBDEVICES
+		fi
 		;;
 	kfreebsd)
 		populate_media usb auto rw,noauto $USBDEVICES
-- 
2.1.3



signature.asc
Description: PGP signature

Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab

[Gaudenz Steinlin]

Samuel Thibault sthiba...@debian.org writes:
 What is new here is that sysvinit-core can now get initially installed
 not from d-i.  And thus the tuning usually done by d-i can't work.

 Also, we probably have to think about ping-pong scenarii: install
 sysvinit-core, then switch back to systemd, purge sysvinit-core, and
 drop /etc/inittab. Change one's mind again, reinstall sysvinit-core.
 We still want to have a console on /dev/hvc0.  We're far from d-i, so
 it'd rather be sysvinit-core which does the job of adding the console to
 inittab.

 Can't some of the logic in finish-install's 90console simply moved to
 sysvinit-core's postinst?

From my POV as an infrequent d-i contributor:  For the reasons above and
because having an /etc/inittab which does not do anything on systemd is
confusing I think moving this to sysvinit-core is the best solution.

Not reassing the bug right now to let others comment first.

Gaudenz


signature.asc
Description: PGP signature

Bug#771465: i386 hd-media image does not boot on Macbooks with 32-bit EFI

[Gaudenz Steinlin]

[ CCing debian-ker...@lists.debian.org for some more insights ]

Teemu Ikonen tpiko...@gmail.com writes:

 Package: debian-installer
 Severity: important

 Hi,

 I recently installed jessie on a 2007 intel Macbook by booting d-i
 from a USB drive. Getting the installer to start required quite a bit
 of hand tuning.

 The Macbook versions Macbook1,1 and Macbook2,1 from 2006-2007 require
 a 32-bit EFI bootloader and thus do not work with amd64 version of
 d-i. On the other hand, the i386 hd-media/boot.img.gz image only works
 with BIOS systems.

Are you sure they don't run amd64 code? From what I've found on the web
these two models have Intel Core Duo and Core 2 Duo processors. Early
Intel based Macs have a 32bit EFI but perfectly run 64 bit code AFAIK.
Earlier kernels (before 3.4 IIRC) are not capable of crossefi booting
(different kernel arch than EFI arch), but that should not be a problem
on jessie's 3.16 kernel.

What you however need is a 32bit grub EFI image because your EFI
environment is 32bit.


 I got the installer running by manually installing GRUB (the i386-efi
 version) to a USB drive with an MBR partition table and a FAT32
 filesystem, copying grub.conf from the amd64 netboot ISO image and
 copying the kernel image and initrd from the i386 netboot image. This
 procedure is straightforward, but requires an existing linux computer
 and probably does not win any usability awards.

Can you test if you can boot the 64bit kernel and initrd from the amd64
image with this procedure (using the 32bit grub-efi)?

I know this works the other way around (64bit grub and EFI booting into
a 32 bit kernel) but never tested the 32bit to 64bit kernel case.


 The straightforward fix would be to install both syslinux and GRUB to
 the hd-media image, as they seem to be able to coexist without
 problem. If this is for some reason not possible, then the procedure
 to get i386 EFI systems booting should be at least documented on the
 Installation guide, somewhere around chapter 4.3.3.1.

EFI 32bit and 64bit and BIOS images of grub can all coexist on the same
installation media. IMO it would make sense to install all of them to
the 32bit and 64bit x86 images.

Gaudenz


-- 
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/87oarolua8@meteor.durcheinandertal.bofh

Re: add net-retriever/localrepo?

[Gaudenz Steinlin]

Wouter Verhelst wou...@debian.org writes:

 Hi,

 I've been thinking it might be nice to extend net-retriever so it checks
 the net-retriever/localrepo template. This would never be shown (only
 used for preseeding), and would work similar to the localudebs
 directory.

 This could be used for more easily testing modules that aren't usually
 included in a built image, but could also be used to allow people to ask
 extra local questions in a mostly-preseeded environment, should they
 want that (create the udeb, create the repository, and preseed
 'net-retriever/localrepo and modules to relevant values).

 Thoughts?

I think that would be a very good idea. It would certainly help for d-i
development. I'm not sure but I vaguely remember that one problem might
be that anna does not really (fully?) support multiple repositories. But
it might also be that this is no longer true.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87ha6hjpss@meteor.durcheinandertal.bofh

Re: HTTPS metadata in Mirrors.masterlist?

[Gaudenz Steinlin]

Colin Watson cjwat...@debian.org writes:

 On Tue, Feb 11, 2014 at 05:22:26PM +0100, Matus UHLAR - fantomas wrote:
 On 11.02.14 15:56, Colin Watson wrote:
 All I have left to say is that the admins in question are my customers,
 
 so, the company is not your customer, but its admins are?

 Oh, whatever.  I'm not interested in this kind of word game.

 I've already exhausted all the avenues of protest you suggest, and they
 still tell me this is something they need.  Based on the work I've done
 so far I don't think this is a particularly onerous thing to support in
 d-i at least as an option, I'm prepared to do the work, and all I'm
 asking for here is a bit of metadata in the mirror masterlist.  If the
 latter can't be provided because we don't think Debian mirrors will
 accept the load or whatever, that's fine, I can always make it
 manual-only or whatever, but at this point it is easier for me to
 support HTTPS than to argue about it. :-)
 
 You can of course configure HTTPS on your server.

 It's their server, not mine.

 MAybe you could configure HTTPS proxy for them. Finally, if they are
 your customers, it's up to you to provide the servicem isn't it?

 Which is what I'm doing by doing this work in d-i!  Of course I could
 just do it in Ubuntu but it seems better to have the code in Debian too;
 it can always be mostly disabled by default so that only people who want
 to turn it on need to care.

I want to thank you for that. I'm happy, that this is not just
implemented in Ubuntu, but also in Debian. I also think that this is a
worthwile feature and that it should be enabled for those mirrors that
want to support it and that it should be as easy as possible to turn on.

While it's true that this does not give absolute protection, no single
measure does. And using HTTPS makes it significantly more difficult to
find out wich packages are downloaded. So it's a step in the right
direction.

Gaudenz


 Note that HTTPS clients verify the servers' certificate and multiple debian
 mirrors with different hostnames can not have the same certificate, nor it's
 sane to maintain different certificates for each hostname on each mirror ...

 Well aware of that, thanks.

 -- 
 Colin Watson   [cjwat...@debian.org]


 -- 
 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/20140211175911.ga28...@riva.ucam.org



-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87fvnp5t82@meteor.durcheinandertal.bofh

Bug#725642: installation-reports: Installer creates over-small root partition when automatically sizing separate partitions

[Gaudenz Steinlin]

Rudy Godoy r...@stone-head.org writes:

 Package: installation-reports
 Followup-For: Bug #725642


 Today, a 10GB partition for root is really small. Take in count that / will 
 hold
 /var/lib and /var/log along with /usr. For a standard desktop install it 
 takes 
 almost 6GB of space, leaving 4GB for other software and software's own data 
 files,
 such as database or logs.

 I propose to use 20% of the disk size or a minumum of 50GB for the
 root partition.

I agree for the case where there is no separate /var and/or /usr partition.
But with /var and/or /usr on separate partitions you really don't need
more than a few GBs. 10GB seems like enough in this case. Using 20% of
your disk would waste a lot of disk space.

I'm not sure if a separate /usr is still supported these days. I
remember some discussion about this in the past.

Gaudenz



 -- Package-specific info:

 Boot method: DVD
 Image version: 
 http://cdimage.debian.org/debian-cd/7.3.0/amd64/iso-dvd/debian-7.3.0-amd64-DVD-1.iso
 Date: 01/03/2014

 Machine: Toshiba Satellite
 Partitions:
 FilesystemType 1K-blocks Used Available Use% Mounted 
 on
 /dev/mapper/elephant-root ext4   9480420  8017992957804  90% /
 udev  devtmpfs 102400 10240   0% /dev
 tmpfs tmpfs   188552  952187600   1% /run
 tmpfs tmpfs 51200  5120   0% /run/lock
 tmpfs tmpfs   377080 1552375528   1% /run/shm
 /dev/sda2 ext223415328860192801  14% /boot
 /dev/sda1 vfat497696  136497560   1% /boot/efi
 /dev/mapper/elephant-home ext4 466318992 67965708 374642564  16% /home
 none  tmpfs40 4   0% 
 /sys/fs/cgroup


 Base System Installation Checklist:
 [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

 Initial boot:   [0]
 Detect network card:[0]
 Configure network:  [0]
 Detect CD:  [0]
 Load installer modules: [0]
 Clock/timezone setup:   [0]
 User/password setup:[0]
 Detect hard drives: [0]
 Partition hard drives:  [0]
 Install base system:[0]
 Install tasks:  [0]
 Install boot loader:[0]
 Overall install:[0]

 Comments/Problems:

 None. Just voting for the request.

 -- 

 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/Linux installer
 DISTRIB_RELEASE=7 (wheezy) - installer build 20130613+deb7u1+b1
 X_INSTALLATION_MEDIUM=cdrom

 ==
 Installer hardware-summary:
 ==
 uname -a: Linux elephant 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
 lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
 Processor Family DRAM Controller [8086:0104] (rev 09)
 lspci -knn:   Subsystem: Toshiba America Info Systems Device [1179:fb50]
 lspci -knn:   Kernel driver in use: agpgart-intel
 lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
 Generation Core Processor Family Integrated Graphics Controller [8086:0106] 
 (rev 09)
 lspci -knn:   Subsystem: Toshiba America Info Systems Device [1179:fb50]
 lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 
 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
 lspci -knn:   Subsystem: Toshiba America Info Systems Device [1179:fb50]
 lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 
 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
 lspci -knn:   Subsystem: Toshiba America Info Systems Device [1179:fb50]
 lspci -knn:   Kernel driver in use: ehci_hcd
 lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 
 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
 lspci -knn:   Subsystem: Toshiba America Info Systems Device [1179:fb50]
 lspci -knn:   Kernel driver in use: snd_hda_intel
 lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series 
 Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4)
 lspci -knn:   Kernel driver in use: pcieport
 lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series 
 Chipset Family PCI Express Root Port 3 [8086:1e14] (rev c4)
 lspci -knn:   Kernel driver in use: pcieport
 lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series 
 Chipset Family PCI Express Root Port 4 [8086:1e16] (rev c4)
 lspci -knn:   Kernel driver in use: pcieport
 lspci -knn: 

Re: net-retriever: handy debug hack to pull in development udeb's at runtime

[Gaudenz Steinlin]

Ian Campbell i...@hellion.org.uk writes:

 Package: net-retriever
 Version: 1.37
 Severity: wishlist
 Tags: patch

 On Wed, 2014-01-22 at 22:23 +0100, Cyril Brulebois wrote:
 Ian Campbell i...@hellion.org.uk (2014-01-22):
  I finally got fed up of rebuilding the initrd to include new versions of
  udebs I was hacking on, so I bodged up something in net-retriever to
  allow me to just throw udebs into a reprepro archive on a local web dir
  and have them be used.
  
  So now I just need to build the initrd once with this included and I can
  preseed a location to get devel udebs from. It fits in quite nicely with
  apt-setup/local0 for debs to install on the target system.
  
  Patch is below. I've also thrown it onto gitorious at:
  https://gitorious.org/ijc-debian/net-retriever/commit/34e4eb1e972dfbcec757b815f81b7d42447dfad7
  
  This is by no means a proper thing and apart from being a massive hack
  it has no support for checking the gpg sigs, release files etc. 
  
  But here it is in case it is useful to someone...
 
 ACK on principle, that avoids having to resort to disabling GPG checks
 in this component and {hacking,cracking} an archive by replacing bits
 with tweaked packages, or having to build custom debian-archive-keyring
 deb/udeb. (Tried both, and neither is nice.)
 
 Can't really look at the implementation right now though, sorry about
 that.

 No problem, I was mostly just putting it out there in case anyone else
 wanted it. It sounds like you think it might be something which could
 plausibly be added to the proper package?

 Might be nice to file a bug against net-retriever to track it?

 Good idea, doing so now (Bcc to submit@) leaving quotes in place and
 attaching the patch for the BTS.

In addition it would be nice to have this on a branch in the official
Alioth repository. 

Gaudenz


 Thanks,

 Ian
 From 34e4eb1e972dfbcec757b815f81b7d42447dfad7 Mon Sep 17 00:00:00 2001
 From: Ian Campbell i...@hellion.org.uk
 Date: Sun, 19 Jan 2014 13:19:21 +
 Subject: [PATCH] Development udeb retrieval support.

 Use via preseeding:
 d-i retriever/devel-udeb/url string http://www-int./~ijc/debian/devel-udeb
 or on the command line:
 retriever/devel-udeb/url=http://www-int./~ijc/debian/devel-udeb
 ---
  debian/changelog   |6 ++
  debian/net-retriever.templates |7 +++
  net-retriever  |   37 -
  3 files changed, 49 insertions(+), 1 deletion(-)

 diff --git a/debian/changelog b/debian/changelog
 index e74d768..6681e99 100644
 --- a/debian/changelog
 +++ b/debian/changelog
 @@ -1,3 +1,9 @@
 +net-retriever (1.38+ijc1) UNRELEASED; urgency=low
 +
 +  * Add hack to allow preseeding a URL to retrieve development udebs from.
 +
 + -- Ian Campbell i...@hellion.org.uk  Sun, 05 Jan 2014 12:43:24 +
 +
  net-retriever (1.37) unstable; urgency=low
  
[ Updated translations ]
 diff --git a/debian/net-retriever.templates b/debian/net-retriever.templates
 index d3da8a9..8b33adf 100644
 --- a/debian/net-retriever.templates
 +++ b/debian/net-retriever.templates
 @@ -11,3 +11,10 @@ _Description: Downloading a file failed:
   problem with your network, or with the mirror. You can choose to retry
   the download, select a different mirror, or cancel and choose another
   installation method.
 +
 +Template: retriever/devel-udeb/url
 +Type:string
 +_Description: Additional udeb mirror for development
 + FOR DEVELOPMENT USE ONLY
 + .
 + No authentication of the mirror is performed. Use at your own risk.
 diff --git a/net-retriever b/net-retriever
 index 347fefc..4c2ac8f 100755
 --- a/net-retriever
 +++ b/net-retriever
 @@ -16,6 +16,8 @@ db_get mirror/$protocol/hostname
  hostname=$RET
  db_get mirror/$protocol/directory
  directory=$RET
 +db_get retriever/devel-udeb/url
 +dev_url=$RET
  
  keyring=/usr/share/keyrings/archive.gpg
  
 @@ -23,6 +25,15 @@ fetch() {
   fetch-url -c ${protocol}://${hostname}${directory}/$1 $2
  }
  
 +dev_fetch() {
 + if [ -z $dev_url ]; then
 + error dev_fetch with no retriever/devel-udeb/url active -- 
 something untoward is going on
 + fi
 +
 + p=${1#@@devel@@}
 + fetch-url -c ${dev_url}/$p $2
 +}
 +
  checkmatch() {
   release=$1
   packages=$2
 @@ -63,7 +74,17 @@ shift
  
  case $cmd in
  retrieve)
 - fetch $@
 + case $1 in
 + @@devel@@*)
 + log devel: $@
 + dev_fetch $@
 + ;;
 + *)
 + log regular: $@
 + fetch $@
 + ;;
 + esac
 +
   exit $?
   ;;
  
 @@ -127,6 +148,20 @@ case $cmd in
   elif [ $ext = .gz ]; then
   zcat $Packages  $1
   fi
 + if [ -n $dev_url ]; then
 + 
 DevelPackages=/tmp/net-retriever-$$-Devel-Packages
 + log Checking $dev_url for DevelPackages
 + if 

Re: init-select

[Gaudenz Steinlin]

Hi

Michael Gilbert mgilb...@debian.org writes:

 Hi :)

 The TC init discussion has diverged significantly from Debian's usual
 ideals of freedom and meritocracy, so I decided to do something about
 it.

 So, today I wrote init-select.  It's a small tool that empowers users
 to freely and simply choose among all of the available init systems.
 It also empowers Debian contributors to devote their energy toward
 their favorite init knowing that users can easily swap inits to try
 the new features they are working on.

IMO you are solving the wrong problem. Or how would you ensure that
while the user can easily switch the init system, when doing so half of
the daemons installed won't start because they don't support the
alternative. And if he switches back, the other half does not start
because the only support the other alternative. IMO the hard problem is
mostly about which systems must be supported by all packages.
init-select does not help to solve this.


 But most importantly, it provides a path for eliminating the
 politicization of the init system problem.

 That would be achieved if Debian's default init were to simply become
 init-select's default.

 Now, I certainly don't want all that weight solely on my shoulders, so
 I would very much prefer this choice to be team-maintained, and I
 think the installer/boot team has the expertise and clout to make the
 right choice when the time is really right to change the default
 Debian init.

 The initial package is up for review at:
 http://people.debian.org/~mgilbert/other

 I've set the maintainer to debian-boot now in the hope that this
 proposal sounds reasonable.  There is of course more work to do, which
 is documented in a TODO file in the source, which will make the
 package better, but the existing functionality, I think, is already
 useful.  I can switch inits on a whim in seconds now.

I don't see why the installer team should be in any better position to
choose the default init system for Debian than any other team. At least
since I'm involved (~ 10 years) the mailinglist name for the installer
was a bit of a  misnomer. The team has nothing to do with everyday
booting of the system. It probably comes from the fact that the
installer before d-i was called boot-floppies.

So IMHO this should not be maintained by debian-boot. But then I'm not
really active here any more at the moment, so if people actually active
on debian-boot want to maintain it, I won't oppose any further.

Gaudenz


 Anyway, that is my modest proposal.  I hope this doesn't sound too
 overly idealistic, intrusive, or I suppose out of the blue :)

 Best wishes,
 Mike


 -- 
 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/CANTw=MPLNu6-ss4uOtv+kSF8bPyGOvBC4FjeNYaOVr=pf6g...@mail.gmail.com



-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87a9fdl91p@meteor.durcheinandertal.bofh

Re: init-select

[Gaudenz Steinlin]

Michael Gilbert mgilb...@debian.org writes:

 On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote:
 Michael Gilbert mgilb...@debian.org (2014-01-03):
 It is often far more ideal when the TC chooses to not act.  TC action
 means that the project is somehow dysfunctional.

 init-select is a very simple technical solution to a very large social
 problem.

 Having to pick an init system is *not* a social problem.

 All TC decisions are attempts at the resolution of social problems.
 They only consider issues that involve the social disagreement between
 at least two people.  The fact that the disagreement is happens to be
 over a technical topic does not eliminate the social aspect.

 Trying to support several init systems is *not* in the best interest of
 a distribution. Having a fully functional one (and a transition from the
 former if it's different) is what we need to work on.

 Following that logic, supporting multiple packaging helpers, desktop
 environments, text editors, compilers, kernels, so on and so on are
 also *not* in the best interest of a distribution.  Let's pick the
 most functional ones, that is what we need to work on.

As Cyril already said these are false analogies. Supporting multiple
packageing helpers does not place a burden on maintainers that only use
one of them. It's also invisible to users. Similar arguments can be made
for your other examples. On the other hand supporting several init
systems places a burden onto every daemon maintainer. Every init system
is only usefull if it's supported by all packages.

The option of just useing the init script compatibility layer that most
(all) init systems currently provide is IMO just not an option because
it does not let us use most of the benefits of the newer systems. It's
just sysv-init in new cloths.

Gaudenz

P.S.: This is my last mail to this thread. I don't think we have to
reiterate this debate over and over on different lists.

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/877gagly1c@meteor.durcheinandertal.bofh

Bug#722898: benchmarks

[Gaudenz Steinlin]

Hi Thiemo

Thanks for working on this.

Thiemo Nagel thiemo.na...@gmail.com writes:

 Hello Ben,

 thanks for your input! I'm attaching a series of patches to wrap up what
 we've discussed so far, more details are in the commit messages quoted
 below.

 I've tested the patches by running blockdev-wipe, they are looking good. I
 haven't tried to build the installer with the new block-dev wipe, though,
 and therefore would appreciate further testing and/or code review.

 Even with the latest version of blockdev-wipe, I'm still seeing ~20%
 improvement by setting min_speed to zero. Yet, I'd suggest to hold back the
 speedlimit patch because I'd expect similar gains for the package
 installation phase. Thus I believe that it makes more sense to set
 speed_limit_min to zero during the startup of the debian installer. Could
 someone please advise me as to where that would fit in best?

The best place to enable this is probably partman-md after creating the
RAID device.

 #5blockdev-wipe: Set blocksize to 512k

 This should be large enough to avoid excessive system call
 overhead and small enough to prevent problems on systems with
 very little RAM.

Any reason why you choose 512k? If I understand your benchmarks right,
doubling this to 1M yelds about another 27% gain. Does increasing the
buffer to 1M just increase the memory requirement by 512k or is there a
hidden penalty to it? If it's just 512k I don't think we should care
as d-i needs in the order of 70-100M overall. And if it turns out to be
a problem wiping could be disabled in lowmem situations. 


 #4blockdev-wipe: Sync at most once per second

 Don't open output devices with O_SYNC, instead sync manually
 every time the progress indicator is updated, but not more
 often than once per second.  This yields performance gains
 of up to factor 10 in setups with dm-crypt on dm-raid.

 Note: Seven years ago, O_SYNC was added to fix OOM issues
 (cf. bug #381135), however it is believed that this problem
 has been addressed in the kernel by now.

 #3blockdev-wipe: Allocate buffer from heap instead of stack

 This allows to use buffers larger than 8M, also it fails more
 gracefully in case the memory can't be allocated.

 #2blockdev-wipe: Reduce progress indicator granularity to 1/1000

This still sounds like a lot of granularity. IMO this could be reduced
to 1/100. Do we really need progress updates for less than 1%? 

Gaudenz


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87txhkhr4n@meteor.durcheinandertal.bofh

Bug#722898: benchmarks

[Gaudenz Steinlin]

Hi

Thiemo Nagel thiemo.na...@gmail.com writes:

 Hello Gaudenz,

 thank you for your email!

 Any reason why you choose 512k? If I understand your benchmarks right,
 doubling this to 1M yelds about another 27% gain.


 I'm sorry, I forgot to mention that I've re-run the benchmarks. After
 removing O_SYNC, the performance was identical for block sizes in the range
 of 32k to 16M. I chose 512k (16 times larger than the lowest value that
 I've tested) with the intent to exclude a block size penalty for devices up
 to 16x faster than my md raid1 setup, which comes in at around 80MB/s.

 Except for low-memory installs, I'm not aware of any obstacle to increasing
 the buffer even more. (And of course, there's always the option to test for
 available memory and chose the buffer size depending on that.)


  #2blockdev-wipe: Reduce progress indicator granularity to 1/1000

 This still sounds like a lot of granularity. IMO this could be reduced
 to 1/100. Do we really need progress updates for less than 1%?


 For a large device, wipe times still can be many hours. At a granularity of
 1/1000, the progress indicator would advance every 10-50 seconds (order of
 magnitude), which I don't consider excessive. (Of course, this only holds
 true if the graphical frontend supports this kind of granularity, which I
 don't know.)

I don't know about the graphical frontend, but I'm pretty sure the console
based frontend is not able to display a finer granularity than 1/100.

If we are changing this anyway, maybe it's a good time to also make the
template partman-crypto/progress/erase a bit more explicit about
canceling.

It currently reads: Erasing data on ${DEVICE}. Maybe something like 
Erasing data on ${DEVICE}. To continue without ereasing press
'Cancel'. How do others feel about this? Several bug reports show that
it's apparently not clear to many users that they can cancel the
operation and what happens if they select cancel.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87li2vi5tt@meteor.durcheinandertal.bofh

Bug#711586: installation-reports: successful install on thinkpad x230

[Gaudenz Steinlin]

reassign 711586 netcfg
retritle 711586 Does not copy wireless configuration for network-manager
tags 711586 +patch
thanks

Julien Cristau jcris...@debian.org writes:

 On Sat, Jun  8, 2013 at 17:49:11 +0200, Gaudenz Steinlin wrote:

 Julien Cristau jcris...@debian.org writes:
  UEFI boot went fine after disabling secure boot.  Installer unnecessarily
  warned about missing iwlwifi firmware, but IIRC that's getting fixed.
  Installed on a WPA network, everything went smoothly.  I thought netcfg
  would write out the network config for network-manager to use post install,
  but apparently not.
 
 That's odd. This should work. If network-manager is installed, a script
 in finish-install should copy the NM configuration to the freshly
 installed system.
 
 Do you still have the installation logs (see /var/log/installer)? Do you
 see anything about copying network configuration during finish-install
 in syslog?
 
 Here goes:

 Jun  8 06:03:17 finish-install: info: Running 
 /usr/lib/finish-install.d/50config-target-network
 Jun  8 06:03:17 finish-install: info: Running 
 /usr/lib/finish-install.d/55netcfg-copy-config
 Jun  8 06:03:17 in-target: Package: network-manager
 Jun  8 06:03:17 in-target: Status: install ok installed
 Jun  8 06:03:17 in-target: Priority: optional
 Jun  8 06:03:17 in-target: Section: net
 Jun  8 06:03:17 in-target: Installed-Size: 4033
 Jun  8 06:03:17 in-target: Maintainer: Utopia Maintenance Team 
 pkg-utopia-maintain...@lists.alioth.debian.org
 Jun  8 06:03:17 in-target: Architecture: amd64
 Jun  8 06:03:17 in-target: Version: 0.9.4.0-10
 Jun  8 06:03:17 in-target: Depends: libc6 (= 2.4), libdbus-1-3 (= 1.0.2), 
 libdbus-glib-1-2 (= 0.88), libgcrypt11 (= 1.4.5), libglib2.0-0 (= 2.31.8), 
 libgnutls26 (= 2.12.17-0), libgudev-1.0-0 (= 146), libnl-3-200 (= 3.2.7), 
 libnl-genl-3-200 (=
 Jun  8 06:03:17 in-target: Pre-Depends: dpkg (= 1.15.7.2)
 Jun  8 06:03:17 in-target: Recommends: policykit-1, ppp (= 2.4.5), 
 dnsmasq-base, iptables, modemmanager, crda
 Jun  8 06:03:17 in-target: Suggests: avahi-autoipd
 Jun  8 06:03:17 in-target: Breaks: network-manager-gnome ( 0.9), 
 network-manager-kde ( 1:0.9), network-manager-openconnect ( 0.9), 
 network-manager-openvpn ( 0.9), network-manager-pptp ( 0.9), 
 network-manager-vpnc ( 0.9), plasma-widget-netw
 Jun  8 06:03:17 in-target: Conffiles:
 Jun  8 06:03:17 in-target:  
 /etc/polkit-1/localauthority/10-vendor.d/org.freedesktop.NetworkManager.pkla 
 c95fc58835c3d93739ef3efea8405b15
 Jun  8 06:03:17 in-target:  /etc/init.d/network-manager 
 ff16e17e89d1aa858485570e90f6f04a
 Jun  8 06:03:17 in-target:  /etc/NetworkManager/dispatcher.d/01ifupdown 
 299819a8e64f00a1edbdfc99d05a8594
 Jun  8 06:03:17 in-target:  /etc/NetworkManager/NetworkManager.conf 
 914f22205f2ed4d4bc84f3682ecd3153
 Jun  8 06:03:17 in-target:  /etc/dbus-1/system.d/nm-dispatcher.conf 
 5711a76c31a3763750fe2c331741f679
 Jun  8 06:03:17 in-target:  
 /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf 
 86ea932131ee974e7a5c7b3d7184a583
 Jun  8 06:03:17 in-target:  /etc/dbus-1/system.d/nm-dhcp-client.conf 
 06b1ecfd8f1fa2a501a5f352e2e5e88e
 Jun  8 06:03:17 in-target:  /etc/dbus-1/system.d/nm-avahi-autoipd.conf 
 91ab68968b0dc06c3a55b482b50b3028
 Jun  8 06:03:17 in-target: Description: network management framework (daemon 
 and userspace tools)
 Jun  8 06:03:17 in-target:  NetworkManager is a system network service that 
 manages your network devices
 Jun  8 06:03:17 in-target:  and connections, attempting to keep active 
 network connectivity when
 Jun  8 06:03:17 in-target:  available. It manages ethernet, WiFi, mobile 
 broadband (WWAN), and PPPoE
 Jun  8 06:03:17 in-target:  devices, and provides VPN integration with a 
 variety of different VPN
 Jun  8 06:03:17 in-target:  services.
 Jun  8 06:03:17 in-target:  .
 Jun  8 06:03:17 in-target:  This package provides the userspace daemons and a 
 command line interface to
 Jun  8 06:03:17 in-target:  interact with NetworkManager.
 Jun  8 06:03:17 in-target:  .
 Jun  8 06:03:17 in-target:  Optional dependencies:
 Jun  8 06:03:17 in-target:   * policykit-1: Required for reading and writing 
 system connections.
 Jun  8 06:03:17 in-target:   * ppp: Required for establishing dial-up 
 connections (e.g. via GSM).
 Jun  8 06:03:17 in-target:   * dnsmasq-base/iptables: Required for creating 
 Ad-hoc connections and
 Jun  8 06:03:17 in-target: connection sharing.
 Jun  8 06:03:17 in-target:   * avahi-autoipd: Used for IPv4LL, a protocol for 
 automatic Link-Local IP
 Jun  8 06:03:17 in-target: address configuration.
 Jun  8 06:03:17 in-target: Homepage: 
 http://www.gnome.org/projects/NetworkManager/
 Jun  8 06:03:17 netcfg[18895]: INFO: Starting netcfg v.1.108 (built 
 20130407-2200)
 Jun  8 06:03:17 netcfg[18895]: DEBUG: No interface given; clearing 
 /etc/network/interfaces
 Jun  8 06:03:17 netcfg[18895]: DEBUG: Writing informative header
 Jun  8 06:03:17 netcfg[18895]: DEBUG: Success!
 Jun  8 06:03:17 netcfg[18895]: DEBUG

Bug#711586: installation-reports: successful install on thinkpad x230

[Gaudenz Steinlin]

Hi

Julien Cristau jcris...@debian.org writes:
 UEFI boot went fine after disabling secure boot.  Installer unnecessarily
 warned about missing iwlwifi firmware, but IIRC that's getting fixed.
 Installed on a WPA network, everything went smoothly.  I thought netcfg
 would write out the network config for network-manager to use post install,
 but apparently not.

That's odd. This should work. If network-manager is installed, a script
in finish-install should copy the NM configuration to the freshly
installed system.

Do you still have the installation logs (see /var/log/installer)? Do you
see anything about copying network configuration during finish-install
in syslog?

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87ppvwob60@meteor.durcheinandertal.bofh

Re: task-desktop: default desktop environment for Jessie

[Gaudenz Steinlin]

Michael Gilbert mgilb...@debian.org writes:

 On Fri, May 31, 2013 at 3:06 PM, Cyril Brulebois wrote:
 Michael Gilbert mgilb...@debian.org (31/05/2013):
 It would probably be good to get that discussion started early during
 this cycle to reduce the surprise factor.

 Since it was rather difficult to fit gnome onto 1 cd in wheezy (and I
 think some pieces were left off anyway), I think it makes sense now to
 start moving toward something like xfce as the default that's small,
 and mostly capable, and 4.10 (now making its way into unstable) brings
 much needed accessibility features.

 A somewhat related question is whether we're going to keep trying to
 fit stuff onto CD#1, as opposed to moving to supporting various “USB
 key sizes”. If I'm not mistaken, Steve has expressed such a wish (or
 intent) during the last wheezy preparation steps.

 As a point of reference, I still have (and use every now and then) an
 old laptop that has a cd-rom but no dvd-rom, and its bios does not
 support usb booting.

You could still use the netinst image on this machine. There is
currently no danger that it's content won't fit onto a CD-ROM and AFAIK
there is no intention to drop this image.

It needs a working network connection to install a full desktop though,
but IMO this acceptable for these rare cases.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
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/87mwra9o01@meteor.durcheinandertal.bofh

Re: ZFS support in partman-target

[Gaudenz Steinlin]

Turbo Fredriksson tu...@bayour.com writes:

 On May 21, 2013, at 7:11 AM, Christian PERRIER wrote:

 How about applying as member of the d-i team on Alioth, if you
 already have an Alioth account? Or applying for such account if you
 don't. Then push your proposed changes to the master branches of the
 various packages they belong to.

 Done. I'll push some commits during the day then.


 Most of my commits should be reasonably straigt forward, but there's
 a few that might need a little more review. Especially since kFreeBSD
 already contain support for ZVOL's, I don't want to risk messing with
 that (it shouldn't, but shit happens :).

 But since the ZoL (zfs and spl) isn't yet available in the archive
 (something about new packages not being accepted this year - !?),
 and the fact that some of the commits might not be very pretty, and
 some needs more talk, I was kind'a hoping someone would actually take
 a look at the commits I done and perhaps comment more on them.

 Maybe even actually testing it themselves? :)

If you now have access to the d-i reporsitories, just push the more
problematic parts to a branch instead of master. This still makes it a
lot easier to review.

If some parts depend on things not yet in the archive IMHO they should
not (yet) be commited to master. A branch is fine, though.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87y5b8zaxo@meteor.durcheinandertal.bofh

Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda

[Gaudenz Steinlin]

Hi Vince


Vincent McIntyre vincent.mcint...@csiro.au writes:

 Sadly, this issue will probably be in wheezy as nobody digged enough
 to tackle this down and we get rid of it before the last version of
 D-I is released.


 Please see my working (for me), tested, waiting-for-review patch [1]
 sent to the -boot list yesterday.

Do you know how the problem can be triggerd. As far as I remember only
some installation from USB are affected and I don't know if the
difference between those affected and those unaffected has ever been
identified. If I know that I'm testing the right test case, I'm willing
to try your patch.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/8738uf9iaa@meteor.durcheinandertal.bofh

Bug#701823: installation-report: Encrypted LVM assisted install failed on Lenovo T430s

[Gaudenz Steinlin]

Raphaël Walther raphael.walt...@gmail.com writes:

 Hi Gaudenz,
 On Mon, Mar 11, 2013 at 10:24:17PM +0100, Gaudenz Steinlin wrote:
 Raphaël Walther raphael.walt...@gmail.com writes:
 
  I reproduce the same issue on the same computer with the new
  motherboard. I tried to encrypt a partition and it failed again at the
  same step.
 
 Can you please post the logs of this attempt. Without any logs it's hard
 to tell why it failed. The logs you previously posted really look like
 it's a hardware issue. Maybe it was not the motherboard which is at
 fault after all. If the logs still contain similar kernel errors like:

 Unfortunatly, an USB key failed with the logs on it. But when I looked
 at it, it was the same type of errors.

 I suggest you also run a comprehensive harddisk test with some testing
 tool like badblocks from a Live CD or from a testing CD provided by your
 hardware vendor. Just to be sure that the hardware issue is indeed fixed.

 I did two tests which were all successful :
 badblocks -nvs /dev/sda - no bad blocks
 smartctl -H /dev/sda - PASSED

That seems indee weired.


 My guess is that  SSD disk works properly. At least, it works as long as
 I don't try to encrypt it (I use the disk on a daily basis).

 What is the command the installer is using to shred the partion or the
 disk?

It uses a standalone C program. See
http://anonscm.debian.org/gitweb/?p=d-i/partman-crypto.git;a=tree;f=blockdev-wipe

There is a Makefile to just build this small utility. Maybe you can
reproduce the error by just calling blockdev-wipe. But be warned this
will wipe your data ;-). The installer calls this with blockdev-wipe -s
65536 $dev in lib/crypto-base.sh.

Gaudenz


 Cheers,
 Raphaël


 -- 
 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/20130315065654.gb7...@gmail.com


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
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/874nfzifyk@meteor.durcheinandertal.bofh

Bug#701823: installation-report: Encrypted LVM assisted install failed on Lenovo T430s

[Gaudenz Steinlin]

Hi Raphael

Raphaël Walther raphael.walt...@gmail.com writes:

 I reproduce the same issue on the same computer with the new
 motherboard. I tried to encrypt a partition and it failed again at the
 same step.

Can you please post the logs of this attempt. Without any logs it's hard
to tell why it failed. The logs you previously posted really look like
it's a hardware issue. Maybe it was not the motherboard which is at
fault after all. If the logs still contain similar kernel errors like:

Feb 27 12:53:59 kernel: [  839.770044] ata1.00: exception Emask 0x0 SAct 0xfffc 
SErr 0x0 action 0x6 frozen
Feb 27 12:53:59 kernel: [  839.770052] ata1.00: failed command: WRITE FPDMA 
QUEUED
Feb 27 12:53:59 kernel: [  839.770062] ata1.00: cmd 
61/08:10:90:8e:2b/00:00:00:00:00/40 tag 2 ncq 4096 out
Feb 27 12:53:59 kernel: [  839.770076]  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 27 12:53:59 kernel: [  839.770078] ata1.00: status: { DRDY }

or

Feb 27 12:53:59 kernel: [  839.770169] ata1: hard resetting link
Feb 27 12:54:04 kernel: [  845.124346] ata1: link is slow to respond, please be 
patient (ready=0)
Feb 27 12:54:09 kernel: [  849.760448] ata1: COMRESET failed (errno=-16)
Feb 27 12:54:09 kernel: [  849.760458] ata1: hard resetting link
Feb 27 12:54:14 kernel: [  855.106726] ata1: link is slow to respond, please be 
patient (ready=0)
Feb 27 12:54:19 kernel: [  859.742825] ata1: COMRESET failed (errno=-16)
Feb 27 12:54:19 kernel: [  859.742832] ata1: hard resetting link
Feb 27 12:54:24 kernel: [  865.097079] ata1: link is slow to respond, please be 
patient (ready=0)
Feb 27 12:54:54 kernel: [  894.701093] ata1: COMRESET failed (errno=-16)
Feb 27 12:54:54 kernel: [  894.701105] ata1: limiting SATA link speed to 3.0 
Gbps
Feb 27 12:54:54 kernel: [  894.701109] ata1: hard resetting link
Feb 27 12:54:59 kernel: [  899.712231] ata1: COMRESET failed (errno=-16)
Feb 27 12:54:59 kernel: [  899.712243] ata1: reset failed, giving up
Feb 27 12:54:59 kernel: [  899.712247] ata1.00: disabled

I suggest you also run a comprehensive harddisk test with some testing
tool like badblocks from a Live CD or from a testing CD provided by your
hardware vendor. Just to be sure that the hardware issue is indeed fixed.

Gaudenz

 Cheers,
 Raphaël


 -- 
 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/20130311125250.ga9...@gmail.com


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
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/87620xzl32@meteor.durcheinandertal.bofh

Bug#702527: installation-reports: No CpuFrequencyScaling with Wheezy RC1

[Gaudenz Steinlin]

Ben Hutchings b...@decadent.org.uk writes:

 On Thu, 2013-03-07 at 22:42 +0100, Gaudenz Steinlin wrote:
 Christian PERRIER bubu...@debian.org writes:
 
  Quoting cl (topolm5...@mail.ru):
  Package: installation-reports
  Severity: normal
  
  Dear Maintainer,
  
  I have downloaded debian-wheezy-live-rc1-amd64-gnome-desktop.iso and 
  installed.
  After the installation I was wondering why my cpu fan was constantly 
  spinning and I found out the CPUfrequencyScaling is not enabled due to 
  that the cpufrequtils package is not installed. After manually installing 
  and configuring cpufrequency everything is fine. As a lot of users are 
  working on laptops it will be really great if cpufrequency could be 
  enabled by default. Thank you.
 
  Sigh, there are so many different power management things that
  choosing among them is a nightmare.
 
  Did cpufrequtils need configuration to do what you want? If so, then
  it would probably better having it to provide a good default
  configuration, then we might consider adding it to the laptop task
  in addition to:
 
 No cpufrequtils does not need any configuration. It works well out of
 the box. And it's not only usefull on laptops but on any hardware with a
 modern (x86/amd64) processor. It also helps saving power on desktops and
 servers.

 cpufreq drivers are now auto-loaded and te default governor is ondemand,
 so most users won't need cpufrequtils installed any more.

Thanks Ben for pointing this out. Did not know it's enabled by default
now. I just checked and can confirm that the ondemand governor and
acpi-cpufreq driver are set even withouth cpufrequtils. So this is
probably much less needed than for squeeze.

Tested on a Thinkpad X200.

Gaudenz


 Ben.

 -- 
 Ben Hutchings
 Always try to do things in chronological order;
 it's less confusing that way.

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/8738w6rw7u@meteor.durcheinandertal.bofh

Bug#702527: installation-reports: No CpuFrequencyScaling with Wheezy RC1

[Gaudenz Steinlin]

Christian PERRIER bubu...@debian.org writes:

 Quoting cl (topolm5...@mail.ru):
 Package: installation-reports
 Severity: normal
 
 Dear Maintainer,
 
 I have downloaded debian-wheezy-live-rc1-amd64-gnome-desktop.iso and 
 installed.
 After the installation I was wondering why my cpu fan was constantly 
 spinning and I found out the CPUfrequencyScaling is not enabled due to that 
 the cpufrequtils package is not installed. After manually installing and 
 configuring cpufrequency everything is fine. As a lot of users are working 
 on laptops it will be really great if cpufrequency could be enabled by 
 default. Thank you.

 Sigh, there are so many different power management things that
 choosing among them is a nightmare.

 Did cpufrequtils need configuration to do what you want? If so, then
 it would probably better having it to provide a good default
 configuration, then we might consider adding it to the laptop task
 in addition to:

No cpufrequtils does not need any configuration. It works well out of
the box. And it's not only usefull on laptops but on any hardware with a
modern (x86/amd64) processor. It also helps saving power on desktops and
servers.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/877gliyjiv@meteor.durcheinandertal.bofh

Re: Debian installer build: failed or old builds

[Gaudenz Steinlin]

Hi Hector

Hector Oron hector.o...@gmail.com writes:

 Hello,

 2013/2/3 Gaudenz Steinlin gaud...@debian.org:

 It seems that the build deamon (ancina) that was building the d-i images
 for armel is currently down. Do you have any updates on what's happening
 or could you please move the build to another host if the failure is
 expected to last longer.

   ancina has been down, it is now up and back building d-i.

Thanks for working on this.

Best,
Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87obfzawxi@meteor.durcheinandertal.bofh

Re: Debian installer build: failed or old builds

[Gaudenz Steinlin]

Dear armel buildd maintainers

It seems that the build deamon (ancina) that was building the d-i images
for armel is currently down. Do you have any updates on what's happening
or could you please move the build to another host if the failure is
expected to last longer.

The last d-i build happened on Jan 28, see below. Since then new
information about attempted, failed or succsessful builds are available
anymore. 

Gaudenz

Daily build aggregator debian-boot@lists.debian.org writes:

 Debian installer build overview
 ---

 Failed or old builds:

 * OLD BUILD:armel Jan 28 08:08 buildd@ancina build_iop32x_netboot 
 
 http://d-i.debian.org/daily-images/armel/daily/build_iop32x_netboot.log

 * OLD BUILD:armel Jan 28 08:10 buildd@ancina 
 build_iop32x_network-console_glantank 
 
 http://d-i.debian.org/daily-images/armel/daily/build_iop32x_network-console_glantank.log

 * OLD BUILD:armel Jan 28 08:13 buildd@ancina 
 build_iop32x_network-console_n2100 
 
 http://d-i.debian.org/daily-images/armel/daily/build_iop32x_network-console_n2100.log

 * OLD BUILD:armel Jan 28 08:16 buildd@ancina 
 build_iop32x_network-console_ss4000e 
 
 http://d-i.debian.org/daily-images/armel/daily/build_iop32x_network-console_ss4000e.log

 * OLD BUILD:armel Jan 28 08:18 buildd@ancina build_kirkwood_netboot 
 
 http://d-i.debian.org/daily-images/armel/daily/build_kirkwood_netboot.log

 * OLD BUILD:armel Jan 28 08:23 buildd@ancina build_kirkwood_netboot-gtk 
 
 http://d-i.debian.org/daily-images/armel/daily/build_kirkwood_netboot-gtk.log

 * OLD BUILD:armel Jan 28 08:25 buildd@ancina 
 build_kirkwood_network-console 
 
 http://d-i.debian.org/daily-images/armel/daily/build_kirkwood_network-console.log

 * OLD BUILD:armel Jan 28 08:28 buildd@ancina 
 build_orion5x_network-console 
 
 http://d-i.debian.org/daily-images/armel/daily/build_orion5x_network-console.log

 * OLD BUILD:armel Jan 28 08:31 buildd@ancina build_versatile_netboot 
 
 http://d-i.debian.org/daily-images/armel/daily/build_versatile_netboot.log

 * OLD BUILD:armel Jan 28 08:33 buildd@ancina build_ads_cf 
 
 http://d-i.debian.org/daily-images/armel/daily/build_ads_cf.log

 * FAILED BUILD: amd64 Jan 30 01:17 debian-cd@pettersson sidamd64 
 http://cdbuilder.debian.org/cdimage-log/sidamd64


 Totals: 105 builds (1 failed, 10 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/e1u1nwc-0005sl...@ravel.debian.org


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87k3qpip1j@meteor.durcheinandertal.bofh

Bug#696732: installation-guide: Section 6.3.5.1. Configuring apt: Removal of references to 'volatile'

[Gaudenz Steinlin]

Cyril Brulebois k...@debian.org writes:

 Brian Potkin claremont...@gmail.com (26/12/2012):
 I originally submitted this patch in
 
http://lists.debian.org/debian-boot/2012/10/msg00444.html
 
 Mentions of volatile remain in Section B.4.9.

 Oops, thanks for insisting. :)

 I'm adding debian-release@ to the loop.

 --- manual/en/using-d-i/modules/apt-setup.xml2012-10-21 
 15:52:12.582381910 +0100
 +++ manual/en/using-d-i/modules/apt-setup_volatile.xml   2012-10-21 
 16:05:53.0 +0100
 @@ -42,16 +42,28 @@
  method you are using and possibly using choices made earlier in the
  installation. In most cases the installer will automatically add a security
  mirror and, if you are installing the stable distribution, a mirror for the
 -quotevolatile/quote update service.
 +quoterelease updates/quote service.
  
  /parapara
  
  If you are installing at a lower priority (e.g. in expert mode), you will
  be able to make more decisions yourself. You can choose whether or not to
 -use the security and/or volatile update services, and you can choose to
 +use the security and/or release updates services, and you can choose to
  add packages from the quotecontrib/quote and quotenon-free/quote
  sections of the archive.
  
 +/parapara
 +
 +Security updates help to keep your system secured against attacks.

 “help keep” I think?

help keeping I'd say, but I'm not a native speaker either.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
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/87obhfstce@meteor.durcheinandertal.bofh

Bug#695403: installation-guide: Please point out the limitations of firmware detection

[Gaudenz Steinlin]

Hi

Brian Potkin claremont...@gmail.com writes:
  
 +/parapara
 +
 +The routines used to detect missing firmware can only be of help for
 +modules loaded after d-i; has started. This implies that the
 +capabilities of some devices, the graphics card, for example, are no
 +different at the end of the installation from what they were at the
 +beginning and may mean some of your hardware is not being used to its
 +full potential. If you suspect this is the case, or are just curious, it
 +is not a bad idea to check the output of the commanddmesg/command
 +command on the newly booted system and search for firmware, missing,
 +unable or fail.
 +

Shouldn't we improve the installer to do this search instead? To me this
seems to be mostly scriptable.

Gaduenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87wqws6au0@meteor.durcheinandertal.bofh

Re: Continuous Integration of the Debian Installer?

[Gaudenz Steinlin]

Luca Favatella slacky...@gmail.com writes:

 Hello,

 Is there a Continuous Integration (CI) infrastructure in place for
 testing the Debian Installer (d-i)?
   http://en.wikipedia.org/wiki/Continuous_integration


IIRC once upon a time joeyh was running automated tests on a bunch of
different machines. Some virtualized, others on bare-metal.

The scripts he used can be found here:
svn+ssh://gaud...@svn.d-i.alioth.debian.org/svn/d-i/trunk/scripts/digress

Maybe JoeyH knows more about the current status of this.

Gaudenz


 It would be nice testing automatically the different installation
 paths (CLI vs. GUI, various setups of ZFS) for the daily images of the
 d-i, especially for architectures without lots of users (e.g.
 kfreebsd-*). I think d-i images would benefit from C-I more that
 Debian packages (for which - I understand - test suites are run after
 build), as d-i images (or at least most flavors of it) depend on a
 Debian repository that has udebs working for that particular version
 of the d-i, and d-i is a quite complex piece of software.

 For the basic tests, I guess that a Debian GNU/Linux box would be
 enough (also for testing kfreebsd-* installer images). The basic test
 should:
 * Download the latest daily installer (e.g. for kfreebsd-i386)
 * Create a fake installation disk (i.e. a file)
 * Run qemu, specifying the installer image and the fake disk
 * Preseed the d-i in some way, ensuring to configure the network
   http://wiki.debian.org/DebianInstaller/Preseed
 * Detect the end of the installation
 * Run again qemu, specifying the fake disk with the (hopefully)
 installed Debian (the d-i image is not needed anymore)
 * Do some simple sanity checks, e.g. ping the qemu node (ssh-ing to it
 would be better...)
 * Consider the test as failed or passed

 More advanced checks could be to try to mount the resulting fake
 installed disk and assert some predicates on it (e.g. I can mount it
 as UFS, the partitioning is as expected, some files are present to
 disk...).


 If there is no such infrastructure, a Debian GNU/Linux x86/x86-64
 testing Wheezy would be needed for starting. I would propose jenkins
 installed on it as a CI tool (as I used it a bit...).
   http://packages.debian.org/wheezy/jenkins

 BTW someone worked on Jenkins and Debian.
   http://jenkins-debian-glue.org/


 Comments?

 Regards
 Luca


 P.S.
 If there is a box with Debian installed available for this, I would be
 available to try to set it up (with no hurry, sadly I only have very
 small chunks of spare time...)


 -- 
 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/cactd9n48z6kuc8bx+f4gaifufv5rxkzrzwmo+09qowgxqed...@mail.gmail.com


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87k3u1v2cr@meteor.durcheinandertal.bofh

Bug#687687: Installation was mostly successfully on Acer Aspire One D150

[Gaudenz Steinlin]

Hi

Brian Potkin claremont...@gmail.com writes:

 says for select:

 Holds one of a finite number of possible values. These
 values must be specified in a field named Choices:.
 Separate the possible values with commas and spaces, like
 this:  Choices: yes, no, maybe

 The values in the templates file for netcfg for wireless_show_essids are
 not separated by commas. Could this be the cause of the behaviour?

That would very much surprise me. The comas are inserted by the
substitution. So when the questions is asked they are there. But it
might be that the substitution breaks preseeding.

BTW: The relevant code is at
http://anonscm.debian.org/gitweb/?p=d-i/netcfg.git;a=summary if you want
to have a look.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87627bxohy@meteor.durcheinandertal.bofh

Re: Proposal to add patches to netcfg (#682737)

[Gaudenz Steinlin]

Hi

I'll try to explain some of the decision as I have been working with
Sorina on this patch.

Joey Hess jo...@debian.org writes:

 Sorina - Gabriela Sandu wrote:
 For that matter, I would like to propose a patch to add support for
 netcfg to write a Network Manager config file and modify the
 finish-install script so that it copies to target either the nm-config
 file or a full /e/n/i config, according to a reasonable default and
 user's choice. This also contain a new question,
 netcfg/target_network_config, which is asked with a medium priority in
 finish-install

 I notice this links network-manager to libuuid. Which is an amazingly
 bloated 124k here. That's being added to the d-i boot image.

When we added this code to netcfg during GSOC I first also feared that
and we even had our own very minimal UUID implementation at some point.
But we then found out that libuuid is already included in the initrd
because it's a dependency of util-linux-udeb (blkid) which is needed for
udev-udeb. So we decided to reuse this instead of adding more code.

Also in my amd64 build:
$ ls -lh ./tmp/netboot/tree/lib/libuuid.so.1
-rw-r--r-- 1 gaudenz gaudenz 19K Jun 23 11:06 
./tmp/netboot/tree/lib/libuuid.so.1

So here it's much smaller...


 AFAICS, the network-manager configuration saves the user from having to
 re-select the wireless network, and re-enter any passphrase that they
 already entered once in d-i. This seems a relatively minor improvement,
 after all users of mobile computers rather frequently have to pick wifi
 networks and enter passphrases.

IMO the major improvement of the proposed change is that wireless
configuration is no longer written into /e/n/i for systems that have
network manager installed. The addition of a working network-manager
configuration is a nice bonus. I don't see a reason not to do it if you
have all the information available. It's just a small convenience
improvement.


 Even without the libuuid bloat (which I'm sure could be worked around
 somehow.. for example c32468fe-00d6-11e2-8510-97e4f3a3dcc1 is a
 perfectly fine uuid I just generated that d-i is free to reuse ;)
 .. I wonder if tying d-i so tightly to network-manager configuration
 file format is worth saving the user that step. Even with a spec, this
 desktop stuff is a pile of sand, it changes at upstream's whim; do we
 really want d-i tied to it?

Do you have evidence that it's that bad or is this just your bad
feeling?


 I also doubt that the medium priority debconf question adds much value
 to the installer. Especially since it also increases the size of the
 boot media. Who is going to pick something other than the default?
 Only users proficient enough to easily edit /etc/network/interfaces
 after the install, and who are apparently already planning to do some
 form of sysadmin work after the install.

The main reason for the question was to make it preseedable. So for
example automated desktop installs could still choose ifupdown. Or if
you know that your configuration management is going to install
network-manager afterwards you can choose the network-manager
configuration depsite it nm not being installed at the moment. Or you
can choose to not configure anything because you have a complex post
install script doing network configuration.


 

 As to the code, I haven't looked at it in detail, but this seems
 a needlessly roundabout way to get the network-manager config file's
 mode locked down:
 http://anonscm.debian.org/gitweb/?p=d-i/netcfg.git;a=commitdiff;h=093e22856d04d4d93c08ae402874ac5ef59d2fb3;hp=1d698b6eeb5a8ab6120adc7389a540dd04e6aa47

 In particular, it fails open -- if the installer is turned off at
 just the wrong point, the system will boot up with a password in the
 file and the file mode 644. It would be much more sensible to create
 the file with mode 600 from the beginning.

Good point. I think this could be improved. On the other hand this is
still an improvement over the current situation where there is no
security at all.


 AFAICS, network-manager uses mode 600 for all connection files, even
 those without passwords. This makes me wonder if it has good reasons for
 doing so. Perhaps it considers other information in the files security
 sensative. Perhaps it sometimes modifies the files to add security
 sensative information, without changing their permissions.

Don't know but it does not hurt either to have them always 600.

Brian Potkin wrote:
 I realise a default is only a default and the selection can be changed,
 but I'm puzzled by the third option. Why treat a wireless install
 differently from a wired install? It would expected that a user who has
 chosen not to use a wired connection would still want connectivity after
 booting into into the new system,

 On the one hand we have people installing a fixed machine that has
 only wifi connectivity. These do exist -- two examples I'm familiar with
 are a friend whose workplace uses wifi for industrial controllers on the
 factory 

Bug#433568: Bug #433568 add vlan support

[Gaudenz Steinlin]

Hi Aron

Aron Xu happyaron...@gmail.com writes:

 I'm sending a reminder on this issue, it would be best if d-i can
 support VLAN using expert mode of installation, configuring VLAN using
 iproute2 during installation is much more annoying comparing to
 configure it within d-i.

A reminder is nice and if you are luck might get things started, but
as you probably know, d-i is free software. Pachtes are most welcome.
Everyone is free to contribute and I don't know of any technically sound
contribution to d-i that has been turned down.

The code is at git.debian.org, the components you probably need to
modify are netcfg and busybox (to enable VLAN support).

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87ehmbci58@meteor.durcheinandertal.bofh

Re: Installation-guide cleanup

[Gaudenz Steinlin]

Hi

Karsten Merker mer...@debian.org writes:
 If there are no objections, I would start working on the
 installation guide and remove (and in some cases replace) several
 outdated parts.  Due to limited time available on my side this
 will probably have to be done bit by bit during the next weeks. 
 If possible, it would be helpful if I could get svn commit
 access, so I could regularly commit the reworked parts.

Just speaking for myself. I would very much appreciate this work! I
agree the remove the outdated content you mentioned. I can't give you
access as I'm not an admin.

Best,
Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/871uiig6cd@meteor.durcheinandertal.bofh

Bug#685414: installation-reports: Hangs while searching drives on a Mac Mini G4 (PowerPC)

[Gaudenz Steinlin]

Hi Gunnar

Gunnar Wolf gw...@gwolf.org writes:

 I just tried with the daily image for today, and got exactly the same
 results :(

Not good :-(

Which daily image did you use exactly. You may need to use a netboot
image to really get the latest mountmedia. I'm not sure how the daily
cdroms images are currently built. They may be built with the beta1
installer. Please verify that you have mountmedia 0.21 on your
installation  medium. 

This image contains mountmedia 0.21:
http://d-i.debian.org/daily-images/powerpc/daily/powerpc/netboot/mini.iso


 The bug you mention happens at a much later stage (at
 partman-auto-lvm, my lockup happens just after localechooser),
 although it does sound related - Trying to mount /dev/sda1 from the
 console still hangs. However, the following messages in
 /var/log/syslog grab my attention:

The bug I mentioned happens every time mountmedia is run. The
installation report also reports two hangs earlier during installation.

#684293 is the corresponding bug in the linux kernel which is the root
cause of the issue I suspect to be your problem.


 Aug 27 16:05:32 hw-detect: Missing modules 'pata_macio (KeyLargo ATA)

As Milan pointed out this is harmless.


 Before getting to hw-detect, a request to mount any of the partitions
 results in:

 # mount /dev/sda1 /media
 mount: mounting /dev/sda1 on /media failed: No such file or directory
 # mount /dev/sda2 /media
 mount: mounting /dev/sda2 on /media failed: No such file or directory

 But once at this stage, real partitions mount successfully:

 # mount /dev/sda2 /media
 #

So it seems that at least some part to make the partitions work is
missing before hw-detect. You could compare the list of loaded kernel
modules. But I'm not sure if this is really relevant because after
hw-detect at least /dev/sda2 is fine.


 But attempting to mount /dev/sda1 just hangs, without issuing any
 messages either to the console or to the syslog. Even attempting to
 kill -9 the 'mount' process fails.

 FWIW, the mount command that's also stalled from d-i is:

 mount -t auto -o ro /dev/sda1 /hd-media


I think that's the important part. This is exactly the same behavior as
in the two bug reports I mentioned. The fix in mountmedia skips
partitions we know to hang. This leaves to posibilities. Either your
image does not have the fixed mountmedia or the fix is not correct for
powerpc (apple partition tables). What does 

blkid -p -s PART_ENTRY_TYPE /dev/sda1 | cut -d ' ' -f 2 | cut -d \ -f 2

report? In mountmedia we currently skip tpyes 0x5 and 0xf. Maybe another
type has to be skipped for apple partition tables. If your partition
type is different you can modify /bin/mountmedia with nano and add your
partition type to the list of types to avoid.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87ipc3cv7h@meteor.durcheinandertal.bofh

Re: Beta2 preparation: proposed unblock for netcfg(?)

[Gaudenz Steinlin]

Cyril Brulebois k...@debian.org writes:

 Christian PERRIER bubu...@debian.org (25/08/2012):
 netcfg is a bit more tricky than other packages I proposed. 
 
 testing has 1.81, unstable now has 1.89.
 
 Changes summary:
 
 * List available ESSIDs: I tested this change myself and...it's
   working as expected
 
 * Add logging to iface activation and deactivation: trivial change
 which is mostly aimed at helping further development, I guess
 
 * Rename cryptic killall.sh to kill-all-dhcp: admitedly cosmetic
 (shut-up lintian...). Tested by myself
 
 * Coding style cleanups: not sure it was appropriate at this stage of
 the release (OK, no more no less than my won cosmetic changes!)but
 seems safe
 
 * Cleanup link detection handling and improve logging: ditto
 
 * Avoid gateway reachability testing on s390(x) with a layer 3 qeth
   network device: as far as I understand, important for s390x
 
 * wireless.c: Fix some spelling mistakes: trivial and safe
 
 and of course, many l10n changes (most of them triggerred by the
 List available ESSIDs change by Sorina)

 Indeed, that one is trickier. It will probably only be reviewed later
 this weekend, or during next week. Thanks for the details.

Just as an additional data point. I have been using all these changes
since they were commited in all my tests and don't know of any
unresolved problems. I also reviewed all changes made by Sorina before
mergeing them to trunk. But of course I can't garantuee that I did not
miss something. Another check is always appreciated.

As a last part of the GSOC project we are working on a better solution
to carry over wireless configuration to the installed system. This
should avoid the current problems that the cleartext password is written
to /etc/network/interfaces and that network-manager does not manage the
wireless interface because of that.

This code can be found in the people/sorina/write_config branch. I don't
intend to merge this before wheezy without prior discussion on
debian-boot. But personally I think both changes should go into the
wheezy installer.

Gaudenz


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgpD7y1J3wLgU.pgp
Description: PGP signature

Bug#682608: Fix

[Gaudenz Steinlin]

Hi

chuck adams chuck.adams.k...@gmail.com writes:

 Using the suggested comment that /etc/network/interfaces needed lines
 commented out, I went to a working system and compared the interfaces
 file.

 In the installation using the wireless interface the interfaces
 file contained a serious security violation as shown here:

 # The primary network interface
 allow-hotplug wlan0
 iface wlan0 inet dhcp
   wpa-ssid NETGEAR
   wpa-psk  wittyflower875


 In that the file contains, in plain ASCII text,
 the ssid and password for the network and the file
 is viewable by all users.

Does anyone know if it's really necessary that /etc/network/interfaces
is world readable? Or could this file set to mode 0600 by d-i if it
contains any sensitive information?


 I commented out the lines and added 

 allow-hotplug eth0

 which I don't know is absolutely necessary.

 A reboot of the system does bring up the WiFi
 interface without any difficulty that I can see
 at the present time.

 Please include a note as to when changes will be made.
 I am aperiodically downloading netinst from the daily-build
 and installing the system from scratch.

We are currently investigating who to best fix this problem. A proposed
(not yet finished) fix can be found in the people/sorina/write_config
branch of netcfg. The currently favoured approach is add a medium
priority question wo select which kind of network configuration should
be written to the installed system. With these options:
1 network-manager configuration
2 configuration in /etc/network/interfaces
3 no configuration at all

If network-manager is installed, option 1 would be the default,
otherwise option 2.


 Another bug found.  When plugging in a USB thumb memory drive,
 it is not recognized and mounted.  This bug may have already
 been reported.  I discovered it when I was thinking of writing
 both installs (with and without using wlan0) and doing a 
 diff -r  (  :-)  ) to compare the file systems and the exact
 files that were configured differently.  So many bugs and so
 little time.

This is an entirely different bug. Please report it separately. The
relevant package is probably udisks.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87r4qsd91d@meteor.durcheinandertal.bofh

Re: Beta2 preparation: proposed unblock for netcfg(?)

[Gaudenz Steinlin]

Hi

Cyril Brulebois k...@debian.org writes:

 Hi Gaudenz,

 Gaudenz Steinlin gaud...@debian.org (27/08/2012):
 Just as an additional data point. I have been using all these changes
 since they were commited in all my tests and don't know of any
 unresolved problems. I also reviewed all changes made by Sorina before
 mergeing them to trunk. But of course I can't garantuee that I did not
 miss something. Another check is always appreciated.

 thanks for your input. I'm not sure I want to push an extra package to
 testing at this point, now I'd rather for beta 3 to get it in. Does that
 look sensible to you? If there's no delay for beta 2, preparing a beta 3
 release in roughly 1.5 month would seem realistic.

I'm not opposing this. But on the other hand having it in beta2 would
mean that it gets testing now and we could fix eventual issues for
beta3. As I said I don't expect there to be any issues, but you never
know. Everything is ready and all it needs is an unblock. But in the end
it's your call.


 As a last part of the GSOC project we are working on a better solution
 to carry over wireless configuration to the installed system. This
 should avoid the current problems that the cleartext password is
 written to /etc/network/interfaces and that network-manager does not
 manage the wireless interface because of that.
 
 This code can be found in the people/sorina/write_config branch. I
 don't intend to merge this before wheezy without prior discussion on
 debian-boot. But personally I think both changes should go into the
 wheezy installer.

 Feel free to mention that on -boot@ right after beta 2 is out, so we
 have time to discuss and push those changes for the beta 3 release
 cycle.

That sounds like a good plan.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87oblwcydw@meteor.durcheinandertal.bofh

Bug#682608: /etc/network/interfaces permissions

[Gaudenz Steinlin]

chuck adams chuck.adams.k...@gmail.com writes:

 Here is a working system, i.e. WiFi interface working,
 and /etc/network/interfaces permissions

 adams@debian:~$ ls -l /etc/network/interfaces
 -rw-r--r-- 1 root root 293 Jun 13 22:26 /etc/network/interfaces

 and contents of file are:

 --cut here
 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo
 iface lo inet loopback

 # The primary network interface
 allow-hotplug eth0
 #NetworkManager#iface eth0 inet dhcp
 --cut here

 The issue is with the contents of the file as shown in previous
 email with the ssid and password in the file.  I believe the
 644 or even the 600 is just fine.  It is that the current
 d-i or netinst is placing the wrong info into the interfaces
 file.


I don't think the information in /etc/network/interface is wrong. I'm
only guessing that you come to this conclusion because the
network-manager applet does not show the connection. What actually
happens is this:

- netcfg currently only knows about /e/n/i and nothing about
  network-manager. It just writes the configuration to /e/n/i. 

- when finishing up the installation (right before the reboot) a script
  is run which disables all interfaces that have the form iface ifX
  inet dhcp without any additional configuration iff network-manager is
  installed. All other interface definitions are untouched. That's why
  your wireless interface is not disabled and shows up as unmanaged in
  network-manager. Network-manager sees that this is confgured by
  ifupdown and does not touch the interface.

- the wireless interface actually works as expected as long as you stay
  in range of your wireless network.

- evolution and other programs using network-manager for network
  detection wrongly think that there is no network connection.

There is nothing inherently wrong with this. It's probably just not the
configuration most (novice) users would expect. That's why we are
currently reworking this part to make it more user friendly.

 By any chance, is the netinst program written in C?  I can
 help if it is.  I just need pointers to the code and let
 me work on it, if you need the help.  I have taught every
 course there is in CS when I was a tenured prof at the
 University of North Texas and I was lead instructor and
 course developer at sgi at one time.  

Yes it's one of the few d-i components written in C. The git repository
for debian-installer can be found on git.debian.org. But beware it's not
the most beautiful piece of C code ever ;-) Also the functionality in
question should go to a finish-install script which is in shell.

The (unfinished) version fixing this can be found in
git://git.debian.org/git/d-i/netcfg, branch write_config.

Help also with other parts of netcfg would be appreciated. See the list
of open bugs at http://bugs.debian.org/netcfg :-) Two of the more
interesting open issues are IPv6 support and tagged VLAN support.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87lih0ccm9@meteor.durcheinandertal.bofh

Re: [EFI] grub-installer: use grub-efi for EFI machines

[Gaudenz Steinlin]

Hi Steve

Steve McIntyre st...@einval.com writes:

 Hi,

 Reasonably simple changes here, again heavily inspired by Ubuntu
 code. One extra issue I found - it looks like /sys and /proc need to
 be mounted in /target when we run the postinst, otherwise we'll fail
 to drive efibootmgr. I've added code to do that here, but I'm not sure
 it's the right way to do it - better suggestions welcome!

From the debian-installer-utils README file:
in-target: Runs the specified command in /target and returns its exit
status. The debconf passthrough frontend is used to make debconf questions
be asked using cdebconf in the installer. This is especially useful for
running things like dpkg-reconfigure, debconf-apt-progress, and tasksel.
The log-output utility is used to log any output; if in-target is called
with the option --pass-stdout, log-output will respect it.

The README does not say so explicitly but in-target takes care of all
the necessary setup to have a woking chroot in /target including
mounting of /sys and /proc. IMO it's the prefered way to run commands
chrooted to /target even if you don't need the full setup.

Gaudenz


 Depends on the libdebian-installer patch to add the efi subarch.

 -- 
 Steve McIntyre, Cambridge, UK.st...@einval.com
 Because heaters aren't purple! -- Catherine Pitt
 mr diff: /home/steve/debian/d-i/d-i/packages/grub-installer
 diff --git a/debian/changelog b/debian/changelog
 index 979eddd..0d857fb 100644
 --- a/debian/changelog
 +++ b/debian/changelog
 @@ -1,3 +1,13 @@
 +grub-installer (1.78) unstable; urgency=low
 +
 +  [ Steve McIntyre ]
 +  * Allow grub for amd64/efi and i386/efi, installing grub-efi instead of
 +grub-pc.
 +  * Make sure that we have /sys and /proc mounted in /target in the
 +postinst, so that efibootmgr will work ok.
 +
 + -- Steve McIntyre 93...@debian.org  Tue, 21 Aug 2012 22:10:40 +0100
 +
  grub-installer (1.77) unstable; urgency=low
  
[ Cyril Brulebois ]
 diff --git a/debian/isinstallable b/debian/isinstallable
 index e66bac1..c404929 100755
 --- a/debian/isinstallable
 +++ b/debian/isinstallable
 @@ -8,13 +8,6 @@ log() {
  ARCH=$(archdetect)
  
  case $ARCH in
 -i386/mac|amd64/mac)
 - # Note: depends on partman-efi to load the efivars module!
 - if [ -d /sys/firmware/efi ]; then
 - log GRUB not yet usable on Intel-based Macs booted using EFI
 - exit 1
 - fi
 - ;;
  powerpc/chrp_pegasos)
   ;;
  powerpc/*)
 diff --git a/debian/postinst b/debian/postinst
 index b32a1d0..5e001f1 100755
 --- a/debian/postinst
 +++ b/debian/postinst
 @@ -1,2 +1,8 @@
  #! /bin/sh -e
 +
 +# If we're installing grub-efi, it wants /sys mounted in the
 +# target. Maybe /proc too?
 +mount -t sysfs sys /target/sys || true
 +mount -t proc procfs /target/proc || true
 +
  grub-installer /target
 diff --git a/grub-installer b/grub-installer
 index a0a4d8c..e9f350e 100755
 --- a/grub-installer
 +++ b/grub-installer
 @@ -312,11 +312,16 @@ case $ARCH in
   if [ -d /sys/firmware/efi ]; then
   # This point can't be reached (yet).  See debian/isinstallable.
   grub_package=grub-efi
 - experimental_arch
   else
   grub_package=grub-pc
   fi
   ;;
 +i386/efi|amd64/efi)
 + grub_package=grub-efi
 + ;;
 +i386/*|amd64/*)
 + grub_package=grub-pc
 + ;;
  powerpc/*)
   grub_package=grub-ieee1275
   experimental_arch
 @@ -409,10 +414,13 @@ db_progress INFO grub-installer/progress/step_install
  # to grub legacy, or vice-versa
  case $grub_package in
  grub)
 - log-output -t grub-installer $chroot $ROOT dpkg -P grub-pc-bin grub-pc
 + log-output -t grub-installer $chroot $ROOT dpkg -P grub-pc-bin grub-pc 
 grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-ia32-bin grub-efi-ia32 
 grub-gfxpayload-lists
   ;;
  grub-pc)
 - log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy
 + log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
 grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-ia32-bin grub-efi-ia32
 +;;
 +grub-efi)
 + log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
 grub-pc-bin grub-pc grub-gfxpayload-lists
   ;;
  esac
  
 @@ -662,7 +670,7 @@ if [ -z $frdisk ]; then
  
   CODE=0
   case $ARCH:$grub_package in
 - *:grub|*:grub-pc|sparc:grub-ieee1275)
 + *:grub|*:grub-pc|*:grub-efi|sparc:grub-ieee1275)
   info Running $chroot $ROOT grub-install 
 $grub_install_params \$bootdev\
   log-output -t grub-installer $chroot $ROOT grub-install 
 $grub_install_params $bootdev || CODE=$?
   ;;
 @@ -675,7 +683,7 @@ if [ -z $frdisk ]; then
   info grub-install ran successfully
   else
   case $ARCH:$grub_package in
 - 

Re: [SCM] d-i netcfg repository branch, people/sorina/check_netmask, updated. 1.65-230-gf3a76bc

[Gaudenz Steinlin]

Petter Reinholdtsen p...@hungry.com writes:

 [Sorina Sandu]
 The following commit has been merged in the people/sorina/check_netmask 
 branch:
 commit f3a76bc12e46edb09637000d1fc31f03c4208cdd
 Author: Sorina Sandu sandu.sor...@gmail.com
 Date:   Sun Aug 19 19:36:01 2012 +0300
 
 /0 and /32 masks are not valid

 Are you sure?

 See URL: http://bugs.debian.org/652573  for a story about /32 as the
 subnet mask.

No we were not sure either and decided on IRC tonight to allow /0 and
/32 and to not be too picky about this.

Gaudenz


 -- 
 Happy hacking
 Petter Reinhoildtsen


 -- 
 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/2fl8vd99xz4@diskless.uio.no


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87fw7h2rw6@meteor.durcheinandertal.bofh

Re: installing on mdraid imsm arrays

[Gaudenz Steinlin]

Hi

Miquel van Smoorenburg miqu...@debian.org writes:

 At work, we're using mainly supermicro servers, and they have support in 
 the BIOS for Intel Matrix raid (imsm), which is a form of 
 sataraid/fakeraid. So I have been looking at installing debian on such a 
 raid system. d-i supports dmraid somewhat, nowadays, but the package 
 in wheezy is out of date, and I have the impression that support for 
 monitoring/rebuilding of arrays by dmraid isn't all that good. It also 
 looks like dmraid is not maintained by upstream anymore.

 Now I also noticed when booting the wheezy installer on a system with 
 the disks configured as imsm, that the mdraid support of the installer 
 actually reckognizes the array as imsm. And that in fact the imsm 
 support in mdadm is quite good. The installer crashes though when trying 
 to access that array, since the mdadm udeb misses 'mdmon'. But that is 
 easily fixed.

 I now have a version of the wheezy installer that succesfully installs 
 and boots debian on a mdadm imsm array.

 I had to fix/update mdadm (bug #684708), libparted (bug #684713) and 
 lvm2 (bug #684712).

 wrt d-i, I had to fix up the following packages:

 - partman-auto: allow partioned md devices
 - partman-base: filter out devices that are part of a
partioned md device
 - grub-installer: reckognize partitioned md devices and install
grub on all the underlaying devices (only for RAID1 right now)

 Do you think that it would be worth it to integrate this for the wheezy 
 release? If so, should I post patches for review on a webpage somewhere, 
 or here on the list, or just submit them as bugs against their 
 respective packages?

It's definitely worth to integrate this into Debian. If it's possible to
include this in wheezy is up to the release team. IMHO the easiest way
to track such changes is to send individual bug reports and to send a
mail explaining how they depend on each other afterwards to all the
reports (with links to all reports). Another possible way to track this
is to add a meta-bug blocked by all the other bugs.

If you have commit access (you can request it if you don't have it yet)
to the d-i repository you can also commit your changes to a feature
branch like people/miquels/imsm.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87fw7r6ma6@meteor.durcheinandertal.bofh

Bug#683773: btrfs-write-performance rechecked, downgrading the severity to 'wishlist'

[Gaudenz Steinlin]

Hi Andreas


Andreas Glaeser bugs.andreas.glae...@freenet.de writes:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 To check if btrfs is really slow I tried the following:
 - -# aptitude install btrfs-tools
 - -created a btrfs-partition as /dev/sdb14 with gparted and aligned it to 
 sector, not to
 mbr, because the harddisk is an advanced format model with 4096k blocks.
 - -# mkfs -t btrfs /dev/sdb14
 - -# mkdir /mnt/test
 - -# mount /dev/sdb14 /mnt/test
 - -# exit
 andreas@g4d:~$ cd /mnt/test
 andreas@g4d:/mnt/test$ mkdir fs-root-c-arc
 andreas@g4d:/mnt/test$ time cp -a /* fs-root-c-arc/ c-arc.txt 2c-err.txt

 real  7m48.020s
 user  0m5.304s
 sys   1m22.868s
 andreas@g4d:/mnt/test$ ls -l
 total 2775172
 - -rw-r--r-- 1 andreas andreas  0 Aug  7 08:20 c-arc.txt
 - -rw-r--r-- 1 andreas andreas1145749 Aug  7 08:27 c-err.txt
 drwxr-xr-x 1 andreas andreas136 Aug  7 08:27 fs-root-c-arc
 andreas@g4d:/mnt/test$ du -hs fs-root-c-arc/
 3.6G  fs-root-c-arc/

 andreas@g4d:/mnt/test$ chmod 000 fs-root-c-arc/
 andreas@g4d:/mnt/test$ time tar -cvf t-arc.tar /* t-out.txt 2t-err.txt

 real  6m25.904s
 user  0m6.016s
 sys   0m47.936s
 andreas@g4d:/mnt/test$ ls -l
 total 2784108
 - -rw-r--r-- 1 andreas andreas  0 Aug  7 08:20 c-arc.txt
 - -rw-r--r-- 1 andreas andreas1145749 Aug  7 08:27 c-err.txt
 drwxr--r-- 1 andreas andreas136 Aug  7 08:27 fs-root-c-arc
 - -rw-r--r-- 1 andreas andreas 2841907200 Aug  7 08:47 t-arc.tar
 - -rw-r--r-- 1 andreas andreas1348292 Aug  7 08:47 t-err.txt
 - -rw-r--r-- 1 andreas andreas6513194 Aug  7 08:47 t-out.txt

 This were two tests, first created an archive of the root filesystem using cp 
 below the
 folder /mnt/test/fs-root-c-arc/. This issued a lot of errors and warning 
 because of
 missing permissions or files, which changed while being read, but in the end 
 after 7m48s
 there were 151869 items in that folder, totalling 3.6 GB.
 Next the mode of the folder was set to 000, because else the content of the 
 folder would
 be taken into the newly created .tar-archive recursively. 
 Then doing basically the same thing, but putting all readable and accessable 
 files into a
 single uncompressed .tar-archive instead of just copying them.
 this was even faster with 6m25s and the archive was 2.6 Gb in size.
 This is not the same as installing from DVD and via network over http, but 
 big files and
 many small files are both written fast enough from xfs to btrfs, given that 
 this is a
 green-labeled harddisk, which is not supposed to break any velocity-records. 
 So I
 downgraded the installation-report to 'wishlist'. I consider the problems 
 were due to
 some kind of strange IRQ-conflict or the like. A software-upgrade was not 
 done since
 installation, just some additional packages installed.

No, your test did not really simulate the situation during installation.
The problem with btrfs is not poor write performance in general, but
very poor fsync performance. dpkg does a lot of fsync's and is therefore
heavily affected by this.

You could verify this by running debootstrap on a btrfs filesstem
(debootstrap wheezy /mnt). This will be incredibly slow. On the other
hand if you use the eatmydata utility which turns all fsync calls into
noops, it will be fast: eatmydata debootstrap wheezy /mnt. But beware,
it's called eatmydata for a reason...

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87ehnj0whb@meteor.durcheinandertal.bofh

Re: [SCM] d-i netcfg repository branch, people/sorina/coding_style, created. 1.65-204-g6652eb1

[Gaudenz Steinlin]

Hi

Philipp Kern pk...@debian.org writes:

 On Sun, Jul 29, 2012 at 02:54:55PM +0300, Sorina - Gabriela Sandu wrote:
 On Sun, Jul 29, 2012 at 12:50 PM, Philipp Kern pk...@debian.org wrote:
  On Sat, Jul 28, 2012 at 11:54:37PM +0200, Cyril Brulebois wrote:
  FWIW: If you want to push those changes into wheezy at some point,
  that's a bit unnice to the ones who get to review the changes, be
  it on the debian-boot@ or on the debian-release@ sides…
  Not only that, it also makes merging of branches (like the ipv6 one)
  unnecessarily hard, I guess.
 I think it's for the best if the entire package uses the same coding
 style rules, it's a bit uncomfortable to have some sources in one way
 and some in the other. I was also planning to do some more coding
 style fixes, but if it causes too much trouble, I can drop the plan.

 I sometimes agree, especially when it's entirely unclear which coding style to
 use. But I'd prefer that it's kept until possible feature branches are merged.
 It also invalidates patches that might be lingering around in the BTS.

We decided to only apply the part that replaced most magical values by
the right constants and dropped the whitespace style fixes.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
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/8739477fk5@meteor.durcheinandertal.bofh

Re: [SCM] d-i netcfg repository branch, people/sorina/coding_style, created. 1.65-204-g6652eb1

[Gaudenz Steinlin]

Hi

Philipp Kern pk...@debian.org writes:

 On Sat, Jul 28, 2012 at 11:54:37PM +0200, Cyril Brulebois wrote:
 FWIW: If you want to push those changes into wheezy at some point,
 that's a bit unnice to the ones who get to review the changes, be
 it on the debian-boot@ or on the debian-release@ sides…

The idea was to have these changes in one commit. So when reviewing you
can just skip this commit (or not if you want to review if it's
correct). Sure this makes reviews by just looking at the debdiff harder.
On the other hand all these changes are at least already reviewd by
myself. So they already get more review than the usual d-i
contributions.


 Not only that, it also makes merging of branches (like the ipv6 one)
 unnecessarily hard, I guess.

Good point. I didn't think of it that way yet. Do you know if the ipv6
branch is still mergable at the moment? I doubt that a bit as it's quite
old.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
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/87hasq7ow8@meteor.durcheinandertal.bofh

Bug#682656: debian-installer-netboot-images: file conflicts between debian-installer-{6, 7}.0-netboot-arch

[Gaudenz Steinlin]

Didier 'OdyX' Raboud o...@debian.org writes:

 Le mardi, 24 juillet 2012 13.17:10, Andreas Beckmann a écrit :
 debian-installer-6.0-netboot-arch and
 debian-installer-7.0-netboot-arch are not co-installable because they
 ship the same files, but don#t have corresponding conflicts.

 Indeed, thanks for your report.

 Since they already provide the debian-installer-netboot-arch virtual
 package, adding Conflicts/Replaces in that virtual package, too, should
 be trivial.

 That, or release-number-specify the paths; I'm not yet decided [0,1]. 
 Opinions?

I'd prefer to have them co-installable. It's not uncommon to have one
install server which serves installation images for different Debian
releases.

Gaudenz


 Cheers,

 OdyX

 [0] http://lists.debian.org/debian-boot/2012/07/msg00074.html
 [1] http://lists.debian.org/debian-boot/2012/07/msg00428.html


 -- 
 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/201207241338.00341.o...@debian.org


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
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/87zk6pjpc7@meteor.durcheinandertal.bofh

Re: [SCM] d-i netcfg repository branch, people/sorina/show_essids, updated. 1.65-150-ga603dff

[Gaudenz Steinlin]

Joey Hess jo...@debian.org writes:

 Justin B Rye wrote:
 But I suspect the best solution is:
 
  Select desired network name (ESSID) for connection attempt.

 Suggestion:

  Select the wireless network name (ESSID) to use during this
  installation process.

 It's not really relevant that it will attempt to connect to it and
 has a failure path. It is relevant that the installer will keep on using
 that same wireless network during the install, and that post-install,
 the system is likely to use a different one, at least when a desktop
 environment is installed.

I like this variant most. Thanks for the suggestion Joey. I suggest to
drop name and to just say the installation process:

Select the wireless network (ESSID) to use during the
installation process.

While it's technically more correct that you select the name
wpasupplicant will use, I think people will think of it as the wireless
network they want to connect to. the installation process sounds
better to me, but I'm not a native speaker. Comments?

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/878vf6jrn0@meteor.durcheinandertal.bofh

current rules for template changes (was Re: d-i: Plans for beta 1?)

[Gaudenz Steinlin]

Hi

Christian PERRIER bubu...@debian.org writes:

 Quoting Cyril Brulebois (k...@debian.org):
 Christian PERRIER bubu...@debian.org (11/06/2012):
  It's likely that a mass upload is needed for l10n purposes. Also, I
  think that a beta is the moment where I should decide about which
  languages I drop
  (http://www.perrier.eu.org/weblog/2012/06/09#di-deactivation-status-8)
 
 I think you're done now?

 Except running after last minute changes like netcfg last evening,
 yes..:-).

Sorry if this upload was wrong according to the rules. I was acting
under the premise that only strings in sublevels 1 and 2 were frozen. So
I thought it is OK to add strings on sublevel 5. IMHO it's absolutely no
problem if those are not translated as they are only shown if you
preseeded an invalid value or if you are running in expert mode. The
changes to all other strings were only trailing whitespace corrections
and I took extra care to verify that the don't change the templates.pot
file in any way. I removed one change because a string became fuzzy.

But as the Google summer of code of Sorina progresses we will have more
templates changes coming up. The new ESSID list (instead of the simple
text input we currently have) and other improvments are only possible by
adding or changing templates. 

What are the current rules for template changes? Is there a way to get
these changes into netcfg and uploaded without disturbing translators
too much?

I know that now with the freeze being just about 1 week away it might be
difficult to get the results of the GSOC project into wheezy. The timing
is quite unfortunate for us. But if possible it would be really nice if
at least some changes could make it into the release.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/874nq3qne5@meteor.durcheinandertal.bofh

Re: current rules for template changes (was Re: d-i: Plans for beta 1?)

[Gaudenz Steinlin]

Hi

Christian PERRIER bubu...@debian.org writes:

 Quoting Gaudenz Steinlin (gaud...@debian.org):

 Please remember that these changes have to be documented in the
 release notes, too

Do you mean the release notes or the installation guide? I have a patch
for the installation guide ready documenting the changes of my last
upload. Will commit it on Monday (away from that computer atm).


 I would anyway suggest to make these templates untranslatable as of
 now. Otherwise, I'll again run after them...and, even if I like
 running, I prefer doing so in the outside..:-)

 I willturn them  to translatable when I think it's safe to launch a
 new call for translations (immediately after beta1 release, I guess).

I'm ok with this.

Gaudenz



-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87zk7vp082@meteor.durcheinandertal.bofh

Re: Debian the FSF Secure Boot petition

[Gaudenz Steinlin]

Hi

Stefano Zacchiroli lea...@debian.org writes:

 Dear d-i hackers, I've been contacted by Paul Wise about FSF campaign on
 secure boot [1] (thanks Paul!). As observed by various commenters over
 the net, it is indeed striking that no FOSS distros is in there. I plan
 to contact the FSF asking that Debian is listed as an endorser of the
 campaign.

 As you are the Debian people working on our installer, I think it should
 be done in agreement with you.

 So, what do you think?  Do you see any reason why Debian should /not/
 endorse such a campaign?  Are you aware of any other initiative on the
 same vein that we should support to make our worries on that front
 heard?

I don't see any reason not to join. I actually was not yet aware of this
campaign and just signed the statement myself. But on the other hand I'm
just a sporadic contributor to the installer, so the word of others
should have more weight.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87wr3fid9h@meteor.durcheinandertal.bofh

Re: GSoC project

[Gaudenz Steinlin]

Hi Sorina

On Sat, 31 Mar 2012 14:32:11 -0400, Sorina - Gabriela Sandu 
sandu.sor...@gmail.com wrote:
 Hello!
 
 Hope you don't mind, I took some time to dig into d-i internals,
 getting used with the code and the build system.
 
 I took a look at bug #610752 [0] and made a first attempt of
 a patch. I posted the git diff on pastebin [1], since I wanted to
 be sure it is ok before submitting it. Please tell me if this was
 the right thing to do.

As far as I can see the code is correct. But it's lacking some error
handling. If the user does not enter an integer you just continue with
the default value with any error message. It would be nice to display an
error note, reset the question and reask the question instead. You can
find an example of how to do this in static.c.

And if I'm not mistaken you misinterpreted the value of link_waits. As
it's used as a upper bound in the loop just after your code and inside
this loop the thread sleeps only for 0.25s. So you have to multiply the
value by 4 (like in the original code).

 
 Firstly, I am not very sure about debconf_go return value. I
 assumed it returns 0 if everything is ok, based on the way it is
 used in other functions, such as netcfg_get_domain
 (netcfg-common.c), but I have not found anything explicitly
 saying so.

The cdebconf client documentation is a bit lacking ;-). I guess the
return codes are from this enum in
d-i/packages/cdebconf/src/debconfclient.h:

/**
 * @brief command codes returned by debconf commands
 */
typedef enum {
CMD_SUCCESS = 0,
CMD_ESCAPEDDATA = 1,
CMD_BADQUESTION = 10, 
CMD_BADPARAM= 15, 
CMD_SYNTAXERROR = 20, 
CMD_INPUTINVISIBLE  = 30, // from debconf_input()
CMD_BADVERSION  = 30, // from debconf_version()
CMD_GOBACK  = 30, // from debconf_go()
CMD_PROGRESSCANCELLED   = 30, // from debconf_progress_{set,step,info}()
CMD_INTERNALERROR   = 100 
} cmdstatus_t;


 
 Secondly, in the bug report it was suggested to remove
 NETCFG_LINK_WAIT_TIME, but I considered it could be used for
 setting a default value, since I believe getting timeout value
 has a low priority and there wouldn't be necessary to loop until
 a correct value is provided.

I definitely agree about the low priority. For the default value I'd
prefer to have that on the debconf template instead. 
 
 In addition, could you please tell me what exactly does installation
 manual appendix updating implies?

All debconf templates that are preseedable (for automatic installation)
are documented in the appendix of the installation manual. The source
for the manual is in d-i/manual/en/ in the d-i subversion repository.
It's not (yet) in git.

Regars,
Gaudenz


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87d3769eb2@meteor.durcheinandertal.bofh

Re: GSoC project

[Gaudenz Steinlin]

Hi Sorina

Please keep the CC to the debian-boot@lists.debian.org mailinglist. This
is the mailinglist for debian-installer development.

On Sat, 24 Mar 2012 18:12:41 -0400, Sorina - Gabriela Sandu 
sandu.sor...@gmail.com wrote:
 Hello!
 
 
 On Sat, Mar 24, 2012 at 8:27 AM, Gaudenz Steinlin gaud...@debian.org wrote:
 
  No there is currently no difficulty level attached to the bugs. You have
  to read through the various bugs and judge for yourself if you think
  that would be a good one to start with. Bugs #646860 and #636211 might
  be good targets to get used to the installer. The first one even has a
  patch in the bug report.
 
 From what I see, the patch for the bug #646860 has not yet been applied, is
 there anything wrong with it? From my point of view, it seems legit.

I haven't had a close look at it but I guess that just nobody took the
time to fix the issue. The installer team is sometimes a bit short on
manpower.

  As for the next steps. Please submit your application n the Debian wiki
  [1] using the provided template [2]. Don't forget to also apply on the
  Summer of Code Site [3] as soon as student registrations open.
 
 I shall get to this right away. Are there any specific requirements for the
 application on the Summer of Code site?

Applications only open tomorrow. As far as I know there are no specific
requirements beside the obvious ones (you need a google account, you
have to be an universitity student, you have to have time during the
summer to work on the project, ...). But check the summer of code site
for the details. For the application in the Debian wiki please use the
provided template (see my previous mail).

 
  There is currently one other application for the project and someone
  else contacted me.
 
 This is not a surprise since the project really is interesting. A
 little competition
 is always welcomed, I hope we can all deliver something useful.
 
  If you all apply for the same project I might give
  you a small taks to evaluate you applications after the application
  deadline.
 
 I'm sorry, but I am not sure I really understand what you mean by
 that.

I meant that I might give all of you a small task to evaluate your
skills. If you look at the timeline[1] you will see that there is a 2
weeks period in April where mentoring organizations review and rank
student proposals. Is it more clear now?

 
 Also, sorry for the late answer, setting up my environment, installing
 Debian (I was using Ubuntu), making configurations and installing all the
 packages needed took a little longer than expected, PPP configuration
 support would have been more than useful.

No problem with the late answer. It's after all only 10 hours after my
last mail. I wouldn't call that a late answer...

 
 This may seem like a silly question, but how could I test/run what I am
 doing with the netcfg under the installer? In my attempts until now I have
 managed to mess up my network config files by writing loopback interfaces
 and stuff. I tried searching the documentation/web, however was unable
 to find an answer.

The easiest way to test modifications is to build a test image of the
installer and to run that in a virtual machine. The process of building
images is explained in the d-i internals manual [2]. The Debian Wiki
also contains some information[3][4].

For wireless testing I used KVM with libvirt and virt-manager. There you
can configure your virtual machine so that KVM passes through your
wireless device with PCI passthrough. For this to work you need a
computer with Intel VT-d or AMD IOMMU CPU extensions. The Fedora
Documentation about Virtualization has more details about how to
configure this [5]. This is equally applicable to Debian. 

Gaudenz

[1] http://wiki.debian.org/SummerOfCode2012#Google_timeline 
[2] http://d-i.alioth.debian.org/doc/internals/
[3] http://wiki.debian.org/DebianInstaller
[4] http://wiki.debian.org/DebianInstaller/Build
[5]
http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/chap-Virtualization-PCI_passthrough.html

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87d3807nyn@meteor.durcheinandertal.bofh

Re: GSoC Project Idea: WPA2 support for the debian installer

[Gaudenz Steinlin]

Hi Max

Thanks for your application. Don't forget to also apply on the GSOC site
as soon as student applications open.

On Sat, 24 Mar 2012 01:47:57 +0100, Max Linke max_linke-deb...@gmx.de wrote:
 Hi
 
 the description looks nice. I have written a draft for my
 application[1]. Does the project schedule look realistic to you?
 Looking in the BUG-Tracker I have found #636211, which looks like a nice
 thing to get started working with the code. As for the other parts I
 think I it would be better if I concentrate on netcfg and work through
 the whishlist-bugs. 

Yes #636211 looks like a nice small bug to get started. Your schedule
while still a bit course grained looks realistic. You probably could
make it a bit finer grained by including phases for things like getting
to know the installer environment, documentation updates, ...

How much experience do you have with debian packaging? All the installer
components are basically small debian packages so you definitely have to
learn a bit about packaging. I suggest the new maintainer guide as a
starting point.

Best,
Gaudenz

 
 lg Max
 
 [1]http://wiki.debian.org/SummerOfCode2012/StudentApplications/MaxLinke
 
 On Wed, 21 Mar 2012 22:32:08 +0100
 Gaudenz Steinlin gaud...@debian.org wrote:
 
  
  Hi Max
  
  On Wed, 14 Mar 2012 15:39:40 +0100, Max Linke
  max_linke-deb...@gmx.de wrote:
   Hi
   
   Yeah I'm interested. Can you give a more detailed
   description on what is still left to do.
  
  I added a description of the project to the wiki page [1]. I made the
  topic a bit broader to include general improvements of the network
  setup in debian installer. The project could even be extended to
  other areas of the installer if time permits and there is interest.
  
  As I said before I'm willing to act as the primary mentor but I would
  like to have at least one co-mentor from the d-i team. Is there
  someone who would like to fill this role?
  
  Also feel free to improve the project description on the wiki page.
  
  Best,
  Gaudenz
  
  [1]
  http://wiki.debian.org/SummerOfCode2012/Projects#Improve_debian-installer_network_setup
   
   best,
   Max
   
   
   On Wed, 07 Mar 2012 15:45:14 +0100
   Gaudenz Steinlin gaud...@debian.org wrote:
   

Hi

On Wed, 7 Mar 2012 11:17:48 +0100, Max Linke
max_linke-deb...@gmx.de wrote:
 Hello
 
 I would like to know if it is a appropriate project for GSoC 
 to add WPA2 support for the debian installer.

As others already said, basic WPA2 support ist available in the
installer. Although the user interface and the feature set are far
from perfect. Currently only PSK is supported. There is no way to
scan for available networks.

I integrated all this into d-i during last DebConf and as far as I
know not much work has been done since then. I would be willing to
mentor any student working on improving WPA support in the
installer.

Are you interested?

Gaudenz
   
   
   -- 
   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/20120314153940.64a1d746@Thinki
   
  
 
 
 -- 
 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/20120324014757.236ff25e@Thinki
 

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87ty1e6wsn@meteor.durcheinandertal.bofh

Re: summer of code: debian installer project

[Gaudenz Steinlin]

Hi Richard

On Fri, 23 Mar 2012 10:32:38 +, Richard Kenyon richardlken...@gmail.com 
wrote:
 Hi,
 
 I'm a CS student and user of Debian and I'd like to take part in the
 summer of code.
 This project looks both interesting and at about the right level of
 difficulty for me.
 
 I don't really mind what tools I use but C is one of the languages
 that I particularly enjoy working with.
 As a user of Debian I have some basic knowledge of package management,
 this won't be enough, but I am more than happy to learn more.
 Similarly with the installer, I am familiar with it, but will need to
 dig around more.
 
 I would really like to work on this project since I've always felt
 that the wireless support in the installer let Debian down a bit,
 and the results would directly benefit me as well many other Debian users.
 
 I'm contacting you now to ask what my next steps should be, where
 should I direct my attention, do you want any sort of deliverable
 before I apply?

Sounds like you would be a good fit for the project. As for the next
steps. Please submit your application n the Debian wiki [1] using the
provided template [2]. Don't forget to also apply on the Summer of Code
Site [3] as soon as student registrations open.

There is currently one other application for the project and someone
else contacted me. If you all apply for the same project I might give
you a small taks to evaluate you applications after the application
deadline. On the other hand we could probably also need more than one
student working on the installer if you would also be interested in
working on other parts of the installer. We would also need more mentors
then though and it's not yet clear how many students for the Debian project
will be approved. This will be decided after the student application
deadline.

Best,
Gaudenz

[1] http://wiki.debian.org/SummerOfCode2012/StudentApplications
[2] http://wiki.debian.org/SummerOfCode/StudentApplicationTemplate
[3] http://www.google-melange.com/gsoc/homepage/google/gsoc2012
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87r4wi6w9n@meteor.durcheinandertal.bofh

Re: GSoC project

[Gaudenz Steinlin]

Hi Sorina

On Thu, 22 Mar 2012 20:41:33 +0200, Sorina - Gabriela Sandu 
sandu.sor...@gmail.com wrote:
 Hello!
 
 I am Sorina Sandu, I am currently a second year bachelors Computer Science
 student at Politehnica University of Bucharest. I have looked through Debian
 Development section and I particulary enjoyed how things are organized and
 how they work.
 
 I have read Gsoc projects ideeas and I fount the debian-installer network 
 setup
 very interesting. I would like to contribute to this project and I
 hoped that you
 could point me in the right direction.
 
 While trying to figure out how work should be done I came across the New
 Maintainers' Guide[0] which seems to be a very good start. I was wondering
 if I could also find something more specific, related to this project.

The new maintainers guide is definitely a good starting point. The
debian installer internals manual[4] also has a chapter on udebs.

 
 Also, I took a look at the bug list and I was wondering what could I start 
 with,
 for getting used to how things work. It would be very good if they had some
 kind of difficulty label (or they have and I didn't see it?)

No there is currently no difficulty level attached to the bugs. You have
to read through the various bugs and judge for yourself if you think
that would be a good one to start with. Bugs #646860 and #636211 might
be good targets to get used to the installer. The first one even has a
patch in the bug report.

What's your experience with C language code?

As for the next steps. Please submit your application n the Debian wiki
[1] using the provided template [2]. Don't forget to also apply on the
Summer of Code Site [3] as soon as student registrations open.

There is currently one other application for the project and someone
else contacted me. If you all apply for the same project I might give
you a small taks to evaluate you applications after the application
deadline. On the other hand we could probably also need more than one
student working on the installer if you would also be interested in
working on other parts of the installer. We would also need more mentors
then though and it's not yet clear how many students for the Debian project
will be approved. This will be decided after the student application
deadline.

Best,
Gaudenz

[1] http://wiki.debian.org/SummerOfCode2012/StudentApplications
[2] http://wiki.debian.org/SummerOfCode/StudentApplicationTemplate
[3] http://www.google-melange.com/gsoc/homepage/google/gsoc2012
[4] http://d-i.alioth.debian.org/doc/internals/
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87obrm6v65@meteor.durcheinandertal.bofh

Re: GSoC Project Idea: WPA2 support for the debian installer

[Gaudenz Steinlin]

Hi Max

On Wed, 14 Mar 2012 15:39:40 +0100, Max Linke max_linke-deb...@gmx.de wrote:
 Hi
 
 Yeah I'm interested. Can you give a more detailed
 description on what is still left to do.

I added a description of the project to the wiki page [1]. I made the
topic a bit broader to include general improvements of the network setup
in debian installer. The project could even be extended to other areas
of the installer if time permits and there is interest.

As I said before I'm willing to act as the primary mentor but I would
like to have at least one co-mentor from the d-i team. Is there someone
who would like to fill this role?

Also feel free to improve the project description on the wiki page.

Best,
Gaudenz

[1] 
http://wiki.debian.org/SummerOfCode2012/Projects#Improve_debian-installer_network_setup
 
 best,
 Max
 
 
 On Wed, 07 Mar 2012 15:45:14 +0100
 Gaudenz Steinlin gaud...@debian.org wrote:
 
  
  Hi
  
  On Wed, 7 Mar 2012 11:17:48 +0100, Max Linke
  max_linke-deb...@gmx.de wrote:
   Hello
   
   I would like to know if it is a appropriate project for GSoC 
   to add WPA2 support for the debian installer.
  
  As others already said, basic WPA2 support ist available in the
  installer. Although the user interface and the feature set are far
  from perfect. Currently only PSK is supported. There is no way to
  scan for available networks.
  
  I integrated all this into d-i during last DebConf and as far as I
  know not much work has been done since then. I would be willing to
  mentor any student working on improving WPA support in the installer.
  
  Are you interested?
  
  Gaudenz
 
 
 -- 
 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/20120314153940.64a1d746@Thinki
 

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/87wr6d8wtj@meteor.durcheinandertal.bofh

Re: GSoC Project Idea: WPA2 support for the debian installer

[Gaudenz Steinlin]

Hi

On Wed, 7 Mar 2012 11:17:48 +0100, Max Linke max_linke-deb...@gmx.de wrote:
 Hello
 
 I would like to know if it is a appropriate project for GSoC 
 to add WPA2 support for the debian installer.

As others already said, basic WPA2 support ist available in the
installer. Although the user interface and the feature set are far from
perfect. Currently only PSK is supported. There is no way to scan for
available networks.

I integrated all this into d-i during last DebConf and as far as I know
not much work has been done since then. I would be willing to mentor any
student working on improving WPA support in the installer.

Are you interested?

Gaudenz


-- 
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/87sjhccwo4@moebius.durcheinandertal.bofh

Re: [pkg-wpa-devel] libnl3 soname change

[Gaudenz Steinlin]

Hi

On Sun, 18 Dec 2011 20:16:08 +0100, Heiko Stübner he...@sntech.de wrote:
 Hi,
 
 Am Donnerstag 15 Dezember 2011, 22:13:43 schrieb Stefan Lippers-Hollmann:
  Hi
  
  On Thursday 15 December 2011, Joey Hess wrote:
   Heiko Stübner wrote:
So the question would be on how to proceed to get this into unstable
without breaking to much.
  
  [...]
  
  I have prepared and tested (for the non-udeb cases, see below) iw[1] and
  wpasupplicant[2] in svn now, likewise hostapd[3] will switch to
  libnl-3 = 3.2 (from libnl1) after it gets available in unstable (no
  urgency at all).
  
  Something seems to be missing for the udeb handling though:
  Package: wpasupplicant-udeb
  [...]
  Depends: libc6-udeb (= 2.13), libcrypto1.0.0-udeb (= 1.0.0),
  libnl-3-200-udeb (= 3.2.3), libnl-genl-3-200, busybox-udeb
   I'm not overly familiar with udeb specifics, but I think
  this is
  missing something equivalent to
  DEB_DH_MAKESHLIBS_ARGS_libnl-3-200 := -Vlibnl-3-200 (=
  $(DEB_UPSTREAM_VERSION)) --add-udeb=$(udeb) in libnl3's debian/rules.
 my understanding of udeb handling is also only rudimentary :-)
 
 As I did not split the udeb libnl-genl-3 resides at the moment in libnl-3-200-
 udeb. The dependencies all have a -udeb in its package name, but libnl-
 genl-3-200 has not. So my guess would be, that a libnl-genl-3-200-udeb is 
 also 
 necessary.

I'll try to look into the udeb issues but not before Thursday this week.
If anyone has time to do this before I'm more than happy. If you have
any specific questions I can answer mails even before.

Gaudenz

 
 
  For iw (which is needed by crda's udev rules), it would be nice to
  have libnl.so.3 and libnl-genl.so.3 in /lib/ (#622247: iw binary should
  be installed in /sbin). The wpasupplicant package would also profit
  from that (#537790), although it is haunted by openssl and zlib as
  dependencies well.
 As libnl seems to be used by a lot of system-level programs, should only 
 these 
 two libs move to /lib or all?
 
 Heiko
 
 
 -- 
 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/201112182016.09233.he...@sntech.de
 

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgpxcMLTiCUvp.pgp
Description: PGP signature

WPA bloat

[Gaudenz Steinlin]

On Thu, 8 Dec 2011 23:45:04 +0100, Philipp Kern pk...@debian.org wrote:
 there's connectivity.  On the other hand we added a bloated wpa
 supplicant with crypto libs without any effort to get it trimmed (yet),

That's simply wrong. I spent quite some time at Debconf trying to trim
down the size of the WPA support. There is certainly room for
improvements but it's not as easy as it may seem at first. I also
discussed the size implications with Otavio at that time. Patches are
always welcome.

Gaudenz

P.S.: I don't oppose the addition of a ping command at all. In fact I
don't care.

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgplxBFLN4m31.pgp
Description: PGP signature

Bug#646699: btrfs: Installer offers BTRFS an optional filesystem

[Gaudenz Steinlin]

On Wed, 26 Oct 2011 23:21:33 +0530, Christian PERRIER bubu...@debian.org 
wrote:
 severity 646699 important
 reassign 646699 partman-btrfs
 retitle 646699 Please make partman-btrfs optional as BTRFS is too unstable
 thanks
 
 Quoting Gergely Nagy (alger...@balabit.hu):
  reassign 646699 debian-installer
  thanks
  
  Maarten mvros...@gmail.com writes:
  
   Package: btrfs
   Severity: critical
   Justification: causes serious data loss
  
   BTRFS shouldn't be offert as a option filesystem in the debian installer.
   It is unsafe to use. Quallity is poor. No recovery possible on filesystem 
   errors. (The btrfs driver will even crash on a filesystem error)
   The provided tool btrfsck doesn't actually do anything.
   There doesn't seem to be any progres on a working btrfsck.
  
   Atleased users should be warned to not use it, unless they don't
   care about dataloss

Do you have any real world cases to support these claims using a recent
kernel version (at least the version currently in testing).

  
  There is no btrfs package in Debian, thus, this report did not reach any
  developers. Furthermore, since it is the installer that is allegedly at
  fault, it should be filed against the debian-installer package.
  
  I went ahead and reassigned it there.
 
 
 Well, if btrfs is in such a bad shape, then partman-btrfs should be
 made optional so that only those people who really want it will have
 it as an option.
 
 I don't think that dropping the package entirely is the best
 option. But making it less visible in D-I is probably good if I
 believe in the above claims (I have no idea about this to be true or
 not).

With my own experience with BTRFS I can not support the above claims. In
several tests and while running my laptop with BTRFS I never saw any
data loss. While it's true that there is no external filesystem checker
(aka btrfsck) as this is a journaling filesystem such a tool is much
less needed than for a non journaling filesystem. Also a btrfsck tool
is in the works, but it's unclear when it will be released.

The main reason why I would not recommend btrfs on Debian for / is it's very
poor fsync performance which makes apt runs a pain in the ass if you
don't use eatmydata which disables fsync. But that's a performance and
not a corectness issue.

BTRFS might be unreliable with the current stable kernel. I did not test
this. So if someone really belives that BTRFS should be less visible,
just do that for the stable installer (if thats possible wrt stable
update policies).

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgpzfjNCr4Ov2.pgp
Description: PGP signature

Re: Problems with d-i on self-made (debian-cd/easy-build.sh) Debian images

[Gaudenz Steinlin]

Hi Mario

On Mon, 24 Oct 2011 19:27:48 +0200, Mario Fux debian...@unormal.org wrote:
 Morning again
 
 So no progress. Tried to freshly install debian-cd with new config files and 
 without custom packages. Build an ISO image with easy-build.sh DVD and got 
 one.
 
 I got some warnings about some GPG stuff which afaik shouldn't be a
 problem.

Hard to tell without any further information...

 
 Doesn't anybody of you is able to build wheezy images which install without 
 the kernel module mismatch error? Or is this the wrong mailing list and is 
 there a debian-cd one?

Is your local mirror up to date? Where did yout get the debian installer
image from? If you are building with the debian-installer image from the
archive this is probably expected, as this package was not updated
recently.

You have to build your debian-cd image with a daily built installer
image from http://d-i.debian.org/daily-images/. See README.easy-build
for instructions on how to build with a custom d-i image. 

 
 Btw I tested the image in virtualbox, qemu and with a usb stick on a real 
 device. Always the same problem.

I don't think that matters at all.

If your problem persists please add a bit more debuging info to your
reports. It's a bit hard to tell what's wrong just with the information
in your mail. Especially check the kernel version the installer is
booting and the version of the kernel module udebs included on your CD.
If the don't match your reported error is expected. 

Gaudenz

 
 Thx for any hint
 Mario
 
 
 -- 
 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/201110241927.48699.debian...@unormal.org
 
From: Gaudenz Steinlin gaud...@soziologie.ch
Subject: Re: Problems with d-i on self-made (debian-cd/easy-build.sh) Debian 
images
To: Mario Fux debian...@unormal.org, debian-boot@lists.debian.org
In-Reply-To: 201110141940.55941.debian...@unormal.org
References: 201110131145.37064.debian...@unormal.org 
87fwiwuhc0.fsf@meteor.durcheinandertal.local.i-did-not-set--mail-host-address--so-tickle-me
 201110141940.55941.debian...@unormal.org

On Fri, 14 Oct 2011 19:40:55 +0200, Mario Fux debian...@unormal.org wrote:
 Am Freitag 14 Oktober 2011, 10.07:27 schrieb Gaudenz Steinlin:
  Hi Mario
 
 Morning Gaudenz
 
  On Thu, 13 Oct 2011 11:45:36 +0200, Mario Fux debian...@unormal.org
  wrote: Non-text part: Multipart/Mixed
  
   Good morning
   
   And then trying to install I got the following error message in qemu and
   virtualbox:
   Error message:
   
   Error: Load installer components from CD:
   No kernel modules were found. This probably is due to a mismatch between
   the kernel used
   by this version of the installer and the kernel version available in the
   archive.
  
  As the error message says (unless there is a bug in d-i itself), the
  version of the kernel you are booting from your CD is not the same as in
  the archive. Which suite (stable, testing, unstable) are you tring to
  install? Did you somhow customize your installer kernel? These versions
  have to match exactly (including ABI version).
 
 No. In the first attempts I used the same version (suite) for the installer 
 images as for the rest of the distribution. Afterwards I tried other 
 combination: d-i from sid and rest from wheezy. Didn't really help.
 
  The most likely cause is that the kernel got updated in between the
  moment you built your image and the installation.
 
 Ok. Will try it again in the next days with an uptodate mirror and will come 
 back if it doesn't help.
 
 thx
 Mario
 
 
 -- 
 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/201110141940.55941.debian...@unormal.org
 
From: Gaudenz Steinlin gaud...@debian.org
Subject: Re: Problems with d-i on self-made (debian-cd/easy-build.sh) Debian 
images
To: Debian Install System Team debian-boot@lists.debian.org
In-Reply-To: 
87fwiwuhc0.fsf@meteor.durcheinandertal.local.i-did-not-set--mail-host-address--so-tickle-me
References: 201110131145.37064.debian...@unormal.org 
87fwiwuhc0.fsf@meteor.durcheinandertal.local.i-did-not-set--mail-host-address--so-tickle-me

On Fri, 14 Oct 2011 10:07:27 +0200, Gaudenz Steinlin gaud...@debian.org wrote:
 
 Hi Mario
 
 On Thu, 13 Oct 2011 11:45:36 +0200, Mario Fux debian...@unormal.org wrote:
 Non-text part: Multipart/Mixed
  Good morning
  
  And then trying to install I got the following error message in qemu and 
  virtualbox:
  Error message:
  
  Error: Load installer components from CD:
  No kernel modules were found. This probably is due to a mismatch between 
  the 
  kernel used 
  by this version of the installer and the kernel version available in the 
  archive.
 
 As the error message says (unless there is a bug in d-i itself), the
 version of the kernel you are booting from your CD

Re: Problems with d-i on self-made (debian-cd/easy-build.sh) Debian images

[Gaudenz Steinlin]

Hi Mario

On Thu, 13 Oct 2011 11:45:36 +0200, Mario Fux debian...@unormal.org wrote:
Non-text part: Multipart/Mixed
 Good morning
 
 And then trying to install I got the following error message in qemu and 
 virtualbox:
 Error message:
 
 Error: Load installer components from CD:
 No kernel modules were found. This probably is due to a mismatch between the 
 kernel used 
 by this version of the installer and the kernel version available in the 
 archive.

As the error message says (unless there is a bug in d-i itself), the
version of the kernel you are booting from your CD is not the same as in
the archive. Which suite (stable, testing, unstable) are you tring to
install? Did you somhow customize your installer kernel? These versions
have to match exactly (including ABI version).

The most likely cause is that the kernel got updated in between the
moment you built your image and the installation.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgp60Gv62Wbnj.pgp
Description: PGP signature

Re: Resync netcfg in D-I git?

[Gaudenz Steinlin]

Hi Christian

Excerpts from Christian PERRIER's message of 2011-08-05 09:54:11 +0200:
 Hello Gaudenz,
 
 As it seems, D-I git is not synced with uploaded netcfg. I wanted to
 do an l10n upload (many translation teams have now translated the new
 WPA templates) but I indeed can't.
 
 Would you mind, when possible (back from your holidays), resyncing
 D-I git with the uploaded 1.66 and 1.67 packages?

I've now pushed everything into the d-i git repo. I thought that this
was automatically done by the do-upload script, but it seems that I
should have done this manually after the upload.

Sorry for the mess I produced.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: [pkg-wpa-devel] Bug#610931: Please build wpasupplicant-udeb

[Gaudenz Steinlin]

Hi 

I've now uploaded the package. Please see the attached NMU patch.

Gaudenz

Excerpts from Gaudenz Steinlin's message of 2011-07-30 04:08:32 +0200:
 Excerpts from Kel Modderman's message of 2011-07-30 01:44:07 +0200:
  On Sat, 30 Jul 2011 06:25:00 AM Gaudenz Steinlin wrote:
   Excerpts from Kel Modderman's message of 2011-07-27 13:30:37 +0200:
On Wed, 27 Jul 2011 02:43:02 AM Gaudenz Steinlin wrote:
 OK. How do you feel about me NMUing wpa_supplicant to add the udeb? I
 added an updated patch for the udeb to this mail. If you are OK I'll
 upload this as an NMU after libnl1-udeb enters the archive.

I would be very happy for you to do that.
   
   After some more investigation we (I and Otavio) decided that we rather
   want to move wpasupplicant to build against libnl3. I guess this has
   to be done at some point anyway and it avoids to have to do the whole
   work again for libnl3. So we created a udeb for libnl3 and will upload
   this soon. I hope you agree to this change. If you are against it
   please reply soon.
  
  This is a far more invasive change than just adding the udeb. Please be 
  prepared to pick up the pieces in case regression in stable functionality 
  are 
  introduced with such a change.
  
  Doing this when moving from wpa_supplicant 0.7.x - 0.8.x (not yet 
  released) 
  would be more appropriate in my opinion.
  
  I am less happy about this change, but do not oppose NMU's regardless of 
  the 
  risk, the rewards may be worth it.
 
 I can understand your concerns.
 
  
   
   The only change needed in wpasupplicant for this is to set 
   CONFIG_LIBNL20=y
   in the linux and udeb configs.
  
  And cross your fingers that it works just the same, without any noticable 
  change to the end users.
 
 For what it's worth I'm using a wpasupplicant built against libnl3
 since 3 days on my laptop here at Debconf without any problems. But as
 it stands this is just testing on one single driver (iwlwifi) on one
 single network. Probably some wider testing would be appropriate.
 
 Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


build_wpasupplicant_udeb_v3.patch
Description: Binary data

Bug#635962: Please provide udeb package of libnl3 for debian-installer

[Gaudenz Steinlin]

Source: libnl3
Version: 3.0-1
Severity: wishlist
Tags: d-i

To add WPA wireless configuration support in d-i we need wpa_supplicant
and thus libnl3 (wpa_supplicant is goning to be converted to libnl3
soon). For this we need an udeb version of libnl3.

We are currently at Debconf working on a patch for your package and will
probably submit it tomorrow. We want to ask you if you would agree to an
NMU for this. 

This is quite urgent for us because the libnl3-udeb has to enter the
archive first so that we can build wpasupplicant against it and then the
d-i component (netcfg) against the wpasupplicant-udeb.

Our patch will modify your CDBS rules file to use the CDBS flavour
functionality to build a special version for the udeb. For this to work
we also need a patch from the upstream git repository to be able to
build the library outside of the source tree.

Thanks for your cooperation,
Gaudenz


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libnl3 depends on:
ii  libc6 2.13-7 Embedded GNU C Library: Shared lib

libnl3 recommends no packages.

libnl3 suggests no packages.

-- no debconf information



-- 
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/20110729195523.30851.64978.reportbug@meteor.durcheinandertal.local

Re: Bug#610931: Please build wpasupplicant-udeb

[Gaudenz Steinlin]

Excerpts from Kel Modderman's message of 2011-07-27 13:30:37 +0200:
 On Wed, 27 Jul 2011 02:43:02 AM Gaudenz Steinlin wrote:
  
  OK. How do you feel about me NMUing wpa_supplicant to add the udeb? I
  added an updated patch for the udeb to this mail. If you are OK I'll
  upload this as an NMU after libnl1-udeb enters the archive.
 
 I would be very happy for you to do that.

After some more investigation we (I and Otavio) decided that we rather
want to move wpasupplicant to build against libnl3. I guess this has
to be done at some point anyway and it avoids to have to do the whole
work again for libnl3. So we created a udeb for libnl3 and will upload
this soon. I hope you agree to this change. If you are against it
please reply soon.

The only change needed in wpasupplicant for this is to set CONFIG_LIBNL20=y
in the linux and udeb configs.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1311970907-sup-4875@meteor.durcheinandertal.local

Re: [pkg-wpa-devel] Bug#610931: Please build wpasupplicant-udeb

[Gaudenz Steinlin]

Excerpts from Kel Modderman's message of 2011-07-30 01:44:07 +0200:
 On Sat, 30 Jul 2011 06:25:00 AM Gaudenz Steinlin wrote:
  Excerpts from Kel Modderman's message of 2011-07-27 13:30:37 +0200:
   On Wed, 27 Jul 2011 02:43:02 AM Gaudenz Steinlin wrote:
OK. How do you feel about me NMUing wpa_supplicant to add the udeb? I
added an updated patch for the udeb to this mail. If you are OK I'll
upload this as an NMU after libnl1-udeb enters the archive.
   
   I would be very happy for you to do that.
  
  After some more investigation we (I and Otavio) decided that we rather
  want to move wpasupplicant to build against libnl3. I guess this has
  to be done at some point anyway and it avoids to have to do the whole
  work again for libnl3. So we created a udeb for libnl3 and will upload
  this soon. I hope you agree to this change. If you are against it
  please reply soon.
 
 This is a far more invasive change than just adding the udeb. Please be 
 prepared to pick up the pieces in case regression in stable functionality are 
 introduced with such a change.
 
 Doing this when moving from wpa_supplicant 0.7.x - 0.8.x (not yet released) 
 would be more appropriate in my opinion.
 
 I am less happy about this change, but do not oppose NMU's regardless of the 
 risk, the rewards may be worth it.

I can understand your concerns.

 
  
  The only change needed in wpasupplicant for this is to set CONFIG_LIBNL20=y
  in the linux and udeb configs.
 
 And cross your fingers that it works just the same, without any noticable 
 change to the end users.

For what it's worth I'm using a wpasupplicant built against libnl3
since 3 days on my laptop here at Debconf without any problems. But as
it stands this is just testing on one single driver (iwlwifi) on one
single network. Probably some wider testing would be appropriate.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1311991544-sup-5662@meteor.durcheinandertal.local

Re: Bug#610931: Please build wpasupplicant-udeb

[Gaudenz Steinlin]

Excerpts from Kel Modderman's message of 2011-07-26 15:14:11 +0200:
 Hi,
 
 On Mon, 25 Jul 2011 09:34:27 AM Gaudenz Steinlin wrote:
   Has there been any solution for the netcfg integration already,
   see 201011041811.11753@otaku42.de [1], referring to the
   originally proposed introduction of embedded source copies of
   wpasuppliant's wpa_ctrl.[hc] into netcfg. Please also keep in
   mind that crda/ wireless-regdb is required for accessing
   channels 11-13/14 on modern drivers.
  
  I've applied the existing WPA netcfg support patches developed by
  Glenn Saberton, and they do appear to include a (stripped down)
  wpa_ctrl.c.
 
 That stripped down crap probably was extracted from a sideline
 project (python-wpactrl) I was working on, and is not good long term
 solution.
 
 wpa_ctrl.{c,h} from current wpasupplicant source tree have lots more
 dependency on other stuff. Extracting and patching wpa_ctrl.{c,h} to
 be standalone is something which should be avoided - I just do not
 know how currently.
 
 Asked upstream wpa_supplicant if wpa_ctrl could be provided in a way
 where it could be a shared library but received no response.

Is there any progress on this?
   
   Nope.
  
  Do you think it's worth poking about this again? The current code in
  netcfg works (at least for the debconf wpa-psk network), but a real
  library would be nicer ;-).
 
 It cannot hurt to ask. I've already asked before, so maybe someone else can 
 this time :).

I'll see what I can do.

 
  
  I
  have no idea what the story is with crda/wireless-regdb, as I said
  before, I don't know anything about WPA.  If you'd like to help
  out, though, your knowledge would be greatly valued.
 
 I wouldn't mind helping out, don't know how though, Have little idea
 about D-I environment and took long enough to just reply to this
 request to feel a little embarrassed.
 
 Also haven't seen the proposed change to netcfg anytime in recent
 past to comment further. Can that be reviewed?

It's in branch people/womble/wpa of
git://git.debian.org/git/d-i/netcfg.

Gaudenz
   
   Thanks for the link.
  
  Do you have time to look at the code in the next days? Otherwise I'll
  probably just merge as it is now and we can fix things later if there
  are problems.
 
 Do not wait for any activity from me, I'm currently not very active with 
 Debian work - mostly keeping up with basic maintenace related tasks.
 
 Not familiar with netcfg or the debian-installer environment at all
 yet.

OK. How do you feel about me NMUing wpa_supplicant to add the udeb? I
added an updated patch for the udeb to this mail. If you are OK I'll
upload this as an NMU after libnl1-udeb enters the archive.

 
  
  I have another yet unresolved problem: With the proposed udeb
  configuration from the original patch and using the netlink driver I can
  connect to the network, but DHCP does not work. When I build a udeb with
  the same
  configuration as for the normal linux package minus DBUS and smartcard
  support it works. Do you know which options I need to include to get a
  package where DHCP also works with the netlink driver?
 
 From the top of my head I do not know why you observe this difference in 
 behaviour. Where WEXT works, nl80211 should work and vice versa.

I found out that I have to enable either CONFIG_IEEE8021X_EAPOL or
CONFIG_WPS. I don't know why it is like this, but both options don't
seem to be related to the problem. This is probably a bug in
wpa_supplicant where a #ifdef enables some code that should be enabled
unconditionally. But a quick grep through the source code did not show
something suspicious. If I get around to it I'll report a bug
upstream.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


build_wpasupplicant_udeb_v2.patch
Description: Binary data

Re: Bug#610931: Please build wpasupplicant-udeb

[Gaudenz Steinlin]

Hi 

So I actually made some progress today. Here's my status report.

Excerpts from Kel Modderman's message of 2011-07-24 00:58:08 +0200:
 On Sun, 24 Jul 2011 08:02:48 AM Gaudenz Steinlin wrote:
   
   nl80211 is the way forward. It would require libnl to be included in D-I.
  
  AFAICS with my iwlwifi card both nl80211 and wext work. Is there any
  practical advantage of nl80211. If possible I would like to avoid
  having to include another library into d-i.
 
 WEXT is deprecated upstream, nl80211 is in active development and all new 
 wifi 
 drivers will use it. Looking into my crystal ball I see that eventually the 
 WEXT compat layer will decay into something that nobody wants to keep 
 maintaining.
 
 If D-I integration of wpasupplicant were to go ahead without including 
 support 
 for nl80211 it would be a waste of time imo.

After discussing this on IRC we (debian-boot) agreed to include wext
and nl80211 support.

 Has there been any solution for the netcfg integration already, see
 201011041811.11753@otaku42.de [1], referring to the originally
 proposed introduction of embedded source copies of wpasuppliant's
 wpa_ctrl.[hc] into netcfg. Please also keep in mind that crda/
 wireless-regdb is required for accessing channels 11-13/14 on modern
 drivers.

I've applied the existing WPA netcfg support patches developed by Glenn
Saberton, and they do appear to include a (stripped down) wpa_ctrl.c.
   
   That stripped down crap probably was extracted from a sideline project
   (python-wpactrl) I was working on, and is not good long term solution.
   
   wpa_ctrl.{c,h} from current wpasupplicant source tree have lots more
   dependency on other stuff. Extracting and patching wpa_ctrl.{c,h} to be
   standalone is something which should be avoided - I just do not know how
   currently.
   
   Asked upstream wpa_supplicant if wpa_ctrl could be provided in a way
   where it could be a shared library but received no response.
  
  Is there any progress on this?
 
 Nope.

Do you think it's worth poking about this again? The current code in
netcfg works (at least for the debconf wpa-psk network), but a real
library would be nicer ;-).

 
  
I
have no idea what the story is with crda/wireless-regdb, as I said
before, I don't know anything about WPA.  If you'd like to help out,
though, your knowledge would be greatly valued.
   
   I wouldn't mind helping out, don't know how though, Have little idea
   about D-I environment and took long enough to just reply to this request
   to feel a little embarrassed.
   
   Also haven't seen the proposed change to netcfg anytime in recent past to
   comment further. Can that be reviewed?
  
  It's in branch people/womble/wpa of
  git://git.debian.org/git/d-i/netcfg.
  
  Gaudenz
 
 Thanks for the link.

Do you have time to look at the code in the next days? Otherwise I'll
probably just merge as it is now and we can fix things later if there
are problems.

I have another yet unresolved problem: With the proposed udeb
configuration from the original patch and using the netlink driver I can 
connect to the network,
but DHCP does not work. When I build a udeb with the same
configuration as for the normal linux package minus DBUS and smartcard
support it works. Do you know which options I need to include to get a
package where DHCP also works with the netlink driver?

Using the wext driver DHCP works in both configurations.

This is the configuration I currently use to produce the working
package:
# Debian's wpa_supplicant build time configuration
CONFIG_DRIVER_WEXT=y
CONFIG_DRIVER_NL80211=y
CONFIG_DRIVER_WIRED=y
CONFIG_AP=y
CONFIG_IEEE8021X_EAPOL=y
CONFIG_EAP_MD5=y
CONFIG_EAP_MSCHAPV2=y
CONFIG_EAP_TLS=y
CONFIG_EAP_PEAP=y
CONFIG_EAP_TTLS=y
CONFIG_EAP_GTC=y
CONFIG_EAP_OTP=y
CONFIG_EAP_SIM=y
#CONFIG_EAP_PSK=y
CONFIG_EAP_PAX=y
CONFIG_EAP_LEAP=y
CONFIG_EAP_AKA=y
CONFIG_EAP_AKA_PRIME=y
#CONFIG_USIM_SIMULATOR=y
CONFIG_WPS=y
#CONFIG_PKCS12=y
#CONFIG_SMARTCARD=y
#CONFIG_PCSC=y
CONFIG_CTRL_IFACE=y
CONFIG_READLINE=y
CONFIG_BACKEND=file
CONFIG_MAIN=main
CONFIG_OS=unix
CONFIG_ELOOP=eloop
CONFIG_L2_PACKET=linux
CONFIG_PEERKEY=y
CONFIG_IEEE80211W=y
CONFIG_TLS=openssl
#CONFIG_CTRL_IFACE_DBUS=y
#CONFIG_CTRL_IFACE_DBUS_NEW=y
#CONFIG_CTRL_IFACE_DBUS_INTRO=y
CONFIG_IEEE80211R=y
CONFIG_DEBUG_FILE=y
CONFIG_DEBUG_SYSLOG=y
#CONFIG_PRIVSEP=y
CONFIG_DELAYED_MIC_ERROR_REPORT=y

This is the configuration where DHCP does not work when using the
netlink driver:
# Debian Installer's wpa_supplicant build time configuration
CONFIG_DRIVER_WEXT=y
CONFIG_DRIVER_NL80211=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
CONFIG_CTRL_IFACE=y

Thanks,
Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to debian-boot-requ

Re: Bug#610931: Please build wpasupplicant-udeb

[Gaudenz Steinlin]

Hi

I'm picking up the task to integrate WPA support into
debian-installer. My goal is to have this finished by the end of
Debconf. Is anyone of you also going to attend Debconf?

 On Tuesday 25 January 2011 04:39:44 Matthew Palmer wrote:
   
   diff -urN wpasupplicant-0.6.10.orig/debian/config/udeb 
   wpasupplicant-0.6.10/debian/config/udeb
   [...]
   +CONFIG_DRIVER_WEXT=y
   
   Given that wext is deprecated, it would imho make more sense to use
   CONFIG_DRIVER_NL80211=y instead, maybe even to leave wext disabled. 
   With the notable exception of ipw2100/ ipw2200, all other linux wlan
   drivers weren't produced in large volumes or don't support wpa2 to
   begin with; for new ones (this covers all mac80211 based ones) nl80211
   support is mandatory and there are some initial efforts to add nl80211
   to ipw2x00. This also avoids the need for deprecated wireless-tools in
   favour of iw/ crda (which is required for ch11-14 anyways) - or being 
   able to use libnl for all configuration in netcfg.
  
  I know nothing about WPA, I've just used a udeb config file that was in an
  existing (out of date) patch to build a wpasupplicant udeb.  In all honesty
  you can set this configuration to whatever you think is best.

 nl80211 is the way forward. It would require libnl to be included in D-I.

AFAICS with my iwlwifi card both nl80211 and wext work. Is there any
practical advantage of nl80211. If possible I would like to avoid
having to include another library into d-i.

  
   diff -urN wpasupplicant-0.6.10.orig/debian/control 
   wpasupplicant-0.6.10/debian/control
   [...]
   +Architecture: linux-any
   
   wpasupplicant is needed, and compatible with-, kFreeBSD as well, at 
   this moment kFreeBSD doesn't support wlan for unrelated reasons
   (ifconfig not being able to configure wlan interfaces, besides the open
   firmware issues, while firmwares are required for most chipsets). So
   ignoring hurd, it should be any or at least linux-any kfreebsd-any.
  
  Wireless config is disabled in d-i for kfreebsd, so there's no reason to
  build wpasupplicant-udeb for those arches.  However, if you're comfortable
  that a wpasupplicant-udeb will build correctly for those arches, it'd save
  changes down the line if/when kfreebsd gets d-i wireless support.

 It'd probably be better to prepare early here and build wpasupplicant-udeb for
 whatever it can build on.

I don't care that much as it mainly concerns your package, but as
kfreebsd does not currently have wireless support in d-i, the package
won't be used for now. I don't know how much work it would be to
enable wireless for kfreebsd in d-i, but that's a another task.

I have another question:
To connect to the debconf network I needed to additional kernel
modules for the encryption algorithms: aes_generic.ko and
aes-x86_64.ko. Are these the only crpyto modules required for WPA or
are there configurations where other algorithms might be needed. Of
course aes-x86_64 has to be replaced by the appropriate module on
other architectures.
 
   Has there been any solution for the netcfg integration already, see 
   201011041811.11753@otaku42.de [1], referring to the originally 
   proposed introduction of embedded source copies of wpasuppliant's 
   wpa_ctrl.[hc] into netcfg. Please also keep in mind that crda/ 
   wireless-regdb is required for accessing channels 11-13/14 on modern
   drivers.
  
  I've applied the existing WPA netcfg support patches developed by Glenn
  Saberton, and they do appear to include a (stripped down) wpa_ctrl.c.

 That stripped down crap probably was extracted from a sideline project
 (python-wpactrl) I was working on, and is not good long term solution.

 wpa_ctrl.{c,h} from current wpasupplicant source tree have lots more 
 dependency
 on other stuff. Extracting and patching wpa_ctrl.{c,h} to be standalone is
 something which should be avoided - I just do not know how currently.

 Asked upstream wpa_supplicant if wpa_ctrl could be provided in a way where it
 could be a shared library but received no response.

Is there any progress on this? 

  I
  have no idea what the story is with crda/wireless-regdb, as I said before, I
  don't know anything about WPA.  If you'd like to help out, though, your
  knowledge would be greatly valued.

 I wouldn't mind helping out, don't know how though, Have little idea about D-I
 environment and took long enough to just reply to this request to feel a 
 little
 embarrassed.

 Also haven't seen the proposed change to netcfg anytime in recent past to
 comment further. Can that be reviewed?

It's in branch people/womble/wpa of
git://git.debian.org/git/d-i/netcfg.

Gaudenz




-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1311457756-sup-9064@meteor.durcheinandertal.local

Re: Preparation of fixes to 6.0.1

[Gaudenz Steinlin]

Excerpts from Adam D. Barratt's message of 2011-03-06 16:20:51 +0100:
 
 - console-setup
 
 Looks okay, other than the version number should be 1.68+squeeze1.
 Fixed in unstable but not migrated to testing yet; could we unblock it?

I prepared a squeeze branch for this and pushed it to the repo[1], but
was told that I should not upload myself because this will be done in
a mass upload. 

The squeeze branch only contains the fix for #610843 and not all the
other changes that are in unstable.

Gaudenz

[1] 
http://lists.debian.org/msgid-search/1297716143-sup-9233@meteor.durcheinandertal.local

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: Move g_ether detection from hw-detect.sh to ethdetect.sh?

[Gaudenz Steinlin]

Excerpts from Otavio Salvador's message of 2011-02-15 00:38:32 +0100:
 On Mon, Feb 14, 2011 at 21:15, Thibaut Girka t...@sitedethib.com wrote:
  I was wondering why g_ether (USB gadget module) detection/loading is
  done in hw-detect.sh, and whether ethdetect.sh would be better suited
  for that.
 ...
 
 I am not sure. As you said it is not really a ethernet device (even
 thought it provides a way for it). I'd like to know what other
 people think about it.
 

I would leave the code in hw-detect.sh unless you can solve a
specific problem with moving the code around. There is similar code
for other modules in hw-detect.sh (like firewire ethernet).

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1297788942-sup-3925@meteor.durcheinandertal.local

Re: Preparation of fixes to 6.0.1

[Gaudenz Steinlin]

Excerpts from Otavio Salvador's message of 2011-02-12 23:46:07 +0100:
 Hello folks,
 
 I have prepare some branches that has what I am intending to upload to
 stable-proposed-updates. The modules I have changed are the following:
 
 grub-installer
 linux-kernel-di-sparc-2.6
 tasksel
 cdebconf
 debootstrap
 kernel-wedge
IMHO console-setup should be uploaded as well to fix #610843. AFAIR it
was agreed that this is 6.0.1 material when the bug first appeared.

If you want I can prepare a branch and upload the fix.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1297694546-sup-9160@meteor.durcheinandertal.local

Re: Preparation of fixes to 6.0.1

[Gaudenz Steinlin]

Hi

Excerpts from Otavio Salvador's message of 2011-02-14 16:47:00 +0100:
 On Mon, Feb 14, 2011 at 14:51, Gaudenz Steinlin gaud...@debian.org wrote:
  IMHO console-setup should be uploaded as well to fix #610843. AFAIR it
  was agreed that this is 6.0.1 material when the bug first appeared.
 
  If you want I can prepare a branch and upload the fix.
 
 Please prepare the branch so near of 6.0.1 we do all the uploads.
 

I've created a squeeze branch for console-setup branched from the
version in squeeze with only the change to fix #610843 and pushed this
branch to the d-i repo.

I also tested the package with a netboot-gtk mini.iso built from
squeeze (and localudebs) and it indeed fixes the bug and AFAICS does
not introduce any regressions.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1297716143-sup-9233@meteor.durcheinandertal.local

Bug#612516: Installation Report Debian Installer 6.0 Release Candidate 1 release

[Gaudenz Steinlin]

Excerpts from Christian PERRIER's message of Mit Feb 09 06:50:26 +0100 2011:
 
 Another option is to suggest that the quiet option passed to the
 kernel doesn't suppress messages related to video mode in case the
 video mode doesn't exist. This would then be a kernel bug.
 
 Anyone with an advice about this?

IMHO this is a kernel bug. Even with the quiet option the kernel
should not suppress messages the user absolutely needs to see to be
able to proceed. Also AFAIUI this issue is not d-i specific.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~



--
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/1297237843-sup-1974@meteor.durcheinandertal.local

Bug#610843: debian-installer: keyboard selection does not work with graphical installer

[Gaudenz Steinlin]

Excerpts from Ronny Standtke's message of Son Jan 23 10:16:15 +0100 2011:
 Package: debian-installer
 Severity: normal
 
 *** Please type your report below this line ***
 I used the Graphical install option.
 In the step Select a language I chose German - Deutsch.
 In the step Select your location I chose Switzerland.
 
 The first issue is that in the next step Configure the keyboard I expected 
 to have Swiss German preselected (as every other well-known distributions 
 do), but instead American English was preselected. I manually chose Swiss 
 German.
 
 The second issue is that this choice did not work. The keyboard layout was 
 still American English for the whole installation process.

I can confirm these two issues with the followning image:
http://d-i.debian.org/daily-images/amd64/20110123-00:18/netboot/gtk/mini.iso
(md5sum: f753e5d4c421e06c01cb66c582585783).
The non gtk build from the same date does not have the issue. So I
guess this is specific to the gtk build. 

The same issue is also present in d-i rc2. 

 
 The third issue is that the installed system also used the American English 
 keyboard instead of Swiss German. I noticed that in /etc/default/keyboard 
 there was
 -
 XKBLAYOUT=us
 -
 instead of
 -
 XKBLAYOUT=ch
 XKBVARIANT=de
 -

I did not test the whole installation, but I guess this would have
been present as well in my test.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: SPARC daily d-i builds

[Gaudenz Steinlin]

Excerpts from Philipp Kern's message of Mit Jan 12 02:46:24 +0100 2011:
 Hi,
 
 am Wed, Jan 12, 2011 at 01:53:59AM +0100 hast du folgendes geschrieben:
  Gaudenz Steinlin gaud...@debian.org (11/01/2011):
   As all my attempts to find someone willing to setup d-i daily builds
   on a sparc buildd [1] failed. I'm going to give up now and will not
   bother you again until some steps up to do the necessary work or
   provide me with buildd access. I added the following note to the d-i
   daily builds overview page: Due to the lack of porter and buildd
   admin interest there are currently no daily builds for the SPARC
   architecture. These builds will be reenable as soon as someone finds
   the time to do the necessary buildd setup.
   
   I would also be willing to do the neccessary setup myself if someone
   provides me with the necessary access to a sparc buildd.
  
  So, again, it's not about lack of interest, it's about lack of
  time.

As Cyril Brulebois was the only one to even answer, I inferred that the other
persons behind sparc@b.d.o and all the subscribers on debian-sparc
don't seem to be interested. My bad. After having more information I
have now reworded the text to:
Due to the lack of buildd suitable buildd machine there are currently no daily
builds for the SPARC architecture. These builds will be reenabled as soon as
as a suitable machine is available.

It was never my intention to offend anyone or to spread FUD. Sorry
if you got this impression.

  
  Also, you could have pinged debian-wb-team@. I believe aba did most of
  the d-i autobuilding stuff, so he might have some clue to share. I've
  added this list to the loop.

I was not aware that the right contact point for this kind of question
would be debian-wb-team@l.d.o. I thought that the correct contact
point would be the sparc buildd admins because the setup needs access
to the buildd and I expected that the persons having this kind of
access to be the buildd admins. I thought that the wb-team is involved
with managing the wb database which is not used for the d-i daily
builds.

 
 and I did tell on #d-boot the following on Nov 13 2010:
 
 [...]
 15:27  trave11er ok, we didn't get any reply from stappers, so sparc 
 dailies still have the old kernels, afaict
 [...]
 15:31  otavio trave11er: buildd people were going to put sparc into it
 15:31  otavio trave11er: dunno if it has been done
 15:31  otavio adsb: ^?
 [...]
 15:33  phil otavio: were going to is quite untrue.  There still isn't a 
 bug
 report, and I did report the result of my investigation, i.e. there's no space
 on the only LVMed sparc buildd we have.
 15:37  otavio phil: I didn't recall about the space issue
 15:37  otavio phil: indeed
 
 So meh, whatever.  To my knowledge that's still true.  We currently don't have
 the capacities and we admitted that.  Furthermore not asking -wb-team might
 not give you answers, indeed.  Sorry if I missed something along the
 way.

Sorry that I missed this along the way. This is the first time I hear
of the space issue.

IMHO IRC is not a good medium to communicate important information to a
team. It's to easy to forget something and the information never
reaches all the involved persons. As I'm very rarely on IRC I missed
this communication.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: SPARC daily d-i builds

[Gaudenz Steinlin]

Hi

Excerpts from Axel Beckert's message of Mit Jan 12 10:47:19 +0100 2011:
 So how much disk space is needed for building the daily images, why
 does it have to be on a buildd (i.e. does it suffice to throw hardware
 at it) and how new/fast does the sparc to be?

The d-i team would like to have all these builds on buildds. This is
to avoid problems due to builds stopping because the person doing the
builds loosing interest. So I would prefer the buildd solution to yet
another single DD run solution.

The builds themselves don't need a lot of disk space and cpu power.
The main part is downloading udebs and building images out of them.
There is no compilation involved.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

SPARC daily d-i builds

[Gaudenz Steinlin]

Hi

As all my attempts to find someone willing to setup d-i daily builds
on a sparc buildd [1] failed. I'm going to give up now and will not
bother you again until some steps up to do the necessary work or
provide me with buildd access. I added the following note to the d-i
daily builds overview page:
Due to the lack of porter and buildd admin interest there are currently no daily
builds for the SPARC architecture. These builds will be reenable as soon as
someone finds the time to do the necessary buildd setup.

I would also be willing to do the neccessary setup myself if someone
provides me with the necessary access to a sparc buildd.

Gaudenz

[1] http://lists.debian.org/debian-sparc/2010/12/msg8.html
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: Recurrent old builds for D-I

[Gaudenz Steinlin]

Excerpts from Gaudenz Steinlin's message of Don Jan 06 23:50:50 +0100 2011:
 Excerpts from Christian PERRIER's message of Don Jan 06 07:01:07 +0100 2011:
  Quoting Daily build aggregator (debian-boot@lists.debian.org):
   Debian installer build overview
   ---
   
   Failed or old builds:
   
   * OLD BUILD:mipsel Dec 09 00:12 bui...@rem 
   build_cobalt_netboot-2.6_serial 
   
   http://d-i.debian.org/daily-images/mipsel/daily/build_cobalt_netboot-2.6_serial.log
  
   * OLD BUILD:s390 Dec 19 00:03 bui...@zandonai build_generic 
   
   http://d-i.debian.org/daily-images/s390/daily/build_generic.log
  
   
   * OLD BUILD:sparc Jul 12 11:08 stapp...@dd build_netboot 
   
   http://people.debian.org/~stappers/d-i/sparc/daily/build_netboot.log
  
  
  So, we still have these three arches where builds are broken for quite
  some time.
  
  Apparently s390 failures are fairly recent but were probably unnoticed
  because the recurrent sparc failures made everybody ignore the daily
  failure mails.
 
 I was aware of them but wanted to wait a bit more to see if they are
 transient or not before pinging the buildd maintainers. And then
 christmas and new year vacations interfered with this plan. I'll ping
 them in the next days.

s390 seems to be fixed now.

 
  
  
  mipsel failures happen since Dec09. Gaudenz pinged the mipsel porters
  list but got no answer (at least none that I can see):
  
  ===
  Hi mipsel buildd maintainers
  
  Since 12/09 the debian-installer daily images for mipsel are no longer
  autobuilt (at least there are no new builds pushed to d-i.debian.org).
  The builds used to be built on rem.
  
  See http://lists.debian.org/20100331165134.ga19...@mails.so.argh.org
  for more information on how the d-i daily images building on the
  autobuilders works.
  
  It would be nice if you could investigate this and report back if
  there is a problem that needs our (debian-boot) help to fix.
  ===
 
 I got an answer that rem is currently moved to a new hosting location
 and added a not to the stats webpage. Probybly these notes should also
 be included in the mails.

I changed the script now to include the notes and to not include any
details about old builds if there is a note for this architecture.

 
  
  
  And sparc failures are a longstanding issue as they are apparently
  built in a broken environment by Geert: 
  
  ===
  Ping!
  
  Two more weeks and no answer from either Geert or the SPARC buildd
  maintainers. I'm CCing this to debian-sparc in the hope to at least
  get some status update.
  
  IMHO the best solution would be to adopt the same setup as on most
  other architectures: To build the d-i daily images on a buildd. See
  below for more information on the setup.
  
  If I don't get an answer by the end of the year I'll add a note to the
  daily images overview[1] and possibly similar pages that currently no
  sparc images can be provided until some steps in to do the necessary
  work.
  ===
  
 
 I got one reply that the first mails had been overlooked and the
 person said to be on semi-VAC currently. After that the conversation
 died off. I don't think Geert is interested anymore and this build
 should be moved to a sparc buildd. As there is apparently also not
 enough interest by sparc buildd maintainers I'm inclined to just turn
 off these builds until there is more interest. 
 
 I would be willing to setup a build on a buildd myself, but earlier
 conversation about giving the d-i team more access to these buildds
 gave me the impression that this is not possible (or at least very
 hard).

I now added a note and sent a last ping to the sparc porter and buildd
admin lists. I won't bother about sparc anymore until either someone
shows interest in setting up a build or someone provides me with the
necessary access.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: Recurrent old builds for D-I

[Gaudenz Steinlin]

Excerpts from Christian PERRIER's message of Don Jan 06 07:01:07 +0100 2011:
 Quoting Daily build aggregator (debian-boot@lists.debian.org):
  Debian installer build overview
  ---
  
  Failed or old builds:
  
  * OLD BUILD:mipsel Dec 09 00:12 bui...@rem 
  build_cobalt_netboot-2.6_serial 
  
  http://d-i.debian.org/daily-images/mipsel/daily/build_cobalt_netboot-2.6_serial.log
 
  * OLD BUILD:s390 Dec 19 00:03 bui...@zandonai build_generic 
  
  http://d-i.debian.org/daily-images/s390/daily/build_generic.log
 
  
  * OLD BUILD:sparc Jul 12 11:08 stapp...@dd build_netboot 
  
  http://people.debian.org/~stappers/d-i/sparc/daily/build_netboot.log
 
 
 So, we still have these three arches where builds are broken for quite
 some time.
 
 Apparently s390 failures are fairly recent but were probably unnoticed
 because the recurrent sparc failures made everybody ignore the daily
 failure mails.

I was aware of them but wanted to wait a bit more to see if they are
transient or not before pinging the buildd maintainers. And then
christmas and new year vacations interfered with this plan. I'll ping
them in the next days.

 
 
 mipsel failures happen since Dec09. Gaudenz pinged the mipsel porters
 list but got no answer (at least none that I can see):
 
 ===
 Hi mipsel buildd maintainers
 
 Since 12/09 the debian-installer daily images for mipsel are no longer
 autobuilt (at least there are no new builds pushed to d-i.debian.org).
 The builds used to be built on rem.
 
 See http://lists.debian.org/20100331165134.ga19...@mails.so.argh.org
 for more information on how the d-i daily images building on the
 autobuilders works.
 
 It would be nice if you could investigate this and report back if
 there is a problem that needs our (debian-boot) help to fix.
 ===

I got an answer that rem is currently moved to a new hosting location
and added a not to the stats webpage. Probybly these notes should also
be included in the mails.

 
 
 And sparc failures are a longstanding issue as they are apparently
 built in a broken environment by Geert: 
 
 ===
 Ping!
 
 Two more weeks and no answer from either Geert or the SPARC buildd
 maintainers. I'm CCing this to debian-sparc in the hope to at least
 get some status update.
 
 IMHO the best solution would be to adopt the same setup as on most
 other architectures: To build the d-i daily images on a buildd. See
 below for more information on the setup.
 
 If I don't get an answer by the end of the year I'll add a note to the
 daily images overview[1] and possibly similar pages that currently no
 sparc images can be provided until some steps in to do the necessary
 work.
 ===
 

I got one reply that the first mails had been overlooked and the
person said to be on semi-VAC currently. After that the conversation
died off. I don't think Geert is interested anymore and this build
should be moved to a sparc buildd. As there is apparently also not
enough interest by sparc buildd maintainers I'm inclined to just turn
off these builds until there is more interest. 

I would be willing to setup a build on a buildd myself, but earlier
conversation about giving the d-i team more access to these buildds
gave me the impression that this is not possible (or at least very hard).

 Goal: stop having a daily mail about failed builds asthis just
 makes everybody ignore them after a few days.

Full ACK. Although I was still paying attention, just not acting on
every change.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1294353597-sup-...@meteor.durcheinandertal.local

Re: Recurrent old builds for D-I

[Gaudenz Steinlin]

Excerpts from Otavio Salvador's message of Don Jan 06 12:32:20 +0100 2011:
 On Thu, Jan 6, 2011 at 04:01, Christian PERRIER bubu...@debian.org wrote:
  Goal: stop having a daily mail about failed builds asthis just
  makes everybody ignore them after a few days.
 
 We might try to have this mail reversed sorted by failure date. So the
 most recent failure will always be show at first item.
 
 Another thing we might have is a mail, for the arch, on the day of
 failure and a summary in weekly basis.
 
 Comments?

In principle I agree to both. The problem is that this probably means
that the current scripts have to be rewritten from scratch. As I'm not
really a Perl Hacker and prefer Python. Would anybody oppose if
I'd do this in Python?

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1294354255-sup-5...@meteor.durcheinandertal.local

Bug#607927: powerpc squeeze CD image fails

[Gaudenz Steinlin]

Package: debian-cd
Severity: serious

Hi 

The creation of the powerpc CD Image currently fails. genoisoimage
aborts with a stack trace as can be seen in this log:
http://cdbuilder.debian.org/cdimage-log/Csqueezepowerpc

Is anyone with access to the build host able to investigate this?
AFAICT the failure started with yesterdays build. Is there a way to
access old logs on cdbuilder.debian.org?

From the build log it seems that the build host is using a locally
modified version of genisoimage. Therefore I'm not filing a bug
against genisoimage yet.

Unfortunately I don't have access to the build machine to investigate
this myself.

I'm setting the severity to serious as we can't release without a
working powerpc CD build and this seems analogous to a FTBS bug. Feel
free to downgrade if you disagree.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

No d-i daily images built for mipsel since 12/09

[Gaudenz Steinlin]

Hi mipsel buildd maintainers

Since 12/09 the debian-installer daily images for mipsel are no longer
autobuilt (at least there are no new builds pushed to d-i.debian.org).
The builds used to be built on rem.

See http://lists.debian.org/20100331165134.ga19...@mails.so.argh.org
for more information on how the d-i daily images building on the
autobuilders works.

It would be nice if you could investigate this and report back if
there is a problem that needs our (debian-boot) help to fix.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Fwd: Re: Fwd: Old kernels used for sparc daily builds

[Gaudenz Steinlin]

Ping!

Two more weeks and no answer from either Geert or the SPARC buildd
maintainers. I'm CCing this to debian-sparc in the hope to at least
get some status update.

IMHO the best solution would be to adopt the same setup as on most
other architectures: To build the d-i daily images on a buildd. See
below for more information on the setup.

If I don't get an answer by the end of the year I'll add a note to the
daily images overview[1] and possibly similar pages that currently no
sparc images can be provided until some steps in to do the necessary
work.

Gaudenz

--- Begin forwarded message from Gaudenz Steinlin ---
From: Gaudenz Steinlin gaud...@debian.org
To: stappers stapp...@debian.org
Cc: debian-boot debian-boot@lists.debian.org, sparc sp...@buildd.debian.org
Date: Mon, 06 Dec 2010 18:03:32 +0100
Subject: Re: Fwd: Old kernels used for sparc daily builds

Hi Geert

Excerpts from Gaudenz Steinlin's message of Mit Nov 10 22:43:37 +0100 2010:
 Hi Geert
 
 You used to build the sparc daily images for d-i. But these images are
 no longer built since June. Are you still intending to provide daily
 d-i images for sparc or should someone else take over this job?

I did not receive any answer from you about this. Are you still
interested? Or is someone from the sparc buildd maintainers interested
in adapting the same setup as is used for other archs?

See http://lists.debian.org/debian-boot/2010/03/msg00599.html for how
to setup the daily builds on Debian build daemons.

Gaudenz

 
 Gaudenz
 
 --- Begin forwarded message from Jurij Smakov ---
 From: Jurij Smakov ju...@wooyd.org
 To: debian-boot debian-boot@lists.debian.org
 Date: Wed, 10 Nov 2010 19:24:36 +0100
 Subject: Old kernels used for sparc daily builds
 
 Hello,
 
 It looks like the sparc daily builds [0] are happening in a broken 
 environment, because the kernel image which gets installed into the
 /boot directory of the ISO image dates back to June:
 
 ju...@droopy:~$ grep 'built on' /mnt/iso/boot/debian.txt 
 This is a Debian installation CDROM, built on 20101110-15:27.
 ju...@droopy:~$ strings /mnt/iso/boot/sparc64 | grep 'Linux version'
 Linux version 2.6.32-5-sparc64 (Debian 2.6.32-15) (b...@decadent.org.uk) (gcc 
 version 4.3.5 (Debian 4.3.5-1) ) #1 Tue Jun 1 06:56:43 UTC 2010
 ju...@droopy:~$ 
 
 It would be great to fix it as testing the images with such an old 
 kernel is meaningless (for example, it hangs on my workstation early 
 during boot).
 
 [0] 
 http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/sparc/iso-cd/
 
 Best regards,
 --- End forwarded message ---
--- End forwarded message ---
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: squeeze build problems

[Gaudenz Steinlin]

Excerpts from Miguel Figueiredo's message of Don Dez 23 13:21:59 +0100 2010:
 I've followed the same procedure and fails the same way.
 Having a look on sources.list.udeb i changed sources.list.udeb.local to:
 
 deb http://ftp.debian.org/debian squeeze main/debian-installer
 
 which seems to be the correct path.
 
 But make build_hd-media still fails with:
 
 E: Unable to locate package ttf-lao-udeb
 
 which is missing in the Packages file.

This udeb is only available in unstable. You have to build your image
with udebs from unstable or comment it out in pkg-lists/gtk-common.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: debian-installer daily builds on hppa buildd

[Gaudenz Steinlin]

Excerpts from dann frazier's message of Mon Dez 20 23:11:16 +0100 2010:
  In progress. I have builds going on a system at home  am working on
  getting the ssh key setup now.
 
 ... and done.

Thanks to everyone involved!

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1292883616-sup-7...@meteor.durcheinandertal.local

Bug#332227: Unofficial Squeeze NetInst CDs: call for testers

[Gaudenz Steinlin]

Excerpts from Frank Fegert's message of Die Dez 14 19:34:12 +0100 2010:
 Hello,
 
 On Tue, Dec 14, 2010 at 04:22:37AM +0100, Aurélien GÉRÔME wrote:
  I just made 2 unofficial CDs available[1].  Each has a sha512sum
  signed by my GPG key[2].
  
  One includes yaboot_1.3.13a-1squeeze1 and the other one includes
  yaboot_1.3.16-2.
  
  Both include packages with needed PowerPC fixes for Squeeze:
* linux-kernel-di-powerpc-2.6_1.74;
* yaboot-installer_1.1.19;
* os-prober_1.42;
* rootskel_1.93.
  
  Please test both of them and tell us about it.
 
 i tried the unofficial-debian-squeeze-powerpc-netinst-1-yaboot-1.3.16.iso
 on a p550 Power6+ LPAR, Microcode 01EL350_085_038, dual VIOS. The
 install fails at Install yaboot on a hard disk with:
 
   [!!] Install yaboot on a hard disk
   No bootstrap partition found
   No hard disks were found which have an Apple_Bootstrap partition.
   You must create an 819200-byte partition with type Apple_Bootstrap.

Do you know if this error is a regression regarding the lenny
installer or the current official beta2 installer? If so we have to
investigate this and fix the bug before the packages enter testing.

But I suspect this nerver worked. See also Debian bugs #332227, #352914
and #350372. I guess this really needs someone with the right hardware
to dig in and solve the bugs or write the missing code for the
installer.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: Bug#606441: unblock: yaboot/1.3.13a-1squeeze1

[Gaudenz Steinlin]

Excerpts from Mehdi Dogguy's message of Fre Dez 10 22:52:34 +0100 2010:
 On 12/09/2010 10:27 AM, Gaudenz Steinlin wrote:
  
  I sponsored an uploaded of yaboot to testing-proposed-updates with the
  following changes to fix RC bugs:
  
   yaboot (1.3.13a-1squeeze1) testing-proposed-updates; urgency=low
   .
 * Team upload.
 * Get scsi, sata, and firewire drive info from sysfs as legacy /proc/scsi
   interface does not exist anymore.
   (Closes: #572869, #377097, #342833, #289201)
 * Use persistent device naming symlinks, UUID and LABEL tags instead of
   unix block device names. (Closes: #580455)
 * debian/copyright: Add copyright notice from ofpath.
  
  The package has to go thourgh t-p-u because there is a newer upstream 
  version
  already uploaded to sid.
 
 I'm ok to approve this upload but I prefer to have an ack from Otavio (or
 boot folks) first.

No problem for me. Just a note that the mail I sent to request pre
upload approval was CCed to debian-boot and up til now nobody
answered. I suggest we give the installer team some more days to
react, but if they don't I think we should not wait indefinitely. 

And please also give feedback about the proposed patch to
yaboot-installer in #572925. I plan to upload this fix soon after
yaboot is accepted.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: pre-upload approval for yaboot (t-p-u) and yaboot-installer

[Gaudenz Steinlin]

Hi release team

Per request from Neil on IRC I give you a debdiff for the two
packages. After reading the last release update I was under the
impression that you want to generate the debdiff yourself anyway...,
sorry.

Gaudenz

yaboot:
diff -u yaboot-1.3.13a/debian/changelog yaboot-1.3.13a/debian/changelog
--- yaboot-1.3.13a/debian/changelog
+++ yaboot-1.3.13a/debian/changelog
@@ -1,3 +1,15 @@
+yaboot (1.3.13a-1squeeze1) testing-proposed-updates; urgency=low
+
+  * Team upload.
+  * Get scsi, sata, and firewire drive info from sysfs as legacy /proc/scsi
+interface does not exist anymore.
+(Closes: #572869, #377097, #342833, #289201)
+  * Use persistent device naming symlinks, UUID and LABEL tags instead of 
+unix block device names. (Closes: #580455)
+  * debian/copyright: Add copyright notice from ofpath.
+
+ -- Milan Kupcevic mi...@physics.harvard.edu  Sun, 05 Dec 2010 10:34:50 -0500
+
 yaboot (1.3.13a-1) unstable; urgency=high
 
   * Convert debian/control from ISO_8859-15 to UTF-8.
diff -u yaboot-1.3.13a/debian/copyright yaboot-1.3.13a/debian/copyright
--- yaboot-1.3.13a/debian/copyright
+++ yaboot-1.3.13a/debian/copyright
@@ -33,6 +33,11 @@
 
 ###
 
+## ofpath: determine OpenFirmware path from unix device node
+## Copyright (C) 2010 Milan Kupcevic
+## Copyright (C) 2000, 2001, 2002, 2003 Ethan Benson
+## Copyright (C) 2000 Olaf Hering o...@suse.de
+
 ## ybin (YaBoot INstaller) installs/updates the yaboot bootloader.
 ## Copyright (C) 2000, 2001 Ethan Benson
 
diff -u yaboot-1.3.13a/ybin/ofpath yaboot-1.3.13a/ybin/ofpath
--- yaboot-1.3.13a/ybin/ofpath
+++ yaboot-1.3.13a/ybin/ofpath
@@ -3,6 +3,9 @@
 ###
 ##
 ## ofpath: determine OpenFirmware path from unix device node
+##
+## Copyright (C) 2010 Milan Kupcevic
+##
 ## Copyright (C) 2000, 2001, 2002, 2003 Ethan Benson
 ##
 ## Portions based on show_of_path.sh:
@@ -27,7 +30,7 @@
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
 PRG=${0##*/}
-VERSION=1.0.7
+VERSION=1.0.7+debian1
 DEBUG=0
 export LC_COLLATE=C
 
@@ -36,9 +39,10 @@
 {
 echo \
 $PRG $VERSION
-Written by Ethan Benson
+Written by Ethan Benson, portions rewritten by Milan Kupcevic
 Portions based on show_of_path.sh written by Olaf Hering
 
+Copyright (C) 2010 Milan Kupcevic
 Copyright (C) 2000, 2001, 2002, 2003 Ethan Benson
 Portions Copyright (C) 2000 Olaf Hering
 This is free software; see the source for copying conditions.  There is NO
@@ -181,140 +185,124 @@
 return 0
 }
 
+# read OpenFirmware device path from its corresponding devspec
+find_of_path()
+{
+  [ -z $1 ]  return
+  [ -f $1/devspec ]  {
+OF_PATH=`cat $1/devspec`
+SYS_PATH=$1
+return
+  }
+  find_of_path ${1%/*}
+}
+
 ## this finds information we need on both newworld and oldworld macs.
 ## mainly what scsi host a disk is attached to.
 scsiinfo()
 {
-## see if system has scsi at all
-if [ ! -f /proc/scsi/scsi ] ; then
-   local kver=$(uname -r)
-   case $kver in
-   2.5.*|2.6.*)
-   if [ -d /sys/bus/scsi/devices -a \
-   -n $(ls /sys/bus/scsi/devices 2/dev/null) ] ; then
-   echo 12 $PRG: /proc/scsi/scsi does not exist
-   echo 12 $PRG: Make sure you compiled your kernel with 
CONFIG_SCSI_PROC_FS=y
-   return 1
-   fi
-   ;;
-   esac
-   echo 12 $PRG: /dev/$DEVNODE: Device not configured
-   return 1
-fi
-
-## first we have to figure out the SCSI ID, have to do that
-## anyway [to] find the attached scsi disks = Direct-Access and
-## stop at sda=1 sdb=2 or whatever count in 3 lines steps
-
-## get last letter of device node, ie sda - a
-SUBNODE=${DEVNODE##*sd}
-
-## turn SUBNODE above into a number starting at 1, ie a - 1
-SUBDEV=$(smalltr $SUBNODE)
-[ $DEBUG = 1 ]  echo 12 $PRG: DEBUG: SUBNODE=$SUBNODE 
SUBDEV=$SUBDEV
-
-DEVCOUNT=0
-
-## copy scsi file into a variable removing Attached Devices
-## which is the first line. this avoids a lot of
-## [incmopatible] crap later, and improves readability.
-
-## find number of lines once and recycle that number, to save
-## some time (linecount is a bit slow). subtract one line
-## to scrap Attached Devices:
-
-SCSILINES=$(($(linecount /proc/scsi/scsi) - 1))
-
-if [ $SUBDEV -gt $(cat /proc/scsi/scsi | grep Direct-Access | 
linecount) ] ; then
-   echo 12 $PRG: /dev/$DEVNODE: Device not configured
-   return 1
-fi
-
-PROCSCSI=$(cat /proc/scsi/scsi | tail -n $SCSILINES)
-
-for i in $(smallseq $(($SCSILINES / 3))) ; do
-
-   ## put every scsi device into one single line
-   DEVINFO=$(echo $PROCSCSI | head -n $(($i * 3)) | tail -n 3)
-   [ $DEBUG = 1 ]  echo 12 $PRG: DEBUG: DEVINFO=$DEVINFO
-
-   ## cut the type field, expect Direct-Access later.
-   DEVTYPE=$(v=$(echo ${DEVINFO##*Type: }) ; echo ${v%% *})
-   [ $DEBUG = 1 

Bug#605932: drives seem to be detected in undefined order

[Gaudenz Steinlin]

severity 605932 grave
Thanks

Hi

Excerpts from Milan Kupcevic's message of Sam Dez 04 20:53:48 +0100 2010:
 forcemerge 572925 605932
 thanks
 
 On 12/04/2010 10:00 AM, Risto Suominen wrote:
  After manually editing /etc/yaboot.conf, I was facing another problem
  on boot: the disk drives seem to be detected in undefined order, and
  this makes it difficult to guess correct /dev/sd letter (and yaboot
  doesn't accept LABEL= syntax). I have two IDE disks (pata_cmd64x) and
  one SCSI disk (the one used here) (aic7xxx).
  
 This is a known problem with a known solution. Fixed Yaboot, which will
 be uploaded within next few days, will recognize persistent device
 naming symlinks and UUID/LABEL syntax. Soon after, yaboot-installer will
 be fixed to produce yaboot.conf using the same features.

IMO this is release critical. Upgrading this bug to grave. BTW I'm
working with Milan on a solution. Stay tuned. 

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

pre-upload approval for yaboot (t-p-u) and yaboot-installer

[Gaudenz Steinlin]

Hi release team

I ask you for pre approval of a yaboot (Powerpc Bootloader) upload to
testing-proposed-updates. The package in unstable unfortunately
contains a new upstream version and is therefore not suitable for
squeeze.

The upload would fix the following RC bugs: 

#572869 [S|+|=♔] [yaboot] installation-reports: PowerMac G5
installation report: ofpath doesn't work in the absence of
/proc/scsi/scsi

#580455 [S|+|=♔] [yaboot] lastest Sid upgrade breakes yaboot.conf and
(maybe) ybin

The proposed upload to t-p-u prepared by Milan Kupcevic is available
at [1]. He also tested the new package on a wide range of powerpc
subarchitectures.

Along with this upload an upload of yaboot-installer to unstable is
planned. This new version will take advantage of the new yaboot
package and avoid errors with different device enumerate during d-i
and in the installed system (see #605932). The proposed patch is in
the BTS and also tested by Milan and several ppl on debian-powerpc.

Do you approve these two uploads? Alternatively we could either upload
yaboot with an epoch to unstable or you would approve to update yaboot
to a new upstream version.

Gaudenz

[1] http://www.quarkline.net/debian/bug/yaboot/
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: debian-installer daily builds on hppa buildd

[Gaudenz Steinlin]

Hi Dann

Excerpts from Andreas Barth's message of Mit Nov 10 22:51:05 +0100 2010:
 * dann frazier (da...@debian.org) [101110 22:46]:
  I'd be glad to set this up on one of the hppa buildds (peri or
  penalosa) if DSA (CC'd) is ok with it. However, the above e-mail
  suggests we need to have working LVM snapshots. iirc, we've had
  problems with those on hppa in the past. Is that a hard requirement?
 
 LVM is just the way it is done now (basically we clone snapshots,
 install stuff there, and then toss the chroot at the end). It could be
 done different of course.

Is there any progress on this. There are still no d-i builds for hppa.

Or is this not going to happen and the daily builds for hppa should be
removed from d-i.debian.org? 

Gaudenz


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1291654487-sup-7...@meteor.durcheinandertal.local

Re: Fwd: Old kernels used for sparc daily builds

[Gaudenz Steinlin]

Hi Geert

Excerpts from Gaudenz Steinlin's message of Mit Nov 10 22:43:37 +0100 2010:
 Hi Geert
 
 You used to build the sparc daily images for d-i. But these images are
 no longer built since June. Are you still intending to provide daily
 d-i images for sparc or should someone else take over this job?

I did not receive any answer from you about this. Are you still
interested? Or is someone from the sparc buildd maintainers interested
in adapting the same setup as is used for other archs?

See http://lists.debian.org/debian-boot/2010/03/msg00599.html for how
to setup the daily builds on Debian build daemons.

Gaudenz

 
 Gaudenz
 
 --- Begin forwarded message from Jurij Smakov ---
 From: Jurij Smakov ju...@wooyd.org
 To: debian-boot debian-boot@lists.debian.org
 Date: Wed, 10 Nov 2010 19:24:36 +0100
 Subject: Old kernels used for sparc daily builds
 
 Hello,
 
 It looks like the sparc daily builds [0] are happening in a broken 
 environment, because the kernel image which gets installed into the
 /boot directory of the ISO image dates back to June:
 
 ju...@droopy:~$ grep 'built on' /mnt/iso/boot/debian.txt 
 This is a Debian installation CDROM, built on 20101110-15:27.
 ju...@droopy:~$ strings /mnt/iso/boot/sparc64 | grep 'Linux version'
 Linux version 2.6.32-5-sparc64 (Debian 2.6.32-15) (b...@decadent.org.uk) (gcc 
 version 4.3.5 (Debian 4.3.5-1) ) #1 Tue Jun 1 06:56:43 UTC 2010
 ju...@droopy:~$ 
 
 It would be great to fix it as testing the images with such an old 
 kernel is meaningless (for example, it hangs on my workstation early 
 during boot).
 
 [0] 
 http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/sparc/iso-cd/
 
 Best regards,
 --- End forwarded message ---
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: debian-installer daily builds on hppa buildd

[Gaudenz Steinlin]

[ Sorry to those that receive this mail twice. I messed up the
recipient list the first time. ]

Hi Dann

Excerpts from Andreas Barth's message of Mit Nov 10 22:51:05 +0100 2010:
 * dann frazier (da...@debian.org) [101110 22:46]:
  I'd be glad to set this up on one of the hppa buildds (peri or
  penalosa) if DSA (CC'd) is ok with it. However, the above e-mail
  suggests we need to have working LVM snapshots. iirc, we've had
  problems with those on hppa in the past. Is that a hard requirement?
 
 LVM is just the way it is done now (basically we clone snapshots,
 install stuff there, and then toss the chroot at the end). It could be
 done different of course.

Is there any progress on this. There are still no d-i builds for hppa.

Or is this not going to happen and the daily builds for hppa should be
removed from d-i.debian.org? 

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Bug#605562: installation-report: Installation from usb stick lead to unbootable system (und unbootable usb stick)

[Gaudenz Steinlin]

reassign 605562 grub-installer
forcemerge 568529 605562
Thanks

Excerpts from Alexander Reichle-Schmehl's message of Mit Dez 01 11:05:01 +0100 
2010:
 Boot method: USB stick
 Image version: beta1 AMD64
 Date: 2010-11-29

 Install boot loader:[E]
 Overall install:[E]
 
 Comments/Problems:
 
 I booted from usb stick (which was presented as /dev/sda) on a hardware
 raid (/dev/sdb).  After the system was successfully installed, the
 bootloader was installed to the mbr of /dev/sda (the usb stick), not my
 hard disc (/dev/sdb).

Can you please recheck with a current daily image. I believe this
issue is fixed in grub-installer 1.57. See #568529 (and duplicates)
for more information.

It would be nice to have a confirmation from you that the issue is
indeed fixed as it does not happen on all systems and is therefore
quite hard to test. Please reopen the bug if it's not fixed on your
hardware.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~



--
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/1291200529-sup-...@meteor.durcheinandertal.local

Bug#605562: installation-report: Installation from usb stick lead to unbootable system (und unbootable usb stick)

[Gaudenz Steinlin]

Excerpts from Alexander Reichle-Schmehl's message of Mit Dez 01 12:04:46 +0100 
2010:
 Hi Gaudenz!
 
 Am 01.12.2010 11:57, schrieb Gaudenz Steinlin:
 
  I booted from usb stick (which was presented as /dev/sda) on a hardware
  raid (/dev/sdb).  After the system was successfully installed, the
  bootloader was installed to the mbr of /dev/sda (the usb stick), not my
  hard disc (/dev/sdb).
  Can you please recheck with a current daily image. I believe this
  issue is fixed in grub-installer 1.57. See #568529 (and duplicates)
  for more information.
 
 Is there a way to check that without a doing a new installation?  Will
 it do, if I boot into expert mode from a daily image, and choose to
 install the boot loader?

You can boot into rescue mode and reinstall grub. But this does not do
100% the same thing as if grub-installer is run during a normal
installation. 

Running expert mode won't help as it does not let you run the
bootloader step before you install the system. If you don't mind
fiddling with the installer state you can boot the installer and
manually set bootstrap base to the configured state, mount the
partitions at the right place and then you should be able to run
grub-installer again.

The most reliable test is to do a complete reinstall to an empty
partition. This would leave your existing installation intact.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature

Re: Bug#562398: anna: fails if multiple versions of a udeb in Packages file

[Gaudenz Steinlin]

severity 562398 important
Thanks

Hi

It also seems quite risky to introduce this change now (see below for
my test results). As this bug is only triggered in very rare
circumstances and as far as I understand these circumstances can't
happen in a stable release, I don't think this issue is really release
critical. I'm therefore downgrading this bug. Feel free to upgrade it
again if you disagree.
 
Excerpts from John Wright's message of Mon Mai 03 10:15:06 +0200 2010:
 On Sun, May 02, 2010 at 03:08:08PM -0600, John Wright wrote:
  Specifically, what happens is that anna unpacks all the packages in one
  batch, and then it configures all of them.  But while unpacking another
  version of a package while another vesrion is in an
  unpacked-but-not-configured state is ok, it's not ok to configure a
  package that's already in the configured state.  So if a package is in
  the list twice, it fails at the second configure for that package.
 
 Here's what's happing in libd-i:  Upon encountering a Packages stanza
 with the same Package field as one it's previously seen,
 di_packages_parser_read_name sets the data pointer the rest of the
 parsing functions will use to the previously-used di_packages pointer.
 At first glance, this would appear simply to prefer packages that appear
 later in the Packages file, irrespective of version.  Unfortunately, it
 appends the di_package to the package list
 (parser-data-packages-list) whether it's a newly allocated one or an
 old one.  So while only one actual di_package exists for a particular
 package name, it might appear multiple times in the list.
 
 The simple way to fix the anna issue is to make sure we only append
 newly allocated di_package objects to the list.  But it would be nice to
 favor new versions rather than whatever shows up latest in the Packages
 file (for example, to facilitate #389430 or LP#234486).
 
 I've attached a quick reproducer to demonstrate the issue, and a patch.
 I would prefer if the version comparison could happen during the
 Packages file parsing, rather than after the fact (since this way
 requires creating a temporary hash table and traversing the list a
 couple of extra times), but that change would seem to be very invasive.
 In any case, after pounding my head for a couple of hours, I couldn't
 figure out how to do it any better with the current parsing
 infrastructure. :)

I tested you patch during the BSP in Bern. The patch still applies
cleanly to the current libdebian-installer. It also still fixes your
test case. But when testing a d-i image with your patch (patched
libdebian-installer installed on the build host and in localudebs!)
anna fails to download (some) dependencies. The install then fails
during clock-setup because tzsetup-udeb is not installed. I'm pretty
sure this is related to the patch because it does not happen with the
daily images.

John did you test your patch in d-i? And did you install the patched
libdebian-installer on your build host? If you don't install it on the
build host, the first part of the installer will run with the
unpatched library.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
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/1291026376-sup-5...@meteor.durcheinandertal.local

Re: Encripting Issue result on many, many hours installing...

[Gaudenz Steinlin]

Hi

Excerpts from Raymundo Dionicio Flores Siordia's message of Fre Nov 26 19:24:26 
+0100 2010:
 Dear debian-boot team:
 
 Could the instaler warn me that encripting my disk will render my 1Tb
 machine useless about 8 hours?.
 
 Maybe could offer to bypass the default pre-cleaning.
 Maybe could offer to encript the first free 25% of HD space.
 Someting like that.

Didn't you have the option to cancel the wipeing? The progress bar
should have a button to cancel the operation. 

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: PGP signature