[arch-general] root $PATH via su - -c mc ??
OK so I guess /root/.bash_profile wouldn't be read by a script generated
login shell that feeds su - -c mc to the -e option of a konsole command,
since it's not considered an interactive login...
Which explains why the conditional PATH command I routinely put in my
.bash_profile scripts (not in .bashrc to prevent it being appended multiple
times):
if [ -d ~/bin ] ; then
PATH=${PATH}:~/bin
fi
doesn't add /root/bin to the default path of the resulting root mc session
in the resulting konsole window, like it does with a console root login...
IE:
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl:/root/bin
But since even a generic user's default system PATH variable includes the sbin
directories... IE:
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl
Why would the root mc shell resulting from the scripted su - -c mc wind
up with a PATH variable containing only:
/usr/ucb:/bin:/usr/bin:/etc
???
I know I can fix this by defining root's path in root's .bashrc, but I'd
have to give up on conditionally adding ~/bin in .bash_profile as every
subshell would overwrite it with the .bashrc assignment...
Suggestions anyone???
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
Re: [arch-general] UEFI secure boot
It would appear that on Jun 4, Alexandre Ferrando did say:
On 4 June 2012 22:27, Sudaraka Wijesinghe sudaraka.wijesin...@gmail.com
wrote:
If this is a poll, I vote Arch should require Secure Boot to be disabled
I choose a distro like Arch because it doesn't have a financial motive
and will not give into market pressures such as this.
If we want keep hardware vendors from forcing Secure Boot on us, we have
to send the message out that we don't want it. Paying a small price of
M$99 is not the way.
However as free software users, we will have to endure some hard time in
the coming days when getting new hardware.
Just my two cents.
Sudaraka.
I'd like to add something to what Sudaraka said:
Arch doesn't seems to have the same kind of user than fedora, Arch if
I don't remember it wrong, tends to be aimed for a competent user.
Such a competent user can disable secure boot in x86 devices. (ARM
devices doesn't seem a problem to Arch because we don't do ARM)
And to that it appears that on Jun 5, Lukáš Jirkovský did add:
Assuming the Arch Users are competent, I'd rather let them add an Arch
Linux key to UEFI without disabling Secure Boot. This way Arch would
work with Secure Boot with added security of no one messing with
bootloader in a harmful way.
Speaking as an Arch user who is just barely competent enough for Arch with
much dependence on google and Arch's most excellent wiki, I'd like to see
Arch continue to do what I see as one of it's strong points.
Yes it insists on it's users having a certain level of competence. But it
generally seems willing to include fairly detailed step by step tutorials
and guides in it's wiki, to help those with less (or outdated) technical
expertise become more competent.
So how about somebody who knows how to disable secure boot on x86 devices
post a good howto in the wiki (or if that would be reinventing the wheel, a
link to a good external guide.)?
And likewise, in case some Arch user should inadvertently acquire some PC
where somehow the firmware option to disable Secure Boot wasn't there. How
about somebody who knows how to add an Arch key to UEFI, posting a wiki
tutorial for that?
Speaking for myself, I know I wouldn't have a clue how to do either without
a good tutorial. And it's starting to sound like I'm going to have to know
how to do one or the other by the time I'm ready for new hardware...
My current desktop is from 2005, and it hasn't shown any signs of failing
{yet}... {{Please God let me find such a tutorial when it does fail...}}
--
| ~^~ ~^~
| * * Joe (theWordy) Philbrook
| ^J(tWdy)P
| \___/ jtw...@ttlc.net
Re: [arch-general] USB mounted into wrong directory
It would appear that on Apr 6, Guus Snijders did say: Op 6 apr. 2012 10:56 schreef Martti Kühne mysat...@gmail.com het volgende: On Thu, Apr 05, 2012 at 08:10:59PM +0200, Tom Gundersen wrote: Nothing should ever require you to disable automounting. The default should be not to mount new devices, anything else sounds like a bug to me. -1 I agree. If a Desktop application wants to automount devices, it's fine. Of course, it would be nice if the user keeps control over this. Besides the desktop environment automounting should *not* occur unless configured by the sysadmin. That way, everybody's happy and the system stays predictable IMHO. I'm glad to hear that's how the smart guys on Arch feel about it. It has been quite some time since I had a problem with it. It's quite possible that the faded memory was from a time before I tried Arch. It's certain that a similar issue of some pop-up wanting to help me deal with a CD or DVD I'd just inserted, annoyed me far more often than Thane ever did with am inserted sub stick... But that, likewise, hasn't happened in a long time. Guess I was just being nervous about nothing... -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
Re: [arch-general] USB mounted into wrong directory
It would appear that on Apr 4, Tom Gundersen did say:
On Apr 4, 2012 11:14 AM, David pixelsh...@gmail.com wrote:
Uh, is there any way to revert to old mapping?
I do not like the new one.
You'd have to check with udisks. My guess is that while reverting might
work for the time being /media is going away in the future as the old
implementation had issues (namespace and privacy in particular). If you
have concerns about the new approach I suggest raising them sooner rather
than later, before things become hard to change.
Pardon me for jumping in here, but you just reminded me that I read
somewhere that /media is going away. Can't say that THAT in it self bothers
me, since I don't use it. But I've been not allowing anything to auto-mount
usb devices for so long now that I've forgotten what (if anything) I had to do
to prevent it in Arch {or for that mater any of the other Linux that I
multi-boot...} My method of dealing with usb sticks/drives etc, is that if
root hasn't found the time to set up a custom fstab entry based on either
LABEL=UniquePartitionName for approved usb drives, or /dev/disk/by-id for
approved usb sticks, then only by getting root to proactively do something
about it do I want the durned thing mounted at all. My fstab method allows
for custom mount points where the user simply issues a mount mountpoint
and/or umount mountpoint command to access the approved device. I usually
do this from mc where the alt+enter binding will paste the mountpoint
dirname to the command line...
Anyway my only concern with the changes that are driving the demise of
media is that I'm hoping they won't result in automatic reactivation of auto
mounting tools that I don't want, don't use, don't understand, and mostly
don't remember how to disable...
Do you know if I'm going to have to go there again???
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
Re: [arch-general] Email via mutt+offlineimap+msmtp
It would appear that on Jan 15, Ralf Madorf did say: I don't understand why that much people are using MUAs without a GUI, anyway, a penfriend is blind, reading braille, a good reason to use a GUI free MUA. And a good reason to support email standards that are still friendly to plain-text clients... My original reason for liking alpine had to do with having gotten used to pine with a Unix login I had with a former employer... That plus NOT having good mouse manipulation skills (I feel a little like a 3yr old trying to color within the lines...) Along with NOT wanting my email client to automatically fetching content from the web (If I decide I want to actually view some stinking HTML mail the way the sender want's me to I can choose to pipe it through Firefox...) And then there have been a few times when I've managed to break something X needs, and having access to all my email resources from the console was then a wonderful thing. An Email I received yesterday was written with User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Debian testing and unstable are at 2.02-3 too. I don't think that Alpin will be dropped by major distros. I'm happy to agree. -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
Re: [arch-general] Email via mutt+offlineimap+msmtp
It would appear that on Jan 13, gt did say:
On Fri, Jan 13, 2012 at 05:14:13PM +0200, Mantas M. wrote:
On Fri, Jan 13, 2012 at 08:33:36AM -0500, Joe(theWordy)Philbrook wrote:
Pardon me for jumping in here, but if mutt isn't smart enough to
automatically use In-Reply-To: and/or References: headers on replies? Or
likes to add extra Re: (IE: Re: Re: Re:) to the subject header line?
{All of which is news to me BTW...} Then I gotta ask, why use it?
It *does* add In-Reply-To and References by default. It does *not* add
extra Re:s if one is already present. (It *does*, however, add Re: if
it has not been added yet; *all* mail programs do that.)
+1
I'm glad to hear it. Not being a mutt user I didn't know for sure...
I hadn't noticed the beginning of this thread. But it appeared that
Madhurya Kakati didn't know how to get mutt to do those things when he
responded to Alfredo Palhares' somewhat impolite complaint about those things...
Hence I offered an alternative.
Also, @ Joe Philbrook
Firstly, Alpine isn't maintained anymore.
see below...
Secondly, mutt is much more configurable and more help is available for
it on the net.
I'm glad to know that. If alpine, re-alpine, or some future fork of them
should stop being viable to me. learning to use mutt might be my only
alternative to giving up on email altogether. (I have yet to find a GUI
client I can stomach...)
Configuring mutt was a pain, but well worth it.
I did once consider mutt but I was having a problem with getting it
configured to suit my needs... And by then I was already hooked on most of
alpine's user interface.
It would appear that on Jan 13, gt did also say:
On Fri, Jan 13, 2012 at 07:14:38PM +0200, Mantas M. wrote:
On 2012-01-13 17:56, gt wrote:
Firstly, Alpine isn't maintained anymore.
There is a fork re-alpine, though.
Yeah, I know of that, but i heard of it, after i got hooked to mutt :)
And I note that as a multi-boot/multi-Linux-distribution user That the
alpine packages found in at least some of the distro's repositories
appears to be compiled from re-alpine sources since If I understand it
right, the last official Uwash alpine version was 2.00 yet for example:
~
UnderTree =- pacman -Ss alpine
extra/re-alpine 2.02-3 [installed]
The continuation of the Alpine email client from University of Washington
~
UnderTree =-
Since I tend to stick with package manager installed software, I can't tell
you how pleased I was when I 1st noticed that some pacman -Syu had upgraded my
Arch installation's alpine beyond version 2.00... ;-)
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
Re: [arch-general] Email via mutt+offlineimap+msmtp
It would appear that on Jan 13, Madhurya Kakati did say:
On 01/13/12 at 08:55am, Alfredo Palhares wrote:
Excerpts from Madhurya Kakati's message of Fri Jan 13 07:23:43 +0100 2012:
Mailed just to say that all of my problems have been resolved. It was a
weird
bug with mutt.
Yeah like, adding Re: on every fucking message and not using In-reply-to
or References tag, and break my fucking threads. No offense :)
Sorry for that. How do I configure mutt to use In-reply-to instead of adding
Re: to the subject?(if it is possible to do so.)
Pardon me for jumping in here, but if mutt isn't smart enough to
automatically use In-Reply-To: and/or References: headers on replies? Or
likes to add extra Re: (IE: Re: Re: Re:) to the subject header line?
{All of which is news to me BTW...} Then I gotta ask, why use it?
If it's because it runs in the console, then my real question is have you
tried alpine? It certainly does use those thread friendly Message-ID: based
reply headers and seldom {if ever} adds any redundant Re: tags to the
Subject: header line. It's also highly configurable with a comprehensive built
in help system. It can use local Linux mail spool and/or remote IMAP folders
(or even pop inboxes). It can be configured to use local sendmail or remote
SMTP servers. And it also does NNTP...
It comes with it's own editor/composer but can easily be configured to use
your choice of alternate editors (I use vim with it)...
Just a thought...
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
Re: [arch-general] Top Posting Revisited
It would appear that on Dec 19, Raghavendra D Prabhu did say:
In mutt, you cannot limit the quote context I guess and I
don't want to limit the context by manually deleting the lines
{snip}
For instance, while replying I make vim place cursor at the bottom
of quoted reply to ease in replying and also make vim fold replies.
Pardon me Raghavendra, But someone who is comfortable (and competent) enough
with vim to make it automatically place the cursor at the bottom shouldn't
find it hard to use -- VISUAL LINE -- mode to quickly crop out most of the
non-relevant content from a quoted message. So I guess the most relevant
part of your entire post were the words I don't want to... sigh
Speaking for myself I have to say that while I personally don't give a rat
whether someone does top, bottom, or in-line posting. I do care about whole
quoting... Though as long as the new {NON-quoted} text is significantly
longer than the combined total of all the quoted text then I tend to forgive
even that. And I should mention that I'm inclined to think that relevance
matters more than context when trimming. Though admittedly it wouldn't be
right to miss quote to the extent that someone who says they think all rabid
dogs should be shot on sight, as only that they think all dogs should be...
To conclude, it is not the theme of discussion with which I have an
issue but the tone.
Now here I'm inclined to agree. Even when they are busy picking on someone
for the horrible bandwidth wasting practice of whole quoting instead of
just the relatively trivial matter of posting on top of a {hopefully} well
trimmed quote, it's much more productive to do so gently. Perhaps to explain
why {in case the alleged offender simply doesn't understand yet} And even to
say 'please'... Whereas to jump in like a swat team on a sniper is only going
to make it more likely that the guy who might have been willing to conform
without agreeing, will instead stubbornly stand with his back against the wall
and fight, like it was as important to never give up as if it was part of the
great Emacs/Vi holy war or something... grin
--
| ~^~ ~^~
| * * Joe (theWordy) Philbrook
| ^J(tWdy)P
| \___/ jtw...@ttlc.net
But if I actually knew everything, then I'd know I was an idiot...
Re: [arch-general] end of the war! Mate has come to archlinux...
It would appear that on Dec 9, fredbezies did say:
If you have a nvidia chipset, you can use nouveau driver with gnome 3.
See Fedora for example ;)
Pardon me for intruding on your discussion fredbezies but I really wish
people wouldn't assume that nouveau works for everyone...
My current desktop is a winxp error HP Pavilion with embedded Nvidia
GeForce 6150 LE for which the nouveau driver as supplied by Arch, Xubuntu,
Sabayon, and OpenSuSE gave me unstable console screen and absolutely no X
until I switched to the proprietary Nvidia drivers... I remember it
because I usually prefer open source stuff. But I'm less likely to willingly
try nouveau again than I'd be to go back to kde4... And that's saying
something because I've been using mostly E17 (or sometimes E16) ever since the
demise of kde3's UI sent me packing. If for some reason I can't use E I fall
back on xfce. But from KDE{4} or gnome{any} I'll only use what I need to run
a few selected applications.
I'll admit I didn't try it with Fedora, But I gave up on them some time
ago...
Just an FYI...
--
|^^^ ^^^
|o o Joe (theWordy) Philbrook
|^ J(tWdy)P
| ___ jtw...@ttlc.net
sigh
Re: [arch-general] [arch-dev-public] gnome 3.2 in testing
It would appear that on Oct 2, Myra Nelson did say: On Sun, Oct 2, 2011 at 18:40, Joe(theWordy)Philbrook jtw...@ttlc.net wrote: Since the version of xorg in question is from testing I suspect I've nothing to worry about and that it wouldn't wind up in the main repo while its still incompatible. But since I know for a fact that my PC's built in Nvidia adapter is extremely incompatible with nouveau, I'd like to understand what and where this Ignorepkg is? Joe: Ignorepkg is in pacman.conf. Oh... Then I guess that for testing purposes users are expected to avoid updating those packages to the versions with compatibility issues with whatever the heck is currently being tested? In which case I'll fall back on my hope that it wouldn't make it to the main stream repos until the compatibility issue had been resolved... Thanks! -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] [arch-dev-public] gnome 3.2 in testing
It would appear that on Sep 30, Matthew Monaco did say that: On 09/28/2011 01:41 PM, Ionut Biru wrote: NVIDIA users be aware that xorg-server 1.11 from testing is incompatible with the current nvidia driver, even with IgnoreABI. You can switch to nouveau or add xf86-input-evdev xf86-input-synaptics xorg-server-common xorg-server to Ignorepkg. I didn't see Ionut Biru's post, and actually not being a gnome user I'm surprised I opened one from this thread. But the bit about NVIDIA users be aware kinda caught my eye. Since the version of xorg in question is from testing I suspect I've nothing to worry about and that it wouldn't wind up in the main repo while its still incompatible. But since I know for a fact that my PC's built in Nvidia adapter is extremely incompatible with nouveau, I'd like to understand what and where this Ignorepkg is? -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
Re: [arch-general] cups not starting on boot after last 2 kernel updates? -- where to put it in the DAEMONS line?
It would appear that on Aug 8, Peter Bui did say:
You have @cups in DAEMONS ... probably need @cupsd?
It would appear that on Aug 8, J. W. Birdsong did say:
You need to start cupsd in rc.conf daemons... not cups
It would appear that on Aug 8, David C. Rankin did say:
Peter, J.W. -- thank you. (slaps self for stupidity) That is a
'forest-for-the-trees' issue it would have taken days to see!
Hmmmnnn. Now I'm confused... According to my console login prompt, I'm
currently using 2.6.39-ARCH And after a recent pacman -Syu cups stopped
loading for me until I changed my Daemons line to say cups rather than cupsd.
There had, if I remember right, been a {is it 'rc.confpacnew' or
'rc.conf.pacnew'?} that didn't have cups listed in the daemons line.
Anyway I remember putting cupsd the new rc.conf first, and when that didn't
work I edited it to just say cups. I didn't think much about it at the time.
All I cared was that my printer worked again.
But why would one Arch Linux installation need cups in the daemons line
while another needs cupsd???
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
Re: [arch-general] OK so HARDWARECLOCK=localtime is strongly discouraged BUT???
It would appear that on Jul 13, C Anthony Risinger did say:
On Jul 12, 2011 8:19 AM, Joe(theWordy)Philbrook jtw...@ttlc.net wrote:
snip
Dude ... just set UTC and forget about it ... forever :-)
The wisdom of others frees time to build more wisdom of self.
Dde ... If my personality type was compatible with just doing things
the way others have decided were best just because it's easier I'd never
have fought my way out of Microsoft's grasp...
When I first heard of Linux I didn't find it easier than winblows. (And
except for the fact that I'm out of practice {and out of touch with changes
in their propitiatory interface} I still wouldn't find it EASIER) But what
attracted me to it was the power of the bash shell (which I had become minimally
exposed to via vt100 terminals connected to my former employers Unix
machines) And the idea that if I could only figure out how, I could make my
own durned decisions about how to set things up. A concept inspired by the
fact that a guy I delivered stuff to at the factory had imposed his will on
his Unix shell's command line prompt so that it read:
Gone fishing:
Well I didn't like his prompt. But I liked the idea of a user being able
to decide such things for himself. And that, more than anything else made
me decide I'd rather fight with *nix to get things the way I want than
learn to live with what MS wanted to spoon feed me.
Over the years I've made MANY non-standard adaptions to my Linux.
Like for example among multi-boot (as in more than one Linux distro) users
it seams the prevailing wisdom was to have one /home partition that gets
mounted regardless of which Linux you boot. But I've seen that sometimes
different Linux will have different versions of the same applications with
incompatible .rcfile formats... So when I got ready to do something like
that I created a user owned data partition that mounts (noauto,user) during
my .bash_profile execution with symlinks in the various distro specific
/home/jtwdyp directory trees...
I NEVER let anything automount or automatically open an application on a
removable filesystem upon insertion. But rather make it easy for user to
mount/umout the usual ones at will. IE these lines in my fstab:
/dev/disk/by-id/usb-USB_Flash_Disk_200803281952-0:0-part1
/Shuttle/gray auto user,noauto 0 0
/dev/disk/by-id/usb-TOSHIBA_TransMemory_5B860381-0:0-part1
/Shuttle/white auto user,noauto 0 0
/dev/disk/by-id/usb-USB_2.0_USB_Flash_Drive_64DDE527-0:0-part1
/Shuttle/mini auto user,noauto 0 0
/dev/disk/by-id/usb-Generic_USB_SD_Reader_2004888-0:0-part1
/Shuttle/Camera-SD-1 auto user,noauto 0 0
make it easy with mc to select {for example} the dir: /Shuttle/Camera-SD-1
type mount alt+Enter ENTER and use mc to access my latest images...
This method works even if I didn't start the gui...
In short {as if that were possible with me tehe} I have sufficient knowledge
of self to know that while I may sometimes have problems with implementing
my choices, while I seek sufficient understanding of the wisdom of others to
better evaluate my own choices, I myself will only ever change those choices
when it feels right to me. And thus I'm resigned to the fact that MY pc
will always be filled with a bunch of half understood kludges that at least
temporarily let me run things my way even when the developers took a
seriously different path... But the fact that I'm allowed to make my own
choices, even if they are not advisable, makes me love Linux, and be at
peace with my alleged place within it. Which is probably as blissfully zen as
I'll ever get... snicker
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
Re: [arch-general] OK so HARDWARECLOCK=localtime is strongly discouraged BUT???
It would appear that on Jul 12, Tom Gundersen did say:
On Jul 12, 2011, at 15:18, Joe(theWordy)Philbrook jtw...@ttlc.net wrote:
Whereas If I put ntpd -qg
in rc.local there is sometimes enough time to type my username before the
NTP based time adjustment can be seen to occur..
Yes, ntpd is run in the background and might take some time to sync. It
sounds like there might be a bug somewhere. You should not notice the ntpd set
unless your clock is way off which should only happen due to DST (twice a
year). Please check that your adjfile (/var/lib/hwclock/adjfile) is set to
LOCAL, to match rc.conf.
Actually I wouldn't notice the adjustment at all except that certain
system messages put things on the tty1 screen. So since I'm logging on to
the console instead of using some {Display Manager's} gui login screen,
there is {echoed?} to the screen a short oneline message about the
adjustment that includes several digits with a . in the middle that I'm
assuming is a reference to how big the change was. At that point I don't
have gpm working so lets pretend it says NTP: adjust RTC [012.001]
n which case if I were starting to login as jtwdyp I might see:
myhost login: jtwd
NTP: adjust RTC [012.001]yp
Password:
Or some such thing. So unless the ntpd called from rc.local is NOT supposed
to leave a message on tty1, I don't think that's a bug.
And for that matter, perhaps more importantly, I always thought that
hwclock was the mechanism that did the adjustment to/from localtime at
startup and shutdown...
It is.
Without hwclock, what process looks at the HARDWARECLOCK=localtime
setting and performs the adjustment to and from RTC localtime??
hwclock has two purposes: adjusting for timezone offset (this is unchanged)
and adjusting for drift (this is incompatible with ntpd/dualboot and is now in
a separate daemon).
So then, If I understand you correctly, IF I'm going to use hwclock to fix
RTC to localtime by including it in my daemons array, then I probably
shouldn't put ntpd in the array as well or sooner or later the two daemons
will be in conflict???
(and if so, is that incompatibility likely to manifest itself when
hwclock is deamonized and ntpd is called once at startup {via rc.local}??)
The way I see it, that if I'm going to keep my RTC set to local time, my
choices are:
1) deamonize both
(and let the daemons duke it out???)
2) deamonize hwclock and call ntpd in rc.local
(may have similar if less persistent issue as above)
3) deamonize ntpd and somehow call hwclock once at startup
(would ensure that some attempt was made to adjust for incorrect startup
system time due to local time being stored in the RTC, even if the internet
isn't available, but may have the same risk of conflict as #2 AND may need
to also somehow call hwclock at shut down to convert system time to
localtime before the RTC is updated?)
4) deamonize only ntpd
(But without hwclock how do I update the RTC with local time on shutdown?
OR does the term ntpd/dualboot refer to some configuration of ntpd where
it will somehow store localtime in the RTC on shutdown without having to
use hwclock???)
5) deamonize only hwclock and depend on my am habit of glancing at the
localtime value stored in the RTC via the bios setup screen, before the days
1st OS boot {and manually fixing if incorrect} to solve DST issues and any
{power off} RTC drift,etc... (of course this way my system time will never be
more accurate than the clock on my office wall..)
--
| ~^~ ~^~
| * * Joe (theWordy) Philbrook
| ^J(tWdy)P
| \___/ jtw...@ttlc.net
Re: [arch-general] OK so HARDWARECLOCK=localtime is strongly discouraged BUT???
It would appear that on Jul 11, Tom Gundersen did say:
On Mon, Jul 11, 2011 at 7:31 PM, Joe(theWordy)Philbrook jtw...@ttlc.net
wrote:
NOT dual-boot, Multi-boot, And I don't think in UTC see above
The more OS'es you have, the better reason to keep RTC in UTC. You
shouldn't need to _think_ about time at all... Anyway, if you want to
do it, I will not try to persuade you otherwise.
Thank you! To me it's a freedom of choice issue. It may not be the wisest
choice I could have made. But I drew this particular line in the sand a
long time ago. And while I might even change my mind someday, I would do so
only for my own reasons and NOT because the prevailing wisdom says it would
be the wise thing to do...
OK I'll buy that I do NOT want fsck to phsck up my filesystem...
The point is: The time in your system will from time to time be wrong,
and this might lead to weird things happening. Usually with fsck.
Speaking of which, I have occasionally seen fsck be forced due to
{I think it said} filesystems last access time in future or some such
thing. Is that the most severe weird thing likely to happen with fsck?
Hence my willingness to put ntpd -qg in rc.local and prevent system
time from FIXING my hardwareclock...
As much as I also don't like letting the internet set my system time.
(some things just shouldn't be totally automatic.) I mean if this
trend goes much further people will stop wanting to slice their own bread
anymore...snicker.
If you insist on having RTC in LOCALTIME, then the best thing you can
do is to set this value in rc.conf, and enable ntp (no need for
rc.conf, just enable the daemon).
Actually, I got the rc.local (not rc.conf) method from an Arch wiki
https://wiki.archlinux.org/index.php/NTP
in the section labeled Syncing the clock without running the daemon
Again I recognize that the prevailing wisdom is that daemonizing the
process is better... But longstanding preferences die hard.
This will work as well (or as badly) as it did before we added this
warning, nothing really changed.
For the record (for anyone else reading this): using LOCALTIME is
never the right thing to do (though it will work well enough most of
the time).
It would appear that on Jul 11, Buce did say:
See
http://mailman.archlinux.org/pipermail/arch-general/2011-April/019775.html and
other posts in that thread.
Which left a trail of breadcrumbs to the wiki url:
https://wiki.archlinux.org/index.php/Systemd#Why_does_systemd_not_support_the_RTC_being_in_localtime.3F
Which in turn did say:
= Recent kernels set the system time from the RTC directly on boot without
= using 'hwclock', the kernel will always assume that the RTC is in UTC. This
= means that if the RTC is in localtime, then the system time will first be
= set up wrongly and then corrected shortly afterwards on every boot. This is
= possibly the reason for certain weird bugs (time going backwards is rarely
= a good thing).
Lets see if I understand... With the recent kernels, The system is
initialized using the RTC as a UTC reference. Then (at some point) it would
notice the HARDWARECLOCK=localtime line in the rc.conf. In response to
which perform a math operation based on timezone data and then adjusts the
system time accordingly... ???
Am I right in thinking that any automatic fsck operation performed during
the boot {especially any such fscking of the root filesystem that is done
while it is still mounted read only} actually happens before the time gets
adjusted??
And that it is those fsck operations, rather than any manually commanded fsck
operations performed at other times on unmounted filesystems, that are most
likely to to be affected by those so called certain weird bugs?
Since I have for a long time kept my RTC set to localtime, did not have
NTP installed, and did have the time built into my tty login prompt.
(I boot to console then decide after login if when to run startx
{granted 9 times out of 10 times it's my first user command}) And this
initial time reference on tty1 has matched my local time, I'm thinking the
time adjustment that compensates for the RTC having been in localtime must
happen before the 1st login prompt is issued. Whereas If I put ntpd -qg
in rc.local there is sometimes enough time to type my username before the
NTP based time adjustment can be seen to occur...
IF I ran NTP as a daemon (simply by adding ntpd to the DAEMONS=() line
in rc.conf?) instead of simply calling it from rc.local, would it sync the
system time to the server before the first tty prompt was generated?
And if deamonized, would ntpd's syncing to the time server operation replace
the process of adjusting for the RTC being in local time, or would the time
still be adjusted by whatever mechanism does it without NTP and then
afterwards, would NTP adjust the system time again to more accurately sync
it to the NTP server's time???
And whether run as a daemon or a rc.local process (as described in the NTP
wiki
Re: [arch-general] OK so HARDWARECLOCK=localtime is strongly discouraged BUT???
It would appear that on Jul 11, jesse jaara did say: Check the systemd wiki page it has info for setting windows to UTC time It's not so much that Windows likes local time. It's that I insist on it... I MUCH prefer to manually set/verify the hardware clock's time with the bios set-up screen prior to loading an OS and I have no intention of having to mentally convert to/from UTC to see if it's correct. It would appear that on Jul 11, Thomas Bächler did say: Am 11.07.2011 17:20, schrieb Joe(theWordy)Philbrook: Since I multi-boot AND do keep my hardware clock set to local time, I'm a little bit concerned by this statement. It gives me two questions. This is no reason. Especially if you dual-boot, keeping the hardware clock in UTC is something to make your life so much easier. NOT dual-boot, Multi-boot, And I don't think in UTC see above 1) just what Known bugs that this could lead to are UNFIXABLE??? - Inconsistencies due to switches from/to DST. - Weird bugs (like in fsck) due to time changing during bootup. OK I'll buy that I do NOT want fsck to phsck up my filesystem... - Complicates travelling and changing time zones. - Whatever, think of anything involving your system clock, and using localtime will make it harder. Hence my willingness to put ntpd -qg in rc.local and prevent system time from FIXING my hardwareclock... As much as I also don't like letting the internet set my system time. (some things just shouldn't be totally automatic.) I mean if this trend goes much further people will stop wanting to slice their own bread anymore...snicker. OK OK I acknowledge that I'm stubborn... But I just realized: there may be a flaw in my plan to use ntpd -qg : You say the potential fsck bug would be due to time changing during bootup. Tell me that letting it get all the way to the login prompt And then letting ntpd -qg correct the time difference between NewYork and UTC isn't likely to mess with fsck... I'm thinking that an automatically run fsck based on the mount count and/or an unclean shutdown would be done before rc.local gets to run. And I'd have to type really fast to login and start a manually called fsck for ntpd -qg not to be done messing with the system time before fsck started. But I don't know for sure. Thanks -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
[arch-general] Nvidia?? (About to do pacman -Syu but:)
In preparation for a pacman -Syu I peeked at the main page and read: The nvidia-173xx and nvidia-96xx driver packages have been removed from our repositories as they are incompatible with newer xorg servers. This can only be fixed by an upstream update, which has not happened yet. For most video cards, the best alternative should be xf86-video-nouveau Since I know for a fact that my integrated Nvidia GeForce 6150 LE is very incompatible with the nouveau driver I'm suddenly concerned... according to pacman -Q nvidia I got: nvidia 270.41.19-1 Should I worry about it? That is should I find out how to prevent pacman from messing with the video driver, or does the 270.41.19-1 mean the above will have no effect on my nvidia driver? Thanks -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
[arch-general] boot loaders and the /boot partition. [was: Reboot - Versioned Kernel Installs]
It would appear that on Jun 12, Heiko Baums did say: Am Sat, 11 Jun 2011 23:07:00 -0400 schrieb Joe(theWordy)Philbrook jtw...@ttlc.net: Actually It's been a long time since I had actual boot failures with Arch... And if memory serves it wasn't the updated kernels fault, though I no longer remember what I'd done... You see, those cases in which a kernel update leads to a boot failure are very rare. ;-) I myself never doubted that. It's one of the reasons why it's currently my default boot choice. But as I've long been on a shoe string budget that does not allow me to be very selective with my hardware, I can't always be sure that my hardware won't be incompatible with some future change. Sometimes I manage to find a deal on used equipment. But I can rarely afford to be choosy. My current desktop was a gift from my brother in law who had just upgraded to something newer. And Arch Linux kernels are usually tested in [testing] and are only moved to [core] if there are no bigger issues found. And I think they do a pretty durned good job of it too... Well I call it grub legacy because that's what gnu.org is calling it now... That's what it's called. According to them the old grub has been replaced with a new version. Though I don't see it as an improvement. I think the only Distro I've got installed that really likes grub 2 is Ubuntu, But since I didn't let it use ext4, I can still even boot that with the classic grub. ☻ Which bootloader you need depends on your installation and hardware, not on the distro. There are at least 3 bootloaders (grub legacy, grub2 and syslinux) which have different capabilities and can't easily be replaced in any case. But all of them can handle ext4. Hmmnnn... Ah yes I see now, there have been patches etc... since I last looked at it. I notice that the instructions to use the patched ubuntu grub to boot an ext4 system seems to require adding the kernel option: rootfstype=ext4 Would that be required with the grub installed to Arch as well? I also note that: https://ext4.wiki.kernel.org/index.php/Ext4_Howto Says something about a Google Summer of Code project (from opensuse) under the topic of Booting from an ext4 filesystem and that it also mentioned that Ubuntu 9.04 and later includes a patch So I'm thinking that I might which version of grub I use might make a difference... I guess you would either call it just a grub partition Or perhaps you would have said boot partition without specifying which boot loader is installed there. I guess you meant the /boot partition. ;-) It is not that uncommon among multi-Linux-Distro, multi-booters to have a separate bootloader installed to the MBR from the ones each distro installed to their root partitions. Though the others I've heard about usually just select the appropriate chainloader entry for the Linux they want to boot, which in turn usually has a very short timeout before it automatically boots it's default entry. I myself rarely bother with the chainloader entries. They are mostly only there in case I goof when I edit the entries I normally boot from. This configuration also makes it easy to use a supergrub disc in the event that my normal boot partition gets corrupted as each installed Linux has it's own boot loader so all I'd need to tell supergrub is to boot the appropriate partition... I would completely remove the chainloaders. Make one /boot parition for every distro, but only install one bootloader from your main distro into the MBR. Don't let the other distros install a bootloader and just configure the one bootloader to boot the other distros, too. That's the easiest way which should always work. Yeah, if I wanted any distro to have control over the booting of the others. I let each distro maintain it's own (root partition based) grub installation so that I can simply (and easily) see what they think is the best way to boot their Linux. Sometimes they auto detect the other Linux. and sometimes the grub entries they add for the other Linux even work. But I like to keep control over the primary boot loader that I like to be able to chain load their boot loaders in case I want to confirm that some issue I'm having with one isn't a goof in my menu.lst configuration. Also,this way I don't need to bother maintaining fallback/recovery/nurse/etc... entries, If I need them I just use the ones their package manager installed to their chainloaded bootloader... Btw., if you let every distro install a bootloader into the MBR, the previously installed one will be overwritten. There won't be two different bootloaders in the MBR. It's been a long time since I had to set up my /boot partition. I'm not even sure which distro I used to do so. But basically I started with all the distro's using the /boot of their root partition, and all but one configured to install it to the first superblock of that partition. Then I tweaked
Re: [arch-general] Reboot - Versioned Kernel Installs
It would appear that on Jun 11, Heiko Baums did say: Am Sat, 11 Jun 2011 12:40:36 -0400 schrieb Joe(theWordy)Philbrook jtw...@ttlc.net: OK so lets see if I understand... I already maintain a manually configured grub legacy partition where each of my installed Linux have both a chainloader menu entry to whichever grub that Linux has installed to /boot on it's root partition, AND a regular menu entry that specified the initrd vmlinuz that I routinely copy to MY grub partition shortly after any kernel upgrade... So in the event that the new kernel was effectively broken that on MY hardware neither the chainloaded Arch nor the arch fallback menu entries were able to boot, I could then boot the not yet replaced last known good kernel and initrd directly from MY grub and then from a console root prompt: «assuming that the following tar.xz file is still there» pacman -U /var/cache/pacman/pkg/kernel26-2.6.38.6-2-x86_64.pkg.tar.xz And when I next reboot using the chainloader to where arch has it's grub installed, and selected Arch Linux it should boot that kernel with it's initrd AND it's modules would be where it expects them with the result that it should be as fully functioning as it was before pacman upgraded from it??? Principally, yes. Thanks! But are you really sure that it is the updated kernel package and not your grub installation or config which causes your boot failures? Actually It's been a long time since I had actual boot failures with Arch... And if memory serves it wasn't the updated kernels fault, though I no longer remember what I'd done... However I have experienced other Linux that no longer booted properly upon kernel upgrades... When my grub installation fails to properly boot one of my Linux, I immediately use the chainloader entry to get that distro's own grub. Having a back-up in case a new kernel doesn't work for me just feels like the right thing to do. And now I know (and will have notes) how to resolve that problem in the event that an Arch kernel upgrade ever does fail me. Thanks again! Your description sounds pretty weird to me. Above all, what is a grub legacy partition and why do you need chainload in grub legacy for booting a Linux kernel? And are you sure that grub legacy is the right bootloader for your uefi mainboard? Well I call it grub legacy because that's what gnu.org is calling it now... http://www.gnu.org/software/grub/grub-legacy.en.html http://www.gnu.org/software/grub/manual/html_node/Changes-from-GRUB-Legacy.html «Which incidentally is the kind of grub that Arch is using on my PC» According to them the old grub has been replaced with a new version. Though I don't see it as an improvement. I think the only Distro I've got installed that really likes grub 2 is Ubuntu, But since I didn't let it use ext4, I can still even boot that with the classic grub. ☻ I guess you would either call it just a grub partition Or perhaps you would have said boot partition without specifying which boot loader is installed there. It is not that uncommon among multi-Linux-Distro, multi-booters to have a separate bootloader installed to the MBR from the ones each distro installed to their root partitions. Though the others I've heard about usually just select the appropriate chainloader entry for the Linux they want to boot, which in turn usually has a very short timeout before it automatically boots it's default entry. I myself rarely bother with the chainloader entries. They are mostly only there in case I goof when I edit the entries I normally boot from. This configuration also makes it easy to use a supergrub disc in the event that my normal boot partition gets corrupted as each installed Linux has it's own boot loader so all I'd need to tell supergrub is to boot the appropriate partition... -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
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 li...@baums-on-web.de wrote: Am Thu, 9 Jun 2011 17:36:21 -0500 schrieb C Anthony Risinger anth...@xtfx.me: 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 | \___/ jtw...@ttlc.net
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
|\___/ jtw...@ttlc.net
* 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] 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 v...@demuzere.be: 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/package-file-name. 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 | \___/ jtw...@ttlc.net
Re: [arch-general] Reboot - Versioned Kernel Installs
really label all new hardware crappy until it's well supported? This is the kind of thing that caused me to become a ‘multi-Linux distribution’, ‘multi-boot’ kind of guy in the first place. When an upgrade «or my own dumb mistakes» break my system I like being able to simply reboot something else and finish anything I'm working on before I spend hours, or days, or even weeks just trying to figure out what broke... It's not likely that anything other than a hardware failure will shut down Arch AND Ubuntu AND PCLinuxOS AND OpenSuSE all at the same time... And for that I still have a laptop... But it would sure be nice to be able to keep using my favorite distro with a fallback kernel instead of having to boot one of the others. But I do have to agree that more than one fully functional old kernel is a bad idea. Though I don't have much trouble manually deleting the really old ones from Ubuntu's /boot dir... -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
Re: [arch-general] Lyx 1.6 vs. 2.0
It would appear that on May 31, Bernardo Barros did say: Hi, Is there a reason not to update Lyx 1.6 to 2.0? Or at least create two packages lyx1 and lyx? Is there known bugs there? I'm not sure if this applies to Arch. it might be just an issue with the binary provided in the repository for PCLinuxOS... Where I just did an apt-get upgrade a few days ago and wound up with LyX 2.0.0 And had some issues with the spellchecker and/or the preference settings for it. Most of which would not be an issue if I didn't sometimes have difficulty with using the mouse and/or if I LIKED sidebars. «I don't mind the spellchecker being sidebar style instead of the pop-up because the pop-up used to sometimes hide the context of the word in question.‥ BUT I can't seem to turn off the option to spell check continuously... And there isn't a keyboard shortcut to dismiss the sidebar.» However I did note that while the preferences say it's using aspell, adding a word to the dictionary does NOT put it in ~/.aspell.en.pws which I can edit to remove words I wish I hadn't added... (Thus it seems my PCLinuxOS copy of LyX will forever accept puleese as a legitimate alternative spelling for please cause I can't un-add it. And also added a hyphenated name «literally ‘Avant-garde’» to the dictionary to ensure I spelled it consistently. The Spellchecker on my PCLinuxOS copy of LyX 2.0.0 no longer recognizes that, even after I tried adding it again... You can find the discussion I started on the LyX user list at: http://thread.gmane.org/gmane.editors.lyx.general/70198 -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] Upgrading while using a package (WAS: Re: pacman -Syu -- then tons of kio and kbuildsycoca warnings. Bug or coincidence?)
It would appear that on Oct 14, Thomas Bächler did say: My recommendations: 1) If you are upgrading your desktop environment, exit your session, quit your login manager and upgrade from the text console. I advise to run pacman -Sywu from the desktop and when the download finishes, run pacman -Su from the text console. OK, pardon my intrusion, but NOW I'm curious... I can understand the advantage of running pacman -Su from a text console (By which I don't mean using ctrl+alt+F[1-6] while the gui is still running.). It just makes sense, especially when pacman is expressly not a gui app. I can also understand that it might be better to run pacman -Sywu first as a separate operation. But why run the latter from the gui??? 2) Put all kernel-related packages on --ignore until you are planning to reboot. If you are not going to reboot, a kernel update will have no effect anyway. As a general rule I always reboot after any pacman -Su operation. If I wasn't prepared to reboot, I wouldn't upgrade my system. -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] community/e-svn 51937-1 BROKEN? themes fail screen resolution fail etc...
It would appear that on Sep 16, Nicky726 did say: Dne Čt 16. září 2010 06:27:23 Joe(theWordy)Philbrook napsal(a): ---snip--- I'll followup to this thread if one of AUR's themes works for me. -or- if e17 respects xrandr resolution settings... I did followup with the info that some of the AUR themes worked for me and that E17 was respecting the xrandr command... This reminds me I did change screen resolution via an autorun script on E17 some time ago (when E17's resolution control showed only the default screen resolution). I can't find the script now, but simply running xrandr -s 1024x768 from terminal inside od E17 changes the resolution correctly. Running just xrandr should give you the list of supported resolution, if the desired one is not listed you have to add a modeline. When you have the correct xrandr call(s) tested, you can automate it by creating say change-resolution.sh (should go in your PATH I think): #!/bin/sh xrandr -s ... which you then set up to autorun in control center -- aplications -- aplication on start (hope I translated it correctly from my localization). Thanks! And your right xrandr -s 1024x768 is the correct command to set a 1024x768 screen resolution. But when I ran xrandr with no argument I found that it was the forth listed resolution thus since the alternative form xrandr -s index starts with zero, I saved myself 7 keystrokes when I originally added the command: xrandr -s 3 to my xinitrc-e16 files that get copied to ~/.xinitrc when I choose e16 on one of my installed linux distros... I went with the .xinitrc method because when I used xrandr from inside an already running e16 it worked except that the borders of any window I opened cheerfully started or ended (or both) outside the new desktop area. By running xrandr inside the .xinitrc it took effect just before e16 started, and so new windows were by default sized and positioned inside the desktop area. Now it's fairly likely that by setting a script up in what in my e17's localization is menu-settings-settings panel-apps-startup applications would accomplish the same thing. But since I use startx rather then some display manager to initialize X I'm used to the ~/.xinitrc method. But I thank you for the clue. It could happen that the linux developers might do something to make the use of display managers mandatory, then I'd have to try the autorun script method. Heck, Ubuntu kinda sorta have done so already. In order to get a runlevel 3 startup with my *xubuntu (*without having to wade through some gui, pop-up error menus) I had to install a simplistic display manager (slim) which unlike gdm kdm still respected the debian method of: = update-rc.d -f foobar remove = update-rc.d foobar stop 20 2 3 4 5 . If the rest of the linux distros (and available display managers) follow ubuntu's (and gdm's) example I might have to give up on startx. Till then, for me, it's the only wayto go... -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] Update: [semi-solved] community/e-svn 51937-1 BROKEN? themes fail screen resolution fail etc...
It would appear that on Sep 16, David C. Rankin did say: Since you seem to like e17 themes, don't forget to check: http://verdegal37.deviantart.com/gallery/ Agust does most of the themes for e17-stuff.org Well it's not so much that I LIKE themes, as that I strongly dislike the default theme (especially dark buttons that don't indicate which one the keyboard is pointing at. I can't blame the Rasterman for not wanting to spend the time to make keyboard navigation easier, he LIKES using the mouse, and he does an awful lot of work on the things he wants to do. But as long as I'm going to need to use themes to accomplish that I might as well find some that I like the panels, menus and pop-ups from. The main graphic don't matter as I use my own specific background images for each of my 12 task specific desktop areas... A glance at the background tells me if I'm in the right workspace... But more themes to pick over are always welcome. So thanks -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
[arch-general] community/e-svn 51937-1 BROKEN? themes fail screen resolution fail etc...
I just did a pacman -Syu And unfortunately I let it upgrade e17.
according to pacman -Ss enlightenment I now have:
community/e-svn 51937-1 (e17-svn) [installed]
e17 no longer cooperates with personal themes
I can select them, it remembers which theme is selected. But none of them
have any effect on the appearance which is locked in on the default theme
which is so dark that I can't even read the clock gadget And unlike my
chosen theme there is no visible indication of which button will
effectively be pushed if I press enter. (I'm a keyboard man mostly because
I can use the keyboard for hours and hours, but 5 minutes of wrestling with
the mouse is enough to cause my hands to start going numb...) So I NEED a
theme that highlights the button currently in focus to use e17 effectively.
It will let me change the screen resolution to one where I can read text
without a microscope, But once I do I'm unable to logout cleanly.
(It locks up and fails to save the configuration changes) While it's so
locked up I can use ctrl+alt+F2 to switch to another tty where I
can log in and do a ps -a to see enlightenment is running But it
doesn't respond to killall enlightenment... (Since I'm a startx user I can
switch to tty1 {where I ran startx} and kill the X server with ctrl+C)
I'm not really surprised (since it isn't listening to the theme) that my
gadget and shelf settings were forgotten. It did let me put them back.
(even if the clock is now useless) But at each and every change it
presented me with an error that there could be only one system tray???
What that had to do with putting the sound mixer gadget back on the
shelf I don't have a clue...
If it matters I'm using an HP Pavilion a1410n with Amd 64 Athlon processors
And an integrated Nvidia GeForce 6150 LE which didn't like the open source
nouveau driver at all. So I'm using a pacman supplied proprietary Nvidia
driver.
I'm just glad that I've also got e16 installed or I'd really be crying in
my beer. I don't suppose it's possible to roll back to the previous version
of e17?
Is anybody else having a problem with community/e-svn 51937-1 (e17-svn)?
Or is it just me? Any suggestions would be welcome... But I already tried
moving my ~/.e directory and letting e17 start with a fresh user profile.
But it still wouldn't let me save my changes if they included screen
resolution changes.
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
Re: [arch-general] community/e-svn 51937-1 BROKEN? themes fail screen resolution fail etc...
It would appear that on Sep 15, Christoph Rissner did say: On 09/15/2010 10:19 AM, Joe(theWordy)Philbrook wrote: community/e-svn 51937-1 (e17-svn) [installed] I'm also running that version (but on i686), without any problems. I'm using the default theme (is it Black White?), mostly because I think its acceptable and the Theme Selector doesn't show any alternatives :-). Is this thing working? Well If I didn't want to change the theme and screen resolution I'd not have found anything sufficiently wrong with it. Except for that odd error message I got whenever I added/removed a gadget to/from the desktop or shelf. Which since it did let me make those changes, I wouldn't have bothered to mention... I remember having an unreadable font problem when I first installed e17 and just digged out my list of font pkgs I had to install to get this fixed. IIRC e17 relies on some external fonts, but the PKGBUILD doesn't set the dependencies, but maybe thats fixed by now. Actually my fonts are ok. It's just that I have a high resolution graphics card/monitor combination and the default is to start at the highest possible resolution. which in this case is 1280x1024 which with my poor eyesight means I can't hardly read anything less than 18 point type without my reading glasses. And if I wear the glasses while looking at the screen my eyes start to water in less than a minute... All I need to do is to get the screen resolution set to 1024x768 and everything comes in to focus. If the Rasterman liked to bother with a visual indicator of which button the tab key had aimed the enter key at I'd just resign myself to doing a menu-settings-panel-screen-resolution to select 1074x768 every time I login. I mean I can always open an xclock whenever I want a time display. Have you tried to change your profile (Settings Panel/Settings/Profile)? I suppose I could try the illume profile... Next time I boot Arch I'll try it... Thanks for the suggestion. It would appear that on Sep 15, Nicky726 did say: Dne St 15. září 2010 11:08:10 Joe(theWordy)Philbrook napsal(a): ... Is anybody else having a problem with community/e-svn 51937-1 (e17-svn)? Or is it just me? Any suggestions would be welcome... But I already tried moving my ~/.e directory and letting e17 start with a fresh user profile. But it still wouldn't let me save my changes if they included screen resolution changes. ... Hello, Joe, I also noticed problems with the new release of E17 at my 32bit Arch. It seems, that there was some change upstream that broke compatibility with older themes/backgrounds/icons, so that they are listed in selections dialogs, but are not loaded. Rebuilding the e17-backgrounds, e17-icons and e17-themes packages from the AUR partially solves the problem, as more themes/backgrounds/icons can now be loaded, some still remains broken though. I've also seen the resolution being reset to default, but in my case the switch to desired one was flawless and logout succeeded (OSS ati drivers). Hope, this will be of some help, Actually though I hadn't thought my themes were that old. True, some of them were based on the style of some older themes but they were rewritten... None of these are work anymore on my Arch installation: :r!ls ~/.e/e/themes blingbling.edj eChrono-0.5.edj GreenTheme.edj Kandy.edj trekpad17.edj Vulcan_Moonlight_0_6_4_by_Ndjee.edj Vulcan_Retro_0_6_4_by_Ndjee.edj Vulcan_Retro_Blue_0_6_4_by_Ndjee.edj wendy17.edj It's those Vulcan themes that give me the best combo of, highly visible indications of active buttons and menu choices. (Which matters because I navigate menus with my arrow keys NOT the durned rodent.) I suppose I'll have to try the AUR themes. Maybe one of them will work for me. Incidentally, Logout only fails if I alter my screen resolution. (At least so far...) I suppose that part could have something to do with the Nvidia upgrade that accompanied the Enlightenment upgrade... I'll have to see if XFCE can still set the resolution to 1024x768 And save it's settings for next time... There is a possibility that I could take a page from the workaround I did for E16 which being more WM than DE doesn't have a native screen resolution setting tool, and put xrandr -s 3 in the file that gets copied to ~/.xinitrc when I select e16 from my startx wrapper script. But since E17 DOES have an internal control for screen resolution, I expect that it will simply reset it back to it's default 1024x768 setting upon startup. sigh I'll followup to this thread if one of AUR's themes works for me. -or- if e17 respects xrandr resolution settings... Thanks guys for info suggestions. -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
[arch-general] Update: [semi-solved] community/e-svn 51937-1 BROKEN? themes fail screen resolution fail etc...
Well I found out that e17 is responding to an xrandr command in the ~/.xinitrc upon startx... So I don't need to use e17's native screen resolution utility... Thus I can get my 1024x768 screen resolution in an automatic fashion that still lets me log out cleanly... I also installed those AUR e17-themes and SOME of them worked. (more or less) Though with most of them, Once I apply them, I can no longer initialize the theme switching tool without a crash. But fortunately I had the forethought to backup the bad ~/.e directory which did at least let me make some changes, including using the theme switcher... mc made it easy to copy it back in between e17 test runs. And I found a few themes that do make it easy to see which button has the keyboards focus. Kind of like blingbling does only without having to squint to spot the outline. Two of the best at that are dali41b and japan2007, The latter being more aesthetically pleasing, and I think slightly more stable at letting me make more changes without crashing. But it's clock gadget is not for me. And while it's shape is a little twisted, I CAN read the formers clock. I find that I can add gadgets to the shelf, But if I try to add one to the desktop it crashes. (Fortunately the ones I care about are already there) So while it still isn't quite right, and I still can't use my preferred themes, at least two of the AUR themes are acceptable. And the xrandr workaround works well enough so that I'll manage until the next upgrade anyway... Thanks again for all the helpful suggestions -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] rc.conf man page
It would appear that on Aug 26, Dave Reisner did say: On Tue, Aug 24, 2010 at 01:35:33PM -0400, Joe(theWordy)Philbrook wrote: As a mere arch user who happens to think that the concept of well commented configuration files such as Arch's rc.conf are WONDERFUL. Especially when they include examples for beginners and those of us who have difficulty remembering. ;-7 My only concerns about having a man page is that eventually the configuration file (in this case rc.conf) might gradually become less well commented, or it's comments become outdated. And that man pages tend to be long on highly technical explanations that I for one have a hard time understanding and are often short on examples. So rather than having the rc.conf refer to a man page for instruction on how to use it. I'd much prefer that the primary method of guidance remain in the rc.local and perhaps include in any man page a url from which one can download a current rc.local.example file. I don't follow -- how does relocating comments to a man page make them inherently any more technical? If you have specific concerns about the verbiage I've used, I'm happy to address them. Please don't misunderstand me to mean that I take exception to the your verbiage. In fact _IF_ I had to depend on a man page rather than a well commented rc.config file someday, I rather hope the man page is very much like yours. I'm not opposed to the idea of leaving them in the file itself as well, but as brought up earlier, it then exposes the chance for the man page and the comments to be out of sync. I'll propose a middle ground -- syntax exists in both places (as its much less likely to change), but more detailed explanations are provided only in the man page. Now that might be good. A man page should have fully detailed explanations as well as syntax (and I think at least some examples)... Where as an actual config file should be rich in commented out examples but as far as explanations go, I think concise one liners that rely on the examples to impart a goodly part of the instruction, are the way to go. Especially if it's practical to include in the config file a hint that the man file exists... I also think that the idea of including in the man page a url to an example config file that is as 'up to date', and as 'in sync' with the man page as possible, would be a good hedge against the mutable nature of the config file. My feelings about man pages (and info documents) in general, stem from years of scratching my head while trying to figure out how to do one unfamiliar task or another with only such documentation to go by. I would not really be surprised to find that most of the man pages found on an Arch system might well be better written than the ones that made me feel like they were meant to impress some professor rather than to impart knowledge to those that don't already have a good grasp of the subject. I know the Arch wiki at least does a real good job of imparting knowledge (once you find the right document)... Which makes me wonder if at the end of the man page, in addition to a url for a current version of the commented config file, would it possibly be a good idea to also reference any applicable wiki pages? -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
[arch-general] yaourt: aur-tovid-svn/./PKGBUILD: line 34: ./bootstrap: No such file or directory
I tried to install the svn version of tovid from the aur with yaourt... Something went wrong. I looked in the terminal buffer and found this line: /tmp/yaourt-tmp-jtwdyp/aur-tovid-svn/./PKGBUILD: line 34: ./bootstrap: No such file or directory Yet the process ended like this: Proceed with installation? [Y/n] y checking package integrity... (1/1) installing tovid-svn [] 100% == Checking vote status for tovid-svn You have to create ~/.config/aurvote with inside: user=YOUR_AUR_USERNAME pass=YOUR_AUR_PASS To create a new account just go to: http://aur.archlinux.org/account.php JtWdyP - /home/jtwdyp which tovid which: no tovid in (/home/jtwdyp/bin1st:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core:/home/jtwdyp/bin:/home/jtwdyp/bin2nd) JtWdyP - /home/jtwdyp which tovid-svn which: no tovid-svn in (/home/jtwdyp/bin1st:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core:/home/jtwdyp/bin:/home/jtwdyp/bin2nd) JtWdyP - /home/jtwdyp yaourt -Ss tovid-svn aur/tovid-svn 2619-1 [3265-1 installed] (26) A suite of utilities designed to make VCD, SVCD, and DVD authoring a little less painful JtWdyP - /home/jtwdyp The complete terminal buffer text of the process is pasted below... I note that my first installation attempt failed because I hadn't installed subversion (which should have been a dependency???) And the command svn wasn't found... One odd thing. The last time I used yaourt once prior to this, once the package was compiled, it wanted my root password to finish the install. This time yaourt never asked for it??? What am I doing wrong??? -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net JtWdyP - /home/jtwdyp yaourt -S tovid-svn == Downloading tovid-svn PKGBUILD from AUR... bsdtar: Removing leading '/' from member names x PKGBUILD First Submitted: Sat, 19 Apr 2008 08:08:16 + tovid-svn 2619-1 : A suite of utilities designed to make VCD, SVCD, and DVD authoring a little less painful ( Unsupported package: Potentially dangerous ! ) == Edit PKGBUILD ? [Y/n] (A to abort) == == n == tovid-svn dependencies: - mplayer (already installed) - mjpegtools (already installed) - ffmpeg (already installed) - python (already installed) - wxpython (already installed) - cairo (already installed) - pycairo (already installed) - imagemagick (already installed) - dvdauthor (already installed) - dvd+rw-tools (already installed) - vcdimager (already installed) - transcode (already installed) - sox (already installed) - normalize (already installed) - pil (already installed) - txt2tags (already installed) == Continue building tovid-svn ? [Y/n] == --- == == Building and installing package == Determining latest svn revision... - Version found: 3265 == Making package: tovid-svn 3265-1 (Wed Jul 28 16:46:32 EDT 2010) == Checking Runtime Dependencies... == Checking Buildtime Dependencies... == Retrieving Sources... == Extracting Sources... == Entering fakeroot environment... == Starting build()... Atovid/tovid Atovid/tovid/AUTHORS Atovid/tovid/src Atovid/tovid/src/makempg Atovid/tovid/src/tovid-stats Atovid/tovid/src/set_chapters Atovid/tovid/src/tovid Atovid/tovid/src/todisc Atovid/tovid/src/todiscgui Atovid/tovid/src/tovid-init.in Atovid/tovid/src/titleset-wizard Atovid/tovid/src/pytovid Atovid/tovid/src/makexml Atovid/tovid/src/idvid Atovid/tovid/src/tovid-interactive Atovid/tovid/src/tovid-test Atovid/tovid/src/makemenu Atovid/tovid/src/tovid.ini Atovid/tovid/src/tovid-batch Atovid/tovid/src/todisc-fade-routine Atovid/tovid/src/pymakexml Atovid/tovid/src/postproc Atovid/tovid/src/makevcd Atovid/tovid/src/makedvd Atovid/tovid/src/pymakemenu Atovid/tovid/src/make_titlesets Atovid/tovid/ChangeLog Atovid/tovid/setup.py Atovid/tovid/docs Atovid/tovid/docs/html Atovid/tovid/docs/src Atovid/tovid/docs/src/en Atovid/tovid/docs/src/en/tovid.t2t Atovid/tovid/docs/src/es Atovid/tovid/docs/src/es/postproc.t2t Atovid/tovid/docs/src/es/makedvd.t2t Atovid/tovid/docs/src/es/makexml.t2t Atovid/tovid/docs/src/es/idvid.t2t Atovid/tovid/docs/src/es/makemenu.t2t Atovid/tovid/docs/src/es/tovid.t2t Atovid/tovid/docs/src/README Atovid/tovid/docs/sphinx Atovid/tovid/docs/sphinx/conf.py Atovid/tovid/docs/sphinx/libtovid Atovid/tovid/docs/sphinx/libtovid/deps.rst Atovid/tovid/docs/sphinx/libtovid/encode.rst Atovid/tovid/docs/sphinx/libtovid/util.rst Atovid/tovid/docs/sphinx/libtovid/stats.rst Atovid/tovid/docs/sphinx/libtovid/render.rst Atovid/tovid/docs/sphinx/libtovid/media.rst Atovid/tovid/docs/sphinx/libtovid
[arch-general] A question about using tar... ( -p --numeric-owner)
I'm a multi-linux-distro/multi-boot guy. I always have more than one configured linux distro on my grub menu. Whenever I'm considering radical changes to one of my working linux I like to back it up. Quite some time ago I learned to do this with tar. For example I've got both Arch Linux and Xubuntu on this desktop pc. I've decided to attempt using a network upgrade process to upgrade the Xubuntu from Karmic to the current Lucid release. So first I boot Arch, mount a storage drive on /mnt/other, mount the Xubuntu partition on /mnt/xubuntu. Then cd to /mnt/xubuntu. (with a root shell of course) # tar -czf /mnt/other/xubuntu.tgz -p --numeric-owner . And of course if it's necessary I can restore the backup to an empty partition with: # tar -xzf /mnt/other/xubuntu.tgz -p --numeric-owner . But I only partially understand the -p and --numeric-owner options. I do know that -p is supposed to be default for root but I like to make sure... I think I understand that the reason somebody told me (quite some time ago) to use --numeric-owner is because (in this example) Arch may have different user id numbers than Xubuntu which could have bad results if it tried to apply permissions based on user names (especially if it involves a system account)... What I don't know is if either of these options are necessary during the tar -czf operation, or if I only need to bother with them when/if I restore a file system with tar -xzf ??? I know it does work the way I expect it to when I use the options for both the -czf the -xzf operations. And that I don't get any error messages from tar when I do it that way. But I don't know if using them for the -czf operation makes any difference or not. Would someone be so kind as to set me straight on this??? -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
Re: [arch-general] Getting firefox to use the PDF I want?
It would appear that on Jul 21, Magnus Therning did say: After installing Gimp it became the default application for PDFs, something I didn't really want. snip How do I get firefox to use the correct application? It would appear that on Jul 21, Nilesh Govindarajan did say: Firefox-Edit-Preferences-Applications It would appear that on Jul 21, Magnus Therning did say: Ah, forgot to mention that I've looked there already. There is no mention of PDF there, and I can't find a way to add an entry to it. snip But where, and how do I change the settings? I used the search box inside Firefox-Edit-Preferences-Applications to pull up what to do with pdf and was then able to set it to okular. But then I no longer get the selection pop-up that would let me override the choice and use evince if I wanted to... And if I select always ask the pop-up doesn't offer okular except by clicking my way to the search box where I need to point or type the full path. IE: /usr/bin/okular rather than just okular So I decided to just set it and forget it. Hope this helps. -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] How up to date does pacman keep Enlightenment(e17)???
It would appear that on Jul 19, David C. Rankin did say: On 07/19/2010 12:10 AM, Joe(theWordy)Philbrook wrote: I can't change it's appearance (except to the extent of accepting a theme's default changes) I can't add or remove gadgets to/from the shelf. I can't change the size of the shelf. I can't change it's position from bottom center to any other setting. E17 is really recent. I have e-svn 49942-1 which is only 80 or so commits behind the current svn tree. That's only about 10-15 days behind today. It could be that the other distros where this still works properly are NOT as up to date... E17 IS still under heavy development after all and subject to such things... When I started E17 tonight to check out what you reported, I encountered an error about the 'conf_exebuf' module not being found and asking if I wanted to unload it -- I did. Yeah, I forgot that I had to add the exbuf module manually. And then I think it must have not worked properly as I pointed my keyboard shortcut at xfrun4 from my xfce desktop... We will need an E17 update from whoever builds E17 for arch. When I opened the Themes dialog to change from the Genesis theme (good by the way), E17 froze. That hasn't happened to me in a while. So it looks like the current Arch build has a few bugs that will hopefully be cured with the next package. Well when it comes to themes I tend to use personal themes downloaded from somewhere... I'm partial to the various vulcan themes by somebody named Ndjee because they make it _easy_ for a keyboard oriented users to see which button or menu choice will happen if enter is pressed. And I like to set the pager module to Kandy because when switching desktop area's I can easily spot which desktops have open windows, And in fact can even so do by squinting at the pager gadget on the shelf when NOT in the middle of a switch... If you want to stay up to the present with your E17 desktop, you can build it yourself from svn painlessly with the easy_e17.sh script. http://exchange.enlightenment.org/application/show/134 The script basically does it all for you. It downloads/updates the latest source packages and then builds e17 for you. I've used it before and liked it. Once you go through the first download, all the remaining updates are fast as you are just downloading changes. Give it a go if you want to see if your issue is fixed already. As I mentioned I've got some painless work arounds in place, so I think I'll stick with the pacman (and apt-get on the other distros) versions until and unless I get a true show stopper I can't get around. As a multi-linux multi-boot user, I'm VERY addicted to using the provided package management tools because if I do much custom configuring on my asst. Linux, I'd never have the time to actually use the PC for anything but reconfiguring it... In any case I thank you ( and others like you ) for making it so that most of the time all I need to understand is how to pacman, apt-get, yum, zypper, etc... as applicable to whichever distro is currently installed. Actually I tried easy_e17.sh twice before on now defunct desktops machines. Once it worked just fine. The other time I couldn't get it past some important package that wouldn't install... -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] Blanks screen after boot
It would appear that on Jul 8, Philipp did say: Hey, I have this problem since a while but it got a lot worse with the last two kernel versions. Now there's an about 50/50 chance to see the user login or simply not see it. I don't have any login manager set up, so after boot there's simply the user login and after that I issue startx. It all works just fine,even if I can't see a thing, and once I issued startx everything goes back to normal, the screen isn't blank anymore. The machine has an Intel chipset, and I guess it's related to that and/or KMS, but that's as far as my guess goes. Maybe one of you knows something about that kind of issue? Don't know for sure but it sounds a little like the problem I just had with my video driver... And my problem was definitely related to KMS... Do you by chance have an Nvidia graphics card??? In my case I have a new/used (new to me) PC with on board Nvidia. It's my first Nvidia and I was caught by surprise when the open source driver didn't work for me. And since it's designed for KMS it was being deployed before I'd even installed xorg... This put me in a blank screen where if I carefully typed the keystrokes I could log in to a console and issue commands. But I couldn't see anything. I have no idea what this would do to the X session you would initialize via startx, But as far as the console mode part goes it was suggested that if I used the kernel option nomodeset when I booted, I might get a more usable console session. And for me it worked long enough to find out that I really needed the proprietary nvidia driver. You can see more details of my experience by reading the thread I started on Jul 4th 2010 with the subject line of: screen goes blank on reboot after 1st pacman Su of new install!!!??? Hmmnnn I just noticed that I said pacman Su on that subject line rather than pacman -Su... Just goes to show that my brain is less than perfect. Hope this is of some help anyway. -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] screen goes blank on reboot after 1st pacman Su of new install!!!???
It would appear that on Jul 7, Myra Nelson did say: Joe: I gave up on gpm in a terminal before x is started. I never could manage to get to work right. Whereas I've almost always got gpm working... In fact I had it working on this install (right after blacklisting nouveau, got me a semi-usable console, right up until I installed nvidia. (sigh) But for anything short of boot screen error messages, I can redirect or tee into a file and use vim's :r command to include anything I really want. It's just such a pain that way... The other thing I've noticed about the onboard graphics is some manufacturers seem to modify the drivers slightly. I had one laptop with ATI onboard and the only drivers I could make work were the ones from the laptop manufacturer. Now why doesn't that surprise me??? Glad you got it working, mostly at least. Me too! Heck now that it's working, I've had time to fully configure xfce, e16 my operational favorite, e17... Course I may like _USING_ e17 best, but configuring it is always a chore. For example this time the keyboard shortcut assignment tool kept ignoring the keyboard (2 out of 3 times) when I'd want to set up shortcuts to exec things like: xterm -bg darkviolet -fg green -fn 12x24 -geometry 92x30 Fortunately I figured out that I could use the mouse pointer to mark the syntax example that always needs to be deleted, then a right click on the marked text let me cut it, and finally by switching to a terminal window with an editor session open, I could create the text of the command there, and then mark it with the mouse, switch back to the semi-functional shortcut routine and paste the text it wouldn't let me type... sigh But I can't complain too much, Once I manage to get it configured to taste, E17 has always been a pleasure to use... At this point I've got Arch sufficiently squared away for me to consider making my next project installing Xubuntu an another partition... But not tonight! Thanks again to everyone who offered advice... -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] screen goes blank on reboot [etc...] {mostly} [SOLVED] I think...
It would appear that on Jul 5, Joe(theWordy)Philbrook did say:
I'm still hoping that the issues I'm having with mc etc... are related to
nomodeset rather than deeper issues. I ran a few empirical tests BTW and
fount that if I start mc before I access more than 2 or 3 tty[1-6] consoles
it will start. And I discovered that if I don't try to execute a subshell
at all from any of them I can log in to all six console screens and have
my .bash_profile get processed. But once I start spawning subshells, all
bets are off.
--snip--
But anyway since it doesn't look like nouveau will work properly in
console mode for me, I tried black listing it... Then probably, I thought,
I'll have to follow the instructions in the Nvidia wiki entry when I try
to get x working. But I found that I'm still having issues in the
consoles with respect to subshells and mc. I'm beginning to think I'd be
better off reinstalling with the 64 bit iso... It won't likely solve the
nouveau issue, but I might get back fully functional console logins.
Well I did that. But the 64 bit version was having the same problem with
the consoles... UNTIL: After I installed nvidia (which required the xorg
server) So I went right on ahead and added all the pacman -S commands
suggested in the beginners guide for installing X plus xfce4, then
followed the install instructions in the enlightenment e17 wiki
pages... added a couple of things I was sure to need and rebooted
All the console issues with failed .bash_profile executions and problems
with subshells and mc all went away. Probably they were symptoms of not
having a working video card driver in place???
On another note however, I had managed, just prior to installing nvidia,
to get gpm working in the console via gpm -m /dev/psaux/mice -t ps2
And accordingly edited the /etc/conf.d/gpm file to include:
GPM_ARGS=-m /dev/psaux/mice -t ps2
But after rebooting with a working nvidia driver the CONSOLEFONT:
sun12x22.psfu.gz still fails to load. (No problem there I'm getting
an 80 column display so I don't need to load larger console fonts...)
But more irritatingly: Now GPM fails to start. And I can't start it manually
either... Could it be that the nvidia drivers xorg dependency is blocking
gpm in the console??? Too bad, I like using gpm's copy/paste functions, and
wouldn't have minded setting up a /root/bin GPM init command with the
correct string to activate it when wanted, even if I needed to gpm -k
before running startx...
One other odd thing. When I tried to man gpm it complained that
/usr/bin/less didn't exist. So I symlinked it to /bin/less and man started
working... ...
Anyway I set my {user} ~/.xinitrc for a minimal e17 start-up and startx got
me there. And the mouse worked as expected there... But I'm too tired of
all this to bother configuring all my e17 keyboard shortcuts etc... So I'm
done for now.
Thank You one and all for the kind hearted suggestions!
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
Re: [arch-general] screen goes blank on reboot after 1st pacman Su of new install!!!???
It would appear that on Jul 4, Andre Osku Schmidt did say: i got lost in your mail... but i do see from your subject that you should use `pacman -Syu` and not just `pacman -Su`, as the package database wont be updated without `y`... Sorry for my natural wordyness but I do have a hard time with brevity. If I hadn't been trying to keep that book down to a couple of chapters I'd have mentioned that I use pacman Sy as a separate command. It's nice that I could combine them into a single command. But on some systems I still use apt-get, and my ingrained habit of starting with a separate refresh command keeps me out of trouble. and for blank screen, maybe try kernel option `nomodeset`... and in next mail try to be more precise what you did and what happens... OK I'll try that on my next reboot cycle. (just have to finish a few E-mail chores first.) I'll let you know what happens... as you talk about pop-ups, did you install xorg ? are you using a DE ? which gfx driver you installed for xorg ?... f...@kokkinizita.net nailed that one... I did think that my overlong text did specify that the pop-ups came from the monitor, but Like you said, you got lost in my post. (Sorry) It would appear that on Jul 4, f...@kokkinizita.net did say: On Sun, Jul 04, 2010 at 11:51:12AM +0200, Andre Osku Schmidt wrote: as you talk about pop-ups, did you install xorg ? are you using a DE ? which gfx driver you installed for xorg ?... The popups are those generated by the monitor when it doesn't get a valid signal. Having a Sony as well they sound familiar to me. Things seem to go wrong well before Xorg gets involved. The nomodeset option willl probably provide a working system in RL 3. Once that is working we can have a closer look. ABSOLUTELY. my next task _was_ supposed to be to open a lynx session on one console open to the wiki to remind myself HOW to use another console to get x working on an arch install... (This is only my second arch install ever. The first, on my laptop has worked out fairly well for me.) But I did have X running on that before they stopped passing control of the video back and forth between the kernel and the xserver. (Did I understand correctly that such control now resides only in the kernel whether x is up or not?) But in any case even when I do get X working I won't allow ANY display manager to control my boot/login process. If they take away startx I'll likely give up X before I'll use GDM, KDM, Entrance (etc...) Any graphical login prompt always makes me so uncomfortable that I forget why I was booting the durned computer in the first place. Heck I even insist on a text based grub menu for similar reasons. When I'm ready to put up with a GUI, I use startx, and not until... Still Like I told Osku, I'll try that nomodeset kernel option and post the results in this thread. Thanks for the help guys. -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] screen goes blank on reboot after 1st pacman Su of new install!!!???
It would appear that on Jul 4, f...@kokkinizita.net did say:
I'm using XDM which is relatively painless compared to
GDM, KDM and friends. With a modified 'Arch' setup it
can be made to look nice.
What looks nice to me is the console login prompt...
Also aside from that, there's another reason I use startx (with a wrapper
script that copies the appropiate file to ~/.xinitrc depending on which
desktop...) Which is usually E17 which can remember where to put a konsole
window based {in part} on the name which I can feed to it with a
running terminal application via a line like this in the ~/.xinitrc...
konsole --workdir ~/mail --name F2alpine --profile BlackGray -e alpine
I've yet to find a DE that will remember enough details of a konsole window
in it's saved sessions method to prestart the correct application(s) in the
correct konsole windows etc...
I don't suppose XDM can be configured to use a ~/.xinitrc like script that
will let me prestart selected terminal applications in a simular manor?
Hint: once you have RL3, make sure you have the network
and sshd configured and running before doing anything X11.
That way you can always log in from another machine if
startx leaves the system in an unusable state. It can
save a lot of rebooting time...
Well I've evidentaly got the internet as fetchmail is working... Though it
said my comcast cablemodem connection to comcast's pop server was insecure.
It said something about verisign not being trusted?
sshd is another matter. My personal paranoia settings require NEVER
allowing ANY remote logins. If God himself want's to use my computer he
dang well better be using the attached keyboard, or there's gonna be
trouble... grin
I wonder if you aleady have nouveau installed. Do an
lsmod | grep nouveau
to check.
Since I haven't yet remembered how to get gdm working in arch, I redirected
that output to a file in lieu of pasteing it into the message. Since I
compose with vim that means :r nouveau.out
nouveau 477159 0
ttm38517 1 nouveau
drm_kms_helper 21512 1 nouveau
drm 131562 3 nouveau,ttm,drm_kms_helper
i2c_algo_bit4319 1 nouveau
i2c_core 15144 5
nouveau,drm_kms_helper,i2c_nforce2,drm,i2c_algo_bit
button 3738 1 nouveau
Nouveau is the new open source driver for Nvidia cards.
Unlike nv it is a kernel module, not an Xorg driver and
that can be confusing if you're not aware of it. If it
is installed, it will be used even before you start X,
and the only way to prevent that (if you want X to use
another driver) seems to blacklist the module in
/etc/rc.conf.
The failing modeset could be because you have nouveau
and it's doing the wrong thing, or because you don't
have it...
I say I'm not sure but I think the above output says I do have it and that
it must be doing the wrong thing...
For X you will have the choice of nv, nouveau, or the
proprietary nvidia driver. Nouveau is reported to work
well, but on some systems I had to revert to nv to get
usable audio latency. This seems to depend on the video
card type as on other audio system here nouveau works
just fine.
Since this is my first Nvidia card AND I'm NOT a gamer, I woiuldn't know
what to do with any of the above. But since (I think) Arch now favors,
ummnnn, What's it called? a, Oh good I found some of my notes: KMS
it would make sense to try to configure the kernal module driver first
wouldn't it? Is there a how-to that doesn't expect me to be a computer
science grad?
By the way, I noticed a couple of odd things durring this nomodeset session.
Don't know if they are symptoms of problems or possibly the results of
having used the nomodxeset kernel option...
1) durring the boot, it said it couldn't load the sun12x22.psfu.gz font
I'd prespecified in my rc.conf... Actualy on the assumption that KMS was
going to notice my high reasolution monitor I figgured I'd likely need
something like ter-128n.psf.gz Like I wound up using in my laptop. But I
haven't installed the terminus font package yet... So the biggest I
expected to start with was one of the 12x22 fonts...
I note that even without loading the large font, I wound up with a large
text size on my hi-res monitor (yup an actual 80 column display) So maybe
the nomodeset option is why the 12x22 font didn't load?
2) a little more disturbing I note that when I switched to another tty and
logged in to another console session, it hungup without executing the
.bash_profile... If I hit ^C I got a default command prompt but my .bashrc
set command path wasn't working untill I used the bash command to open a
subshell... Could the nomodeset option be responsible for this???
3) WHA-DA-{censored} Now I notice I can't get mc to fire up. I used it
earlier in this login session, But now the tty just hangs, and I need to
use another tty to issue a killall mc to get my prompt back... I'm not
[arch-general] screen goes blank on reboot after 1st pacman Su of new install!!!???
Hi. I'm not that sure what's happening. But I just acquired an HP Pavilion
desktop. (My Sister's Hubby just bought a new win 7 box and let me
recycle his old xp box... I told him right away that I'd found the
problem he was having with the old box, it was running windows...)
Anyway it's got AMD 64 processor with a gig of ram, and integrated NVIDIA
GeForce 6150 LE (which could be the problem for all I know. But since I
don't give a tallywack about 3d acceleration I doubt I'm supposed to need
to know much about tweaking NVIDIA graphics.
Anyway I promptly used gparted to squeeze the existing winxp installed to
the 200 gig sata harddrive down to only 70 gig, attached an ide seagate 250
gig drive I'd had left over from my former (defunct) desktop which had died
about a year ago. Making room for multiple Linux distros. Because PCLinuxOS
features a mylivecd script that's designed to make it easy for non-experts
to make fully configured and installable live cd/dvd images of their running
PCLinuxOS installation, PCLinuxOS got the first install.
But Arch was supposed to be the 2nd. I installed the core system from an
archlinux-2010.05-core-dual.iso But since I already have a 64 bit Arch on
my laptop I thought I'd try the i686 image on the desktop...
Then I set up my user partitions via udev rule (I've named all my
partitions cause something like LABEL=Arch_desk-7, LABEL=PCLOS_desk-3
are much more human readable than any UUID={string} will ever be).
Anyway, I updated the new Arch system and kept working on customizations.
I kept getting interrupted so it was a couple of days later that I was
comfortable enough to reboot. It does reboot, but right after the bootup
screen says something about waiting for UDev events the monitor goes
blank. (I expect this to happen cause the arch on my laptop does the same
thing except with the laptop, the screen returns to life a moment later
with a new screen font that holds true until it enters runlevel: 3 where
the font I defined in my rc.conf finally takes over...
But on this new desktop which has a nice Sony flat screen monitor, when the
screen goes blank, the Sony monitor flashes a pop-up notification about no
signal, which is quickly followed by a notice that it's going to power save
mode... And the new arch system never sends it any more output to wake it
up. No mater what I do to the keyboard or mouse. And no matter how long I wait
either. I tried just waiting... Went to bed, got up late the next day.
Still no monitor output... But Arch itself is NOT hung up. It will respond
to the three fingered salute with a reboot, and I even one time blindly
logged in as root to the console and blindly typed:
shutdown -h now
Which resulted in a powerdown.
But I still don't have any idea what's killing my monitor output. I can
use my PCLinuxOS installation's root account to examine/edit *ANY* file.
But I don't have a clue what to look for. Suggestions anyone???
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
Re: [arch-general] File Associations for firefox thunderbird :)^
It would appear that on Jun 16, Patrick Brisbin did say: On 06/14/10 at 11:33pm, Michishige Kaito wrote: I found thunderbird asking me for a program to execute for links. Pointed it to the right program and told it to remember. Never asked again. I wouldn't know where to change it if I ever wanted, but it's been working so far, and I don't use a DE. xdg-open for non-DE users is annoying but possible. I spent an evening reading the source (it's just a bash script anyway). When no DE stuff is present it falls back to some application.list file which associates mimetypes with .desktop files. The list and .desktop files are searched for in /usr/share/applications globally and ~/.local/share/applications on a per user basis. There's also xdg-open commands to add/remove associations and .desktop files to/from the list. No match found for a mimetype and we fall back on $BROWSER. At least that's how I remember it all working, I haven't looked in quite some time. I hear you can also install mimeo or some other Xyne-tool which will override all this and make it work better. Pardon me but this all sounds like a petty annoyance I have when I want to see the content of a pdf I find on the web. I once was a kde user and still prefer several of it's applications over the gnome equivalents. Nowadays I'm usually working from within E17 which is by now more of a DE than a WM (I think)... And I routinely use two different web browsers. (Opera Firefox) Both of which ask me which application I want to open it with. Unfortunately it always defaults to Evince. And I usually get better results with Okular. But unlike Michishige, I'm unwilling to use the pop-up to set the default because I like always having the choice. Unfortunately, for some reason when I'm doing this with my Arch Linux installation, the Open With scroll box never offers any other choices besides Other which won't find okular but makes me enter the full pathname of /usr/bin/okular and worse still, it doesn't even remember the choice if I need to open another pdf from the same browser session. (like when I'm reviewing my banking activity, and I want to peek at more than one canceled check image) These files you mention in /usr/share/applications interest me. But I don't know what to do to them to give greater preference to the desktop files: /usr/share/applications/kde4/okular.desktop /usr/share/applications/kde4/okularApplication_*.desktop Than to: /usr/share/applications/evince.desktop would you be so kind as to give me a pointer or two? I mean I don't suppose I could getaway with simply renaming evince.desktop as okular.desktop to get that effect without buggering up my ability to get evince on the rare occasions when I actually want it? Or perhaps I could simply copy all the okular desktop files from /usr/share/applications/kde4/ to /usr/share/applications/??? -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
Re: [arch-general] dialup woes wvdial, external v92 modem connected via usb/serial adapter
It would appear that on Jun 5, Ross did say:
On 05/06/10 17:36, Joe(theWordy)Philbrook wrote:
Wvdial only finds the modem when I specify 'Modem = /dev/ttyUSB0' in
my wvdial.conf file...
Are you able to access the modem with minicom?
I'm unable to figure out how to use minicom...
After much fumbling around I managed to find where to define the init
string and where to put the number to be dialed. (I think) Anyway, somehow
I managed to get it to talk to the modem itself, BUT...
I start minicom and it initializes the modem. (If the init string
includes the H1 it goes off hook, which soon leads to the phone company
interrupting the dial tone to tell me to dial again. Without the H1 it
never goes off hook.) Either way it still doesn't dial.
(if I type '^A Z D {enter}' it tells me I'm already online and that I
should hangup first. But doing a '^A H' {followed by selecting 'yes' in
the pop-up text box} has no effect...) And incidentally I when it told me
I was already online, I opened another terminal and confirmed that I
couldn't 'ping google.com' without reconnecting the ethernet cable.
--
|^^^ ^^^
|o o Joe (theWordy) Philbrook
|^ J(tWdy)P
| ___ jtw...@ttlc.net
| ' `
Re: [arch-general] dialup woes wvdial, external v92 modem connected via usb/serial adapter
It would appear that on Jun 4, Ross did say: If you are using a usb - serial adapter I think your Modem should be something like /dev/ttyS0 (you could check on your system with dmesg |grep serial) instead of /dev/ttyUSB0 I would have thought so to. But unless I'm remembering wrong, isn't /dev/ttyS[1-3] the linux equivalent of com[1-4]? In which case, if the modem could be found on one of those wvdial wouldn't tell me: -- Cannot get information for serial port. just before it initializes the modem device specified in the wvdial.conf file, would it??? And in any case, /dev/ttyUSB0 is where wvdialconf identified my modem. = UnderTree =- wvdialconf wvdial.cfg = Editing `wvdial.cfg'. = = Scanning your serial ports for a modem. = = Modem Port Scan*1: S0 S1 S2 S3 = WvModem*1: Cannot get information for serial port. = ttyUSB0*1: ATQ0 V1 E1 -- OK = ttyUSB0*1: ATQ0 V1 E1 Z -- OK = ttyUSB0*1: ATQ0 V1 E1 S0=0 -- OK = ttyUSB0*1: ATQ0 V1 E1 S0=0 C1 -- OK = ttyUSB0*1: ATQ0 V1 E1 S0=0 C1 D2 -- OK = ttyUSB0*1: ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 -- OK = ttyUSB0*1: Modem Identifier: ATI -- Zoom V.92 Serial s110701 -C Z207 = ttyUSB0*1: Speed 4800: AT -- OK = ttyUSB0*1: Speed 9600: AT -- OK = ttyUSB0*1: Speed 19200: AT -- OK = ttyUSB0*1: Speed 38400: AT -- OK = ttyUSB0*1: Speed 57600: AT -- OK = ttyUSB0*1: Speed 115200: AT -- OK = ttyUSB0*1: Max speed is 115200; that should be safe. = ttyUSB0*1: ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 -- OK = = Found a modem on /dev/ttyUSB0. = wvdial.cfgWarn: Can't open 'wvdial.cfg' for reading: No such file or directory = wvdial.cfgWarn: ...starting with blank configuration. = Modem configuration written to wvdial.cfg. = ttyUSB0Info: Speed 115200; init ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 = UnderTree =- Still lets see what dmesg says: = UnderTree =- dmesg|grep serial = usbcore: registered new interface driver usbserial = usbcore: registered new interface driver usbserial_generic = usbserial: USB Serial Driver core = UnderTree =- ls -l /dev/ttyS* = crw-rw 1 root uucp 4, 64 Jun 5 00:11 /dev/ttyS0 = crw-rw 1 root uucp 4, 65 Jun 5 00:11 /dev/ttyS1 = crw-rw 1 root uucp 4, 66 Jun 5 00:11 /dev/ttyS2 = crw-rw 1 root uucp 4, 67 Jun 5 00:11 /dev/ttyS3 = UnderTree =- ls -l /dev/ttyU* = crw-rw 1 root uucp 188, 0 Jun 5 00:11 /dev/ttyUSB0 = UnderTree =- vim /etc/wvdial.conf = UnderTree =- wvdial = -- WvDial: Internet dialer version 1.61 = -- Cannot open /dev/ttyS0: Input/output error = -- Cannot open /dev/ttyS0: Input/output error = -- Cannot open /dev/ttyS0: Input/output error = UnderTree =- vim /etc/wvdial.conf = UnderTree =- wvdial = -- WvDial: Internet dialer version 1.61 = -- Cannot open /dev/ttyS1: Input/output error = -- Cannot open /dev/ttyS1: Input/output error = -- Cannot open /dev/ttyS1: Input/output error = UnderTree =- vim /etc/wvdial.conf = UnderTree =- wvdial = -- WvDial: Internet dialer version 1.61 = -- Cannot open /dev/ttyS2: Input/output error = -- Cannot open /dev/ttyS2: Input/output error = -- Cannot open /dev/ttyS2: Input/output error = UnderTree =- vim /etc/wvdial.conf = UnderTree =- wvdial = -- WvDial: Internet dialer version 1.61 = -- Cannot open /dev/ttyS3: Input/output error = -- Cannot open /dev/ttyS3: Input/output error = -- Cannot open /dev/ttyS3: Input/output error = UnderTree =- vim /etc/wvdial.conf = UnderTree =- wvdial = -- WvDial: Internet dialer version 1.61 = -- Cannot get information for serial port. = -- Initializing modem. = -- Sending: ATZ = ATZ = OK = -- Sending: ATQ0 V1 E1 S0=0 C0 D2 H1 +FCLASS=0 = ATQ0 V1 E1 S0=0 C0 D2 H1 +FCLASS=0 = OK = -- Modem initialized. = -- Sending: ATDT7340102 = -- Waiting for carrier. = ATDT7340102 = ERROR = -- Invalid dial command. = -- Disconnecting at Sat Jun 5 00:38:10 2010 = UnderTree =- Wvdial only finds the modem when I specify 'Modem = /dev/ttyUSB0' in my wvdial.conf file... -- |^^^ ^^^ |o o Joe (theWordy) Philbrook |^ J(tWdy)P | ___ jtw...@ttlc.net sigh
[arch-general] dialup woes wvdial, external v92 modem connected via usb/serial adapter
I'm having a problem getting dialup to work...
Due to financial limitations, I'm going to have to give up my expensive
broadband connection in favor of {sigh} dial-up which will save me about
$50/month.
I still have my external v92 zoom serial modem from before I went
broadband. But now that my only working computer is my laptop I had the
problem of not having a serial port to connect it to.
I already tried to get my laptops internal {win}modem to work via Linmodem,
but failed miserably... Thus I acquired a usb/serial adapter cable, and used
it to connect my v92 modem. wvdialconf detected it OK. But I can't get it to
dial. With some experimentation based on some init strings I found online
and a brief modem command reference, I've been able to get the modem to at
least go off hook, by adding H1 to the Init2 string. Proving at least that
wvdial was attempting to control the correct device. But it didn't dial.
It complained that my dial string was invalid and disconnected...
Except that the modem didn't hang up (I listened to the phone company
recording about hanging up and dialing again...)
A little more experimentation reveled that if I used C0 instead of C1
it would hang up when it disconnects. But it still doesn't actually
dial. And still complains about my dial string. I have verified the 7
digit 'Phone = 7340102 ' string by manually dialing it with a
telephone and heard the sound of my ISP's modem attempting to
negotiate a connection. And, in my wvdial.conf, I have tried the string
both with and without quotes.
I've included {below} a copy of my wvdial.conf pasted in the results
of my last attempt to use wvdial...
Could somebody tell me what I'm doing wrong?
= My wvdial.conf (with password line modified of course):
[Dialer Defaults]
Init1 = ATZ
# Init2 as defined by wvdial.conf:
# Init2 = ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0
# Init2 modified: Without H1 stayed on hook. Without C0 wouldn't hang up on
disconnect...
Init2 = ATQ0 V1 E1 S0=0 C0 D2 H1 +FCLASS=0
Modem Type = Analog Modem
Modem = /dev/ttyUSB0
Baud = 115200
New PPPD = yes
# tried with and without Carrier Check
Carrier Check = off
# tried with and without Stupid Mode
Stupid Mode = on
Dial Command = ATDT
Phone = 7340102
ISDN = 0
Username = jtw...@ttlc.net
Password = xxx
= A screen capture of my last wvdial attempt:
UnderTree =- wvdial
-- WvDial: Internet dialer version 1.61
-- Cannot get information for serial port.
-- Initializing modem.
-- Sending: ATZ
ATZ
OK
-- Sending: ATQ0 V1 E1 S0=0 C0 D2 H1 +FCLASS=0
ATQ0 V1 E1 S0=0 C0 D2 H1 +FCLASS=0
OK
-- Modem initialized.
-- Sending: ATDT7340102
-- Waiting for carrier.
ATDT7340102
ERROR
-- Invalid dial command.
-- Disconnecting at Thu Jun 3 15:38:23 2010
UnderTree =-
Re: [arch-general] dialup woes wvdial, external v92 modem connected via usb/serial adapter
It would appear that on Jun 4, Ross did say:
Perhaps you need pulse instead of tone dialing? If that is the case try
setting Dial Command = ATDP
Thanks for the suggestion Ross. Though I don't see how that could be it...
All of my telephones use tone not pulse (I just double checked the one on
my desk, it's switchable, but the switch is set to the clearly marked
tone setting.
None the less, I suppose the modem itself might be malfunctioning in
some way that prevents tone dialing. So while I doubt pulse dialing is
the answer, I shall test this theory.
. . .
UnderTree =- wvdial
-- WvDial: Internet dialer version 1.61
-- Cannot get information for serial port.
-- Initializing modem.
-- Sending: ATZ
ATZ
OK
-- Sending: ATQ0 V1 E1 S0=0 C0 D2 H1 +FCLASS=0
ATQ0 V1 E1 S0=0 C0 D2 H1 +FCLASS=0
OK
-- Modem initialized.
-- Sending: ATDP7340102
-- Waiting for carrier.
ATDP7340102
ERROR
-- Invalid dial command.
-- Disconnecting at Fri Jun 4 00:07:41 2010
UnderTree =-
Nope, wasn't that. {sigh} I do wish I could be sure what's wrong.
If anybody familiar with zoom brand external modems could confirm that
the wvdial.conf I included in my previous post SHOULD work, I might
conclude that my zoom modem may have developed a malfunction during
the years it spent collecting dust in the junk box under my desk.
In which case, I still have about a week to return the $39 usb/serial
adapter to staples where $59 will get me a new zoom v92 usb modem.
But if it turns out that there is something wrong with my wvdial.conf
that's causing the problem, (rather than a defective serial port modem)
then I've got better things to do with the $20 difference.
--
|~-~ ~-~ Guess I just don't know.
|? ? Joseph (the Wordy) Philbrook
|^ J(tWdy)P
| ___ jtw...@ttlc.net
sigh
[arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
Currently my pc is a laptop. I don't use a wireless interface. I connect to the Internet via cable broadband with a wired Ethernet connection and DHCP... This id very reliable. I can usually disconnect the laptop from the Ethernet cable and bring it into the livingroom for various offline use. Then when I bring it back to my desk, all I usually have to to is plug the Ethernet cable back in and wait a few seconds and the Internet will start to work again. BUT that is contingent on the Ethernet cable having been connected during boot up. So if for example I were to boot up my laptop in the livingroom where there isn't an Ethernet connection the boot process will delay at the point where it's screen message says its starting the network. Then it says it failed and continues setting everything else up. At this point, if I bring the laptop back to the desk, and plug in the Ethernet cable, it doesn't automatically connect. I tried: # ifconfig eth0 up but ping still doesn't find my ISP What am I missing -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
It would appear that on May 18, Dan McGee did say: Your dhcp process didn't start either, so you need to start one of those. Something as simple as `dhcpcd -i eth0` might work. That makes sense Dan, Thanks! While it looks like woldra's suggestion may be the best one, yours gives me a clue as to why ifconfig didn't do it for me... Thanks again. You also made me curious, I will likely try the dhcpcd method at least once to see if it works... It would appear that on May 18, C Anthony Risinger did say: You may need to modprobe the module for your Ethernet card. Try lsmod to get it's name. I'm hoping I don't need that because lsmod produces pages of output, none of which sounds like an ethernet card to me... But thanks for pointing out the possibility... It would appear that on May 18, Rafael Correia did say: Man, I don't that's the point, but here I need to do this: ifconfig eth0 0.0.0.0 Thanks Rafael, A look at 'man ifconfig' seems to indicate that you are telling it to set the ip address of the interface to 0.0.0.0 though I haven't a clue why you need to do that. If all else fails I'll try it. It would appear that on May 18, wol...@fsfe.org did say: ifplugd is your friend it detects the calble being plugged in and brings the interface up. Thanks woldra, I never heard of ifplugd before... have to admit, what I learned with a quick scroogle search on it tells me that it's probably my best option. Especially if it really only affects the ethernet connection. But 'man ifplugd' is rather terse. After doing a 'pacman -S ifplugd' will I need to add it to the daemons list in my rc.conf??? It would appear that on May 18, Kaiting Chen did say: Um should he just /etc/rc.d/network restart? That performs everything that happens when the network interface is brought up on system start. Thank you Kaiting. This might even turn out to be necessary, the boot up screen messages don't specify what starting the network failed to do. So if ifplugd doesn't do it, I'll probably go this route... It would appear that on May 19, wol...@fsfe.org did say: Um should he just /etc/rc.d/network restart? That performs everything that happens when the network interface is brought up on system start. sure you can do that, but why not let the little tool do that for you? A little automagic doesn't harm as long as you know whats going on;) Apart from that ifplugd just controls one interface where the network script starts/stops the whole networking (including 127.0.0.1)... So then I'm guessing that means that if a process is using the local loopback interface when a /etc/rc.d/network restart is issued, then that process my crash or hang etc... ??? It would appear that on May 18, Kaiting Chen did say: I see I've never heard of ifplugd but it looks like the best solution. What I was referring to was that /etc/rc.d/network restart is preferable to ifconfig in that it will start up dhcpcd for you. Well Kaiting, While woldra's ifplugd suggestion does sound like the best solution, YOUR suggestion, and that of Dan McGee, seem to explain what I was missing with my ifconfig idea... Which is what I actualy asked... I'd like to thank all of you very much for the kind suggestions. This thread will definitely be copied to my LinuxClues folder for future reference. -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
Re: [arch-general] dual ISP: 1)cable broadband (DHCP) 2){shudder} dial-up (ppp?) Please help!
It would appear that on Apr 28, Rogutės Sparnuotos did say:
Since you haven't tested your modem yet, the first thing to do would be
running minicom or some other serial terminal on your /dev/ttyS?, issuing
the ATZ command and see if you get OK. There is no point worrying about
anything else as long as you are not sure you have a working modem.
Yeah, that is the main problem here...
I thought the solution would be to fall back on my external v92 serial
modem BUT unfortunately I wasn't thinking about the fact that this laptop
doesn't have a serial port connection to plug it into. (And not having 2
nickles to rub together at the moment makes new hw a non-solution...)
Still, I looked into Linmodem and there is hope. scanModem suggests:
Smart Link soft modem driver slmodemd But it looks like it might
have to be reworked every time an update gave me a new kernel.
And I need a set it and forget it solution that I can fall back on and or
otherwise use to rarely to make that worth doing on any frequently updated
system... Still my laptop has the room for 4 concurrently installed Linux
distros (at current bloatware levels) And I'm only actively going to be
upgrading 3... Arch, and PCLinuxOS, which are both rolling release models
(though sometime this year PCLinuxOS is supposed to require a reinstall
thanks to some major changes like the kde4 crap, But they haven't done that
since 2007 so I guess they can be called a rolling release...)
and Xubuntu which can at least sometimes be upgraded to the next release
without totally starting over...
So my plan is now to attempt to get slmodemd going on my existing Elive
which isn't going to be upgraded any more but word serve as an outdated
backup system which would make a good place to set-up a linmodem fix that
stays fixed for occasional and back-up use.
Failing that, I'll try the same thing with my current 2007 based PCLinuxOS
installation, and let that become the static outdated backup. In which case
the eventual 2010 PCLinuxOS, will overwrite my current elive... Either of
those options would leave me with a few kde3 version tools to play with for
those occasions when I want to remember that I used to like kde.
The next fallback plan is to try to get slmodemd going with my current Xubuntu
installation, which could become static by way of doing a clean install of the
next 'buntu on the current elive partition. If That fails my next option is
to build a 2nd Arch on the current elive partition and do the slmodemd on
one of the Arch install which one won't get any more updates...
...
I suppose you've setup your broadband in either rc.conf or netcfg. If that
is the case, know that these setups are Archlinux specific and there is
basically no software which will touch these. So you always get what you
have specified in rc.conf after a reboot.
That's good to know.
And you _can_ have lots of modems and lots of ethernet cables connected to
you computer, and still have your broadband working. With most setups,
data packets to the internet go through the default route (try running
'route'), which is changed after a successful pppd connection and changed
back after it closes (this is not wvdial specific).
Then if slmodemd works but I have wvdial issues, I can always try another
dialer. Thank you for the good news. I needed something good to counter the
negative energy that filled my very soul the moment I knew for sure that
the {expletive deleted} 'personalities' at gateway build a winmodem into the
high def sound card... sigh
Thanks again
--
| ~^~ ~^~
| * * Joe (theWordy) Philbrook
| ^J(tWdy)P
| \___/ jtw...@ttlc.net
Re: [arch-general] dual ISP: 1)cable broadband (DHCP) 2){shudder} dial-up (ppp?) Please help!
It would appear that on Apr 28, Rogutės Sparnuotos did say: Joe(theWordy)Philbrook (2010-04-28 02:21): ... When/if connected via dialup, I'll be paying by the connected hour, so I don't want anyone I don't trust with the root password to be able to use it... Offtopic: This anyone I don't trust with the root password sounds strange to me. There should be only one root... Not so off topic... ;-7 I did specifically bring up the concept of trusting someone with root access (and I wasn't referring to a limited sudoer) But be that as it may, while I can imagine a few circumstances involving more than one admin with root privileges, in practice I've only got my personal Linux box. And since my life partner isn't very computer literate, that means I'm the only one I trust with my root password, so I don't want anybody but me jacking up my back-up isp bill... I'm hoping that All I'll need to do is open a terminal window, su to a root shell, type wvdial Then open a browser or email client in another window. And to be able to quickly pull the plug on the connection ... Actualy I'm thinking I should maybe get in the habit of doing that via $ su -c wvdial Do I need to worry about wvdial and/or other dial-up ppp connection messing with the broadband Ethernet setup? ISPs usualy charge per minute, so there is no need to be in a hurry pulling the plug. Are you really getting nervous when thinking about dial-up, or am I imagining things? Not at all. It's been so long since I bothered that I've forgotten almost everything I ever knew about Linux dialup except about how much cooperation I'll get from the ISP's tech dept. right after a let the word Linux slip past my lips... So yeah, when you add to that a shoe string budget, I'm willing to admit I'm just a tad nervous. wvdial will not touch any of your network related configs (only the ppp ones), so if you will not use any other tools, your broadband will be safe. At least after reboot. Good. Then I can afford 'some' empirical testing after all. ;-) From what I've found online, and what little I can remember, wvdial should be available for just about any distro. So if I keep it's set up fairly simple, I should be able to clone a successful implementation to the other Linux installed on my multi-boot laptop. So yeah, as long as you don't count set-up utilities such as wvdialconf, and if need be, minicom, I don't plan on using any other dialup tools... wvdialconf has to be run only once. It should ask you for the telephone number, user and password. That's good to know. From what I read in the man page I was under the impression that it would only configure the modem part of the wvdial.conf and that I'd have to manually edit in the login data... Later, to connect, you simply run wvdial and wait for the connection (it will fetch the DNS settings, set the default gateway etc.). Then pressing ^C, it will disconnect and change the settings back to what they were. So then, I won't need to specify the DNS, AND it will restore any such existing settings. (I knew that wvdial was the one for me...) But, if you do not test dialing-up at home, it is likely that something will go wrong when you try connecting at your sister's (and there won't be any internet connection to seek help). Absolutely. That was my plan. Else I wouldn't have worried about some brain flatulence causing me to accidentally have the Ethernet cable connected, while wvdial was active. And are you sure the modem in your laptop is working and recognized by linux? Not yet! :-( But if I can't get it working I've got my old external serial modem in one of the assorted junk boxes that clutter up my office. What I won't find though, is the manual for it sigh (I'd much prefer to be able to use the built in... (fewer things to lug around and all that) Could someone point me at the URLs of the other 'dialup' related documents that are supposed to be in the Arch Linux Wiki (since searching for 'dialup' didn't help me)? Did you search for ppp? Doh! And to think I didn't think of that. I knew I suffered from CRS... But now I'm thinking it must be getting worse... Actually though, I've never been particularly skillful at coming up with good search strings. But I still should have thought of that one. Thanks! -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
Re: [arch-general] packman -S eterm [done] But: bash: eterm: command not found ????
It would appear that on Apr 20, Nathan Wayde did say: On 20/04/10 03:56, Joe(theWordy)Philbrook wrote: Am I missing something obvious here??? Yeah, `pacman -Ql eterm | grep bin/`. The binary is Eterm (upper-case e) dou! I think I knew that once upon a time..., Why did I forget? Oh, I'll bet I did something like this: UnderTree =- ln -s /usr/bin/Eterm /usr/bin/eterm I'm not surprised that I hadn't yet picked up on 'pacman -Ql' though... However, now that I can start eterm, I've bumped into some other small wrinkle that I don't understand... I don't know if it matters, but I'm running E17 as a desktop via startx from user account jtwdyp if I type the Eterm (Or with the above symlink, eterm) from the run prompt, or from an existing terminal it fires up an eterm, apparently as a login shell. (I know this because my ~/.bash_profile mounts a user owned data partition, and unlike xterm, konsole, or roxterm, the eterm starts up with an error message about the partition being already mounted... Why would Eterm default to that? More significantly: (Note: my preferred way to get a root shell is via a keyboard shortcut that fires up a konsole window using a --profile having a background color that reminds me it's for root use, and a -e su -c mc Where my root account's .mc setups also includes distinctive panel colors for the same reason.) But for some reason when I ^O my way to a bash shell from above described root mc session and type Eterm A non-responsive eterm window opens with an error message: -bash: 11: Bad file descriptor hunh? I suspect this is related to Eterm starting as a login shell, or whatever causes the .bash_profile to be executed for it... But I'm just guessing. -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
[arch-general] packman -S eterm [done] But: bash: eterm: command not found ????
Could be I'm missing something here... But shouldn't 'pacman -S eterm' put executable somewhere in the standard path??? This was done using a root shell in a konsole terminal under E17 on my recently updated Arch installation... I did search the wiki for eterm just in case there was something about eterm that requires more than a simple pacman install. Didn't find anything useful. Am I missing something obvious here??? UnderTree =- pacman -S eterm resolving dependencies... looking for inter-conflicts... Targets (2): libast-0.7-2 eterm-0.9.5-3 Total Download Size:0.91 MB Total Installed Size: 2.98 MB Proceed with installation? [Y/n] y :: Retrieving packages from community... libast-0.7-2 260.8K 315.2K/s 00:00:01 [###] 100% eterm-0.9.5-3674.3K 828.9K/s 00:00:01 [###] 100% checking package integrity... (2/2) checking for file conflicts [###] 100% (1/2) installing libast [###] 100% (2/2) installing eterm [###] 100% UnderTree =- eterm bash: eterm: command not found UnderTree =- Here are the last few lines of my pacman.log: [2010-04-17 00:35] synchronizing package lists [2010-04-17 00:38] installed roxterm (1.18.1-1) [2010-04-19 21:31] synchronizing package lists [2010-04-19 21:34] installed libast (0.7-2) [2010-04-19 21:34] installed eterm (0.9.5-3) I note roxterm works, eterm doesn't... I don't see any errors listed in the pacman.log... -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
Re: [arch-general] did my 4/10/10:pacman -Syu: destabilized e17's run command dialog??
It would appear that on Apr 17, David C. Rankin did say:
On 04/16/2010 04:12 PM, Joe(theWordy)Philbrook wrote:
snip
How can I a regular Joe user, figure out if this is an actual E17 bug
or if it's an Arch specific thing???
Joe,
I'll have to check my E17 install on Arch, but I just got through going
through
fits with E17 on suse. All of a sudden, E17 virtual desktop management and the
pager went nuts. If I opened an app on desktop 1 and then switched to desktop
2,
etc.. the open app was visible on on desktops. (like you had the window set as
sticky to show up on all desktops)
Further, E17 would crash every time I tried to change shelf properties
or
add/remove apps from ibar, etc.. The issues ended up being something in my
~/.e
directory. I hadn't changed any settings at all in E17 for quite some time, so
one of the E17 updates did something strange to the config that really screwed
E17 up. Wiping out my ~/.e directory and restarting with the default black
white theme cured it. After the restart and forced rebuild of the default
configuration, I could reconfigure E17 exactly the way I had it before and it
worked just fine. If you haven't tried it, it might be worth a shot.
Thanks for looking into it David, And for the suggestion. I suppose it
could be that something messed with something in my ~/.e file hierarchy
That's probably more likely than that something changed in such a way as to
make some formerly viable set up to suddenly become incompatible...
I really hope that if either is true, it's the former as I really detest
rebuilding my keyboard shortcuts with the freaking pointNclick GUI config
tool. Especially since there isn't a one that matches the default settings
AND my mouse skills are a negative value... {Gawd how I miss the old
scriptable pre-dbus enlightenment_remote command. that allowed me to set
*_MY_* default keybindings with a bash script as the first thing to do once
e17 was installed}
At least (if the former is the case) I can use the fact that when I first
got it set up the way I liked I did a cp -R ~/.e ~/tmp/e_bu (Something
I learned to do because with some of my e17 installations the remember
settings for a few things in my .xintrc kept getting lost...
{PCLinuxOS comes to mind where I've actually gone so far as to put an
cp -R in my .bash_profile to restore the original every time I login...})
I'll have to test if restoring the prev version of .e will fix it. After
all the only thing I'd lose is the updated keybinding assigning Alt+F2 to
xfrun4 instead of the e17 run prompt... Then I suppose (given I can still
restore the .e dir if it doesn't help) I could let e17 build me a new
default .e ... I'll let you know how it pans out in a day or two.
--
| ~^~ ~^~
| * * Joe (theWordy) Philbrook
| ^J(tWdy)P
| \___/ jtw...@ttlc.net
[arch-general] did my 4/10/10:pacman -Syu: destabilized e17's run command dialog??
Actually, I'm not sure if this is thanks to E17 itself or specific to
Arch... And it's no big deal anyway because:
A) e17 is under heavy development, (And I know that means it's unstable)
B) I've already got a workaround that works for me...
But I'd like to understand what happened a little better.
First you should know that I'm a multi-Linux/multi-boot kind of guy, and
that in every distro I install I depend on their package management system
to keep me out of dependency hel^Hck... ;-7 Of all my currently installed
distros, Arch is the one that seems most likely to install an unadulterated
upstream package, rather than a distro specific {modified} version. And e17
is definitely a package that I wouldn't even attempt to install by hand.
Thus the fact that the only e17 on my laptop that this has happened to is
the one in Arch, doesn't make it distro specific. It probably only means
the Arch e17 is more fully updated... At least that's mt best guess.
Anyway I'm not sure what the e17 version number that I installed to Arch
sometime since my mid March initial installation of Arch itself was, but as
of now the e17 help about lists it as Enlightenment 0.16.999.063.
Prior to this recent pacman -Syu, e17's run prompt worked normally.
Afterwards it's become fussy what the first character I input into it is.
That is I usually start opera via the run prompt and when I type o the
command history displays the last instance of the command And I can in fact
start opera. I also use firefox, though I usually start that from inside
alpine. Today I tried to start firefox from the run prompt. But as soon as
I type an f into the first character position of the command input field,
I get a pop-up error telling me that Enlightenment SEGV'd That also
advises me to compile everything with -g in CFLAGS So far, the the restore
button succeeds in restarting e17 without closing any open applications...
But of course I didn't get firefox. I can start firefox from an xterm. And
I tested that I can type of into the run prompt without an immediate SEGV
But I can't type an f as the first character. I haven't tested the whole
alphabet, But I also can't type a command starting with b or / as the
first character. Though just because I'm stubborn I can tell you that I can
start firefox [via e17's run prompt] with: ~/../../usr/bin/firefox (go figure)
I did say I've got a work around that works for me... I've also got XFCE
installed as a back-up desktop, so I've reassigned the keybinding I used to
pull up e17's run prompt with, to /usr/bin/xfrun4. Which is works just
fine.
How can I a regular Joe user, figure out if this is an actual E17 bug
or if it's an Arch specific thing???
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
Re: [arch-general] KVM with larger console font set in rc.conf[was ...microscoic console font...]
It would appear that on Apr 11, Nicky726 did say:
Joe said:
If I let KMS happen, everything that printed to the screen before the
kernel enabled it is gone. And if I set a larger console font, it clears
the screen again when it enters runlevel 3... sigh I guess that if/when I
choose to use KMS with a large console font, I'm going to have to settle
for dmesg... I could even put a call to dmesg in rc.local. But it wouldn't
be the same as watching the screen to see if any [failed] indicators
scroll by. So whether or not I disable KMS, I'm uncommenting that tty rule
and reinstating my echo statement. That, will at least let me keep an eye
on my rc.local initializations. {Even with KMS larger fonts enabled...}
Hello,
try to use early KMS and keymap hook in mkinitcpio.
Ondrej Vadinsky
Oh great, another thing I gotta learn to do... sigh Well I did know
choosing Arch was going to make me learn a thing or two. ;-7
Actually, When I skimmed the mkinitcpio wiki, I did see something about
the keymap kook grabbing the font to use directly from rc.conf...
Which means that if I figured mkinitcpio out, and got it to load KMS
early enough to leave most of the start up messages intact, it sounds
like the keymap hook would prevent the screen from clearing again upon
entering runlevel 3... If so, It might be worth the time... It's on my
todo list. In the meantime Somebody replied off list and pointed me at
a decent set of fonts that I was even able to get via pacman. So at
least I'm not squinting at my console screens anymore.
Thanks
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
[arch-general] successful pacman -Syu w/new kernal26: Now have microscopic console font :-(
Sigh...
I just did a pacman -Syu. It updated lots of stuff.
The only issues listed in my pacman.log were:
While: updating keystore /etc/ssl/certs/java/cacerts...
ignored import, signature not available:
/etc/ssl/certs/COMODO_Certification_Authority.pem
keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA
Signature not available
And a warning about my manually managed separate primary boot partition
not being mounted... Which will never be mounted during *_any_* Linux
distro's upgrade process...
I compared /boot and /mnt/boot grub entries, verified that the vmlinuz and
kernel.img filenames hadn't changed, Then copied the vmlinuz, and
both kernal.img files from /boot, to /mnt/boot And rebooted...
As far as I can see (so far) the only real issue I have with my upgraded
Arch system is that the size of my console fonts has drastically been
reduced...
Once the gui started, all the X font sizes were just fine. But my eyes
hurt just trying to read the console well enough to login to run startx...
The next thing I did was to edit MY grub's kernel line to include:
vga=normal, and rebooted. But partway through the boot messages the
screen still clears and the font size becomes painfully small.
Next, Even though I've never had to bother with framebuffer before (I
prefer the normal sized console font, and I don't like pretty pictures on
my screen until AFTER I run startx...) I read the FRAMEBUFFER RESOLUTION
SETTINGS comments in the /boot/grub/menu.lst file. And that led me to
the framebuffer section of the grub wiki file. Which in turn led to my
installing hwinfo from aur on this amd_64 laptop.
02: None 00.0: 11001 VESA Framebuffer
[Created at bios.459]
Unique ID: rdCR.mrzO17IxmKC
Hardware Class: framebuffer
Model: ATI MS48
Vendor: ATI Technologies Inc.
Device: MS48
SubVendor: ATI Radeon® Xpress 1150
SubDevice:
Revision: 01.00
Memory Size: 16 MB
Memory Range: 0xc800-0xc8ff (rw)
snip
Mode 0x0312: 640x480 (+1920), 24 bits
snip
the comments in the menu.lst file say on the 16MB line 0x312=786
So I tried vga=786 And rebooted...
Just before the boot messages list :: Bringing up loopback interface
the screen still clears {expletive-deleted!} And then the fontsize still makes
me
squint. {many expletives-deleted!}
Problem #1
How can I stop the reduction in the console font size???
Evidently the framebuffer setting isn't doing it...
Problem #2
How can I stop the boot process from clearing the screen on tty1???
I really dislike ANY of the boot messages to disappear. I LIKE
being able to use gpm to copy/paste them into a console editor...
I didn't like it when it cleared the last few lines just prior to giving
me a login prompt. But at least that could be compensated for by the
kludge of including a multi-line echo statement in /etc/rc.local.
But now that it lops the majority of the boot messages off the top
it's beyond my ability to kludgon it into submission. ;-(
Suggestions anyone?
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
I'm NOT clueless... But I just don't know.
Re: [arch-general] successful pacman -Syu w/new kernal26: Now have microscopic console font :-(
It would appear that on Apr 10, Jeroen Op 't Eynde did say: On Sat, 10 Apr 2010 18:00:53 +0200, Joe(theWordy)Philbrook jtw...@ttlc.net wrote: Sigh... Problem #1 How can I stop the reduction in the console font size??? Evidently the framebuffer setting isn't doing it... Problem #2 How can I stop the boot process from clearing the screen on tty1??? For #1: For the resolution, you probably have some high resolution screen and KMS is now enabled by default. So check here: http://wiki.archlinux.org/index.php/KMS That does appear to be the issue. For me the quick fix was to disable KMS from grub by adding radeon.modeset=0 to the kernel options... For #2: Just edit /et/inittab and comment out the rule with tty1 Yup, that works... I can deal with only having 5 ttys available. AND with having to explicitly choose one before I login. Thanks! -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] Arch Linux Release Question
It would appear that on Apr 8, Isaac Dupree did say:
On 04/08/10 07:21, Joe(theWordy)Philbrook wrote:
My take on it is that while it's always a good idea to be using a
current install medium, with Arch it only matters that your system is
able to become current via update. The release of a new install set in
itself should never be a reason to reinstall a working system.
Good description (although I'm willing to bet there's some little bit of
unimportant cruft on a system originally installed several years ago, due to
various organizational updates, in addition to you as admin forgetting which
files you've left around in /etc...)
No doubt. But cleaning out a build up of cruft on ones own system is a
separate thing from needing to reinstall simply because somebody released
a new install image... Though I'll acknowledge, that if I felt my system
was due for that intense a spring cleaning, I think I'd probably time
it to right after a new install set has been sprung on us... ;-7
All I know for sure is that while Arch takes a bit more work to get a
running desktop system than some other distros, The idea of not having
to start from scratch every 6 months makes it way worth it...
if you don't mind running old versions of software... which I do...
I take it that you don't feel that pacman -Syu or if applicable
something like yaourt -Syu –aur Will bring your Arch system as fully
up to date as installing the latest Ubuntu release, followed by an
apt-get dist-upgrade would???
As a dedicated multi-Linux, multi-booter I usually have three or more
distros installed. I've noticed enough variance in software
versions between fresh installs of the latest OS releases of enough
distros to know that a new install of a new OS release is no guarantee
that *_ALL_* of the software will be the latest possible release.
I've learned that if I can only find the right wiki entry, there is
usually a good comprehensive walk through of whatever I need to do to my
system. And this way, I wind up with a better understanding of my system.
oh indeed! Over the years, the Gentoo wiki has been a pretty good source of
info too (whatever distro you're on), and even the Ubuntu wiki has some nice
info for specific hardware (MacBooks at least), etc. Arch has a pretty good
wiki now also!
I'll agree that there's good stuff in the other wiki(s). But the Arch
wiki impressed me with how it approaches how-to instructions with
regard to helping users who really don't have a clue yet, work their
way through it. At least, that's the impression I got from the
Beginners Guide, And nothing in the 17 arch wiki bookmarks I've added
to my ~/lynx_bookmarks.html so far. Along with the fact that all of
them lend themselves well to using a console browser like lynx. Which
was helpful when I was trying to get X up and running..
So as long as the rolling release process turns out to be consistently
more reliable than updating a 'buntu system to the next release {by
editing the sources list and doing an apt-get dist-upgrade (2 out of 5
such upgrades really hosed my my 'buntu installs...)}
You did it wrong, according to Ubuntu documentation. Ubuntu (unlike Debian)
(well, I'm not sure about ubuntu-server...) only supports the GUI update
manager as an update path (I believe it does a few more things than a mere
dist-upgrade, depending on the particular upgrade; and by not doing those
things, you're asking for trouble...). On the other hand, I can't vouch for
the official upgrade path being terribly reliable (I usually reinstalled in a
separate partition because there was no way to roll back on the same partition
if the new release had different hardware problems that I didn't yet figure
out how to solve).
Yeah I know the Ubuntu devs only recommend using a Gui method. BUT:
1)My 'buntu experience started with KUbuntu, Where (at least at the
time) the apt-get method WAS still recommended. (kde users didn't much
like depending on a gnome gui tool...)
2) Even now if you look deep enough, there still exist valid
command line methods... For example check out this excerpt from
http://ubuntuguide.org/wiki/Ubuntu:Karmic
- Upgrading Intrepid or Jaunty to Karmic
-
- * Also see the official Ubuntu desktop upgrade documentation.
-
- There are several methods for upgrades from the command-line interface
- (Terminal) (which can be used for both the desktop and server editions of
Ubuntu/Kubuntu).
-
- * This is the preferred method:
-
- sudo apt-get install update-manager-core
- sudo do-release-upgrade
-
- * You can also use the update-manager (all editions):
-
- sudo apt-get install update-manager
- sudo update-manager -d
-
- * You can also use:
-
- sudo apt-get update
- sudo apt-get upgrade
- sudo apt-get dist-upgrade
-
- (Note: the first two lines simply make sure your current distribution is
- current before upgrading the entire distribution, and are optional
Re: [arch-general] Arch Linux Release Question
It would appear that on Apr 8, Lukáš Jirkovský did say:
Hi David,
It doesn't matter whether you use the
latest install set or the one from 3 'releases' back, after the first
update,
you will have the exact same, current Arch Linux we all have. It is the
smartest
way to do a Linux distribution -- hands down.
I don't agree with you. For 99 % (just guessing) packages it's true,
but if you need new kernel to correctly boot it's a problem. The fact
that in the repo is kernel new enough for you to boot but installer
has too old kernel is not really a way how to attract users.
I hope you don't mind an {Arch-newbie} jumping in here... ;-7
Perhaps what David should have said is something like:
[paraphrase]
It doesn't matter whether your Arch system was installed yesterday using the
latest install set or was previously installed using the one from 3 'releases'
back, after the next update, you will have the exact same, current Arch Linux
we all have. It is the smartest way to do a Linux distribution -- hands down.
[/paraphrase]
My take on it is that while it's always a good idea to be using a
current install medium, with Arch it only matters that your system is
able to become current via update. The release of a new install set in
itself should never be a reason to reinstall a working system.
All I know for sure is that while Arch takes a bit more work to get a
running desktop system than some other distros, The idea of not having
to start from scratch every 6 months makes it way worth it...
I've learned that if I can only find the right wiki entry, there is
usually a good comprehensive walk through of whatever I need to do to my
system. And this way, I wind up with a better understanding of my system.
So as long as the rolling release process turns out to be consistently
more reliable than updating a 'buntu system to the next release {by
editing the sources list and doing an apt-get dist-upgrade (2 out of 5
such upgrades really hosed my my 'buntu installs...)} then I'll be singing
praises to the rolling release concept for a long time. (I really detest
having to recreate my user environment every 6 months...)
Nuff said.
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
Re: [arch-general] kaffeine [sigh] is there an alternative that:...
It would appear that on Mar 31, Guilherme M. Nogueira did say:
On Wed, Mar 31, 2010 at 10:49 AM, Joe(theWordy)Philbrook
jtw...@ttlc.netwrote:
[ ... ]
99% of the time what I want is to just play the whole list in random order
with an easy hot key to skip any I decide, upon hearing, that I'm not in
the
mood for.
That is exactly what I do, with a collection of about 10.000 songs.
I use MPD and ncmpcpp frontend, which is great.
with ncmpcpp you just go with TAB to change from playlist to browser and
vice-versa
and press SPACE to add a directory and all its subdirs to the playlist.
So, if you have a top directory where all your mp3s are stored (like I do),
you would
just go to browser and press SPACE on this top dir, and you have the
playlist with
all your songs.
Press 'z' to turn random on and off. User up and down arrow keys or pgup
pgdown
to navigate the playlist, and ENTER to play a song.
Well the MPD/ncmpcpp combo might work for me. But I liked the default
keybindings attributed to MOC. Then I found out it's browser is very much
like mc... So I decided to try MOC first. {errr make that mocp}
So far MOC works for me... I was able to get it from the official
repositories of all 4 of my installed linux distros. But if it acts up
I'll look into MPD/ncmpcpp...
It would appear that on Mar 31, Linas did say:
Joe(theWordy)Philbrook wrote:
Actually though *_IF_* the $PLAYER doesn't choke on the lines representing
each
directory itself being included with the list of the music files within it,
so that
I don't have to edit the resulting .m3u file. -snip-
find -type f :)
You may want a script to automatically update the list, run it manually
or from cron, add -name constraints for some file types...
I just wanted to remind you that you can use it. Advanced options are an
exercise for the reader :)
Thank you for that Linas, that works great. Once I figured out that it
was actually find $path -type f that is... ;-)
You have basically rescued kaffeine for me. Thanks! Though, depending on my
mood, I'm starting to like MOC
It would appear that on Mar 30, David C. Rankin did say:
You know, it just really makes your wonder -- What were they thinking?? That
combined with all the basic operations that now require ctrl+alt+shift+F11
what
used to be a simple mouse-click, has completely reinvented finger twister.
I don't know what they were thinking. But it sure wasn't how to keep me
using it... KDE4 forced such a change in user methods. (Felt like a Resistance
is futile. You have no choice. You WILL use your PC OUR way. mind set) Any
way it reminded me of why I left Microsoft behind.
But I can't quite agree with the complaint you listed. KDE (even KDE4) lets
you change most keybindings. So finger twisters are avoidable. And
personally, I'd rather have to:
RighthandCtrl+LefthandAlt+BothShifts+F11 then get stuck HAVING to
click on something. One of the things that bugged me with KDE4 was how
many things I used to be able to do without dusting of the trackball,
that were no longer practical without clicking... Especially the
keyboard shortcut assignment method. With kde3, I didn't need to touch the
mouse at all to assign shortcuts. (unless I wanted to assign a 2nd
shortcut) This just isn't practical with KDE4. So of course, I've kind of
adopted E17 as my new favorite desktop, and their keybinding gui is just
as mouse intensive. (sigh) go figure...
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
Re: [arch-general] kaffeine [sigh] is there an alternative that:...
It would appear that on Mar 30, Heiko Baums did say: I don't know if it meets your requirements regarding the playlist, but the best audio player I know is MOC (http://moc.daper.net). It has the best sound quality of every player I know and is controlled by keyboard. You can set a global music directory in its config file and by pressing 'a' it appends the selected file or recursively every music file in the selected directory and its subdirectories to the playlist. Well I suppose if it's easy to add music files recursively to the playlist. AND if it's just as easy to wipe the old contents, it might work for me. Pressing 'h' brings the help screen. That's a nice touch... It would appear that on Mar 30, ludovic coues did say: have you try mpd ? mpc allow you to lod every file from the mpd's music directory with a single commnd like `mpc findadd Title ` No I haven't. But to be honest, While I want keyboard control, I don't really want to deal with remembering a command syntax when I just want to get my music going so I can work to it... It would appear that on Mar 30, Xavier Chantry did say: On Tue, Mar 30, 2010 at 8:46 AM, Joe(theWordy)Philbrook jtw...@ttlc.net wrote: Could somebody recommend another media player I could try that will let me create temporary music lists on the fly by typing the path to a parent dir containing multiple music directories??? I don't know any music player that does not allow that. The Kaffeine from kde4... grin One that understands keyboard commands for it's functions??? And same here. It's probably true that most do have some shortcuts, But they're not always obvious. I must confess to being partial to a keyboard accessible pop-up menu like Kaffeine uses where alt+F opens the file menu. And alt+P lets me at the player commands etc... That way I don't have to memorize the assigned keybindings... Anyway I would suggest you to keep trying audio players until you find one that suits your need. Yeah I guess your right. Of course when one doesn't know the names of very many of them, it can be hard to know what to try... For example here is a list of light one : http://wiki.archlinux.org/index.php/Lightweight_Applications#Audio_Players I might have known Arch would have a wiki for this... sheepish grin The console/curses one are made exclusively for keyboard control. That's good to know... It would appear that on Mar 30, Ian-Xue Li did say: On Tue, Mar 30, 2010 at 01:12:15PM +0200, Linas wrote: If your main problem is to create playlists for a recursive music tree, I guess that this would work with pretty much all players: find /path/to/music music-list.m3u $PLAYER music-list.m3u One shortcoming of this way is that you might need a expert shell script to update the lists containing the file, plus that filename handling needs some work with shell scripts. Actually though *_IF_* the $PLAYER doesn't choke on the lines representing each directory itself being included with the list of the music files within it, so that I don't have to edit the resulting .m3u file. Then it looks like updating would be handled by simply letting the command overwrite the old .m3u with the new contents... So I guess it wouldn't require that fancy a shell script. Probably even I could write one... Opon the original issue, I think any music player with databases would suit the original writers need. For example, exaile. I'm more interested in the ability to quickly generate a these are there now playlist than in trying to keep an existing database up to date... As for MOC, I recommend cmus over MOC because it got more decoder over different types files. That might be useful. It would appear that on Mar 30, Xavier Chantry did say: Heh cmus is probably my preferred player now so I ought to defend it. Too complicated, seriously ? The only command I ever need is the initial one to add my music directory : # add files, short for ':add ~/music' :a ~/music After that, all you need is 3 keys : space to expand an artist and view the albums, enter to play what you want, tab to switch between album view and track view if you want a particular track. 99% of the time what I want is to just play the whole list in random order with an easy hot key to skip any I decide, upon hearing, that I'm not in the mood for. By the way, in the main/default mode, you don't see directory, you see artist/albums from tags. That would bug me. tags smags IF I'm looking at album/artist info what I want to see is the durned directory names I filed the music under... I could care less what the original album names were. Everything I want to know IS in the pathnames... And these 5 shortcuts can be useful too : x player-play c player-pause v player-stop C toggle continue s toggle shuffle You
Re: [arch-general] /etc/rc.local: chown user: /dev/sda10 /etc/fstab: defaults, owner, noauto
It would appear that on Mar 29, Thomas Bächler did say:
Am 29.03.2010 15:01, schrieb Joe(theWordy)Philbrook:
I was pleased to note that Arch evidently does think a rc.local is an
appropriate place for local initialization stuff to happen. However it's
come to my attention that about 5 out of the last 25 times I've booted Arch
only 2 of the 3 partitions 'chown'ed in my /root/bin/fix_dev script can be
mounted by my user account. (unless I use root account to manualy rerun
the /root/bin script...)
On the occasions when a user script's attempt to mount the 3rd such
partition
fails {with an error message telling me that only root can do that} the
other
two such partitions mount just fine.
USB devices are detected asynchronously (other too, possibly). The
device node may be (re)created after rc.local has finished.
Yeah USB devices should be... All three of the partitions in question
are on the one and only internal hard drive of my laptop...
the fix_dev script consists of:
chown jtwdyp: /dev/disk/by-label/jSTUFF_lap-8
chown jtwdyp: /dev/disk/by-label/Jimages_lap-9
chown jtwdyp: /dev/disk/by-label/j10_lap-10
which normaly represent /dev/sda8 /dev/sda9 /dev/sda10
It would make sense to me that the whole device node might get
recreated if I attached or removed a device. But why would it recreate
the device node for /dev/sda10 without also recreating the nodes for
/dev/sda8 /dev/sda9
It wouldn't bother me so much if it wasn't for the fact that of all my
user scripts that expect to mount or umount any of these partitions the
one that's been getting these errors is actually my ~/.bash_profile which
mounts all three on user login. Which 99.9% of the time is the first
thing I do after boot up is complete.
Is there something special I need to do to get Arch to *_consistently_*
respect
all three chown commands???
man udev
I am thinking about something like:
SUBSYSTEM==block, ENV{ID_FS_UUID}==your_uuid, OWNER=your_user
in a late udev rule file (say, /etc/udev/rules.d/99-local-disk.rules).
Thank you!
I do wish that the authors of various man and info documentation
believed even half as much as Arch's wiki files in explaining how to
to someone who doesn't already know, rather than just reminding some
professor which options are currently compiled in...
I know for certain that man udev wouldn't have given me a clue how to
write that example rule template, even if I'd studied it for a year and
a day.
Thanks again! But: sigh
I hates UUID (or any other human NON-readable device id, config files,
etc...) considerably more than Yosemite Sam ever hated rabbits. ;-7
Actually I only converted to using /dev/disk/by-label/ when I recently
decided to try Arch and the {much better written than most} Arch wiki
convinced me that I should convert to Persistent block device naming.
{And which even gave step by step instructions for naming various FS types}
I do hope this is a valid adaption of the above template:
SUBSYSTEM==block, ENV{ID_FS_LABEL}==j10_lap-10, OWNER=jtwdyp,
GROUP=jtwdyp
But I wonder if this would be applicable to my other linux as well?
That is maybe I won't need to bother running my fix_dev script anymore...
--
| ~^~ ~^~
| * * Joe (theWordy) Philbrook
| ^J(tWdy)P
| \___/ jtw...@ttlc.net
Re: [arch-general] /etc/rc.local: chown user: /dev/sda10 /etc/fstab: defaults, owner, noauto
It would appear that on Mar 30, Thomas Bächler did say:
Am 29.03.2010 23:58, schrieb Joe(theWordy)Philbrook:
I do hope this is a valid adaption of the above template:
SUBSYSTEM==block, ENV{ID_FS_LABEL}==j10_lap-10, OWNER=jtwdyp,
GROUP=jtwdyp
Looks fine to me.
But I wonder if this would be applicable to my other linux as well?
If it uses udev, it should work.
Thank you for the confirmation Thomas, empirical testing will soon
confirm if it works in my arch installation as I've already included
3 such rules in my new /etc/udev/rules.d/99-local-disk.rules file,
and commented out the line in my rc.local that sourced my old kludge.
As of this boot cycle I can at least confirm that the addition of the
udev rule file caused no errors. Next boot should confirm that I don't
need the kludge anymore... If it fails, I'll follow up here...
But since I expect that this is my last posting on this thread, I'd
like to thank you again for so kindly including such a well formed
example when you suggested I man udev. Incidentally your example
included the scroogle search term ENV{ID_FS_UUID} which wasn't in
the man udev output except in very general terms that assumed the
reader knew what key values were possible. That soon led to a
confirmation that ID_FS_LABEL was also a valid key. the GROUP
variable name was mostly a guess that was initially confirmed only by
vim's syntax highlighting that color matched it to OWNER.
But if I'd had to depend on man udev, I'd still be as stuck as I was
the last time I tried to understand what udev was all about. back when
the attempt turned my brains to mush until I figured out how to
implement my kludge (I think that was on Kubuntu breezy, but it might
have been fedora core 2... I lose lots of memories to CRS ya know)
But like I said Thomas:
HH HHAA NN NN KK
TT HH HH A A NN KK KKSSSS
TT HH HH AA AA NN NN NN KKKK SS
TT HH NN NN NN KK KK S
TT HH HHAA AA NN NN NN KKSS
TT HH HH AAAA NN KK KK SSSS
TT HH HH AA AA NN NN KKKK
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
Re: [arch-general] I'm having a brain far^Hilure... I can't find the XFCE control
??? -- | --- --- | Joe (theWordy) Philbrooko o | J(tWdy)P ^ | jtw...@ttlc.net /---\ bla bla bla... | \___/ ...and bla... At least I know my mouth is running, I just can't find the off button!
Re: [arch-general] I'm having a brain far^Hilure... I can't find the XFCE control
It would appear that on Mar 21, Joe(theWordy)Philbrook did say:
Thank you bardo! Trouble is I just tried that and I still get icons for
any files in ~/Desktop.
big snip
Hunh? Now I'm confused. I verified that Icon type setting (which was already in
place when I fired up XFCE today...) And I poked around doing a couple of
other tasks that needed doing for nearly a half hour before I composed that
last longish reply {which basically said it didn't work and added a *Lot* of
verbiage about why I didn't want the icons cluttering up my desktop} Then
when I thought I was done with my email I closed he nearly fullscreen
terminal Alpine had been running in. and hunh?, the icons were gone???
They *_WERE_* still there when I started composing that message. And that
was at least an hour since the last time I reaffirmed Icon-type = None
in the desktop settings... They were I tell you.
But now about another hour later they spontaneously disappeared...
Is XFCE stable? Does it only process config changes at certain times of
day? What could possibly account for it taking hours ( actually several
reboots PLUS hours since I first made that desktop setting say None.)
for it to start respecting the setting
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
Re: [arch-general] I'm having a brain far^Hilure... I can't find the XFCE control
It would appear that on Mar 21, Heiko Baums did say: Xfce is stable. Changes at the .desktop files in /usr/share/applications (the menu) are processed only after Xfce is restarted or immediately by running `update-desktop-database` as root. I think they are also processed without restarting Xfce once in a while. I don't know if this also applies to the .desktop files in ~/Desktop, but I think so. Well that only leaves me wondering why it didn't take the first time I set that to None... But as long as it continues to work like it's working now, then I really don't care... -- | ~^~ ~^~ | * * Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ jtw...@ttlc.net
Re: [arch-general] I'm having a brain far^Hilure... I can't find the XFCE control
It would appear that on Mar 21, Heiko Baums did say: Am Sun, 21 Mar 2010 09:15:43 -0400 schrieb Joe(theWordy)Philbrook jtw...@ttlc.net: BTW I don't suppose you know of a way to get a different background image on each XFCE workspace??? That's currently not possible on Xfce. There's already a feature request for that in Xfce's bug tracker since more than 5 years. That figures... Still, I run multiple desktops and to be honest I'll spend most of my time in either E16 or E17 depending on my mood... I used to install those to various kde based Linux installations (I still have a strong preference for a few kde apps) But kde lost me with kde4. And so far XFCE has proven to be a reasonable substitute for almost everything I used to like kde3 for. As a back-up and occasional change of pace desktop I can put up with only having one wallpaper... What's slightly less good is how well saving a session doesn't quite work. You see, I thought of another way to visually mark a few workspaces... I put the xdalicock on the upper left corner of one workspace, Put oclock on the upper right of another. Xclock --digital in the bottom of a third. And in the one I'd use foe music or video media I put both kaffeine the default mixer... Then I logged out with the save session option checked. It remembered where to put xdaliclock mixer. Both oclock xclock wound up on screen center of the 1st workspace. And it wouldn't restart kaffeine at all... sigh Ah well, can't have everything. And like I said, so far XFCE has been a fair substitute for kde and a great backup to enlightenment. Well have a good one! -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net
Re: [arch-general] fdisk vs cfdisk... And is my drive borked or what?
It would appear that on Mar 18, Mauro Santos did say:
Gparted (which is just a frontend for parted) may be able to resize your
extended partition without touching any of the logical partitions inside
(you may need to delete your last partition first though, it all depends
on what alignment gparted will try to use), however I try not to use
gparted because once it wrecked havoc during a resize operation, because
of that and because I have a big enough spare disk, I always do a full
backup before any major partition changes.
Tried it... Gparted didn't like my existing partition table any better than
cfdisk did... It refused to use the table data. But unlike cfdisk it was
willing to proceed in case I wanted to recreate the whole thing from
scratch...
Your primary partitions are safe but the logical ones can just vanish if
things go wrong. I guess that if you take note of the start and end
sectors for all partitions you can recreate the layout if anything goes
wrong (I have never tried it though so I can't say how well that will work).
I can now certify that rebuilding them with fdisk works... ;) {see below}
It would appear that on Mar 18, Guus Snijders did say:
To be safe, first make an *exact* note (on paper) of the current partition
table. If anything goes wrong, you can boot a rescue CD and recreate the
partition table from this note.
You could also make a copy of the first sector with dd and store that on some
media (USB hdd comes to mind), but i would still make the paper note.
I did print the partition table data... I'm not good with dd. I've got
explicit notes on using it to backup/restore the mbr, and have a copy of
that on the usb drive (is that what you mean?) but using it back-up the rest
of the partition table is beyond me.
After that, just change the end sector of the extended partition to match the
end sector of your swap partition and you should be fine.
(try starting cfdisk at this point to see if the error still exists).
Basically that's what I did with fdisk. I had a text file with the table
data in it on the usb drive. which I opened in one window while I ran fdisk
in another. It let me delete the old extended partition without explicitly
deleting the logical partitions, But of course when I recreated it, I
pasted the ending value from the swap partition. Then proceeded to recreate
the logical partitions the same way. (I had used the fdisk u to set units
to sectors:
1)type n copy the default beginning sector to clipboard
2)switch to the window with the text file open with vim
3)paste number next to old starting value to confirm values match
4)copy the ending sector from the old data to the clipboard
5)switch windows to the fdisk session
6)paste in the ending sector.
7)repeat 1-6 until all logical partitions had been recreated
8)use t to reset the type of the swap partition back to 82
w write table...
And it worked.
If you're feeling brave, you could also recreate the entire partition table
from scratch. It's just a table listing which partitions are where. Nothing
more.
I could have done that. But why mess with the 1st 3 partitions???
If you don't fully trust the process, you could try mounting the data
partitions after the change. If that succeeds without errors, it should be ok.
I trust it better now...
It would appear that on Mar 18, Linas did say:
It works. But you should copy the values *in sectors*. It's amazing how
different tools interpret the same values on different actual positions.
Well I could have recreated the whole table from scratch with gparted. But I
felt more secure using fdisk, since it was fdisk that provided the sector
data...
The good news is afterwards, I rebooted (successfully) And then tested
cfdisk, which no longer complains. I figure if cfdisk is willing to work on
it, my partition table must now be nearly perfect...
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
[arch-general] I'm having a brain far^Hilure... I can't find the XFCE control
I know it can be done. I've done it twice, once in Xubuntu, and once in PCLinuxOS... I've managed to turn off all the other annoying desktop icons. But I cant find the control to tell it to stop cluttering up my XFCE desktop up with iconic representations of my hard drive partitions. could somebody give me a clue how to disable them? Thanks! -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
Re: [arch-general] I'm having a brain far^Hilure... I can't find the XFCE control
It would appear that on Mar 19, Heiko Baums did say:
Am Fri, 19 Mar 2010 14:50:36 -0400
schrieb Joe(theWordy)Philbrook jtw...@ttlc.net:
could somebody give me a clue how to disable them? Thanks!
Right click onto the desktop. Then desktop settings - Icons or Symbols
(I don't know how it's called in the English version).
OK I tried that it got me to the same place as:
PopupMenu-settings-desktop-icons
Which is where I turned off the other icon types. this lists only 4 choices
for:
[ ] Home
[ ] Filesystem
[ ] Trash
[ ] Removable Devices
Unchecking the first three each removed one icon. The last would only come
in to play if I plugged in a removable device such as a usb drive...
I've unchecked ALL of them but there are still 12 icons sitting there. Nine
of which are marked with a truncated form of the 9 labels found in
/dev/disk/by-label
I'm not sure what the other three are... But thanks for the suggestion, it
is after all where the control should be...
Hmmnnn Wait a minute!
I just looked into the directory ~/Desktop and found 12 symlinks to some
entries from my newly installed Enlightenment desktop... But I installed
XFCE first. And I distinctly remember scowling at those icons BEFORE I
installed Enlightenment {where they hide the setting to NOT display such
icons in the filemanager setups of all places...} Still since more than one
Desktop environment may put things in ~/Desktop, there should be a setting
somewhere to turn off displaying them. I just can't find it. Sigh I
suppose I could use a brute force kludge to get them off the desktop.
There would be no point in removing the Desktop directory itself as it would
just get automatically recreated. But I could delete the symlinks from it and
then chmod 000 ~/Desktop which should stop anything but a root process from
recreating them. But I have no idea if some desktop process will react
poorly to not being able to use the Desktop directory.
Yup, that did it! Had to restart xfce before they went away. But at least
they are gone from my desktop...
--
| --- ___
| 0 - Joe (theWordy) Philbrook
| ^ J(tWdy)P
|~\___/~ jtw...@ttlc.net
Re: [arch-general] fdisk vs cfdisk... And is my drive borked or what?
It would appear that on Mar 17, Linas did say:
Joe(theWordy)Philbrook wrote:
fdisk /dev/sda
Which complained about a dos compatibility flag and that I should
change the display/entry units to sectors. This showed me a small bit of
unused space above my last logical partition (/dev/sda12)...
It shows those two warnings with the default call. AFAIK it is unrelated to
your actual partition contents.
I'll buy that... The odd thing is the fdisk from my other distros doesn't
bother... So the warnings got my attention.
Anyway I decided to look at it with cfdisk (which I haven't used in years
but remembered as being easier to work with than fdisk...) But all I got
from cfdisk was.
= FATAL ERROR: Bad primary partition 3: Partition ends after end-of-disk
= Press any key to exit cfdisk
When cfdisk /dev/sda says partition 3: is it counting from 0?
That is, does it mean /dev/sda4 ???
Could be.
I've pasted both the sector and cylinder views of my part table below, Is
this anything I should be worried about??? Is there a way to fix this
without destroying everything in the extended partition??? (That's a LOT of
backing up to dvd, and I don't have room anyplace else...)
Caveat emptor: you should have a backup before touching partitions :)
That said, you only want to truncate the partitions, and since your last
partition is the swap, that should be pretty safe. The process of unmounting
swap partition, delete partition with fdisk, create with fdisk, reformat swap
/shouldn't/ affect your data.
I hadn't intended to touch the partitions. I only gave the malfunctioning
installer permission to reformat an existing ext2 partition as ext3.
That's an mkfs job that shouldn't have led to ANY table rewrite, never mind
writing to the table of a different drive...
Also, backing up everything isn't always practical. I really don't
have the spare storage space. So backing up 4 Linux installations would
eat a *LOT* of time and several DVD's... I do have enough room on my usb
drive to back up the personal data partitions. But if I bork up the drive
while fixing this I'm going to have to do a *LOT* of reinstalling from
scratch. Which leads to a *LOT* of painful configuring... But I note
that while the ending sector of the extended partition apparently
exceeds the drive's ending sector... The ending sector of the last
logical partition within it does not... So I don't think I need to redo
the swap. but rather (and for me more problematic) just the extended
partition that contains it. {I'll have more on that in my reply to Mauro below.}
It would appear that on Mar 17, Mauro Santos did say:
On 03/17/2010 10:45 PM, Linas wrote:
Joe(theWordy)Philbrook wrote: {quote tag re-inserted by Joe...}
= FATAL ERROR: Bad primary partition 3: Partition ends after
end-of-disk
= Press any key to exit cfdisk
cfdisk can complain if _anything_ isn't as it wants it to be. cfdisk is
easier to use than fdisk but complains a lot if the partition table
deviates a little from the most compatible format possible.
So I noticed... But I think it does have a point.
Because that's my extended partition... And a close look at the ending
cylinder/sector of /dev/sda4 is a slightly higher number than it reports
the total cylinders/sectors to be...
I take it that the first listing is in sectors, if you look closely you
will see that your last partition (swap) end before the end of the disk
so you're safe, the extended partition is just a placeholder for other
partitions, so if the partitions do not try to use space that doesn't
exist it should be ok. However I would still try to rectify the ending
of the extended partition. Backup all your data and try to shrink that
extended partition until it fits in your disk.
I can backup all my personal data... But I don't have the room to back up
all my Linux installations. Rebuilding them all from scratch, all at once
would be a nightmare. But it's a risk I'll have to take. I'm not so sure
how to shrink the extended partition itself. cfdisk won't touch it. And if
I remember right, to do it with fdisk I basically have to delete and then
recreate the said extended partition using the correct sectors... But that
would, I think mean I'd have to delete the logical partitions first, and
then recreate them with their correct sector information within the
correctly recreated extended partition.
(And pray I got it right before I write the rebuilt table.)
I've never used gparted (unless maybe it was used as a backend for the set
up your partitions manually section of some Linux installer???
But does it have the ability to resize a NON-empty extended partition?
If not, is there something I can get from pacman that does?
And is it any more risky than the tedious fdisk process I described above?
I find an oddity on your paritition table, though. You say that
/dev/sda4
Re: [arch-general] HAL depreciation
It would appear that on Mar 17, Jan de Groot did say: At this moment several applications, including XFCE and KDE, use hal for removable device handling. xorg-server still uses hal to configure input devices. Starting from xorg-server 1.8, we'll disable the hal backend and switch to udev, devices will get configured through udev rules in that case. This will cause some breakage of existing setups, but there's no way to enable both backends. KDE should support udisks/upower in the next major release. I don't know about XFCE though, but if that one follows, I'm almost sure hal will no longer exist in 2011. Hopefully the nice wiki Beginners'Guide will get updated to tell dummies like me how to set up x without it... And just as important, a nice how to fix your hal dependent, thus borked in 2011 arch system wiki document that is as easy for newbies to find and follow as the said beginners guide... I'm new to Arch, and way to used to the way other distro's do things. Following this guide (last night) was the very first time I got a working x server that wasn't handed to me by the installation cd/dvd. And I gotta say that so far I'm VERY impressed with the arch wiki documents. They actually seem to be written to instruct the guy who doesn't already know the answers... So how will this up and coming demise of hal affect idiots like me who don't know how to do what we can't find in the wiki??? -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net
Re: [arch-general] on rolling release / reinstallation
It would appear that on Mar 16, Isaac Dupree did say:
I enjoyed the 6-month reinstalls... for a while. They reminded me how my
system was set up ; to make backups ; etc.
I've got a slight difficulty with that... I've been a multi-boot guy for a
long time. It started because sometimes I couldn't get the cd burner
working in the same distro as the soundcard, on my old decrepit (now defunct)
desktop. Then one day I, (or some upgrade) borked my bootloader, {I think it
was lilo at the time...}, And I had to try to use a rescue cd... Yeah right! I
didn't know to type /usr/bin/mc instead of mc which wouldn't have helped
anyway because it turned out that rescue disk didn't have mc... {Without which I
have a hard time navigating the file system. (Why a non-gui rescue disk wouldn't
include mc is beyond me...)} Worse I didn't know which partition was which. And
being an extreme klutz with any rodent based control system, I'm excruciatingly
dependent on the keyboard shortcuts my fingers are already used to... And
unfortunately almost none of them match the default global shortcuts of any
window
manager or desktop I've tried to date... Thus the gui rescue/live cd wasn't any
easier.
I'm never comfortable unless I've got at least 3 fully configured
and personalized linux installations, from different distros, so that it's
very unlikely I'll have to use some rescue or live cd that my fingers don't
already know where to find things, or that I won't be able to use my Email
to seek help...
There are actually quite a few non-standard configurations built into my
personal
~/ user file system. Such as (I don't use a /home partition because each distro
may
have different versions of software that may have fits over incompatible
~/.{somethingrc} files.) Instead I have user owned personal partitions
mounted at places like ~/mail ~/images etc...
But the keyboard shortcuts alone make reinstalling a distro a bit of a
nightmare to
me. I mean it's not like very many desktops/window managers will let me set my
global
shortcuts by editing a config file when that desktop isn't actually running.
(e16 is
the only exception I've found so far, and e17 took that nice human editable
config
file away... For a while I could force feed my keybindings to e17 with
something
called enlightenment_remote. (thanks to a bash script that somebody else wrote
to use it to extract configuration settings into an output bash script
consisting of
a list of enlightenment_remote commands to restore them. And the keybinding
section could be used on a different version of e17 (Until the e17
developers decided that the gui tools now included enough utility to stop
supporting the underling code that enlightenment_remote depended on...)
And then there's the application shortcuts...
And did I mention that just as I'm not comfortable with having only one
distro on my PC, I'm also have never been happy with just one
desktop/window manager on any installed distro (at least not since kde4
chased me away from kde...) currently I like XFCE as a back up to e16 e17
in part because it's fairly easy to pump in the shortcuts via pasting into
the add shortcut input box snippage from my e16 bindings.cfg file.
Actually every time I have to do this I wind up spending so much time
reconfiguring the new install just to get it to the point where I can
stand to use it that for at least a week, my Lady is in danger of
forgetting what I look like.
Workarounds are easier, but need to be done more often than once
every six months. It was nice to be able to do upgrades during my
school-vacation-time rather than when I have a paper due shortly
(there's ALWAYS a paper due, or an e-mail to get back to, at my
college..)
That makes me think... I'm new to the rolling release concept.
So I'm guessing that these workarounds happen whenever a pacman -Syu
leads to breaking something... (Which means that I probably should only
do an pacman -Syu when A) I've got time to test all my stuff.
AND B) I've got time to look for a workaround that I hope someone else
already figured out...)
My question is how often would you recommend doing a pacman -Syu to avoid
having so many workarounds that you feel like it might have been easier
to reinstall
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
[arch-general] fdisk vs cfdisk... And is my drive borked or what?
I'm new to Arch. I recently dumped a very bloated Sabayon installation which left me enough room on my laptop for two other distros... I went with PCLinuxOS AND Arch because both sounded like reinstalling from scratch wasn't a twice a year thing... Actually I tried installing PCLinuxOS on a usb drive before I dumped Sabayon. But something went wrong in the first attempt when the installer formatted the new PCLinuxOS root partition on /dev/sda (as it called my usb drive) and promptly wrote the partition table to /dev/hdb (as it called my laptop's internal drive... ARGH! Fortunately after a send attempt succeeded in installing to usb drive succeeded some tool called testdisk: was able to restore my laptop's partition table. And every thing worked again... (That was the last time I'll ever let an installer format anything. Strictly pre-partition and pre-mkfs from now on...) Any way I only mention it because When I got around to installing Arch on one of the two partitions I recovered from Sabayon, I skipped the installation step of letting cfdisk touch my partitions and simply selected the partition I previously prepared for it with mkfs.ext3. But later as working my way through the beginners guide in the wiki, the clear explanation of why distro's like to use UUID instead of /dev/Xdx# sold me on using persistent (BUT HUMAN READABLE!!!) entries like: /dev/disk/by-label/Arch_lap-7 /dev/disk/by-label/SWP_lap-12 Especially since there was a wealth of how-to info right there in the wiki... But in the process I happened to do an: fdisk /dev/sda Which complained about a dos compatibility flag and that I should change the display/entry units to sectors. This showed me a small bit of unused space above my last logical partition (/dev/sda12)... Anyway I decided to look at it with cfdisk (which I haven't used in years but remembered as being easier to work with than fdisk...) But all I got from cfdisk was. = FATAL ERROR: Bad primary partition 3: Partition ends after end-of-disk = Press any key to exit cfdisk Which considering the recent testdisk repair, frightened be a bit. But it also frustrated me. Especially since fdisk didn't show anything like that... Unless maybe: When cfdisk /dev/sda says partition 3: is it counting from 0? That is, does it mean /dev/sda4 ??? Because that's my extended partition... And a close look at the ending cylinder/sector of /dev/sda4 is a slightly higher number than it reports the total cylinders/sectors to be... I've pasted both the sector and cylinder views of my part table below, Is this anything I should be worried about??? Is there a way to fix this without destroying everything in the extended partition??? (That's a LOT of backing up to dvd, and I don't have room anyplace else...) -- | ~^~ ~^~ | ? ? Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ jtw...@ttlc.net Disk /dev/sda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x4573c650 Device Boot Start End Blocks Id System /dev/sda1 * 635545637927728158+ 7 HPFS/NTFS /dev/sda25545638068372639 6458130c W95 FAT32 (LBA) /dev/sda36837264070332569 979965 83 Linux /dev/sda470332570 23445260982060020f W95 Ext'd (LBA) /dev/sda570332633 10353892416603146 83 Linux /dev/sda6 103538988 13674527916603146 83 Linux /dev/sda7 136745343 16995163416603146 83 Linux /dev/sda8 169951698 175815359 2931831 83 Linux /dev/sda9 175815423 183622949 3903763+ 83 Linux /dev/sda10 183623013 195334334 5855661 83 Linux /dev/sda11 195334398 2328418555043+ 83 Linux /dev/sda12 232444548 234436544 995998+ 82 Linux swap / Solaris Disk /dev/sda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x4573c650 Device Boot Start End Blocks Id System /dev/sda1 * 1345227728158+ 7 HPFS/NTFS /dev/sda234534256 6458130c W95 FAT32 (LBA) /dev/sda342574378 979965 83 Linux /dev/sda44379 1459482060020f W95 Ext'd (LBA) /dev/sda54379644516603146 83 Linux /dev/sda66446851216603146 83 Linux /dev/sda78513 1057916603146 83 Linux /dev/sda8 10580 10944 2931831 83 Linux /dev/sda9 10945 11430 3903763+ 83 Linux /dev/sda10
Re: [arch-general] Arch is ummnn different: my 1st installation: tried to install xfce...OOPS!
to use a different email client, But I'd really be lost without vim mc... I did a: pacman -Si xfce|less and looked for a package that might get me to a minimal desktop I could work with. I thought maybe xfdesktop... pacman -S xfdesktop Why have you done this? If you look at the 'man' page you will see http://linux.die.net/man/1/xfdesktop xfdesktop manages the desktop itself in the Xfce 4 Desktop Environment. You should have done pacman -S xfce4 You see, that's what I meant by knowing what order I need to install which packages... When I searched the output of the pacman -Ss xface I was looking for something resembling a meta-package that was designed to pull in everything needed to run xfce, Like using: apt-get install xubuntu-desktop on a Ubuntu base system or, apt-get install task-XFCE on PCLiniuxOS... Not actually knowing the names of all the components of XFCE, xfdesktop sounded like a possible candidate to me. By the sound of it you've only installed part of the desktop environment. More to the point: Will I need to figure out how to uninstall xfdesktop to resolve the error? No. Good! You need to do as others have suggested and read the beginners guide http://wiki.archlinux.org/index.php/Beginners%27_Guide especially the Setting up X section. Yeah, woulda, coulda, shoulda, but didn't. In my defense I can only say that the one time (pre-install) that I looked at the beginners guide, I had already peeked at: http://wiki.archlinux.org/index.php/Official_Arch_Linux_Install_Guide And the first several screenfuls of the beginners guide's text was on the same topic, and didn't seem as easy to boil down to the extract I almost needlessly typed and printed..., At # : /arch/setup Follow menu in order... Choose Manually Partition [ uses cfdisk :) ] Good it will let me tell it where to install grub To that I pasted in the section from the install guide about pacman commands... By the time I saw that error message, my brain was tired. I rebooted into one of my other linux, signed up for the list, composed my help request while I could still remember what I'd done. Then I went the heck to bed. I was certainly pleased with all the kind replies I found the next day. And not a one that felt like I was being hit with an RTFM... This tells me a lot about the people here. I thank all of you for being so helpful. And I'll try not to abuse this nice list. But sooner or later I'm sure to wind up with another case of brain flatulence that'll have me asking more stupid questions. Hopefully not so often as to become a pest. It would appear that on Mar 15, Linas did say: Looks like xfdesktop packages doesn't specify some of its dependancies (which is probably provided in the xfce4 group). http://www.archlinux.org/packages/?q=xfce4 should also include that there's a group with that name. I don't think it was a bad expectation from his part, looking at pacman -Ss xfce output. And even then, it could have worked, would xfdesktop have taken as dependancies the whole desktop. Thanks for pointing that out. Still it looks like if I'd have read the whole beginners guide first, I wouldn't have been as likely to make this mistake. Probably all I needed was to start with xorg then move on to xfce4 But I'll read http://wiki.archlinux.org/index.php/Xfce4; before I resume the process as well. It does look like getting Arch Linux configured the way I need it is going to take a bit more work than I'm used to. But if the rolling release part of what I've read about it means I won't have to recreate my personal user environment (heavily modified keyboard shortcuts etc...) every 6 months or so just to keep up to date, then I figure it'll be more than worth the effort. -- | --- ___ | 0 - Joe (theWordy) Philbrook | ^ J(tWdy)P |~\___/~ jtw...@ttlc.net Thanks again to all of you!
