[nobug] Paardenrookvlees eth0 auto-connect

[rhowaldt]

i noticed when booting Paardenrookvlees that it took a long time checking for an eth0 connection when there wasn't any (i use wireless only). eventually it just continued, but after 30 seconds of trying and trying again. is this on purpose? or an old eth0 setting in /etc/network/interfaces still left over from your own install?

p.s. this was the only weird thing i could find.
p.p.s. for those having trouble with the name:
Paardenrookvlees. Paarden = Horses; Rook = Smoke; Vlees = Meat. simple as that. in German, PferdenRauchFleisch :)

[machinebacon]

Actually it is on purpose, after users called it a 'bug' when it didn't autoconnect - and it is not a leftover of previous installations. One decision had to be made: auto-connect or not, search for DHCP on eth0 or not. Originally, this should only happen in a live session.

You might run Ceni and stop network-manager, remove the old configuration for eth0 (in ceni) and rewrite a new one for wlan0.

Wouldn't call this a bug, sorry :) If DHCP times out, it just continues.

http://wiki.debian.org/NetworkConfiguration
http://crunchbanglinux.org/forums/topic ... me-solved/

[rhowaldt]

that's what i thought, but i figured 'better safe than sorry' so reported it nonetheless. thanks for explaining, and don't mind that you don't call it a bug - i'd rather have no bugs than bugs :)

[machinebacon]

Well of course I can remove the interfaces completely, and the user can then add his network adapters at every boot from stick. Don't know what's worse :D

Scenario 1: somebody downloads the ISO, puts it on a stick, boots up in 30 seconds, has no network.

Scenario 2: somebody downloads the ISO, puts it on a stick, boots up in 45 seconds, has network.

Who will stay with BBQ? - You know what I mean... :)

Edit: Anyway these releases are meant to be customized, changed, added with own configs, and then remastered with the bbqsnapshot tool if wished. Users who can do this procedure will have little problems to change the defaults of the network manager, especially since documentation for Debian applies.

[rhowaldt]

totally agree on all this. will mark it '[nobug]'

[machinebacon]

It's okay, we don't have a designated FAQ section, so this is the only sane place to post questions and suggestions :)

[dkeg]

with my new install of oyster had noticed and wondered about the same thing. I have not dug any deeper as I was too busy getting configs in order. I have chosen to use Ceni and disable NM, but have not done any rewrite of anything yet. Guess I'll get to it when I can. Other than that, yay!!! Curious on a couple key bindings in spectrewm, but I'll post that up elsewhere when I have a few minutes.

thanks!

[machinebacon]

The behaviour should be less verbose now starting from RC1 (the 64-bit is in the works and will come up soon as RC2 with minor changes)

About keybinding is SpectrWM (Oyster version) just a brief explanation: the Alt-F1 to Alt-F9 shortcuts and some general 'open Terminal' shortcuts are defined in .xbindkeys (IIRC that's the name, Pidsley will chime in if I'm wrong), so if there are keybinds that 'overlap' with the spectrwm.conf keybinds, you should change them in .xbindkeys

Example: if Spectrwm has a keybind Alt-F3 opening an editor, it is already overriden by xbindkeys' Alt-F3 open dmenu. In this case simply disable (comment) the line in xbindkeys.

We have used xbindkeys to ensure that there are always the same keybinds working in all WMs, so that one can always easily open a terminal or log out from X.

[dkeg]

Yes, I have noticed that with the keybindings.....

[dkeg]

in i3 a conflicting keybinding is if you change dmenu to MOD+p instead of the default MOD+d. I realized this b/c of the look of dmenu and b/c I change up the look of it with my own colors, etc. But it wouldn't take. When I reconfigured to use MOD+d, it worked. So maybe not only, but looks like it takes the spectrewm dmenu config when used with MOD+p.