- Arch-general - lists.archlinux.org

Re: [arch-general] Reboot - Versioned Kernel Installs
by Paul Gideon Dann 12 Jun '11

12 Jun '11

I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work. I wouldn't want more than one old version of the kernel, though. Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK... Paul On Monday 06 June 2011 18:23:50 Tom Gundersen wrote: > On Mon, Jun 6, 2011 at 6:22 PM, Tavian Barnes <tavianator(a)tavianator.com> wrote: > > I have kernel26-lts installed as a backup kernel, and this is all > > that's really necessary for rolling back broken kernel updates. I've > > been bitten by a BTRFS bug once and rolled back with -lts no problem. > > -1 from me on keeping multiple kernel versions installed; I really > > like that arch doesn't keep 6 old kernels around. > > I agree. > > The reason I am against keeping old kernels around is that we would > not be able to test user space against all the possible combinations, > so it would not be a good idea to suggest that we do (we do try to > support all sorts of self-compiled kernels, but at least if you > compile your own kernel it is pretty obvious that it will not be as > well tested as the "official" ones). > > One possibility would be to do like upstream does and always rename > the previous kernel to .old. That should keep the last known working > kernel around while making it clear that it should not be relied on > for day-to-day use (and that it will get overwritten on the next > kernel upgrade so these things won't get old). > > That said, I'm not involved with packaging the kernel, so if you want > anything to change with how it is packaged (maybe after this > discussion is over), it would be best to file a feature request on FS. > > Cheers, > > Tom

14 41

[arch-general] [netcfg] Prerelease package before 2.6 release
by Rémy Oudompheng 12 Jun '11

12 Jun '11

Hello, I have uploaded a premilinary netcfg package including the latest changes. It does not correspond to a particular tag in the Git repository (it's commit 1f5183b8). http://dev.archlinux.org/~remy/netcfg/netcfg-2.5.90-1-any.pkg.tar.xz I plan to produce version 2.6 after some polishing has been made. * I can test static configuration * I can test IPv4 wireless * I remember wireless IPv6 worked previously, maybe due to autoconfiguration. I don't know if there are real people out in the world using DHCP for IPv6. net-tools is now an optional dependency. It's only necessary if you want to use the IFCFG option. Changes: version 2.6 - add support for IPv6 configuration (FS#18699) - add support for static routes configuration (FS#18700) - add support for creating tun/tap interfaces (FS#15049) - wireless: add support for explicit BSSID (FS#24582) - wireless: add support for ad-hoc connections (FS#19683) - use /run instead of /var/run - drops dependency on net-tools package Regards, Rémy.

1 0

[arch-general] Network Config - Fixed IP - ifconfig no longer reports broadcast address?
by David C. Rankin 11 Jun '11

11 Jun '11

Guys, Bug or feature? After updating rc.conf to contain the new network configuration for a fixed IP, ifconfig no longer reports the broadcast address. Using the new config of: interface=eth0 address=192.168.6.14 netmask=255.255.255.0 gateway=192.168.6.13 I get: 17:48 archangel:~> ifconfig eth0 Link encap:Ethernet HWaddr 00:21:85:1A:8C:FA inet addr:192.168.6.14 Bcast:0.0.0.0 Mask:255.255.255.0 ^^^^^^^^^^^^^^ inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:102 errors:0 dropped:0 overruns:0 frame:0 TX packets:140 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14657 (14.3 Kb) TX bytes:15177 (14.8 Kb) Interrupt:41 Base address:0x2000 Prior to the change, the broadcast address was correctly reported. eth0 Link encap:Ethernet HWaddr 00:21:85:1A:8C:FA inet addr:192.168.6.14 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:103 errors:0 dropped:0 overruns:0 frame:0 TX packets:139 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14683 (14.3 Kb) TX bytes:15505 (15.1 Kb) Interrupt:41 Base address:0x2000 If I modify rc.conf and change back to the old format: # old network config for broadcast address eth0="eth0 192.168.6.14 netmask 255.255.255.0 broadcast 192.168.6.255" INTERFACES=(eth0) gateway="default gw 192.168.6.13" ROUTES=(gateway) then the broadcast address is correctly reported again. Is this a bug or feature? -- David C. Rankin, J.D.,P.E.

3 3

[arch-general] [signoff] kernel26-2.6.39.1-1
by Tobias Powalowski 11 Jun '11

11 Jun '11

Hi guys, please signoff 2.6.39 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges WARNING: AUFS2 support is gone for now, if this is no showstopper we should go move it to [core]. If noone has real objections, I hope to get this kernel into [core]. Along with this the binary modules mentioned on the previous thread will be removed from [core] and [extra]: - tiacx (broken) - ndiswrapper (not needed anymore) - intel536/537 (does not compile on .39 series) - madwifi (obsolete) - martian (old modem driver) - tiacx-lts - ndiswrapper-lts greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3

[arch-general] blacklisting/MOD_AUTOLOAD - what drove the change?
by David C. Rankin 11 Jun '11

11 Jun '11

Guys, Just curious for the reason behind the changes to blacklisting and MOD_AUTOLOAD. What drove the change? -- David C. Rankin, J.D.,P.E.

2 1

[arch-general] Dejavu sans mono fonts rendering issue.
by mwnn 11 Jun '11

11 Jun '11

Hi, I am unable to configure fonts on my new arch linux system. The fonts from the old slackware installation are similar to http://i.imgur.com/UcwHS.png. The new arch linux fonts look like http://imageshack.us/photo/my-images/695/newemacs.jpg/ Regards, mwnn

4 5

Re: [arch-general] [arch-announce] Deprecation of net-tools
by Heiko Baums 11 Jun '11

11 Jun '11

Am Wed, 08 Jun 2011 16:01:15 -0000 schrieb "Arch Linux: Recent news updates: Tom Gundersen" <announce(a)archlinux.org>: > Tom Gundersen wrote: > > This April marked the ten year anniversary of the last net-tools > release. We decided to look at this as an opportunity to deprecate > net-tools and provide alternative, and better maintained, solutions > for net-tools functionality. > ... > We want to encourage the use of more > advanced network solutions, such as `networkmanager` or our own > `netcfg`. Well, I don't want to say anything, but netcfg still depends on net-tools. ;-) Heiko

7 16

[arch-general] EveryDNS compulsory migration to Dyn
by Abdul Halim 11 Jun '11

11 Jun '11

I can't help but notice that ArchLinux is using EveryDNS for its DNS server. And since I also use EveryDNS DNS server, what is the plan for ArchLinux domain administrator since EveryDNS users need to migrate to Dyn by 31-Aug-2011? Will the administrator use the paid service or something else?

2 1

[arch-general] EveryDNS compulsory migration to Dyn
by Abdul Halim 11 Jun '11

11 Jun '11

I can't help but notice that ArchLinux is using EveryDNS for its DNS server. And since I also use EveryDNS DNS server, what is the plan for ArchLinux domain administrator since EveryDNS users need to migrate to Dyn by 31-Aug-2011? Will the administrator use the paid service or something else?

1 0

[arch-general] On deprecation of net-tools
by Magnus Therning 11 Jun '11

11 Jun '11

With the recent deprecation of net-tools I did notice some changes: - The binary 'hostname' now accepts remarkably few options, specifically 'hostname -d' no longer works. - The command 'dnsdomainname' disappeared. (I'm not really sure why I ended up using it though, since 'hostname -d' would have worked just as well.) I have read FS#24647 already, so I'm aware that some of this is being worked on. What I'm wondering is, what can I do in the meantime to get 'hostname -d' back? -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

2 2