Re: [arch-general] Dejavu sans mono fonts rendering issue.
On Sat, Jun 11, 2011 at 12:18 PM, Rémy Oudompheng wrote: > On 2011/6/11 mwnn wrote: >> 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/ > > Hello, > > You do not seem to have a question or a problem that people might try > to solve. Do you have any? > > Regards, > Rémy. > The Slackware fonts are much thicker than the one on Arch. Would like to know how I can configure the fonts on Arch to look similar to Slackware. I have read Archwiki's Fontconfig entry and tried setting various configurations in ~/.fonts.conf. BTW the issue appears only in Emacs and GVIM. Firefox, for example, renders fonts correctly. P.S: I am using icewm as my window manager and xdm as my display manager.
Re: [arch-general] Dejavu sans mono fonts rendering issue.
On 2011/6/11 mwnn wrote: > 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/ Hello, You do not seem to have a question or a problem that people might try to solve. Do you have any? Regards, Rémy.
[arch-general] Dejavu sans mono fonts rendering issue.
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
Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
On Friday, June 10, 2011 23:36:18 C Anthony Risinger wrote: > On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos > > wrote: > > Arch users have lived without the last good known kernel so far and > > without an -lts kernel until recently. > > this applies to technology in general -- we don't need any of it, but > forward we move nonetheless. > > > IMHO it is a lot more advisable > > to have an install cd/usb, or even better, a custom install in some > > external media that can be used to boot the system in case something > > goes wrong or in case of emergency. Then you can just chroot into the > > broken install and fix the problem or tell pacman where the root and > > cache are located and fix things. > > why is that simpler/advisable? now you need to mount everything > properly by hand else things like autodetection fail in mkinitcpio, > etc. i don't think it's hard to recover, and i would never have any > of these issues, but i think a *real* recovery shell is not a bad idea > ... why add more work for me the human when the machine could get me > 95% the way there? and offer some options even? > > On Fri, Jun 10, 2011 at 7:45 PM, Joe(theWordy)Philbrook wrote: > > The only reason to even consider keeping an old kernel around with Arch > > was just in case the new kernel is effectively borked... (possibly due > > to a hardware incompatibility...) And if I remember right, you said > > something about this not working if the new kernel can't boot... > > you wouldn't want to boot it past the final step, ie. you don't want > to actually switch_root into your / device and continue the boot > process ... however, at that moment, you have: > > ) booted a good kernel > ) have all autodetected modules available (possibly not loaded tho) > ) ... and (IIRC) -fallback version has the full module tree if needed > ) loaded your last configuration of initcpio hooks/etc > ) ... which means your / is probably mounted properly, even with > encryption and other exotics > ) other filesystems like /dev /sys are mounted, --move'd, and ready to > go on the new_root > ) the whole system is poised for regular boot > > ... so initcpio script *could*, if aware of your dilemma: > > ) drop to shell immediately with some helpful info > ) chroot for you into /new_root (your real system) > ) ... maybe bind mount the module hierarchy into new_root to prevent > accidental loading of wrong mods (if that's even possible, not sure) > > ... basically just bring you 95% the way there, then let you fix it > and reboot ... done. > > On Fri, Jun 10, 2011 at 8:06 PM, Joe(theWordy)Philbrook wrote: > > It would appear that on Jun 10, Robert Howard did say: > >> Why not just copy the old kernel image, modules and initrd image > >> somewhere by hand before you upgrade kernels. > > > > That wouldn't be such a bad idea. And in fact I already do that with the > > kernel and initrd image. > > and that option will always be available ... but any trivially > repetitive procedure requiring consistent user interaction is a poor > solution IMO, if even worthy of being called a solution. definitely > an exaggeration, but why even have timed scripts a la cron, or a > packaging system at all, when we could just remember to do stuff? why > not boot the system by hand :-)? probably because these automata > improve consistency and reduce the likelihood of errors ... we suck at > being computers :-) > > http://panko.shidler.hawaii.edu/HumanErr/ProgNorm.htm > > > * CRS : "Can't Remember Sh^Htuff" > > ha nice ... i've never heard anyone else say/use this (CRS acronym) > ... my grandmother has been telling me that since i was a kid -- i > always thought she made it up :-) -- one of those independently > discoverable things i suppose. > > On Fri, Jun 10, 2011 at 8:33 PM, Heiko Baums wrote: > > Am Fri, 10 Jun 2011 21:21:17 -0400 > > > > schrieb "Joe(theWordy)Philbrook" : > >> Now that, Heiko, is a good idea. And one that I could actually do. > >> I'd just have to decide which of my other Linux distributions to > >> sacrifice to make room for it... Keeping in mind that as you say: > >> "those cases in which an updated kernel is unbootable are very, very > >> rare." I think I'd rather learn how to use the "pacman -U" method... > > > > Would at least be less work. > > how is installing another distro that you may never use easier? you'd > still have to go thru the whole manual recovery process. LiveCD beats > this any day for me -- i rarely install anything these days because my > distro-hopping abruptly ended with Arch :-) (though i do check them > out from time to time, or for work related things) > > -- > > and the end of the day people just want to reinstate a useable system > as rapidly as possible. we can yammer on and argue that the user > "should not be using testing then", "should be making full backups", > "should have/know an alternate recovery plan", "should be manually > backing up k
[arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos wrote: > > Arch users have lived without the last good known kernel so far and > without an -lts kernel until recently. this applies to technology in general -- we don't need any of it, but forward we move nonetheless. > IMHO it is a lot more advisable > to have an install cd/usb, or even better, a custom install in some > external media that can be used to boot the system in case something > goes wrong or in case of emergency. Then you can just chroot into the > broken install and fix the problem or tell pacman where the root and > cache are located and fix things. why is that simpler/advisable? now you need to mount everything properly by hand else things like autodetection fail in mkinitcpio, etc. i don't think it's hard to recover, and i would never have any of these issues, but i think a *real* recovery shell is not a bad idea ... why add more work for me the human when the machine could get me 95% the way there? and offer some options even? On Fri, Jun 10, 2011 at 7:45 PM, Joe(theWordy)Philbrook wrote: > > The only reason to even consider keeping an old kernel around with Arch was > just in case the new kernel is effectively borked... (possibly due to a > hardware incompatibility...) And if I remember right, you said something > about this not working if the new kernel can't boot... you wouldn't want to boot it past the final step, ie. you don't want to actually switch_root into your / device and continue the boot process ... however, at that moment, you have: ) booted a good kernel ) have all autodetected modules available (possibly not loaded tho) ) ... and (IIRC) -fallback version has the full module tree if needed ) loaded your last configuration of initcpio hooks/etc ) ... which means your / is probably mounted properly, even with encryption and other exotics ) other filesystems like /dev /sys are mounted, --move'd, and ready to go on the new_root ) the whole system is poised for regular boot ... so initcpio script *could*, if aware of your dilemma: ) drop to shell immediately with some helpful info ) chroot for you into /new_root (your real system) ) ... maybe bind mount the module hierarchy into new_root to prevent accidental loading of wrong mods (if that's even possible, not sure) ... basically just bring you 95% the way there, then let you fix it and reboot ... done. On Fri, Jun 10, 2011 at 8:06 PM, Joe(theWordy)Philbrook wrote: > > It would appear that on Jun 10, Robert Howard did say: > >> Why not just copy the old kernel image, modules and initrd image somewhere >> by hand before you upgrade kernels. > > That wouldn't be such a bad idea. And in fact I already do that with the > kernel and initrd image. and that option will always be available ... but any trivially repetitive procedure requiring consistent user interaction is a poor solution IMO, if even worthy of being called a solution. definitely an exaggeration, but why even have timed scripts a la cron, or a packaging system at all, when we could just remember to do stuff? why not boot the system by hand :-)? probably because these automata improve consistency and reduce the likelihood of errors ... we suck at being computers :-) http://panko.shidler.hawaii.edu/HumanErr/ProgNorm.htm > * CRS : "Can't Remember Sh^Htuff" ha nice ... i've never heard anyone else say/use this (CRS acronym) ... my grandmother has been telling me that since i was a kid -- i always thought she made it up :-) -- one of those independently discoverable things i suppose. On Fri, Jun 10, 2011 at 8:33 PM, Heiko Baums wrote: > Am Fri, 10 Jun 2011 21:21:17 -0400 > schrieb "Joe(theWordy)Philbrook" : > >> Now that, Heiko, is a good idea. And one that I could actually do. >> I'd just have to decide which of my other Linux distributions to >> sacrifice to make room for it... Keeping in mind that as you say: >> "those cases in which an updated kernel is unbootable are very, very >> rare." I think I'd rather learn how to use the "pacman -U" method... > > Would at least be less work. how is installing another distro that you may never use easier? you'd still have to go thru the whole manual recovery process. LiveCD beats this any day for me -- i rarely install anything these days because my distro-hopping abruptly ended with Arch :-) (though i do check them out from time to time, or for work related things) -- and the end of the day people just want to reinstate a useable system as rapidly as possible. we can yammer on and argue that the user "should not be using testing then", "should be making full backups", "should have/know an alternate recovery plan", "should be manually backing up kernel related stuff", "should be awesomely l33t with linux by now", "prob shouldnt use Arch then" or limitless other assertions, none of which will help anyone learn anything. i can recover my system. i can recover it pretty much no matter how fubificated it is in
[arch-general] EveryDNS compulsory migration to Dyn
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?
[arch-general] EveryDNS compulsory migration to Dyn
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?
Re: [arch-general] Reboot - Versioned Kernel Installs
Am Fri, 10 Jun 2011 21:21:17 -0400 schrieb "Joe(theWordy)Philbrook" : > Mind specifying for an idiot like me just which package-file-names > I'd need to use with pacman -U to restore the previous kernel, > complete with it's modules? Try `ls /var/cache/pacman/pkg/kernel26*` and I guess you will find it. > Now that, Heiko, is a good idea. And one that I could actually do. > I'd just have to decide which of my other Linux distributions to > sacrifice to make room for it... Keeping in mind that as you say: > "those cases in which an updated kernel is unbootable are very, very > rare." I think I'd rather learn how to use the "pacman -U" method... Would at least be less work. Heiko
Re: [arch-general] Reboot - Versioned Kernel Installs
Am Fri, 10 Jun 2011 21:06:21 -0400 schrieb "Joe(theWordy)Philbrook" : > That wouldn't be such a bad idea. And in fact I already do that with > the kernel and initrd image. But I'm almost ashamed to admit that I > don't have enough understanding of the modules to know how to > preserve and when needed restore them. And as was I think mentioned > in this thread, without the modules, the gui wouldn't work... You don't need the modules and the GUI to downgrade the kernel package if the updated kernel should be broken. > Is there a step by step how-to or wiki I could bookmark??? 1. Boot the old kernel 2. Login on the text console 3. pacman -U /var/cache/pacman/pkg/kernel26--.pkg.tar.xz 4. reboot Old kernel and its modules are back. But before you do this, you should write down or copy the necessary error messages and details to file a bug report about the kernel issue. Heiko
Re: [arch-general] Reboot - Versioned Kernel Installs
It would appear that on Jun 10, Heiko Baums did say: > Am Fri, 10 Jun 2011 12:48:57 +0200 > schrieb Vic Demuzere : > > > Having multiple kernels is insane. I don't get why it's needed. There > > is a live cd to rescue your system if needed. > > And the old kernel packages (every package) are saved in pacman's cache > (usually /var/cache/pacman/pkg) anyway until pacman -Sc or pacman -Scc > is run. So every package can easily be downgraded by running pacman > -U /var/cache/pacman/pkg/. Mind specifying for an idiot like me just which package-file-names I'd need to use with pacman -U to restore the previous kernel, complete with it's modules? -snipped. . . .. . . .. .stuff > The better and much cleaner solution is to first try the fallback initrd > or to install a different kernel package like kernel26-lts parallel to > kernel26. > > Keep in mind, those cases in which an updated kernel is unbootable > are very, very rare. > > And people who need a reliable system and are so afraid of > broken kernels, of course, shouldn't use [testing]. They should better > install a multiboot system with one stable system and one test system. > This way they can test kernel updates from [testing] on their test > system and update the kernel on their stable system only if the test > system is working correctly. This would, btw., help to filing bug > reports for the kernels on esoteric hardware before they get into > [core]. Now that, Heiko, is a good idea. And one that I could actually do. I'd just have to decide which of my other Linux distributions to sacrifice to make room for it... Keeping in mind that as you say: "those cases in which an updated kernel is unbootable are very, very rare." I think I'd rather learn how to use the "pacman -U" method... -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ <>
Re: [arch-general] Reboot - Versioned Kernel Installs
It would appear that on Jun 10, Robert Howard did say:
> Why not just copy the old kernel image, modules and initrd image somewhere
> by hand before you upgrade kernels. If we try to make this automated it
> isn't going to be kiss. I used to do this way back in the day by including
> the entire kernel version in the pkgver and giving the images longer names.
> It was possible to have concurrently installed kernels. Check out how some
> of the AUR kernels manage to be the same kernel version as the official
> without causing issues.
That wouldn't be such a bad idea. And in fact I already do that with the
kernel and initrd image. But I'm almost ashamed to admit that I don't have
enough understanding of the modules to know how to preserve and when needed
restore them. And as was I think mentioned in this thread, without the
modules, the gui wouldn't work...
«I blame CRS {see below}» I've tried to learn stuff like that but the knowledge
didn't stick.
Is there a step by step how-to or wiki I could bookmark???
--
| ~^~ ~^~
|Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ <>
* CRS : "Can't Remember Sh^Htuff" : In my case this means that unless I
* do something the same way every day for a LONG time, or have examples
* of how I did it before (where I can still find them), I usually wind up
* scratching my head the next time I need to do a non-daily task. Or for
* that matter, to remember what I was doing before the durned phone rang etc...
Re: [arch-general] On deprecation of net-tools
On Sat, Jun 11, 2011 at 02:38:29AM +0200, Tom Gundersen wrote: > On Sat, Jun 11, 2011 at 2:26 AM, Magnus Therning wrote: > > 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? > > Install net-tools and coreutils from [testing], where this has > already been resolved (reverted to the old behavior). Ah, thanks for that info! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgpvTWSjplVyO.pgp Description: PGP signature
Re: [arch-general] Reboot - Versioned Kernel Installs
It would appear that on Jun 9, C Anthony Risinger did say: > On Jun 9, 2011 5:50 PM, "Heiko Baums" wrote: > > Am Thu, 9 Jun 2011 17:36:21 -0500 > > schrieb C Anthony Risinger : > > > >> does this sound genius or completely insane? some insanely genius guy > >> once said they are only separated by a fine line ... > > > > Sounds completely insane. > > ook ... and ... why? -snipped. . . .. . . .. .stuff The only reason to even consider keeping an old kernel around with Arch was just in case the new kernel is effectively borked... (possibly due to a hardware incompatibility...) And if I remember right, you said something about this not working if the new kernel can't boot... -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ <>
Re: [arch-general] On deprecation of net-tools
On Sat, Jun 11, 2011 at 2:26 AM, Magnus Therning wrote: > 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? Install net-tools and coreutils from [testing], where this has already been resolved (reverted to the old behavior). -t
Re: [arch-general] On module blacklisting
On Sat, Jun 11, 2011 at 02:22:56AM +0200, Tom Gundersen wrote: > Hi Magnus, > > On Sat, Jun 11, 2011 at 2:11 AM, Magnus Therning wrote: > > 1. As I read it, it's only blacklisting that's affected, is that > > correct? > > Correct. > > > So MODULES in rc.conf can in the future only be used to load > > modules at boot-up. > > Correct. > > > (Is there even a way to configure modprobe to > > load modules on boot?) > > No (that's why we need to keep this in rc.conf). > > > 2. When does this change take effect? > > Which version of which package will it come with? > > The packages were moved to [core] shortly after the announcement was > made. You should have received notifications when installing > initscripts and udev. Thanks, that's exactly the info I was looking for :-) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgphfhH9FfUyn.pgp Description: PGP signature
[arch-general] On deprecation of net-tools
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: mag...@therning.org jabber: mag...@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 pgpZYJDZvH5TY.pgp Description: PGP signature
Re: [arch-general] On module blacklisting
Hi Magnus, On Sat, Jun 11, 2011 at 2:11 AM, Magnus Therning wrote: > 1. As I read it, it's only blacklisting that's affected, is that > correct? Correct. > So MODULES in rc.conf can in the future only be used to load > modules at boot-up. Correct. > (Is there even a way to configure modprobe to > load modules on boot?) No (that's why we need to keep this in rc.conf). > 2. When does this change take effect? > Which version of which package will it come with? The packages were moved to [core] shortly after the announcement was made. You should have received notifications when installing initscripts and udev. Cheers, Tom
[arch-general] On module blacklisting
I just read about the changes to module blacklisting[1] and I'm left wondering: 1. As I read it, it's only blacklisting that's affected, is that correct? So MODULES in rc.conf can in the future only be used to load modules at boot-up. (Is there even a way to configure modprobe to load modules on boot?) 2. When does this change take effect? Which version of which package will it come with? /M [1] http://www.archlinux.org/news/changes-to-module-blacklisting/ -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgpMM0NjwIKkW.pgp Description: PGP signature
Re: [arch-general] Reboot - Versioned Kernel Installs
Arch users have lived without the last good known kernel so far and without an -lts kernel until recently. IMHO it is a lot more advisable to have an install cd/usb, or even better, a custom install in some external media that can be used to boot the system in case something goes wrong or in case of emergency. Then you can just chroot into the broken install and fix the problem or tell pacman where the root and cache are located and fix things. -- Mauro Santos
Re: [arch-general] [arch-dev-public] [signoff] kernel26-2.6.39.1-1
On Fri, Jun 10, 2011 at 5:09 PM, Tobias Powalowski wrote: > > 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 Signoff both. -t
Re: [arch-general] [signoff] kernel26-2.6.39.1-1
Am 10.06.2011 17:09, schrieb Tobias Powalowski: 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 signoff x86_64 -- Regards, Richard Schütz
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On Fri, Jun 10, 2011 at 12:52 AM, Joker-jar wrote:
> /etc/conf.d/bridges (bridge-utils) still has old rc.conf example:
>
> # example:
> #
> # in /etc/rc.conf:
> # eth0="eth0 up"
> # eth1="eth1 up"
> # br0="br0 192.168.0.2 netmask 255.255.255.0 up"
> # INTERFACES=(lo eth0 eth1 br0)
> #
> # in /etc/conf.d/bridges
> # bridge_br0="eth0 eth1"
> # BRIDGE_INTERFACES=(br0)
> #
>
> In addition bridged interfaces doesn't work with new rc.conf syntax (unknown
> interface br0). How to set up?
The dchp still works with net-tools installed:
eth0="eth0 up"
br0="dhcp"
INTERFACES=(eth0 br0)
However using netcfg it can be accomplish, it has examples:
/etc/network.d/examples/bridge
I have two profiles, one for dhcp (work) and one for static (home):
% cat /etc/network.d/wired-dhcp
#
DHCLIENT=yes
CONNECTION='bridge'
DESCRIPTION='A basic dhcp ethernet connection using iproute'
INTERFACE='br0'
BRIDGE_INTERFACES="eth0"
IP='dhcp'
CARRIER_TIMEOUT=3
% cat /etc/network.d/wired-static
#
CONNECTION='bridge'
DESCRIPTION='A basic static ethernet connection using iproute'
INTERFACE='br0'
BRIDGE_INTERFACES="eth0"
IP='static'
ADDR='192.168.1.159'
GATEWAY='192.168.1.1'
DNS=('200.91.75.5' '200.91.75.6' '192.168.1.1')
CARRIER_TIMEOUT=3
So I use net-profiles daemon instead of network one, :-)
Notice for some reason dhcpd is not a good option for bridging under
netcfg, since somehow the dhcp client keeps alive after netcfg -a, so
I preferred using dhclient, which works well...
So perhaps you might consider using netcfg for bridging, :-)
--
Javier.
Re: [arch-general] mpd fails to start
On 06/10/2011 10:29 PM, Madhurya Kakati wrote: > On 06/10/2011 10:21 PM, Richard Schütz wrote: >> Am 10.06.2011 18:47, schrieb Madhurya Kakati: >>> Hello, >>> Recently mpd has stopped working. It doesn't start up at boot and when i >>> run "rc.d start mpd" I get this error /etc/rc.d/mpd: line 6: 24502 >>> Aborted /usr/bin/mpd /etc/mpd.conf&>/dev/null. >>> I am using gnome3(if thats somehow causing the problem.) I believe its >>> due to some ALSA pulseaudio mixup but I am not sure. >>> However if I run "sudo mpd" I get this output: >>> [papul@papuldesktop ~]$ sudo mpd >>> output: No "audio_output" defined in config file >>> output: Attempt to detect audio output device >>> output: Attempting to detect a alsa audio device >>> output: Successfully detected a alsa audio device >>> >>> and after that if I run "mpc play" I get this: >>> [papul@papuldesktop ~]$ mpc play >>> Metallica - The Unforgiven II >>> [paused] #4/8 0:00/6:36 (0%) >>> volume: n/a repeat: off random: off single: off consume: off >>> ERROR: problems opening audio device >>> >>> Please help coz I haven't been able to listen to music for quite >>> sometime now. :( >> Did you try to configure MPD to use PulseAudio then? (see [1]) >> >> [1] https://wiki.archlinux.org/index.php/MPD >> > how do I check if I am using pulseaudio or alsa or whatever else there is? Uncommenting ALSA audio output section in /etc/mpd.conf solved the problem. Thanks for the help. signature.asc Description: OpenPGP digital signature
Re: [arch-general] mpd fails to start
On 06/10/2011 10:21 PM, Richard Schütz wrote: > Am 10.06.2011 18:47, schrieb Madhurya Kakati: >> Hello, >> Recently mpd has stopped working. It doesn't start up at boot and when i >> run "rc.d start mpd" I get this error /etc/rc.d/mpd: line 6: 24502 >> Aborted /usr/bin/mpd /etc/mpd.conf&>/dev/null. >> I am using gnome3(if thats somehow causing the problem.) I believe its >> due to some ALSA pulseaudio mixup but I am not sure. >> However if I run "sudo mpd" I get this output: >> [papul@papuldesktop ~]$ sudo mpd >> output: No "audio_output" defined in config file >> output: Attempt to detect audio output device >> output: Attempting to detect a alsa audio device >> output: Successfully detected a alsa audio device >> >> and after that if I run "mpc play" I get this: >> [papul@papuldesktop ~]$ mpc play >> Metallica - The Unforgiven II >> [paused] #4/8 0:00/6:36 (0%) >> volume: n/a repeat: off random: off single: off consume: off >> ERROR: problems opening audio device >> >> Please help coz I haven't been able to listen to music for quite >> sometime now. :( > > Did you try to configure MPD to use PulseAudio then? (see [1]) > > [1] https://wiki.archlinux.org/index.php/MPD > how do I check if I am using pulseaudio or alsa or whatever else there is? signature.asc Description: OpenPGP digital signature
Re: [arch-general] mpd fails to start
Am 10.06.2011 18:47, schrieb Madhurya Kakati: Hello, Recently mpd has stopped working. It doesn't start up at boot and when i run "rc.d start mpd" I get this error /etc/rc.d/mpd: line 6: 24502 Aborted /usr/bin/mpd /etc/mpd.conf&>/dev/null. I am using gnome3(if thats somehow causing the problem.) I believe its due to some ALSA pulseaudio mixup but I am not sure. However if I run "sudo mpd" I get this output: [papul@papuldesktop ~]$ sudo mpd output: No "audio_output" defined in config file output: Attempt to detect audio output device output: Attempting to detect a alsa audio device output: Successfully detected a alsa audio device and after that if I run "mpc play" I get this: [papul@papuldesktop ~]$ mpc play Metallica - The Unforgiven II [paused] #4/8 0:00/6:36 (0%) volume: n/a repeat: off random: off single: off consume: off ERROR: problems opening audio device Please help coz I haven't been able to listen to music for quite sometime now. :( Did you try to configure MPD to use PulseAudio then? (see [1]) [1] https://wiki.archlinux.org/index.php/MPD -- Regards, Richard Schütz
[arch-general] mpd fails to start
Hello, Recently mpd has stopped working. It doesn't start up at boot and when i run "rc.d start mpd" I get this error /etc/rc.d/mpd: line 6: 24502 Aborted /usr/bin/mpd /etc/mpd.conf &>/dev/null. I am using gnome3(if thats somehow causing the problem.) I believe its due to some ALSA pulseaudio mixup but I am not sure. However if I run "sudo mpd" I get this output: [papul@papuldesktop ~]$ sudo mpd output: No "audio_output" defined in config file output: Attempt to detect audio output device output: Attempting to detect a alsa audio device output: Successfully detected a alsa audio device and after that if I run "mpc play" I get this: [papul@papuldesktop ~]$ mpc play Metallica - The Unforgiven II [paused] #4/8 0:00/6:36 (0%) volume: n/a repeat: off random: off single: off consume: off ERROR: problems opening audio device Please help coz I haven't been able to listen to music for quite sometime now. :(
Re: [arch-general] Reboot - Versioned Kernel Installs
On Fri, Jun 10, 2011 at 5:42 AM, Martti Kühne wrote: > On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger wrote: > >> what if we (optionally) stored the original images _inside_ the new >> one? the new/bad kernel would boot, and via some bootloader entry eg. >> kernel param the new initcpio script would kexec the old kernel, with >> another (different) kernel param ... when the old kernel booted it >> would load the exact same initramfs image, except it would use an >> alternate tree, ie. instead of /init it would chroot to /previous and >> run /previous/init ... >> > > eh, for the priority of known sources of error: an UPDATE image could > contain the NEW kernel in an alternate tree /new/init, because the OLD > kernel is KNOWN to boot that far... yeah but when i update then kernel, i expect it to be updated ... not boot the old one next time i restart. i'm pretty sure you'd get all sorts of confusion over that. ... and the machine probably wouldn't work anyway because the module tree would be incorrect, though the ones in the initramfs would still be ok. since it's not really practical to actually boot the previous kernel (unless your using some kind of _system_ recovery mechanism like *cough* btrfs rollback), we're really just talking about a small recovery environment. lts kernel kind of works for this, but the last known good kernel is better ... i still think the best solution is to just drop some externalized hooks into the .install file for kernel package and let to community run with it. this eliminated developer burden/responsibility and allows flexibility for different implementations and different needs. maybe if we like some they can be added to standard repos in time. for example, a couple months back i was working on trying to get kernel rollbacks working with the mkinicpio-btrfs hook ... i needed a two-stage boot via kexec because the real kernel was inside a btrfs subvolume -- which bootloaders cannot yet access -- and it needed to be rebuilt with the real kernel. a simple drop in hook for this would have made things much much easier. so i say forget about versioned kernels and all that jazz because that's just one possible use. create something like: /etc/pacman/hooks.d/kernel26/ ... where kernel26 matches the package name. i haven't looked at the proposition for pacman hooks but this seems like it could serve as a small pilot to a more generic mechanism. ultimately this thread is not about "versioned kernels" but rather providing a way to link into the system management procedures performed by pacman, and do custom stuff. C Anthony
Re: [arch-general] Reboot - Versioned Kernel Installs
On Fri, Jun 10, 2011 at 8:29 AM, Vic Demuzere wrote: > On 10 June 2011 15:25, Paul Gideon Dann wrote: >> Also, I wonder what happens if power is lost whilst pacman is installing a >> new >> kernel? I haven't tried this, but it wouldn't surprise me if the system >> ended >> up with a truncated kernel that wouldn't boot. That's a bug right there, >> although it's a pretty tiny corner case, granted :) >> >> Paul >> > > Is that the case? The kernel should be replaced only after the new one > is ready, else it would fail if you pushed CTRL+C while updating the > kernel as well. > > Vic > paul, please check out https://bugs.archlinux.org/task/8585 for the power issue I really don't see how implementing this feature would give any more benefits to say installing an -lts kernel or some other kernel you know just works. On the other hand, I do see versioned kernels increasing the complexity of the system.
[arch-general] [signoff] kernel26-2.6.39.1-1
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 tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, Jun 10, 2011 at 4:59 PM, Bogdan Ionuț wrote: > On Fri, Jun 10, 2011 at 17:58, Tom Gundersen wrote: > >> On Fri, Jun 10, 2011 at 3:31 PM, Bogdan Ionuț wrote: >> > same for rp-pppoe users. >> >> Please file a bug about the missing dependency. >> >> -t >> > > https://bugs.archlinux.org/task/24639 Thanks! -t
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, Jun 10, 2011 at 17:58, Tom Gundersen wrote: > On Fri, Jun 10, 2011 at 3:31 PM, Bogdan Ionuț wrote: > > same for rp-pppoe users. > > Please file a bug about the missing dependency. > > -t > https://bugs.archlinux.org/task/24639
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, Jun 10, 2011 at 3:27 PM, Ignacio Galmarino wrote: > wicd stop working if you uninstall net-tools. Just a warning to wicd users :) Please file a bug about the missing dependency. -t
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, Jun 10, 2011 at 3:31 PM, Bogdan Ionuț wrote: > same for rp-pppoe users. Please file a bug about the missing dependency. -t
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, 10 Jun 2011 15:05 +0200, "Tom Gundersen" wrote: > On Fri, Jun 10, 2011 at 2:51 PM, James Rayner > wrote: > > The only reason net-tools was still a requirement was setting hostname. > > A change similar to initscripts [2] at line 121 of > > src/connections/ethernet [3] would suffice. > > What is the reason the hostname is set in netcfg? Do we ever want it > to change from what was set on boot? > > -t > Hostname is only set if someone specifies one in the configuration, otherwise it is left as is. I've never heard of anyone using this option. Judd's original netcfg script from 2005 included this option so I retained it when I wrote netcfg. James
Re: [arch-general] Alternative for Xyne's makerepo?
On Friday 10 June 2011 15:13:07 Vic Demuzere wrote: > Hi there, > > I used to host a pacman repository on dropbox, for myself and a few > friends. The easiest way for me to update this repo was Xyne's > makerepo. > > That project isn't supported anymore, so I'm looking for an > alternative. Something simple that can build and update a repository > (with AUR packages) using a package list. Suggestions? Hi, I wrote repoman time ago. It's a tool to manage your personal repo. Archers used it, but I don't get a bug from time (last is dated 12th Aprile 2010); I don't use it anymore (because I've no more my repo), but I'm still here to fix bugs. You could try it and see if it still works. See http://code.google.com/p/repoman-arch/wiki/Usage for usage. -- Andrea
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, Jun 10, 2011 at 16:27, Ignacio Galmarino wrote: > On Thu, Jun 9, 2011 at 3:01 PM, Heiko Baums wrote: > > Am Wed, 08 Jun 2011 16:01:15 - > > schrieb "Arch Linux: Recent news updates: Tom Gundersen" > > : > > > >> 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`. > > > > wicd stop working if you uninstall net-tools. Just a warning to wicd users > :) > > Ignacio > same for rp-pppoe users.
Re: [arch-general] Reboot - Versioned Kernel Installs
On 10 June 2011 15:25, Paul Gideon Dann wrote: > Also, I wonder what happens if power is lost whilst pacman is installing a new > kernel? I haven't tried this, but it wouldn't surprise me if the system ended > up with a truncated kernel that wouldn't boot. That's a bug right there, > although it's a pretty tiny corner case, granted :) > > Paul > Is that the case? The kernel should be replaced only after the new one is ready, else it would fail if you pushed CTRL+C while updating the kernel as well. Vic
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Thu, Jun 9, 2011 at 3:01 PM, Heiko Baums wrote: > Am Wed, 08 Jun 2011 16:01:15 - > schrieb "Arch Linux: Recent news updates: Tom Gundersen" > : > >> 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`. > wicd stop working if you uninstall net-tools. Just a warning to wicd users :) Ignacio
Re: [arch-general] Reboot - Versioned Kernel Installs
On Friday 10 June 2011 14:03:32 Yaro Kasear wrote: > On Friday, June 10, 2011 04:26:21 Robert Howard wrote: > > Why not just copy the old kernel image, modules and initrd image > > somewhere by hand before you upgrade kernels. If we try to make this > > automated it isn't going to be kiss. I used to do this way back in the > > day by including the entire kernel version in the pkgver and giving the > > images longer names. It was possible to have concurrently installed > > kernels. Check out how some of the AUR kernels manage to be the same > > kernel version as the official without causing issues. > > +1 on this. If you really need the old kernel, why not make sure you back > up the old one and its image before upgrading instead of inconveniencing > other users and the developers for a feature only a minority even wants? Because it's painful to go through that every time a new kernel update comes along. Also, I think you're underestimating the interest in this. This list will typically contain the most advanced Arch users, who are confident rescuing their system from a bad kernel upgrade. I'm sure there are plenty of Arch users out there that aren't reading this list, but for whom this feature could save them a lot of time and effort. Just because most of *us* can probably fix this in our sleep, doesn't mean it's right for Arch users in general. Also, I wonder what happens if power is lost whilst pacman is installing a new kernel? I haven't tried this, but it wouldn't surprise me if the system ended up with a truncated kernel that wouldn't boot. That's a bug right there, although it's a pretty tiny corner case, granted :) Paul
Re: [arch-general] Reboot - Versioned Kernel Installs
On Friday 10 June 2011 14:05:14 Yaro Kasear wrote: > Another agreement from me here. Also, may I also add that a great deal of > Arch users have /boot in a (tiny) partition to start with and can't really > KEEP that much stuff in there? Keeping old kernels would definitely screw > their systems up and keep them from upgrading with any ease. I have two kernels in /boot at the moment, and that takes 32MiB. My /boot partition is 200MiB, which is pretty generous as far as separate /boots go. That gives me room for 12 kernels. I'm not sure many would have a /boot smaller than 100MiB, and can't see *anyone* partitioning a /boot to less than 32MiB. I don't think space is a concern when we're talking about 2-3 kernels (current, previous, and possibly a custom build.) Paul
[arch-general] Alternative for Xyne's makerepo?
Hi there, I used to host a pacman repository on dropbox, for myself and a few friends. The easiest way for me to update this repo was Xyne's makerepo. That project isn't supported anymore, so I'm looking for an alternative. Something simple that can build and update a repository (with AUR packages) using a package list. Suggestions? Thanks, Vic Demuzere
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, Jun 10, 2011 at 2:51 PM, James Rayner wrote: > The only reason net-tools was still a requirement was setting hostname. > A change similar to initscripts [2] at line 121 of > src/connections/ethernet [3] would suffice. What is the reason the hostname is set in netcfg? Do we ever want it to change from what was set on boot? -t
Re: [arch-general] Reboot - Versioned Kernel Installs
On Friday, June 10, 2011 05:48:57 Vic Demuzere wrote: > On Jun 10, 2011 12:43 PM, "Martti Kühne" wrote: > > On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger > > wrote: > > > > > > > what if we (optionally) stored the original images _inside_ the new > > > one? the new/bad kernel would boot, and via some bootloader entry eg. > > > kernel param the new initcpio script would kexec the old kernel, with > > > another (different) kernel param ... when the old kernel booted it > > > would load the exact same initramfs image, except it would use an > > > alternate tree, ie. instead of /init it would chroot to /previous and > > > run /previous/init ... > > > > eh, for the priority of known sources of error: an UPDATE image could > > contain the NEW kernel in an alternate tree /new/init, because the OLD > > kernel is KNOWN to boot that far... > > > > Anything else would be insane. > > Having multiple kernels is insane. I don't get why it's needed. There is a > live cd to rescue your system if needed. > > Vic Another agreement from me here. Also, may I also add that a great deal of Arch users have /boot in a (tiny) partition to start with and can't really KEEP that much stuff in there? Keeping old kernels would definitely screw their systems up and keep them from upgrading with any ease.
Re: [arch-general] Reboot - Versioned Kernel Installs
On Friday, June 10, 2011 04:26:21 Robert Howard wrote: > Why not just copy the old kernel image, modules and initrd image somewhere > by hand before you upgrade kernels. If we try to make this automated it > isn't going to be kiss. I used to do this way back in the day by including > the entire kernel version in the pkgver and giving the images longer names. > It was possible to have concurrently installed kernels. Check out how some > of the AUR kernels manage to be the same kernel version as the official > without causing issues. +1 on this. If you really need the old kernel, why not make sure you back up the old one and its image before upgrading instead of inconveniencing other users and the developers for a feature only a minority even wants?
Re: [arch-general] Reboot - Versioned Kernel Installs
On Thursday, June 09, 2011 21:22:50 Timothy L. wrote: > On Thu, Jun 9, 2011 at 9:25 PM, C Anthony Risinger wrote: > > On Jun 9, 2011 5:50 PM, "Heiko Baums" wrote: > > > Am Thu, 9 Jun 2011 17:36:21 -0500 > > > > > > schrieb C Anthony Risinger : > > >> does this sound genius or completely insane? some insanely genius guy > > >> once said they are only separated by a fine line ... > > > > > > Sounds completely insane. > > > > ook ... and ... why? > > > > ) initramfs is not very big (fallback on my sys is only 13MB + 2MB kern) > > ) keeps the whole thing in mkinitcpio > > ) does not affect any current images and is even backward compat > > ) small chance of absolute failure (i think :-) > > ) only small changes to mkinitcpio, if any at all > > ) ... > > ) ... KISS BABY! > > ) oh yeah and ... PROFIT! > > > > im pretty sure it could be implemented as a hook (possibly 2) to the > > current system ... this might even be the best way. `install` hook > > would unpack the current image to a known location (prob > > `/lib/initcpio` somewhere), copy the kernel to the same place, and > > then add the directory to the image (after removing the old-old image > > if existed :-). the real `hook` would then check for one of two > > flags: > > > > ) kexec.flag ... kexec the old kernel with the boot.flag > > ) boot.flag ... chroot to "previous", run old hooks/mods/etc, exit > > chroot, switch_root like normal > > > > i thought it was pretty succinct ... elegant even :-) ... with some > > sprinkles of insanity that give it the funny but mildly enjoyable > > aftertaste. i don't have any free time for a couple days, but i'm > > *pretty* sure this could be done as a hook to the current mkinitcpio > > in a couple hours -- might take a whack at it this weekend, would be > > useful, as i've personally mucked my boot more than once, and though i > > can recover easily enough, i'm liking this more and more ... > > > > ... though i could very well be missing something obvious, certainly > > wouldn't be the first time ... surely someone out there reads this and > > thinks "why not?" > > > > C Anthony > > Keeping the previous kernel after upgrading sounds sane to me. For the > apprehensive, couldn't we just include a simple configuration option/check > somewhere? > > /etc/mkinitcpio.conf > KEEP_PREVIOUS_KERNEL="yes" > > I've read most of this thread but please excuse me if this has already been > mentioned. I'd accept that solution just so long as the default is set to "no" and not "yes." Most Arch people don't want old kernels.
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, 10 Jun 2011 08:19 +0200, "Rémy Oudompheng" wrote: > On 2011/6/9 Thomas S Hatch wrote: > > Does netcfg still need net-tools? or can it be an opt depends? It was my > > understanding that it only used ip unless specified otherwise. > > Actually, I think it only depends on net-tools because there is some > obscure option that allows users to make it run ifconfig with certain > options. Of course, it could be replaced by an option that runs ip > with custom options... All the remaining things are indeed done with > iproute2 > > Rémy. netcfg has an option that runs ip/iproute with any custom option (routes, IPs anything), the option is "IPCFG". It may be seen in the example ethernet-iproute[1]. IFCFG is the obscure command you mention, unfortunately it's not too obscure, as this was how static IPs were set before iproute configuration was added. It was retained for backwards compatibility. The only reason net-tools was still a requirement was setting hostname. A change similar to initscripts [2] at line 121 of src/connections/ethernet [3] would suffice. After that it ought to be safe to make net-tools an optional dependency. Systems already using net-tools will keep functioning, and a notice could be placed in code that handles IFCFG to advise those users to migrate to the iproute configuration. [1] http://projects.archlinux.org/initscripts.git/commit/?id=f262299928f1aca454a0bbadbcda144b3fb2e7e2 [2] http://projects.archlinux.org/netcfg.git/tree/src/connections/ethernet#n121 [3] http://projects.archlinux.org/netcfg.git/tree/examples/ethernet-iproute
Re: [arch-general] hwclock and openntpd
Paul, On Fri, Jun 10, 2011 at 1:05 PM, Paul Gideon Dann wrote: > I've found this gnawing at me since I read it. I originally started using > OpenNTPD because it was smaller, lighter, and easier to configure. However, > it's disappointing that it doesn't deal better with the hardware clock. > > Searching around for more information, I discovered that OpenNTPD is not > currently well supported for Linux, and the "portable" version that our > package is based on is lagging significantly behind the mainline. > > I've heard a few people mention Chrony as a good alternative, and I like the > sound of it. There's an AUR package, but no Wiki entry. Has anyone given > Chrony a shot, or have any strong opinions about it? I don't know about Chrony, but I was in the same situation as yourself when I found out about the status of OpenNTP. I tried installing the regular ntpd, and it was actully very simple to set up, and not particularly huge, so I'm using that. PS A solution for OpenNTP is to call "hwclock --systohc" when it stops. -t
Re: [arch-general] Reboot - Versioned Kernel Installs
Am Fri, 10 Jun 2011 12:48:57 +0200 schrieb Vic Demuzere : > Having multiple kernels is insane. I don't get why it's needed. There > is a live cd to rescue your system if needed. And the old kernel packages (every package) are saved in pacman's cache (usually /var/cache/pacman/pkg) anyway until pacman -Sc or pacman -Scc is run. So every package can easily be downgraded by running pacman -U /var/cache/pacman/pkg/. Of course, the pacman cache should only be flushed if the updated software is working correctly. There's no need for keeping old kernel images, even less included in a new and updated kernel image or initrd, however this would be possible anyway. Maybe there could be made an option in /etc/pacman.conf for the kernel package (a hook isn't needed) which tells pacman if it shall first copy /boot/vmlinuz26 to /boot/vmlinuz26.old. But this should definitely not be done by default for every user. And it's really not necessary to backup all old modules for being able to boot an old kernel for fixing the new one (see pacman -U above). The better and much cleaner solution is to first try the fallback initrd or to install a different kernel package like kernel26-lts parallel to kernel26. Keep in mind, those cases in which an updated kernel is unbootable are very, very rare. And people who need a reliable system and are so afraid of broken kernels, of course, shouldn't use [testing]. They should better install a multiboot system with one stable system and one test system. This way they can test kernel updates from [testing] on their test system and update the kernel on their stable system only if the test system is working correctly. This would, btw., help to filing bug reports for the kernels on esoteric hardware before they get into [core]. Heiko
Re: [arch-general] hwclock and openntpd
On Saturday 04 June 2011 08:44:34 Jan de Groot wrote: > On Sat, 2011-06-04 at 03:06 -0400, Yclept Nemo wrote: > > Perhaps openntpd does not set the hwclock. Therefore, should openntpd > > be used in conjuction with the hwclock daemon? > > That's true, and that's also the reason why Openntpd doesn't play well > with Xen where all guest VMs will take over the clock from the host VM. > With the normal ntp distribution that works, but with Openntpd you need > something to push the changes to the hwclock. I've found this gnawing at me since I read it. I originally started using OpenNTPD because it was smaller, lighter, and easier to configure. However, it's disappointing that it doesn't deal better with the hardware clock. Searching around for more information, I discovered that OpenNTPD is not currently well supported for Linux, and the "portable" version that our package is based on is lagging significantly behind the mainline. I've heard a few people mention Chrony as a good alternative, and I like the sound of it. There's an AUR package, but no Wiki entry. Has anyone given Chrony a shot, or have any strong opinions about it? Paul
Re: [arch-general] Reboot - Versioned Kernel Installs
On Jun 10, 2011 12:43 PM, "Martti Kühne" wrote: > > On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger wrote: > > > what if we (optionally) stored the original images _inside_ the new > > one? the new/bad kernel would boot, and via some bootloader entry eg. > > kernel param the new initcpio script would kexec the old kernel, with > > another (different) kernel param ... when the old kernel booted it > > would load the exact same initramfs image, except it would use an > > alternate tree, ie. instead of /init it would chroot to /previous and > > run /previous/init ... > > > > eh, for the priority of known sources of error: an UPDATE image could > contain the NEW kernel in an alternate tree /new/init, because the OLD > kernel is KNOWN to boot that far... > > Anything else would be insane. Having multiple kernels is insane. I don't get why it's needed. There is a live cd to rescue your system if needed. Vic
Re: [arch-general] Reboot - Versioned Kernel Installs
On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger wrote: > what if we (optionally) stored the original images _inside_ the new > one? the new/bad kernel would boot, and via some bootloader entry eg. > kernel param the new initcpio script would kexec the old kernel, with > another (different) kernel param ... when the old kernel booted it > would load the exact same initramfs image, except it would use an > alternate tree, ie. instead of /init it would chroot to /previous and > run /previous/init ... > eh, for the priority of known sources of error: an UPDATE image could contain the NEW kernel in an alternate tree /new/init, because the OLD kernel is KNOWN to boot that far... Anything else would be insane.
Re: [arch-general] Reboot - Versioned Kernel Installs
Why not just copy the old kernel image, modules and initrd image somewhere by hand before you upgrade kernels. If we try to make this automated it isn't going to be kiss. I used to do this way back in the day by including the entire kernel version in the pkgver and giving the images longer names. It was possible to have concurrently installed kernels. Check out how some of the AUR kernels manage to be the same kernel version as the official without causing issues.
Re: [arch-general] Bachelor thesis
> Fsck for btrfs seems to be a rather complicated for one person to study and implement. Nevertheless I will consider it. > Thank you Thomas. > I'm fairly certain that the btrfs fsck is being worked on already, but they could probably use any help you could give them. There is also the project to add multi-device, subvolume and compressed btrfs feature support to grub2.
Re: [arch-general] Bachelor thesis
Cituji Thomas Dziedzic : 2011/6/9 Marek Otahal : On Thursday 09 of June 2011 10:34:45 Luštický Josef wrote: Hello everyone, I'm Josef Lusticky and I'd like to write a Bachelor thesis about operating systems. I'm student of Faculty of Information Technology in Brno, Czech Republic and I have been using Linux since 2006 and Archlinux since 2008. I'm enthuasistic user of Arch and Linux in general and I'd like to help this project by improving or creating some stuff. I'd like to implement some driver or port of app. I know C, assembly and some scripting languages. Yes, I know there is the pacman package signing feature missing, but I do not consider it work for one person and I would rather work on something like userspace tools needed for kernel (e.g. filesystem tools, etc.). Can you recommand me something good for my skills? Best regards, Josef Lusticky Ahoj Pepo :) I just remembered your email from yesterday when I was crying about the fortune of kmobiletools. It is/was a great tool, but the development has ceased. Please see my wish: https://bugs.kde.org/show_bug.cgi?id=270266 and consider if you would like to work on that project? :) It's developed in C(++?), can touch driver issues (if you want), and definitely is highly popular and has good promises for the future. The old hackers are still around, so they should be able to help you with some details if you needed. It just crossed my mind so I gave it a try and pass the idea to you. Have a nice day, cau, Marek -- Marek Otahal :o) I've heard btrfs is still missing a proper fsck Fsck for btrfs seems to be a rather complicated for one person to study and implement. Nevertheless I will consider it. Thank you Thomas.
Re: [arch-general] Bachelor thesis
Cituji Thomas Dziedzic : 2011/6/9 Marek Otahal : On Thursday 09 of June 2011 10:34:45 Luštický Josef wrote: Hello everyone, I'm Josef Lusticky and I'd like to write a Bachelor thesis about operating systems. I'm student of Faculty of Information Technology in Brno, Czech Republic and I have been using Linux since 2006 and Archlinux since 2008. I'm enthuasistic user of Arch and Linux in general and I'd like to help this project by improving or creating some stuff. I'd like to implement some driver or port of app. I know C, assembly and some scripting languages. Yes, I know there is the pacman package signing feature missing, but I do not consider it work for one person and I would rather work on something like userspace tools needed for kernel (e.g. filesystem tools, etc.). Can you recommand me something good for my skills? Best regards, Josef Lusticky Ahoj Pepo :) I just remembered your email from yesterday when I was crying about the fortune of kmobiletools. It is/was a great tool, but the development has ceased. Please see my wish: https://bugs.kde.org/show_bug.cgi?id=270266 and consider if you would like to work on that project? :) It's developed in C(++?), can touch driver issues (if you want), and definitely is highly popular and has good promises for the future. The old hackers are still around, so they should be able to help you with some details if you needed. It just crossed my mind so I gave it a try and pass the idea to you. Have a nice day, cau, Marek -- Marek Otahal :o) I've heard btrfs is still missing a proper fsck Ahoj Marku, I have a good old Nokia 5110 :) and I am also not a KDE user although I have experiences with Qt programming. This is something I can recommend someone wanting to make a Bachelor thesis in Qt, but this project is not for me now. Anyway thank you for suggestion. Cheers!
Re: [arch-general] Bachelor thesis
Cituji Yclept Nemo : Also NILFS filesystem development is very slow and the project has a long todo list including some gui tools. Thanks for suggestion, this sounds good to me. I will definitively look at NILFS. Cheers.
Re: [arch-general] Bachelor thesis
Cituji Kirill Churin : 2011/6/9 Luštický Josef : Hello everyone, I'm Josef Lusticky and I'd like to write a Bachelor thesis about operating systems. I'm student of Faculty of Information Technology in Brno, Czech Republic and I have been using Linux since 2006 and Archlinux since 2008. I'm enthuasistic user of Arch and Linux in general and I'd like to help this project by improving or creating some stuff. I'd like to implement some driver or port of app. I know C, assembly and some scripting languages. Yes, I know there is the pacman package signing feature missing, but I do not consider it work for one person and I would rather work on something like userspace tools needed for kernel (e.g. filesystem tools, etc.). Can you recommand me something good for my skills? Best regards, Josef Lusticky netcfg http://projects.archlinux.org/netcfg.git/ needs much more love and it's ArchLinux project with direct benefit to Arch… Yes it is! I know of netcfg but I am more into C programming than scripting in Bash. Nevertheless I will also look at netcfg. Thanks for suggestion.
Re: [arch-general] Bachelor thesis
2011/6/9 Luštický Josef : > Hello everyone, > I'm Josef Lusticky and I'd like to write a Bachelor thesis about operating > systems. > I'm student of Faculty of Information Technology in Brno, Czech > Republic and I have been using Linux since 2006 and Archlinux since > 2008. > I'm enthuasistic user of Arch and Linux in general and I'd like to help this > project > by improving or creating some stuff. > I'd like to implement some driver or port of app. I know C, assembly > and some scripting languages. > Yes, I know there is the pacman package signing feature missing, but I do > not consider it work for one person and I would rather work on something > like userspace tools needed for kernel (e.g. filesystem tools, etc.). > Can you recommand me something good for my skills? > > Best regards, > Josef Lusticky > > netcfg http://projects.archlinux.org/netcfg.git/ needs much more love and it's ArchLinux project with direct benefit to Arch…
Re: [arch-general] Reboot - Versioned Kernel Installs
On Fri, Jun 10, 2011 at 3:17 AM, C Anthony Risinger wrote: > On Thu, Jun 9, 2011 at 8:25 PM, C Anthony Risinger wrote: >> >> ... though i could very well be missing something obvious, certainly >> wouldn't be the first time ... > > ... after 1/2 implementing this i suddenly realized a painful truth > that's probably already been voiced ... > > the kernel is *long-since upgraded* by the time _any_ hooks run ... > the original image is gone, the package is gone, all hope is gone, > fml. the hook saves the images just fine because they are in the > process of being created ... but the original kernel image ... not so > much :-( ... though with the help of the .install script as mentioned earlier, this could be remedied. what would be even better is if some kind of generic hook was added to the install points for the kernel only. not the same as full blown pacman hooks, but since kernel is a bit unique anyway i don't think it would hurt ... if the .install script sourced a known location, eg. /etc/pacman/kernel26.hook or something similar, then any of us would be free to implement backups however we wished. C Anthony
Re: [arch-general] Reboot - Versioned Kernel Installs
On Thu, Jun 9, 2011 at 8:25 PM, C Anthony Risinger wrote:
>
> ... though i could very well be missing something obvious, certainly
> wouldn't be the first time ...
... after 1/2 implementing this i suddenly realized a painful truth
that's probably already been voiced ...
the kernel is *long-since upgraded* by the time _any_ hooks run ...
the original image is gone, the package is gone, all hope is gone,
fml. the hook saves the images just fine because they are in the
process of being created ... but the original kernel image ... not so
much :-(
i don't know how this can work without hooks into pacman, anything
else i think of is too hacky ... even for me.
sorry guys, i tried :-( i finished the `install` script and realized
it soon after. my work follows for the benefit of children
everywhere.
C Anthony
# vim:set ft=sh:
install () {
SCRIPT="oldkernel"
local src dst obase fdesc fmode fgid fuid fmaj fmin
local okdir=".oldkernel-$(basename "${GENIMG%.img}")-${KERNELVERSION}"
mkdir -p "${TMPDIR}/${okdir}"
bsdtar -xf "${GENIMG}" -C "${TMPDIR}/${okdir}" --exclude
/.oldkernel --strip-components 1
cp -a /boot/vmlinuz26 "${TMPDIR}/${okdir}"
#FIXME: we should just keep the old file list around ...
# hack BASEDIR to build links correctly
obase="${BASEDIR}"
BASEDIR="${TMPDIR}"
while read -r src dst; do
IFS=$'\t' read -r fdesc fmode fgid fuid fmaj fmin <<<"$(stat
-c $'%F\t%a\t%g\t%u\t%t\t%T' "${src}")"
case "${fdesc}" in
'regular file'|'symbolic link')
add_file "${src}" "${dst}";;
'directory')
add_dir "${dst}";;
'fifo')
echo "pipe ${dst} ${fmode} ${fgid} ${fuid}" >> "${FILELIST}";;
'socket')
echo "sock ${dst} ${fmode} ${fgid} ${fuid}" >> "${FILELIST}";;
'character special file')
echo "nod ${dst} ${fmode} ${fgid} ${fuid} c ${fmaj}
${fmin}" >> "${FILELIST}";;
'block special file')
echo "nod ${dst} ${fmode} ${fgid} ${fuid} b ${fmaj}
${fmin}" >> "${FILELIST}";;
*)
echo "UNKNOWN FILE: ${src}";;
esac
done < <(bsdtar -tf "${GENIMG}" --exclude /.oldkernel |
sed "s,.*,${TMPDIR}/${okdir}\0 /${okdir}\0,g")
add_file /boot/vmlinuz26 "/${okdir}/vmlinuz26"
BASEDIR="${obase}"
}
help () {
cat <
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
Thx, ss does exactly what i want. On Thu, Jun 9, 2011 at 5:39 PM, Evangelos Foutras wrote: > On 9 June 2011 16:37, Wim Van Deun wrote: >> Is there also an alternative to netstat ??? > > ss :p >
