[nobug] Paardenrookvlees eth0 auto-connect
Forum rules
We don't support installations in VirtualBox, VMWare, qemu or others. We ignore posts about WINE, PlayOnLinux, Steam and Skype. We don't support btrfs, lvm, UEFI, side-by-side installations with GPT or dualboot with anything newer than Windows XP.
Google your problem first. Check the Wiki. Read the existing threads. It's okay to "hijack" an existing thread, yes! If your problem is not yet covered, open a new thread. To get the quickest possible help, mention the exact release codename in your post (uname -a is a good idea, too). Due to the lack of crystal balls, attach the output of lspci -nnk if you encounter hardware problems.
We don't support installations in VirtualBox, VMWare, qemu or others. We ignore posts about WINE, PlayOnLinux, Steam and Skype. We don't support btrfs, lvm, UEFI, side-by-side installations with GPT or dualboot with anything newer than Windows XP.
Google your problem first. Check the Wiki. Read the existing threads. It's okay to "hijack" an existing thread, yes! If your problem is not yet covered, open a new thread. To get the quickest possible help, mention the exact release codename in your post (uname -a is a good idea, too). Due to the lack of crystal balls, attach the output of lspci -nnk if you encounter hardware problems.
[nobug] Paardenrookvlees eth0 auto-connect
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 :)
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 :)
All statements are true in some sense, false in some sense, meaningless in some sense, true and false in some sense, true and meaningless in some sense, false and meaningless in some sense, and true and false and meaningless in some sense.
-
- Baconator
- Posts: 10253
- Joined: Thu Sep 16, 2010 11:03 am
- Location: Pfälzerwald
- Contact:
Re: Paardenrookvlees eth0 auto-connect
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/
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/
..gnutella..
Re: Paardenrookvlees eth0 auto-connect
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 :)
All statements are true in some sense, false in some sense, meaningless in some sense, true and false in some sense, true and meaningless in some sense, false and meaningless in some sense, and true and false and meaningless in some sense.
-
- Baconator
- Posts: 10253
- Joined: Thu Sep 16, 2010 11:03 am
- Location: Pfälzerwald
- Contact:
Re: Paardenrookvlees eth0 auto-connect
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.
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.
..gnutella..
Re: Paardenrookvlees eth0 auto-connect
totally agree on all this. will mark it '[nobug]'
All statements are true in some sense, false in some sense, meaningless in some sense, true and false in some sense, true and meaningless in some sense, false and meaningless in some sense, and true and false and meaningless in some sense.
-
- Baconator
- Posts: 10253
- Joined: Thu Sep 16, 2010 11:03 am
- Location: Pfälzerwald
- Contact:
Re: [nobug] Paardenrookvlees eth0 auto-connect
It's okay, we don't have a designated FAQ section, so this is the only sane place to post questions and suggestions :)
..gnutella..
Re: [nobug] Paardenrookvlees eth0 auto-connect
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!
thanks!
Work hard; Complain less
-
- Baconator
- Posts: 10253
- Joined: Thu Sep 16, 2010 11:03 am
- Location: Pfälzerwald
- Contact:
Re: [nobug] Paardenrookvlees eth0 auto-connect
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.
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.
..gnutella..
Re: [nobug] Paardenrookvlees eth0 auto-connect
Yes, I have noticed that with the keybindings.....
Work hard; Complain less
Re: [nobug] Paardenrookvlees eth0 auto-connect
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.
Work hard; Complain less