Bug#327309: (no subject)
-- 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/20101101182644.ga16...@faui44a.informatik.uni-erlangen.de
Bug#327309: (no subject)
-- 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/20101101182640.ga16...@faui44a.informatik.uni-erlangen.de
Re: wpasupplicant for all wireless ops?
Jérémy Bobbio writes: > On Tue, Apr 14, 2009 at 09:53:59PM +0200, Frans Pop wrote: >> On Tuesday 14 April 2009, Jérémy Bobbio wrote: >> > * NetworkManager is used on most distros (and Debian as well) for >> >desktop installations. NetworkManager always use wpasupplicant for >> >interaction with wireless networks so now both wpasupplicant and the >> >drivers have been quite tested. >> > >> > Getting rid of our custom code dealing with the wireless sounds to >> > favor more commonly used software sounds like a desirable goal to me. >> > >> > What do other thinks? >> >> As long as networkmanager does not become a requirement. Installing a >> system using wireless should result in working networking both with and >> without networkmanager installed in the target system. > > Sure, I was only thinking about netcfg internals. Configuring /e/n/i > should be done as it currently is, only installing wpasupplicant by > default if a WPA network was used for the installation. What does that mean for installations via WPA? Do you intend to write out the WPA key in /e/n/i? Besides, what does happen for installations via WEP encrypted wifi? Wouldn't it be better to not configure wifi devices in /e/n/i at all, at least not when the installer has installed network-manager? This would be my preferred option with my pkg-wpa-devel hat on. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Netcfg--Add-WPA-support 3/3] Add WPA support
Glenn Saberton writes:
> Reinhard Tartler wrote:
>> Glenn Saberton writes:
>>
>>> +static int start_wpa_daemon(struct debconfclient *client)
>>> +{
>>> +wpa_supplicant_pid = fork();
>>> +
>>> +if (wpa_supplicant_pid == 0) {
>>> +fclose(client->out);
>>> +if (execlp("wpa_supplicant", "wpa_supplicant", "-i", interface,
>>> "-C",
>>> + WPASUPP_CTRL, "-P", WPAPID, "-B", NULL) == -1) {
>>> +di_error("could not exec wpasupplicant: %s", strerror(errno));
>>> +return 1;
>>> +}
>>> +else
>>> +return 0;
>>> +}
>>> +else {
>>> +waitpid(wpa_supplicant_pid, NULL, 0);
>>> +return 0;
>>> +}
>>> +}
>>
>> this looks fishy. Are you sure you want to return if the child has
>> failed to exec?
>>
> Can you explain what you mean by looks fishy? Suggestions and
> improvements are more than welcome, and I still have a few things I want
> to do yet myself. I'm a bit of a C novice, so I am more than likely to
> have done a few things the less than perfect way, but I'm not sure what
> you mean by the above comment. As is, if the exec fails, then we return
> back, which could really do with an error template as well. I think I
> still need to do a bit more work on the error handling side of things.
fork() clones the current process. The exec then tries to replace the
"child" process with a new one, in this case wpasupplicant. If
wpasupplicant can be executed and the exec call succeeds, it never
returns.
However if exec fails, you generally don't want to continue execution,
but exit with an error code.
If done like you did here, you'll have 2 netcfg processes in the
system. From the first look, it doesn't look that this is intended.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Netcfg--Add-WPA-support 3/3] Add WPA support
Glenn Saberton writes:
> +static int start_wpa_daemon(struct debconfclient *client)
> +{
> +wpa_supplicant_pid = fork();
> +
> +if (wpa_supplicant_pid == 0) {
> +fclose(client->out);
> +if (execlp("wpa_supplicant", "wpa_supplicant", "-i", interface, "-C",
> + WPASUPP_CTRL, "-P", WPAPID, "-B", NULL) == -1) {
> +di_error("could not exec wpasupplicant: %s", strerror(errno));
> +return 1;
> +}
> +else
> +return 0;
> +}
> +else {
> +waitpid(wpa_supplicant_pid, NULL, 0);
> +return 0;
> + }
> +}
this looks fishy. Are you sure you want to return if the child has
failed to exec?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
FAUMachine for testing LTSP and d-i
I have been asked by Petter Reinholdtsen at debcamp to post a link to FAUmachine here: http://www3.informatik.uni-erlangen.de/Research/FAUmachine/ It is a research project for writing a virtual machine solution. It is not that known, but it has a really great testing framework. You basically write a small script which setups and connects the machine(s) you want to test, and run it unattended. Here's an example for installing Debian etch: http://git.informatik.uni-erlangen.de/cgi-bin/gitweb.cgi?p=FAUmachine;a=blob_plain;f=experiments/install-Debian-4.0r0/generate;hb=HEAD Have a look at the other experiments in http://git.informatik.uni-erlangen.de/cgi-bin/gitweb.cgi?p=FAUmachine;a=tree;f=experiments;h=a4b0513729ff4cb2905a93805c9625a3f45adc8f;hb=HEAD as well. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ideas thrown around for Fully Automated Installations
C. Gatzemeier wrote: > Another idea I'd like to throw in is to also keep an eye on m23 and coordinate > ideas. Im sorry to tell you but m23 is not intended to do full automatic installations acording to its authors. It has nice web based guis that simplify mass installations, but that's not usefull for fully automatic installs. Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#237075: Bug not related to Sparc64... Maybe related to Creator?
On Fri, Mar 19, 2004 at 05:20:15PM +0100, Thomas Poindessous wrote: > then you indeed found a bug in bterm > > Could test this : > > booting with "devfs=mount init=/bin/sh" options > you will get a shell and then > > bterm -f unifont.bgf > > and maybe also > > bterm -f unifont.bgf -l C.UTF-8 > > you should get an error message. nope. The screen in the upper half gets messed up, long thin horizontal blue lines, and nothings happens. As soon as I press any key i get a segmentation fault. I tested this with Jeff's image but I don't think that this result will differ from beta3. Any other ideas I could try? regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#237075: Bug not related to Sparc64... Maybe related to Creator?
On Fri, Mar 19, 2004 at 02:43:28PM +0100, Thomas Poindessous wrote: > I think this problem is resolved. You were using unofficial image of d-i > made by Jeff Bailey, and it seems that his build system wasn't using the > last version of libbogl-dev. > > [...] > > Could you please retry with a official build ? Sure. I just booted this image: http://ftp.debian.org/debian/dists/unstable/main/installer-sparc/20040315/images/sparc64/netboot/boot.img This image still has the problem with "unable to open initial console" so the option "devfs=mount" was needed. Not so in Jeff Bailey's build. bterm keeps on segfaulting with this image too. > PS : you can use image from > http://ftp.debian.org/debian/dists/unstable/main/installer-sparc/ These are not the daily builds, are they? I used Jeff's because they seemed to be newer. They also boot without that "devfs=mount" option. regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#237075: Bug not related to Sparc64... Maybe related to Creator?
On Tue, Mar 16, 2004 at 03:50:27PM -0800, Blars Blarson wrote: > The creator is removable, but unless you have an sbus framebuffer there > isn't much point. The ultra 1 does not have an onboard framebuffer. > > You can try using a serial console by disconnecting the keyboard and > using serial port a. (Default 9600 baud.) Well, due to the fact that I get the debian-installer menu when booting with the option "framebuffer=false" I think that installing via serial console works. But that doesn't resolve the Problem that bterm is broken on sparc64, i.e. that displaying UTF-8 characters is not possible. This Problem should at least be documented bevore d-i ist released. regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#237075: Bug not related to Sparc64... Maybe related to Creator?
Gunnar Wolf <[EMAIL PROTECTED]> wrote: > I worked some time ago with an Ultra 10, the Creator board was an > add-on, and when it was removed the base VGA port came back to > life. Does the Ultra 1 also have this? Have you tried without the > Creator? I'm not very familiar with sun hardware, but looking inside and at the board, I don't think that I can remove the Creator board. :( regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#237075: Workaround: disable framebuffer
I managed to track the problem down to bterm, which segfaults. I could use the installer passing the boot option "debian-installer/framebuffer=false". This bug seems to be related to #232720. Many thanks to Petter Reinholdtsen (pere) on irc (#debian-boot). regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#237075: Debian installer segfaults on Sun Ultra 1 Creator 3d (sparc64)
Package: installation-reports Debian-installer-version: March 09, 2004, http://people.debian.org/~jbailey/d-i/sparc/daily/sparc64/netboot/ uname -r: 2.4.24-sparc64 Date: March 09, 2004, 16:24 CET Method: Bootet via DHCP/TFTP, using following command on the boot prompt: > boot net:dhcp devfs=mount Machine: Sun Ultra 1 Creator 3d Processor: sparc64, UltraSparc 167Mhz Memory: 128mb Root Device: scsi device Root Size/partition table: n/a Output of lspci: Base System Installation Checklist: Initial boot worked:[E] Configure network HW: [ ] Config network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: The kernel boots and the scripts to copy the initrd image to /mnt work cleany. But when chrooting to /mnt and starting the debian-installer binary itself, it segfaults and nothing more is possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
