Can I get rid of the .local domain that I don't want and which shuts down Avahi?

New to Ubuntu:
- read the Ubuntu Manual, it's very informative: http://ubuntu-manual.org/
Click on the "download Button" to download the latest PDF version.
- The Ubuntu pocket guide: http://www.ubuntupocketguide.com/
- The online help https://help.ubuntu.com/10.04/index.html

Relax and fun:
http://planet.ubuntu.com/ and Full Circle Magazine http://fullcirclemagazine.org/

You have brought up a number of problems besides the Avahi problem: sudo not working, strange package management, and (possibly separate from the package management problem) an apparently broken Samba installation. Those problems are almost certainly separate from this Avahi issue, so you should create new questions for them. The sudo problem is likely unrelated to the others, and just became visible at the same time because you use sudo in connection with a package management application to perform package management operations. If you don't experience it again, I wouldn't worry about it. If the Samba problem is gone, I wouldn't worry about that either; if it's still an issue and you think it's related to your package management problem (packages being installed for unknown reasons and old security updates being installed), then you should post about it in the same question as that; if it's still an issue and you think it's not related, you could post separately.

In summary, you should probably post one or two additional questions. This question should be reserved for discussing the Avahi problem. To post a new question regarding package management problems, you can use this link: https://answers.launchpad.net/ubuntu/+source/apt/+addquestion

Regarding the Avahi issue with .local, please open a Terminal window (Ctrl+Alt+T or Applications > Accessories > Terminal) and run this command (by pasting it into the Terminal and pressing enter):

hostname -fv; echo; cat /etc/hosts

Then select all the text in the Terminal (Edit > Select All), copy it to the clipboard (Edit > Copy), and paste it here.

I can take a look at that, and let you know if it looks like there's anything you can do to change your computer's configuration with respect to the .local unicast domain. Assuming there isn't, I'll probably tell you to try the "Better workaround" presented at http://avahi.org/wiki/AvahiAndUnicastDotLocal.

Thanks for the links Marco, I d/l'ed the Pocket Guide and will try and read bits and pieces when I can - it looks solid cheers!

-----------

Thanks a heap Eliah - I'm pretty sure the issues are all linked as they effectively mirrored the problems I was having with Windows, after my non-existent network security was breached, and I spent 2 months of formatting and OS installing, until I was able to work out that I was facing deployed unattended silent installations instead. The symptoms are all the same, but of course with ubuntu there is merely a fraction of the vulnerabilities of Windows. I actually don't think there is any hacking going on at all now that I'm using Linux - but I'm still battling the residual corrupted code (not sure if that even makes sense, but that's my take on it).

But yes, I'm in the process of buying new systems, so the only thing that really concerns me is this .local domain which I didn't set up, my ISP says has nothing to do with them, it's got a Windows stink all over it - most notably in the inability of seemingly every person I've spoken to, who claim they understand it, but...if they do, they give a remarkably convincing impression that they are clueless.

goscuter1@j-d:~$ hostname -fv; echo; cat /etc/hosts
j-d

127.0.0.1 localhost
127.0.1.1 j-d

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

----------

Thanks again for your assistance Eliah! I don't understand "workarounds". If I don't want a .local domain, why can't I simply...not have one?

lol that cannot possibly be as dumb a question as it sounds....

"I'm pretty sure the issues are all linked as they effectively mirrored the problems I was having with Windows"

Huh? How?

Are you saying that (a) you also got security updates downgraded on your Windows system, (b) installed software strangely became uninstalled on your Windows system, (c) sudo stopped working on your Windows system, and (d) Samba was strangely and inexplicably installed on your Windows system and could not easily be removed? These seem to be your chief complaints (besides the Avahi issue we're working on now), and only half of them seem possible on a Windows system. Specifically, while User Access Control in Windows is superficially similar to sudo in Ubuntu, there really is nothing in Windows that corresponds functionally to sudo in Ubuntu. Furthermore, since Windows has its own implementation of the SMB and CIFS file sharing protocols (these protocols were originated by Microsoft), it doesn't have Samba. (You *can* get sudo and Samba installed on a Windows system if you install them in a Unix-like environment for windows, such as Cygwin or Interix, but I'm guessing that's not what you were doing.)

Since some of the problems you've reported seem specific to Unix-like systems, I think that I do not adequately understand what you mean when you say that they all effectively mirror problems you had in Windows. If you explain this further, I may be able to offer better help.

"The symptoms are all the same, but of course with ubuntu there is merely a fraction of the vulnerabilities of Windows."

I agree with you that, overall, Ubuntu's security is better than Windows's. I think this is due to a combination of multiple factors, and that the significantly lower typical *severity* of vulnerabilities found in Ubuntu is more significant than the slightly lower *incidence* of vulnerabilities. But I admit that this analysis might be based on old statistics--I have not read up recently on how different operating systems fare compared to another with respect to vulnerabilities.

"I actually don't think there is any hacking going on at all now that I'm using Linux - but I'm still battling the residual corrupted code (not sure if that even makes sense, but that's my take on it)."

That does not make sense to me. Can you explain what you're thinking? Specifically, if you wiped your disk and installed Ubuntu, what remains to still be corrupted? While malware that infects a BIOS (http://en.wikipedia.org/wiki/BIOS) image exists and is of at least academic interest, I am not aware of any actual instance where such malware has ever even suspected to be in actual use, much less confirmed.

This is a related question which may have more direct bearing on the problems you've been experiencing, and which combines and, to a degree, synthesizes several questions about a major of information which I think you may be trying to convey: Why do you believe that you were subject to "hacking" back when you ran Windows; what, if any, connection do you suspect between that and the problems you had on your Windows system; and what is the connection between those problems and the problems you're experiencing now with Ubuntu?

"every person I've spoken to, who claim they understand it, but...if they do, they give a remarkably convincing impression that they are clueless."

Well I'll come out and tell you right now -- I don't understand it. (This Avahi issue with the unicast .local domain, I mean.) Not in the strong sense that I am confident that I could give you instructions that you could follow which would reveal the precise cause of your problem in great detail and without fail. (Though I might be willing to try, if that kind of investigation proves necessary.) I have some degree of understanding, which enables me to answer (some of) your questions coherently. With that said, please read on...

"If I don't want a .local domain, why can't I simply...not have one?"

Actually, you do want a .local domain -- Avahi is, by default, configured to require one. (Or, you could say, to provide one.) But it has to be multicast, in order to do what Avahi does (http://en.wikipedia.org/wiki/Zero_configuration_networking). So a pre-existing unicast .local domain is a problem that must be solved or worked around. (Multicast means you send out a single packet and that "goes to"--i.e., is usefully visible to--multiple devices on a network; unicast means a single packet goes to a single device. See http://en.wikipedia.org/wiki/Unicast and http://en.wikipedia.org/wiki/Multicast.)

But that doesn't really answer your question, which can be easily modified to ask, "If I don't want a unicast .local domain, why can't I not have one?"

If the domain were configured on your computer, you could reconfigure your operating system not to have one. Given the information you have just provided from running that command, this does not appear to be the case. Therefore, it's likely that some other device is presenting your computer with a .local domain. Typically, that means that your computer is using a DNS server that defines .local as a domain. This server could be running on your router, your cable/DSL/ISDN/whatever modem, or it could be run off-site by your ISP, or even run by some entity other than your ISP but enabled via a DHCP server somewhere.

We can probably investigate this issue further and find out precisely what is causing your computer to see a .local domain. But I recommend trying the "Better workaround" at http://avahi.org/wiki/AvahiAndUnicastDotLocal first and see if it works. If that doesn't work, then I'd likely recommend trying the first (non-"better") workaround, but before you do that, please post again with details. (Please also note that the non-"better" way, as explained on that page, is a potential source of insecurity.)

Hi Eliah, firstly thanks SO much for committing so much of your time to assisting me with this. I'll try and answer your questions as succinctly as I can.

**"Are you saying that (a) you also got security updates downgraded on your Windows system, (b) installed software strangely became uninstalled on your Windows system, (c) sudo stopped working on your Windows system, and (d) Samba was strangely and inexplicably installed on your Windows system and could not easily be removed? These seem to be your chief complaints (besides the Avahi issue we're working on now), and only half of them seem possible on a Windows system."**

a) That's exactly what I'm saying. I provide evidence of (merely one of the dozens of examples) in this post proving Windows Update, Active Directory, WFP and SFC can all be used as attack vectors): http://ubuntuforums.org/showpost.php?p=10685576&postcount=102

b) That's exactly what I'm saying. Uninstalled before my eyes initially, then everything moved to "unattended" and "silent". You know when someone else has control of your systems; I knew because someone else was controlling my desktop, deleting files, changing UAC groups, adjusting the firewall etc.

c) That's exactly what I'm saying, except my illiterate mind makes no distinction between being logged in as Sudo or logged in as Net Administrator, when I'm trying to access things and getting permission denied messages. In Win7, when logged in as Administrator, I would lose my permissions, and be instructed to contact my system administrator. I wouldn't be allowed to save *some* files to my desktop, or to my hard drive, but other files I could download, install and execute fine. This would also happen when logged in as Super Administrator also. nb. Please let me know if you require evidence for any of this, I have MOUNTAINS.

d) Not Samba, but hackers were installing virtual drives and remote access services like CIFS and SMB and others. I also have Samba, CIFS, SMB and other file-sharing protocols like OpenSSH automatically installed everytime I low-level format and install a new Linux distribution. I believe the .local domain is a residual element of that - I never set it up, my ISP swears it's got nothing to do with them, I didn't used to have it, so...? Every time I look at something suspicious, it seems to be connected with .local somehow:
http://imgur.com/JKF0x

I spent an hour trying to make sense of that screenshot above. And learned nothing. I've done that hundreds of times, hundreds and hundreds of hours in the last 2 months. I'm not IT-minded, but I'm fairly bright. And I already know as much as most of the 'experts', but then I knew as much when I was illiterate, with some of the 'experts' in this industry.

Pls note, that's just the start of the similarities. There are countless more, it's ridiculous how similar everything is:

* things like endless recursion which crashes my systems. http://i.imgur.com/i95Hf.png
* countless "unknown" files (which experts don't know anything about so they say not to worry, because that's intelligent response to anything unknown)
* unable to access directories or delete files or retrieve system information even when logged in as Sudo (or Super Administrator in Win7): http://i.imgur.com/1Ns61.png
* junction points or hard links or dynamic links I didn't create and cannot access: http://i.imgur.com/kmgai.png

And so on and so on...

This is all linked to the .local domain picked up by Avahi, I'm sure of it.

**"Specifically, if you wiped your disk and installed Ubuntu, what remains to still be corrupted? While malware that infects a BIOS (http://en.wikipedia.org/wiki/BIOS) image exists and is of at least academic interest, I am not aware of any actual instance where such malware has ever even suspected to be in actual use, much less confirmed."**

lol. Sorry, that's gallows grim laughter I assure you. If only BIOS malware were the problem, I would have fixed it 2 months ago when I DBAN'd my hard drive and flashed the BIOS, then installed Win7 Ultimate from Genuine Advantage $340 discs from Microsoft. With all networking functionality COMPLETELY disabled (deactivated in BIOS or simply uninstalled), router switched off, unplugged, not a wifi network in range (tested with my phone)....lol. If only it was something as simple as the BIOS.

No, DBAN and KillDisk and other low-level formatting 'solutions' can't touch some virtual, encrypted partitions. DBAN doesn't even format the HPA for christ's sake, let alone the unknown stack of other Dell hidden partitions which they are oh-so-secretive about but which are known to exist. nb. For what it's worth, all this started when a Dell technician installed a rigged new hard drive, with complimentary 2005-2009 outdated drivers, unnecessary firmware, illogical functionality and even non-existing (seemingly) ControlVault firmware (I guess he had never heard of Dell.com - fwiw Dell have clammed up into "no comment" mode, which is a bitch when you have Active NBD on-site cover, CompleteCover insurance, and active warranties - as I do):
http://i.imgur.com/zMxi2.png
http://i.imgur.com/dz4Z6.png

F DELL. F em to Hell.

**"Why do you believe that you were subject to "hacking" back when you ran Windows; what, if any, connection do you suspect between that and the problems you had on your Windows system; and what is the connection between those problems and the problems you're experiencing now with Ubuntu?"**

Well, when someone is controlling your desktop and it's not you, moving cursors around, deleting and installing and accessing obscure elements of your system you didn't know exist, it's a pretty big clue. Also, my systems just randomly powering up from being COMPLETELY turned off, was pretty spooky. This has stopped now, as soon as I moved to Linux.

The connections are that all the problems simply carried over, except for a few improvements. Moving to Linux from Windows (as far as my issues went) didn't fix much. I only changed to Linux for security reasons, so was disappointed. But it's aiight cause Linux >>> Windows, by a very long margin.

**"Well I'll come out and tell you right now -- I don't understand it. (This Avahi issue with the unicast .local domain, I mean.) Not in the strong sense that I am confident that I could give you instructions that you could follow which would reveal the precise cause of your problem in great detail and without fail. (Though I might be willing to try, if that kind of investigation proves necessary.)"**

Though I'm not surprised (although I was initially, by the incompetence of the network security 'experts' I hired, who shrugged or even worse, claimed it was all standard, then invoiced me for their lies), **thank you** for being maybe the first expert I've spoken to (of the dozens or more, in person or on forums) who has had the simple character / dignity / decency to admit to not knowing everything (as if that could POSSIBLY be 'shameful'). But this industry is full of frauds, who market their ignorance, so of course it's shameful to them - so they either go silent, and just ignore the threads, or they pretend they are blind, whilst telling me everything is fine, ignoring my direct questions, ignoring screenshots of evidence, declaring their Malwarebytes clean scans as proof I'm 'imagining' what I've already proven to them, irrefutably. Bunch of idiots.

**"Actually, you do want a .local domain -- Avahi is, by default, configured to require one. (Or, you could say, to provide one.) But it has to be multicast, in order to do what Avahi does (http://en.wikipedia.org/wiki/Zero_configuration_networking). So a pre-existing unicast .local domain is a problem that must be solved or worked around"**

This could be the dumbest question of my life, but if I don't even *want* to have any home networks, file-sharing, homegroups or local domains, do I still want a .local domain? i.e. Can I connect directly to the internet without all this exploitable crap? I hardly have need for any of it's functionality, and I really have need to retain my sanity. And it seems to be a trade-off, for my filthy 'network'.

**"Therefore, it's likely that some other device is presenting your computer with a .local domain. Typically, that means that your computer is using a DNS server that defines .local as a domain. This server could be running on your router, your cable/DSL/ISDN/whatever modem, or it could be run off-site by your ISP, or even run by some entity other than your ISP but enabled via a DHCP server somewhere."**

I am 100% certain that you are correct. And that another device is doing this. And I'm 99% sure it's for malicious purposes. And I'm 100% certain I don't want it lol. My ISP swears .local is not part of my VDSL service, and that it's coming from somewhere else. I suspect my filthy ZTE modem, but here's the thing. I live in Corruption Country, where business is all conducted via "exclusivity contracts" (read: bribe-purchased monopolies). So not only can I not change my ISP, not only can I not change my service to ADSL or w/e, I cannot even change my modem brand from ZTE (who paid good bribe money for the contract, so it's unreasonable to expect them to accept competition). Today, I investigated ZTE and tried to get some CS happening. LOL. Filthy joke company, non-existent CS, support numbers aren't even active, support forum is dead, handful of questions unanswered, no documentation for my modem or even any search hits on their website for it. lol

**"We can probably investigate this issue further and find out precisely what is causing your computer to see a .local domain."**

Bless you. May the gods smile upon your children and may your camels remain strong and sturdy.

**"But I recommend trying the "Better workaround" at http://avahi.org/wiki/AvahiAndUnicastDotLocal first and see if it works."**

?? I'm confused. I only see this one on the Avahi page...?

**"If you come across a network where .local is a unicast DNS domain, please contact the local administrator and ask him to move his DNS zone to a different domain. If this is not possible, we recommend not to use Avahi in such a network at all."**

I could literally kill the next innocent who instructs me to contact my network administrator. I could almost kill my network administrator. And just might, if I'm forced to move...again. Sigh.

lol I'm exhausted and unable to be 100% certain that my wry melodrama just there in that last paragraph reads off the page correctly, in correct tone I mean...

The likelihood of any of those happening are in this order, and hopefully extremely low (if not quite non-zero chances for any or all):

Moving to a new residential apartment. Again. fml

Killing my Network Administrator.

Killing innocents. (this one is fairly close to 0.00% - but then I would say that, wouldn't I?) lol I should get some sleep. cheers!

"Every time I look at something suspicious, it seems to be connected with .local somehow: http://imgur.com/JKF0x"

That looks normal to me. In particular, the .local there is not related to the .local domain. A folder called .local inside a user's home folder is one of the places where some applications store files that are specific both to the local machine and to that specific user. (Since there are networked systems with large parts of their filesystems actually existing on remote machines, any combination of those two is possible.) Practically speaking, most of the times such files are inside a subdirectory of ~/.local called share, since share is a standard name for a directory containing files that are not architecture-dependent. This is a somewhat informal extension of the standard directories in the Filesystem Heirarchy Standard (http://en.wikipedia.org/wiki/Filesystem_hierarchy_standard). The .local folder starts with a . (dot) so that it is hidden in normal directory views, as when you're usually looking through your home folder, its presence would be a distraction.

There are many instances where two or more different things are called by the same name, and it is indeed confusing. Besides the .local folder inside your home folder and the .local domain used by zeroconf implementations like Avahi (and apparently by other stuff that shouldn't be using it), other examples of this that frequently produce confusion are: "Your home folder" being /home/your-username while the folder called /home not being anybody's home folder (but rather the folder that contains all the home folders, except root's home folder). Also, there is a root user, a root directory (/) which is not root's (or anyone's) home folder, and the /root directory, which is *not* the root directory, but rather is the root user's home folder.

"* things like endless recursion which crashes my systems. http://i.imgur.com/i95Hf.png"

That recursion in also normal. It's a little oddity on Ubuntu and most other Linux-based operating systems. X11 is a symbolic link to the directory called . (just a dot), which represents the current directory (in the same way that .. represents the parent directory). To clarify, it's not the current directory in the sense that when you change the directory you're in, it changes. Rather, it is the current directory relative to the directory in which it resides, which means that it is the directory in which it resides. To clarify further, a symbolic link inside /usr/bin to "." is a symbolic link to /usr/bin/. which is another name for /usr/bin itself--this is in the same sense that a symbolic link inside /home/your-username to "blah" is a symbolic link to /home/your-username/blah.

Thus, the directory X11 inside the /usr/bin directory is in effect a symbolic link to /usr/bin itself, and X11 inside /usr/bin/X11 is in effect a symbolic link to /usr/bin/X11 itself which is in effect a symbolic link to /usr/bin itself, and so forth. This is so that the /usr/bin/X11 directory "exists" (for programs that expect it to exist and contain X11 programs), but it's the same as the /usr/bin directory, where most program binaries are stored. It's a backward-compatibility thing.

Please let me know if that explanation doesn't make sense, and I'll explain it in a totally different way.

While that recursion in the filesystem is normal, it should not cause any crashes (nor any hangs). Did your file browser crash when you tried to expand that directory tree? If so, that's a bug, and it's worth reporting and fixing. If you're willing, please provide detailed information about what you did and what (bad thing) happened, and I'll help you to report it as a bug (or to find where it has already been reported as a bug, as the case may be, and to add any important additional information to the bug that might be missing).

"* unable to access directories or delete files or retrieve system information even when logged in as Sudo (or Super Administrator in Win7): http://i.imgur.com/1Ns61.png"

Access denied and permission denied messages can happen even if you are running with the highest level of local system privileges. Sometimes this happens because the access is denied due to the unavailability of a resource. In this case, though, it's not obvious that you were being denied permissions to access something on your own system. You were in the pts utility, which is part of openafs-client, and OpenAFS is a distributed filesystem, so generally speaking having total control over your own machine might not confer you total control over the filesystem you're trying to access.

If you want to look into this situation, I recommend you start a new question about openafs: https://answers.launchpad.net/ubuntu/+source/openafs/+addquestion

"* junction points or hard links or dynamic links I didn't create and cannot access: http://i.imgur.com/kmgai.png"

Can you explain the problem in greater detail? I'm not sure I understand it, from looking at the picture. Is it just that there is a file inside a directory that appears to be reported as empty? Where is the hard link? What do you mean by a "dynamic link"?

"And so on and so on..."
"This is all linked to the .local domain picked up by Avahi, I'm sure of it."

Please feel free to give additional examples. So far, these things seem to have reasonable explanations, and do not appear to be related either to DNS resolution generally, nor to Avahi.

"With all networking functionality COMPLETELY disabled (deactivated in BIOS or simply uninstalled)"

Since the context of that tangential discussion is BIOS malware, deactivating something in a compromised BIOS might not actually deactivate it. But actually being infected with BIOS malware is very unlikely--I wouldn't worry about it.

"No, DBAN and KillDisk and other low-level formatting 'solutions' can't touch some virtual, encrypted partitions. DBAN doesn't even format the HPA for christ's sake, let alone the unknown stack of other Dell hidden partitions which they are oh-so-secretive about but which are known to exist."

Perhaps the utility called scrub would interest you. See http://manpages.ubuntu.com/manpages/maverick/man1/scrub.1.html and https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/142538. Please note that while Scrub meets two of the commonly referred-two government standards in secure data erasure **when used to erase an entire disk, and otherwise in accordance with those agencies' guidelines**, it's your responsibility to ensure that it meets your needs or the needs of your organization / customers (and as you know, that's where the responsibility rests with any such utility -- with you or your IT department).

"Well, when someone is controlling your desktop and it's not you, moving cursors around, deleting and installing and accessing"

Yes, this is a very bad sign. Unless you deliberately have provided them access, and you know who they are. Many security exploits are untargeted, like most of the Windows spyware that floats around. This might be targeted. Or it might just be some total stranger who broke into your system because they could, and started messing around with it.

To clarify that: There are ways to scan for and/or trap systems that are insecurely configured or used, though automated means. If that was how initial access was obtained, then the interactive process of an actual malicious person accessing your system specifically does not indicate a person connection between the perpetrator and you.

"Also, my systems just randomly powering up from being COMPLETELY turned off, was pretty spooky."

I wouldn't rush to associate that with a security breach in most cases, though it can indicate one. Of course, given that you have other strong evidence of one, I would be inclined to associate this with it, too.

When a computer is hibernated, its power state is OFF. Computers can be scheduled to unhibernate automatically, or even to boot up when not hibernated. They also can be configured (in the BIOS) to respond to Wake On LAN (the Ethernet card receives a specific kind of data and tells the computer to turn itself on). There's usually stuff going on (though not necessarily in an active sense) in your computer, even when it's off. For example, the clock continues advancing forward in time--if you turn your computer off for a while, and you deprive it of network access and boot it up, it will usually still show the correct time.

"This could be the dumbest question of my life, but if I don't even *want* to have any home networks, file-sharing, homegroups or local domains, do I still want a .local domain?"

That's a very smart question, so unless every other question you've ever asked has been ingenious, it is not the dumbest of your life. ;-)

Only zeroconf implementations should use a .local domain--it is, to put is a big bluntly, *wrong* for a unicast .local domain to exist. So if you don't need Avahi, you don't need a .local domain. Do you need Avahi? If you don't know whether or not you need it, there's a good chance you don't. And if you don't need Avahi, you could just remove it (or keep it but disable it, if you prefer), and then it doesn't matter that some DNS server somewhere is creating a unicast .local domain.

"?? I'm confused. I only see this one on the Avahi page...?"

I only recommend you try the "better workaround" if you actually *need* Avahi for something.

But if you do need Avahi, then the better workaround is indeed separate from what you quoted--you can find it on that page by pressing Ctrl+F and searching the page for the text "Better workaround" (without the quotes).

Finally, please note that (as you've probably guessed), there *are* bugs in Ubuntu--I don't think the appearance of a unicast .local domain name is due to a bug, but it's possible. And assuming that this is due to bad behavior on the part of a DNS server somewhere (which it probably is), that still doesn't mean that it is targeted at you specifically, nor that it is deliberately done to exploit security vulnerabilities (or even deliberately done at all).

**http://imgur.com/JKF0x
"That looks normal to me. In particular, the .local there is not related to the .local domain. A folder called .local inside a user's home folder is one of the places where some applications store files that are specific both to the local machine and to that specific user. (Since there are networked systems with large parts of their filesystems actually existing on remote machines, any combination of those two is possible.) Practically speaking, most of the times such files are inside a subdirectory of ~/.local called share..."**

Ah okay, well that's pretty confusing lol. But if a running process I'm not convinced I require (ostensibly eliminates a headache I didn't have), repeatedly accessing deleted files (which aren't actually deleted http://i.imgur.com/sLhbr.png), stored as metadata for a gvfs virtual filesystem I don't want, which is used for remote access to my desktop data.....is normal....well, I'm just never going to 'get' it. Because my brain works differently.

**"This is so that the /usr/bin/X11 directory "exists" (for programs that expect it to exist and contain X11 programs), but it's the same as the /usr/bin directory, where most program binaries are stored. It's a backward-compatibility thing.

Please let me know if that explanation doesn't make sense, and I'll explain it in a totally different way."**

I actually can't believe it lol, but I think you've actually clarified it for me. That...makes sense to my mind. Thanks! So the 30 or whatever X11 folders, would they be for these? http://i.imgur.com/aPYaS.png

But whether they are or aren't, why do I have all those? 63 tty's, then a bunch of ttyS's and more. They're all inaccessible of course, not that I have need to access them, aside from being unhappy that they're there. I see others on forums 'solved' the problem with formatting and reinstalling. I see that 'solution' a lot.

**"While that recursion in the filesystem is normal, it should not cause any crashes (nor any hangs). Did your file browser crash when you tried to expand that directory tree?"**

I actually got all the way to the end. http://i.imgur.com/tJemy.png
It doesn't crash but it gets very slow and labored. When recursion was occurring in my Win7, I could never get to the end, and my PC would hang or crash, and the recursion would keep going until my entire HDD was full, at which point...I would have to 'solve' the problem the most common way.

What I don't understand though, is why half the files inside the X11 directories have the arrow signifying that they are hardlinks, and others don't? And why can't I open any of them? And how much backwards compatibility do I need, for a freshly installed* (not quite but I'll get to that in a sec) ubuntu OS?

**"You were in the pts utility, which is part of openafs-client, and OpenAFS is a distributed filesystem, so generally speaking having total control over your own machine might not confer you total control over the filesystem you're trying to access."**

Yup I understand that. But I have one standalone machine. There was a reason I was trying to access that filesystem. It has access to mine.

**http://i.imgur.com/kmgai.png
"Can you explain the problem in greater detail? I'm not sure I understand it, from looking at the picture. Is it just that there is a file inside a directory that appears to be reported as empty? Where is the hard link? What do you mean by a "dynamic link"?"**

Sorry, I just assumed that was a junction point for some reason. I actually don't really know what it is, Google search says it's for extracting Microsoft cabinet files. Why I would want to do that, I have no idea. Actually, I have a few very valid reasons for NOT wanting to do that. And what it has to do with KDE4, I have no idea, having never installed KDE4. Microsoft dynamic link libraries are a favourite cheat for lazy hackers, obviously:

"The file formats for DLLs are the same as for Windows EXE files. As with EXEs, DLLs can contain code, data, and resources, in any combination. In the broader sense of the term, any data file with the same file format can be called a resource DLL. Examples of such DLLs include icon libraries and font files."

Perhaps it's for unpacking cabinets FULL of DLLs lol. I don't know of course, and don't care, except for the fact that it's on my computer and I don't want it there. And can't delete it.

**"Please feel free to give additional examples. So far, these things seem to have reasonable explanations, and do not appear to be related either to DNS resolution generally, nor to Avahi."**

We might have different definitions for 'reasonable', but I'm not imagining my systems going to chaos in front of my eyes, without my doing a single thing about it except 40 or so reformats and OS reinstalls when it's game over. Two of the 3 systems are now dead. This one is showing the same symptoms. What kind of evidence is required, the shells of the paperweights that no longer switch on?

**"Since the context of that tangential discussion is BIOS malware, deactivating something in a compromised BIOS might not actually deactivate it. But actually being infected with BIOS malware is very unlikely--I wouldn't worry about it."**

I was unaware of this, but I'm wasn't worried about it as countless flashes had led me to isolate the modem as the last possible suspect. But today in logs I saw this in /var/log/Xorg.0.log - line 7 seems like a problem. http://codepad.org/P5BU3zuA

Also down at the bottom, I pasted the content of (Line 18):
[ 16.424] (==) Using system config directory "/usr/share/X11/xorg.conf.d"

[QUOTE]Section "InputClass"
    Identifier "vmmouse"
    MatchIsPointer "on"
    MatchTag "vmmouse"
    Driver "vmmouse"
EndSection

So a BIOS image is installing a VMware mouse. Which has functionality I don't care for, really. It seems...security-related.

"This package provides the driver for the X11 vmmouse input device.
The VMMouse driver enables support for the special VMMouse protocol that is provided by VMware virtual machines to give absolute pointer positioning.
The vmmouse driver is capable of falling back to the standard "mouse" driver if a VMware virtual machine is not detected. This allows for dual-booting of an operating system from a virtual machine to real hardware without having to edit xorg.conf every time."

How wonderful, that if a virtual machine is not detected, it's capable of performing as my mouse driver? I might have uppity standards, but I'd prefer to be first choice for all drivers installed on my system.

**"Yes, this is a very bad sign. Unless you deliberately have provided them access, and you know who they are. Many security exploits are untargeted, like most of the Windows spyware that floats around. This might be targeted. Or it might just be some total stranger who broke into your system because they could, and started messing around with it.

To clarify that: There are ways to scan for and/or trap systems that are insecurely configured or used, though automated means. If that was how initial access was obtained, then the interactive process of an actual malicious person accessing your system specifically does not indicate a person connection between the perpetrator and you."**

Yeah, I understand. And thank god for that. Because when someone started waltzing through my desktop, I was simply unable to source help. Every day I was sure I was going to wake up to 5 figure CC bills or bank txt chaos or Paypal or w/e. But nothing financial, aside from just DESTROYING my systems fairly predictably. I read somewhere that over 20% of all Windows PCs are part of botnets without even realising it, or some ridiculous % like that which completely makes sense, considering the ludicrous 'advice' and 'solutions' posted to what is clearly malicious activity on support.microsoft.com forums and whatnot.

So, knock wood, the damage is limited to under 10k so far, if I can just nail down the security hole I'll buy entirely new hardware and be done with the thing. Surely there are logs I should be looking at? ubuntu seems to do a FAR better job of recording what's happening, I just can't analyse the output effectively. But there is all sorts of chaotic script written in the seconds whilst the PC is booting into logon screen, I haven't been able to find the right logs that match up with the glimpses of the activity I see for a flash however.

**"But if you do need Avahi, then the better workaround is indeed separate from what you quoted--you can find it on that page by pressing Ctrl+F and searching the page for the text "Better workaround" (without the quotes)."**

I cannot believe I missed that, I must be blind. They should put it at the top of the page! I did it, reconnected and no warning message coming up. But then I'm not sure why I even need Avahi in the first place. But I'm confused (exhausted), it wasn't Avahi that was causing the problem right? Avahi was merely detecting it, no? (at least, this has been my entire frame of mind till this point)

Ohhh, is .alocal simply to eliminate the error message from Avahi? It's still a unicast .local domain isnt' it? Hyayayayy...I'm a moran. Okay, killing Avahi....it went crazy with pages of stuff about upstartjobs or something, pages and pages of upjobs output or whatever. I failed to copy it effectively. Not sure it's important, as config looks...? ok? ;)

http://ideone.com/XtkCn

~$ testparm -v
http://ideone.com/jgeqa

Ah crap, Avahi just...ah, this is too much for me. I can't expect anyone else could be interested but I'm exhausted. I can't....lol Avahi config files just recreated themselves. How cute.

Avahi is uninstalled but..somehow not. http://pastebin.com/s4qZep39

200 processes alive and I can't kill them with sudo kill or killall. I dunno...

bah. I give up. Uncle. Thanks a HEAP for giving me so much of your time Eliah, I can't impose any longer and I'm exhausted. I don't think Linux is for me. Too many unexplainables, and I don't have the mind for it or the time...maybe I just need some sleep. Thanks again!

ugh. I can't kill this ssh-agent thing. http://pastebin.com/fhFZWkxS

root@j-d:/home/goscuter1# ps -aux | grep ssh
1000 1647 0.0 0.0 3368 192 ? Ss 09:53 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session --session=ubuntu
root 6739 0.0 0.0 3368 192 ? Ss 20:49 0:00 ssh-agent
root 6815 0.0 0.0 4156 856 pts/3 S+ 20:58 0:00 grep --color=auto ssh

lol I don't even know if I want to, I'm just going off what forum posts say. I'm being ridiculous. Sleep. Thanks Eliah, you're a champ!!

[Please do not feel as though you have to reply to this message. I understand that you have marked this as Solved. In this post, during the course of seeking to answer your questions, I do ask for more information about some things, but if you no longer want to examine this further, I fully understand and appreciate that.]

"But if a running process I'm not convinced I require"

If you're talking about bamfdaemon, if you want your different applications to be able to talk to each other (so you can drag stuff between them and so that your desktop environment can be used to do things like mounting devices, for example), you probably need D-Bus (http://en.wikipedia.org/wiki/D-Bus, http://www.freedesktop.org/wiki/Software/dbus). Many applications on Ubuntu, especially the ones that comprise your desktop environment, use BAMF (https://launchpad.net/bamf) to communicate via D-Bus, so you probably do in fact need bamfdaemon running.

If you didn't need bamfdaemon running, then it probably wouldn't be doing much when it runs, so it probably wouldn't have many files open.

"repeatedly accessing deleted files"

Accessing deleted files is normal behavior on any Unix-like system. When a file won't need to be accessed by anything but the programs that currently have it open, it can be safely deleted. It is only subject to "erasure" once no program has it open anymore.

To say it another way: In a Unix-style file system, a file can have zero or more hard links, also called filenames. When a file has zero hard links, it is subject to deletion once no program has it open. Deleting a file consists of deleting its hard links. Most files have one hard link most of the time, but there are numerous uses for having multiple hard links. See http://en.wikipedia.org/wiki/Unlink_(Unix) and http://en.wikipedia.org/wiki/Hard_link.

To address a common confusion about hard links: If B is a hard link to A, then B "is the file" just as much as A "is the file." Furthermore, the statement "B is a hard link to A" is equivalent to the statement "A is a hard link to B." (This is emphatically not the case for symbolic links--a symbolic link is a filesystem entry that has a string of text called its target; it points to the file whose path is that string of text. See below for more information about hard links and symbolic links.)

"(which aren't actually deleted http://i.imgur.com/sLhbr.png)"

That's not, generally speaking, a problem. Even if those views were truly concurrent--and it's likely they were--you can still have an open file that was since deleted, and another file created with the same name. Given that this is a temporary file used for GVFS (http://en.wikipedia.org/wiki/GVFS), that's highly plausible.

"So the 30 or whatever X11 folders,"

In order to better explain the raison d'etre for this, a more detailed presentation of the topic, with a higher degree of linguistic precision, is warranted.

There's only *one* folder whose name is /usr/bin/X11. This is the same folder whose name is /usr/bin. This is also the folder whose name is /usr/bin/X11/X11, which is the same folder whose name is /usr/bin/X11/X11/X11, and so forth. These are not separate folders--they're separate names.

There are two primary ways that a file in a Unix-style file system have multiple names. Hard links refer to the file's device and inode numbers (i.e., they refer to the file itself), and symbolic links, or soft links, refer to hard links. See http://en.wikipedia.org/wiki/Inode, http://en.wikipedia.org/wiki/Hard_link, and http://en.wikipedia.org/wiki/Symbolic_link.

In this case, the folder /usr/bin contains a symbolic link whose name is X11 and whose target is ".". Since "." doesn't start with a /, it's a relative rather than an absolute path. See http://en.wikipedia.org/wiki/Path_(computing) for an explanation of those terms. A symbolic link whose target path is relative is taken as relative to the directory containing the symbolic link. Therefore, the directory to which the symbolic link /usr/bin/X11 points is the directory /usr/bin/. (i.e., the entry called . inside /usr/bin). That directory is just another name for /usr/bin (see http://en.wikipedia.org/wiki/Current_directory, and notice that this is a third way, or to be more precise, a special case of a third way, that a directory can have multiple names).

The reason for the directory /usr/bin to contain the symbolic link

     X11 -> .

is because there are files inside /usr/bin which were traditionally stored in /usr/bin/X11, which was traditionally a separate directory altogether. For backward compatibility, these files must remain accessible inside /usr/bin/X11 even though they are really inside /usr/bin. This symbolic link makes /usr/bin/X11 another name for /usr/bin.

That this creates recursion is a side-effect; the recursion itself is not desirable, though it is not problematic either. It creates recursion because since /usr/bin/X11 is another name for the directory /usr/bin, it contains that same symbolic link

     X11 -> .

which means that /usr/bin/X11/X11 is another name for /usr/bin/X11 (and /usr/bin), so it contains that same symbolic link

     X11 -> .

which means that /usr/bin/X11/X11/X11 is another name for /usr/bin/X11/X11 (and /usr/bin/X11 and /usr/bin), and so forth.

This **sort of** goes on forever, and **sort of** stops eventually. On the one hand, every one of those directories contains another symbolic link to . called X11. But on the other hand, the operating system has a maximum path length that it will deal with. Understanding why that is and what that really means is more deeply technical than this discussion has been so far, but in case you're interested, I will refer you to http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html (see PATH_MAX), and suggest that you take a look at http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html to see how PATH_MAX is applied. In a very meaningful sense, file and directory names longer than PATH_MAX - 1 (including those much longer) *do* exist, but are only *usable* if applications bend over backwards to do the work that the operating system is unwilling to do. (At this point, it is worthwhile for me to define what I mean by "operating system"--in this specific case, I'm referring to the kernel and libc--see http://en.wikipedia.org/wiki/Kernel_(computing), http://en.wikipedia.org/wiki/Linux_kernel, http://en.wikipedia.org/wiki/Libc, and http://en.wikipedia.org/wiki/Glibc). Feel free to ask further questions about this--I'll try to answer them.

Because of the PATH_MAX limitation, many (not all) applications on Ubuntu will only show you the first 41 names for the same directory as is indicated by /usr/bin/X11 (or the first 40, if we don't count /usr/bin itself). In a sense, only these first 41 exist. But in another sense, they all (all "infinity" of them) exist.

Finally, please note that it's not the number 41 that's important. It's just that the 42nd-shortest such name is the first one whose length exceeds PATH_MAX - 1.

"would they be for these? http://i.imgur.com/aPYaS.png"

As you can probably surmise from the above explanation: No.

"why do I have all those? 63 tty's, then a bunch of ttyS's and more."

In a Unix-style file system, there are file system entries for things other than directories and files. You already know this, since you know about symbolic links. Another kind of file system entry is a device, also called a "device special" or "device file." (Depending on how the term "file" is defined, we may include nominally non-file file system entries as files, so that directories and device files are considered files. This is just a language issue--the word "file" is used in two senses, one of which generalizes the other.) Actually, device files can be subdivided into more subtypes. See http://en.wikipedia.org/wiki/Device_file for a better explanation and more detailed information.

/dev/tty1 through /dev/tty63 are the device files for the 63 virtual terminals that you might have. They're "virtual" because you can switch between them without switching from one physical display to another. See http://en.wikipedia.org/wiki/Virtual_console for details. In practice, you almost always have only 7 or 8 virtual terminals. You can switch from the terminal on which your graphical user interface is running by pressing Ctrl+Alt+FN, where FN is the function key whose number is N. This switches to ttyN. So, to switch to tty1, you would press Ctrl+Alt+F1. When you're not in graphical mode, you don't need the Ctrl. That is, you can switch between terminals with Alt+FN. Your graphical interface typically runs on the last virtual terminal, so to get back to it, try Alt+F7 or Alt+F8.

/dev/tty0 represents the currently active virtual terminal. It's not an alternate name for that device's file system entry, but reading and writing data from/to the /dev/tty0 device is equivalent to reading/writing it to that device name. On systems where you can see the current virtual terminal (i.e., no GUI is in front of it), a program will write messages to /dev/tty0 to make sure you see them. (On systems running a GUI, messages will still get written to /dev/tty0 -- you just won't see them.) See http://www.linuxselfhelp.com/HOWTO/Text-Terminal-HOWTO-6.html.

/dev/ttyS0 through /dev/ttyS31 are the device files for the 32 serial ports you might have. If your computer is reasonably new, you probably actually have zero serial ports. See http://en.wikipedia.org/wiki/Serial_port. Serial ports on a Unix-like system have traditionally been, can be, and still sometimes are used to connect terminal devices (see http://en.wikipedia.org/wiki/Serial_console). For example, if you have a computer (often a server) with no keyboard/monitor, you could connect another computer to it with a null modem cable (http://en.wikipedia.org/wiki/Null_modem) and control it from the other computer.

As for the "and more," I would encourage you to search the web to discover the meaning of any (or all) other device files in /dev. I'd be pleased to answer questions about specific devices (or groups of devices distinguished from each other just by numbers), even *lots* of questions about *lots* of devices, but this post of mine is already extremely long and I am not sure that it would serve you well for me to increase its size from long to huge.

Finally, please note that the console devices associated with Terminal windows are *not* called virtual terminals and their device names are not of the form /dev/tty... -- instead, they care called pseudo-terminals, they are dynamically created and destroyed, and they care located inside /dev/pts. See http://en.wikipedia.org/wiki/Pseudo_terminal and http://manpages.ubuntu.com/manpages/lucid/en/man4/pts.4.html, and please note that this pts should not be confused with the OpenAFS Protection Server or the utility used to administer it, which is the sense of pts that we were discussing before (see http://manpages.ubuntu.com/manpages/lucid/en/man1/pts.1.html).

"They're all inaccessible of course, not that I have need to access them, aside from being unhappy that they're there."

They're accessible when you're root. Please see below (in the discussion of cabextract). Please note that the contents of /dev are there for a reason (some of the reasons I have explained above), and even for device files that are not in use, there are good reasons to keep them. For example, to find out that a device does not exist or that (whether or not it exists) it is not accessible, a program might (try to) access its device file.

"I see others on forums 'solved' the problem with formatting and reinstalling."

I would say that's a solution in search of a problem, except that reinstalling isn't really a solution, and reinstalling should not remove these entries, and anything that *did* remove them would be a problem in need of a solution. Or were they other /dev entries (besides tty... and ttyS... devices) that someone managed to remove by reinstalling? Can you provide a link to the relevant forum topic?

"It doesn't crash but it gets very slow and labored."

That's better than crashing but still not good. What are the specific steps that I can follow to reproduce this? That is, what specifically are you doing to traverse the tree (i.e., to get from /usr/bin to /usr/bin/... with 40 X11's).

If it's simply that there was some wait time each time you double-clicked on X11, but the wait time did not increase subsequent times you clicked on it, then that's almost certainly just because each time you entered the new directory (which was, of course, really the same as the old directory), the (same) contents had to be examined all over again, as would be the case if you were entering a totally new directory containing many files.

(/usr/bin/X11 is one of the very few cases of this kind of recursion, and even in this case there is little practical use associated with traversing deep down into the tree, so to code for this as a special case--where reloading the directory's contents doesn't have to happen--would add bloat to Nautilus without yielding any justifiable benefit. Furthermore, when you enter a directory in Nautilus, you generally want to see its contents as they *currently* are, even if they have changed very recently--this should also be Nautilus's behavior when navigating into a symbolic link to the current directory.)

"Yup I understand that. But I have one standalone machine. There was a reason I was trying to access that filesystem. It has access to mine."

Yes, you are quite right to be interested in why this is happening, though you have not provided any information to indicate that it is a bug or that it reflects an attempt to compromise your security. (It's still worth looking into, especially if it's interfering with your ability to accomplish some task.) I encourage you to open a separate question about this (https://answers.launchpad.net/ubuntu/+source/openafs/+addquestion).

"I actually don't really know what it is, Google search says it's for extracting Microsoft cabinet files."

It's an archive format that you might be interested in having access to. You might also never want to open a .xls spreadsheet, but it would be a bad thing Ubuntu to ship based on the assumption that its users will never want to do that, and then require users to undertake technically sophisticated actions to enable that functionality.

"Why I would want to do that, I have no idea."

Probably the most common--and most important--use for cab archive extraction functionality on an Ubuntu system is that fonts are often distributed in .cab files, especially fonts intended for use on Windows systems, which may nonetheless be necessary to use on an Ubuntu system for viewing/editing documents that use them, or for running Windows programs on Ubuntu using Wine (http://en.wikipedia.org/wiki/Wine_(software)).

"And what it has to do with KDE4, I have no idea, having never installed KDE4."

This file is provided by the package cabextract, and not by any of the packages specifically associated with KDE4. See http://packages.ubuntu.com/search?searchon=contents&keywords=cabextract.desktop&mode=exactfilename&suite=maverick&arch=any and http://packages.ubuntu.com/maverick/cabextract. It is provided so that KDE4, and programs that use KDE4 or components of it (which may include programs you currently have), will be able to use cabextract, if and when such programs are installed.

"except for the fact that it's on my computer and I don't want it there. And can't delete it."

Given what I have said above, you might decide that in fact you *do* want to keep it. I recommend this.

However, you *can* remove it, either by removing the "cabextract" package, or by manually deleting the file.

Before removing cabextract, I would encourage you to find out what is currently depending on cabextract. Removing cabextract will remove some functionality (.cab file extraction functionality) from various programs, but you can restore that functionality by reinstalling cabextract. On the other hand, packages declaring dependencies on cabextract will be automatically removed when you remove cabextract. You will be warned about this when you remove cabextract, but I have seen many single-minded Ubuntu users determined to remove a package who disregard this warning, or who assume that it is less significant than it is, and then end up requiring assistance because the packages they were warned about losing were removed as promised.

This is why I recommend finding out about the consequences of removing cabextract before actually removing it. I do this sort of thing myself frequently--this is not something that I only recommend to less experienced users of Ubuntu. One way to do it is to open a Terminal window and run this command:

apt-get -s remove cabextract

This absence of "sudo" is intentional. This runs a simulation of removing the cabextract package (the -s flag before anything else tells apt-get that it's a simulation), and among other things, this will reveal what other packages, if any, would be removed along with cabextract. If you run that command and then post the text from the Terminal here, then I can interpret the results for you and explain what the consequences of removing cabextract would be, if any.

While I'd encourage you to run that and post here before proceeding to remove cabextract, if you wish to completely remove cabextract, one way to do it is with the command:

sudo apt-get purge cabextract

You should not manually remove that file--if you decide you really don't want cabextract, and you remove it as specified above, that file should be removed. But you most certainly *can* remove it manually. If you insisted on removing it manually, which I again hasten to add you should *not* do, you could do it by pressing Alt+F2, entering the command "gksu nautilus" without the quotes, navigating to the /usr/share/kde4/services/ServiceMenus directory, and deleting cabextract.desktop.

Let's examine that procedure, because while you should *not* use it for that purpose, the general technique is useful in many situations. The reason you're unable to delete the file just by browsing to it normally is that it is owned by the root user, and only the root user has permission to modify it. (I have written some about the root user in my last post--if you are unclear about why having a locally all-powerful root user account but using a limited account for most tasks is a *good* thing, please let me know, and I'll explain or provide links.) The program "gksu" is a preferred way to run graphical programs as root. The file browser is called Nautilus and the command that can be used to run it is "nautilus" (because its executable file is /usr/bin/nautilus). Therefore, "gksu nautilus" gives you a file browser with "God powers" that you can use to perform administrative tasks (including very-much-not-recommended administrative tasks like this one).

You could similarly use this technique to delete or modify entries inside /dev. This is another thing that you should not do. In fact, this would be way worse than removing cabextract.desktop--messing with the contents of /dev unless you really know what you're doing (and sometimes even if you do know what you're doing, but make a mistake) can break your Ubuntu system in rather profound ways. Furthermore, these days (see http://en.wikipedia.org/wiki/Udev), if you do need to remove entries from /dev -- which you almost always should not do -- manually deleting them is not the best way to do it. If you want more information about this, please feel free to ask.

"We might have different definitions for 'reasonable', but I'm not imagining my systems going to chaos in front of my eyes, without my doing a single thing about it except 40 or so reformats and OS reinstalls when it's game over."

Perhaps I was unclear. Having your Windows system taken over by a malicious intruder is a problem that definitely needed fixing. It was not "reasonable" in any meaningful sense. I hope no one has taken the attitude that that's not a problem, for it certainly is. I hope I have not inadvertently conveyed that attitude--to do so was not my intention. And there is a sense in what that is chaos--that is a legitimate term to use for a situation where a user does not have control over his or her own computer system.

Without wishing to come off as argumentative, I feel I must say that there is no sense in which any of the other things you have asked about so far are "chaos." One of them is an indication of a problem (the presence of a unicast .local domain on your network), though it might be a problem without any serious negative ramifications. The openafs issue seems to me to merit greater investigation, but that impression might be primarily because of my only cursory understanding of openafs; this is one of the reasons why I am encouraging you to start a new, separate question about that. Most of the things you have noticed and found odd and curious on your Ubuntu system and asked about are present on all or most Ubuntu systems, and if they weren't that way, your Ubuntu system would be broken--for some of these things, severely broken. For example, you would probably not have a functional desktop environment without bamfdaemon, you would probably have no working graphical user interface without /usr/bin/X11, and pretty much everything would be nonfunctional without the /dev/ttyN files. The common thread that seems to be woven through most of your concerns is the presence of strange-looking phenomena on your system, combined with your concern about not being able to change or remove those things (which, with the exception of openafs, you have been unable to change because you are using a program that is not being run as root). It was in the context of your concern that these things might be an indication that you were (or were still) experiencing a security breach that said that, on the contrary, these things appear to be reasonable.

Your questions are quite legitimate, and they merit answers. I find answering them to be worthwhile and enjoyable, and I encourage you to keep asking them. The oddities or apparent oddities of Ubuntu and other Linux-based operating systems are worthy of explanation, not just so that interested users who wish to approach their computers with a technical attitude can progress toward a point of knowing on sight when something really is just-not-right, but also because answering questions about oddities often also conveys a more general understanding about how stuff works. In saying that the things you ask about tend to have reasonable explanations, I do not mean that your questions aren't legitimate or important, but instead that I hope my answers to them have the effect of moderating your high degree of apprehension (which, based on your past computing experiences, is probably justified).

In addition to asking questions, I'd also encourage you to read up on topics that are of interest to you. In particular, you might find the documentation at https://help.ubuntu.com, http://tldp.org, and the manual pages (accessible through the Yelp help browser, at http://manpages.ubuntu.com, and also via the man command, see http://manpages.ubuntu.com/manpages/lucid/en/man1/man.1.html). People who gravitate toward use of the Terminal typically prefer to read manual pages on the Terminal as well. macrobra provided links to some other good resources in his first post in this thread.

"But today in logs I saw this in /var/log/Xorg.0.log - line 7 seems like a problem. http://codepad.org/P5BU3zuA"

First of all, this has nothing to do with the BIOS. Second of all, this has nothing to do with virtual machine or VMware (as I suspect from context you may have been thinking). /boot/vmlinuz-2.6.38-8-generic-pae is the kernel image file that gets loaded into RAM on bootup. The "vm" is because, like any remotely modern kernel except on tiny embedded systems, it supports virtual memory. The "z" at the end is because it is compressed with the gzip algorithm. "generic" means that it's compiled with standard options--in Ubuntu, the desktop kernel is "generic", whereas the server kernel, called "server" instead of generic, is compiled with an altered configuration that renders it better for acting as a high-throughput network server. "pae" means that the kernel is compiled with Physical Address Extension enabled, which makes it so that it can address (i.e., access) more than 3.5 GB of RAM even with a 32-bit processor. See http://en.wikipedia.org/wiki/Vmlinuz and http://en.wikipedia.org/wiki/Physical_address_extension.

b511f6e9-75d8-425f-9b14-fb6d269f7fdf is the universally unique identifier of the partition that is mounted as / (i.e., of the root filesystem). See http://en.wikipedia.org/wiki/Uuid. See http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/ch09.pdf for an explanation of the ro, quiet, and splash options. vt.handoff=7 means that when the system boots the 7th virtual terminal (tty7) will be shown--this is the virtual terminal on which Plymouth runs (the graphical screen with the Ubuntu logo and the dots as your system boots up), and on which the graphical user interface typically runs.

"So a BIOS image is installing a VMware mouse. Which has functionality I don't care for, really. It seems...security-related."

This also has nothing to do with the BIOS. The file /usr/share/X11/xorg.conf.d/10-vmmouse.conf is present by default in *all* Ubuntu 10.04 Lucid systems (http://packages.ubuntu.com/search?searchon=contents&keywords=vmmouse.conf&mode=&suite=lucid&arch=any), and similar files performing the same function are present in other Ubuntu releases (such as 50-vmmouse.conf in Natty, which has exactly the same contents).

Ubuntu supports a wide variety of pointing devices, which includes the virtual mouse device that is part of a VMware virtual machine, which enables the user to use the host (physical) machine's mouse pointer as the mouse pointer on both the host and guest (virtual) machines. By way of example, you are unlikely to have a synaptics pointing device *and* a wacom pointing device attached at the same time, but it's nonetheless not a problem that Ubuntu has support for both at the same time. Ubuntu is very tolerant of hardware changes by retaining drivers and configuration files for a wide variety of hardware--there is very little to lose with this approach, and much to gain. It stinks when you change your computer's hardware and then suddenly your operating system breaks--the Ubuntu project considers that kind of (mis)behavior to be a bug except where there is a strong rationale to justify it.

I highly recommend you leave this file alone, but if you want to remove it, it is again very strongly preferable to remove the package that provides it, rather than the file itself. (Removing that file wouldn't actually remove support for a vmmouse pointing device anyway, it just *might* prevent one from working properly.) To do this, which I again recommend you *not* do, you could run the command:

sudo apt-get purge xserver-xorg-input-vmmouse

That will also remove the virtual package xserver-xorg-input-all; the result of that is that you would not get support for new classes of input devices as updates to Ubuntu. Since new major functionality is not added in the default software sources, this would be very unlikely to cause any problems for you, unless you have enabled (or will one day enable) the backports repository *and* need the new functionality (which might be why you'd enable backports). You could re-add the package then...but since there is no benefit associated with removing it now, I recommend against doing so.

"How wonderful, that if a virtual machine is not detected, it's capable of performing as my mouse driver?"

You have misunderstood what is says. It will relinquish control to the driver for a non-vmmouse pointing device, not *act* as the driver for a non-vmmouse pointing device.

"I might have uppity standards, but I'd prefer to be first choice for all drivers installed on my system."

What do you mean by that? I can think of two ways to interpret this. You could be saying that a fundamental change in the way a device is used is something you'd like to be informed of and consulted about before it goes into effect, in which case, that's already the case (except in situations where you can't be informed of it because the system *has* to use an alternate driver in order to function at all, such as is the case when the graphics driver you're using breaks--Ubuntu will try to use an alternate driver so you have a graphical interface). Or you could be saying that you don't want other people (the Ubuntu developers) to select what drivers run in your system for you, but that instead you want Ubuntu to ship in an initially unusable state, which is rendered usable by the act of you manually installing the specific drivers you want for all your devices. You can control what drivers are installed on your system and what drivers are enabled, but if you want to have to take an active role in order for a driver to be installed in the first place, then I'd recommend migrating from Ubuntu to http://www.linuxfromscratch.org/.

If you mean something else, please clarify.

By the way, I don't have an Ubuntu 10.04 system so I don't know this for sure, but I would be very surprised if the vmmouse driver were actually running. You can find out by running:

sudo lshw | grep driver; echo; lsmod

That will list all the drivers that are running or configured for use with hardware that Ubuntu detects your system to possess.

"So, knock wood, the damage is limited to under 10k so far, if I can just nail down the security hole I'll buy entirely new hardware and be done with the thing. Surely there are logs I should be looking at?"

Unless someone is targeting you specifically, which is usually not the case but I'm not familiar with the details of what you've experienced, a security breach of an individual user's computer or computers is typically due to running vulnerable software which is exposed to an exploit. For example (and this is just an example, this is not related to your situation **at all**), a user with an exploitable browser might visit a malicious website that exploits a vulnerability in the browser to steal information--such as the username and password for the current login to their banking website--from a different window/tab. Sometimes insecure user practices are involved as well. For example, users who run programs that they receive in their email are at risk of installing malware, as are users who click "Install Now" in their web browsers without making sure that what they're installing is OK, and users who fail to regularly update their systems. Bad personal practices greatly increase the change of being exploited but good practices don't eliminate all the risk. (Please note that as an exposition of vulnerable software and bad user practices, that is an example, and is extremely far from being exhaustive.)

Given what you have said, I see no reason to worry about a current credible threat to your security when running Ubuntu. It sounds like you are looking for something that is not there. So far, you have not presented any evidence that your Ubuntu system has been exploited or is under attack, or even that it has *ever* been under attack. (Your Windows system obviously *was* under attack, and at least one attack on it succeeded with quite unfortunate flying colors.) A security breach of your past Windows system would almost certainly not leave any forensic clue that would be visible in your current Ubuntu system.

"But then I'm not sure why I even need Avahi in the first place."

You very likely don't need avahi, but on the other hand, there is very little reason to disable it, now that it is working, and there is a significant (though not huge) chance that you will need in in the future and will have to re-enable it. Furthermore, running avahi does not incur a high security risk. I would keep it as it is, but that is really more a matter of personal preference than anything else.

You can find out the consequences of removing Avahi:

apt-get -s remove avahi-daemon

(Feel free to post that here so I can help you interpret it.)

If you go through with the option that simulates, Avahi will no longer be running. You could go the extra mile of getting rid of all avahi-related packages, which I do not recommend you do, but which wouldn't have dire consequences like those associated with removing entries from /dev. To simulate that:

apt-get -s remove avahi-\* libavahi-\* python-avahi

That operation is extensive enough that it might not actually be possible, without manually removing or adding other packages too, besides the ones that the package manager "feels comfortable" removing/adding automatically. If that is the case, the simulation will of course reveal that as well.

(If you actually go ahead with removing stuff, then in this case you may want to use apt-get remove rather than apt-get purge, because you may want to keep the configuration files, such as the file you modified to make avahi work in your network situation.)

"But I'm confused (exhausted), it wasn't Avahi that was causing the problem right? Avahi was merely detecting it, no?"

Avahi was detecting the problem. The problem prevented Avahi from working. Avahi did not cause the problem, though if you were to define the problem not as "there's a .local unicast domain even though .local is supposed to either not exist or be multicast" but instead as "software I don't need is producing an annoying error message since it's unable to start" then you could say that Avahi was causing the problem. ;-)

"Ohhh, is .alocal simply to eliminate the error message from Avahi?"

No, you have not merely silenced the error message. You have actually worked around the problem and enabled Avahi to work, whereas before Avahi did not work.

"It's still a unicast .local domain isnt' it?"

No, .alocal is a multicast domain (and its name is no longer .local), just like the .local multicast domain that Avahi is configured by default to use but couldn't because it would have conflicted with the .local unicast domain, which should not exist but does, probably because some DNS server somewhere creates it even though it shouldn't.

"Not sure it's important, as config looks...? ok? ;) http://ideone.com/XtkCn"

That looks OK, though not every possible problem can be detected by looking at that output. Notably, it says that avahi-daemon is off. Please note that just because chkconfig says that something is "off" doesn't mean it's not running (it just means it doesn't get run by the start-up mechanism that chkconfig is used to examine and configure, see http://manpages.ubuntu.com/manpages/lucid/en/man8/chkconfig.8.html). For example, on my system:

ek@Apok:~$ chkconfig | grep avahi; ps ax | grep -v grep | grep avahi
avahi-daemon off
  802 ? S 0:03 avahi-daemon: running [Apok.local]
  804 ? S 0:00 avahi-daemon: chroot helper

(And I have not modified any avahi-related configuration on this system.)

"~$ testparm -v http://ideone.com/jgeqa"

What do you want me to look for as I am examining this? This doesn't really relate to Avahi--it gives information about Samba configuration (for SMB/CIFS file sharing).

"Ah crap, Avahi just...ah, this is too much for me."

In my opinion, beyond what you have already done (making Avahi use .alocal instead of .local), there are two options that are both reasonable and relatively simple:

(1) Do nothing.

(2) Remove Avahi--by which I mean the Avahi service, the thing that actually runs and does stuff--using the command "sudo apt-get remove avahi-daemon". Before doing this, I highly recommend running "apt-get -s remove avahi-daemon" to see what else would be removed, and please feel free to post the output of that command here for analysis.

"Avahi is uninstalled but..somehow not. http://pastebin.com/s4qZep39"

I'm not sure what you've done to uninstall it, but two things come to mind:

(1) Many of those files are associated with other avahi packages besides the one you would remove in order to make sure Avahi doesn't run. They would be removed by the longer, more hard-core, less recommendable removal command (which you could still run even if you have run the first command)--but see #2.

(2) Some of those are configuration files, which are retained in a removal operation, but not in a purge operation. I have shown both removal and purge commands using apt-get. If you are using the Synaptic Package Manager, then "Mark for Removal" sets a package up to be removed, and "Mark for Complete Removal" sets it up to be purged. Keeping configuration files is often actually a good thing, so that you get your configuration back if you reinstall the package. Since the presence of a configuration file cannot enable a package's program to run and they don't take up much space, quite often removal operations are preferable to purge operations, and almost always they are sufficient. (One situation where they are not sufficient is if you suspect that a package's files are broken, perhaps including breakage of the configuration files. That situation does not seem to apply here.)

"200 processes alive"

That's not an unusually large number. I have 159 processes running right now, and I'm running a more lightweight variant of Ubuntu (Lubuntu).

"and I can't kill them with sudo kill or killall."

You'll have to provide more information about that, for me to offer advice. Except I can make two comments:

(1) Killing a process owned by root often prevents your system from working correctly (though rebooting should correct problems caused that way). There's nothing inherently destabilizing about killing root's processes, it's just that root's processes tend to be running for a reason. Sometimes that reason is more important than other times. By killing your own processes, you might have to log out and back in to fix the problem, but the consequences there are usually less severe than when killing root's processes, especially if you know that the processes are associated with malfunctioning programs that need to die, such as a hung flash plugin ("npviewer.bin") taking up 100% CPU.

(2) Suppose, for this example, that a process's pid is 2000. If I run "kill 2000", that sends the terminate signal (SIGTERM) to the process, which tells it that you want it to terminate, and to perform any important last operations (cleaning up after itself) and then quit. But a process is free to ignore SIGTERM. If you really need a process to die, you can send it SIGKILL, which it cannot ignore. To send SIGKILL to a process, run "kill -KILL 2000". On Linux-based systems, the signal number for SIGKILL is 9, so "kill -9 2000" also works. (And now you can understand http://www.youtube.com/watch?v=Fow7iUaKrq4.) See http://en.wikipedia.org/wiki/Unix_signals, http://manpages.ubuntu.com/manpages/lucid/en/man1/kill.1.html, and http://manpages.ubuntu.com/manpages/lucid/en/man1/killall.1.html for more information. Generally speaking, you should at least attempt to kill a process with SIGTERM before you kill it with SIGKILL.

"ugh. I can't kill this ssh-agent thing. http://pastebin.com/fhFZWkxS"

ssh-agent is provided by the package openssh-client. OpenSSH is very useful, so you should perhaps not remove this. But if you do, you can put it back. And you might well not have use for OpenSSH. As before, I recommend checking to see what the consequences would be of removing it, before actually doing so:

apt-get -s remove openssh-agent

Finally, whatever operating system you use is your choice--no one else cannot make that choice for you. You may have very good reasons for choosing not to use a Linux-based operating system--it depends on many factors. But any operating system that is sophisticated enough to be useful, especially on a general-purpose computer, will also contain intricacies that don't have immediately obvious explanations. I dare say that you'd probably find just as many comparable curiosities on a Windows system by browsing through the registry (you can use regedit.exe) and Event Log (you can use eventvwr.msc).

Hi Eliah, just a quick note to say I was humbled and in awe of your spectacular assistance - just...wow. I had a pretty long post written, which largely comprised of my blubbering in gratitude for assistance which, frankly, I feel embarrassed to receive and undeserving of.

Just quickly with Avahi, after I changed .local to .alocal and reconnected, no warning message flashed so I assumed that meant Avahi was working. I'm not so sure it was. Actually, I'm really confused. I can't remember the uninstall commands I used to (not) uninstall Avahi, but *blush* avahi-daemon was not included. The commands I used did however, delete the config files I had just gedit'ed and saved. Or blanked them. I'm not sure if ~$ sudo gedit /etc/example.conf actually creates a new blank example.conf

Anyway, I noticed in exasperation towards the end of the post that the /etc/avahi/avahi-daemon.conf files had just...reappeared all full of configured settings. The .alocal was still set, however.

later, when I rebooted, the warning message came up from Avahi again about the .local domain. I checked /etc/avahi/avahi-daemon.conf expecting to see .local but .alocal was still there! Hecka confused at this stage, I installed avahi-discover and it said Avahi wasn't running, which is to be expected I suppose.

I'd written all this out and a lot more, when my ISP arrived with a replacement VDSL modem. First, they couldn't access the old modem using 198.168.0.0 or w/e, but they got into it fine with their laptop. I thought that was an issue worth discussing, but they weren't intrigued by it. The technician said the .local domain was being created by incorrect DNS settings, he entered in the correct ones, and asked if I still wanted the new modem. I shrugged and thought :whynot, they replaced it and configured it all, and I disconnected network-manager and reconnected, and lo and behold, the .local warning again. .alocal was still in the .conf file. So they were wrong about the cause. But they had no further theories.

We immediately tried to run some dslreports.com speed tests, but strange stuff was happening which effectively amounted to ubuntu hanging basically. I rebooted, for the first time since the new modem was installed (not sure if that's important) and....GAME OVER. My PC would boot through the BIOS checks, then greeted by an indefinite black screen.

I had earlier in the week created a boot disc with JoliCloud, so I threw that in loaded Joli from the CD and tried to access my files, I could see them all there I think, but inaccessible. Nothing of value, so I shrugged and formatted with the Joli CD and everything seemed great, until it told me to remove the disc and reboot. Same black screen.

To cut a long story short, sigh, I was forced to low level format again, rewrite the MBR, flash the BIOS and then enumerate the drivers with a HP utility. To be honest, I completely forgot about your recommendation above to format the drive, regrettably. Then, because I have a STACK of overdue work piling up, I installed Win7 as I just know my way around it a bit better. That took most of the day, I just wanted to quickly say an inadequate thanks! and let you know I'll be back once I've caught up on work, and trick my g/f into foolishly remaining so.

Oh, and there's a lot wrong with my new Win7 install. A LOT wrong. but I have to get back to the real world for a little bit...thanks again, I'm humbled by the quality of your response above...just amazing stuff...I'll be back asap...

Just one super quick question, does a Linux format ignore NTFS USN Journal records?

The reason I ask, is I have 675,925 lines in Notepad of USN Journal output from a NET USER ADMINISTRATOR elevated command > fsutil usn enumdata 1 0 1 C: >> usn.txt on my SO-NOT-FORMATTED hard drive. A mountain of hardlinked files as well. Like, there has to be something relevant about these USN Journal entries as like I said, my Win7 genuine (dis) advantage clean install is a mess already. One of the 'messes', is I've got some environment variables I'm pretty sure I don't want and which aren't default, swapped (without my consent or even memo'd) for some ones I really do want, which allow me to oh, execute files. Another of the 'messes', is the INBUILT Administrator's inability to do much at all, like fsutil usn deletejournal /d /n c: (and other tricks) doesn't delete squat. And he's useless against registry keys that really require deletion, but of course really don't recognise the rank structure in my 1-computer domain which, I have a sneaking suspicion, is in a domain not entirely as redundant as Microsoft experts would argue.

But anyway I have to reformat again to give myself a day or two of operational working time, till I can buy some new systems or w/e. K I gotta run, thanks again and please ignore the above Windows issues if they're deemed unrelated to Avahi (though I really think everything is related, and it's all about the ostensibly redundant Windows domain / workgroup / NT crap Win7 users are saddled with, and I have some Windows logs from my install, and a stack of adjusted non-default UAC and remote access values and whatnot (all changed from the very few GOOD Microsoft default settings, the very rare GOOD ones lol)..which I think suggest I'm right. But what do I know, aside from the fact if I don't end this now, and get work done and trick my annoyingly bright g/f into being a sucker, it will all be moot very shortly and I wont' need to worry about new systems as there are no power plugs under the bridge, where my tent will be.

So holla for now, thanks again, you're a legend, and I'll be back once I have my head above water, and stuff.

I'll try and reply to your recent messages pretty soon, but I just noticed that I provided incorrect (though not dangerous) information near the end of my last post. To simulate the operation of removing the OpenSSH Client (openssh-client), you would run

apt-get -s remove openssh-client

and not

apt-get -s remove openssh-agent

as I had mistakenly said.

(I realize that this is probably not relevant to you right now, as you have wiped out your Ubuntu system, but I didn't want that to unnecessarily go uncorrected.)

This is a reply to the first of your two recent messages (i.e., not your most recent message, but the one before that). I hope to get a chance to reply to the other one soon.

"Just quickly with Avahi, after I changed .local to .alocal and reconnected, no warning message flashed so I assumed that meant Avahi was working. I'm not so sure it was. Actually, I'm really confused."

Since the Ubuntu system this was on no longer exists, we cannot examine it to figure out what's going on. But if you end up deciding to reinstall Ubuntu and experience similar issues, then we can look into it.

One of the ways to test Avahi is to see if functionality that it provides works:
http://en.wikipedia.org/wiki/Zero_configuration_networking

In particular, since you have multiple physical machines, you could connect two of them directly with an Ethernet cable, enable link-local networking for the Ethernet interface in the Network Manager, and see if it works. (Automatic IP address assignment over a link-local network is one of Avahi's functions.)

"First, they couldn't access the old modem using 198.168.0.0 or w/e, but they got into it fine with their laptop. I thought that was an issue worth discussing, but they weren't intrigued by it."

Do you mean they couldn't access it from your computer, but they were able to access it from their computer? If so, that is interesting. Of course, to examine this further, you would have to know (or discover) the actual IP of the device--it was probably not 192.168.0.0. You might be able to find it in your web browser's history, if they tried it on a computer that has not since been wiped.

192.168.100.1 is probably the most common IP address exposed by a cable/DSL/ISDN modem to a LAN for configuration.

"The technician said the .local domain was being created by incorrect DNS settings, he entered in the correct ones, and asked if I still wanted the new modem. I shrugged and thought :whynot, they replaced it and configured it all, and I disconnected network-manager and reconnected, and lo and behold, the .local warning again. .alocal was still in the .conf file. So they were wrong about the cause. But they had no further theories."

It's probably still caused by wrong DNS configuration. Just not the configuration that they (able to have) edited.

But are you saying that you had the "Better workaround" from http://avahi.org/wiki/AvahiAndUnicastDotLocal still implemented, and you saw the same error you'd previously seen before implementing it, which had gone away when you had implemented it?

"We immediately tried to run some dslreports.com speed tests, but strange stuff was happening which effectively amounted to ubuntu hanging basically. I rebooted, for the first time since the new modem was installed (not sure if that's important) and....GAME OVER. My PC would boot through the BIOS checks, then greeted by an indefinite black screen."

It seems that perhaps your computer has hardware problems. I recommend testing its RAM (you can do this by selecting memtest86+ in the boot menu on any Ubuntu system or live CD--to do it on a live CD, you'll have to press Spacebar when you first see the keyboard and person icons at the bottom of the screen and then select your language first) and its hard disk (with a S.M.A.R.T. utility).

Besides that, I'd need more information. The system Ubuntu system would have to still be installed in order to examine it.

"To cut a long story short, sigh, I was forced to low level format again, rewrite the MBR, flash the BIOS and then enumerate the drivers with a HP utility."

You probably don't have to keep re-flashing the BIOS every time.

"Just one super quick question, does a Linux format ignore NTFS USN Journal records?"

Super quick answer: Yes.

Longer answer: Yes, so if they survived, that's strange! How did you format the partition? By the way, this has nothing to do with USN journals, but if you want to wipe everything out (which seems to be the attitude you were taking, what with re-flashing the BIOS and all), rather than formatting existing partitions it makes more sense to do a "low-level format", creating a new, empty partition table. In Unix-style slang, the partition table is often called a disklabel. To do this in GParted, you would use Device > Create Partition Table... (If you've got more than one drive, make sure the right device is selected lest you wipe out the partition table on the wrong drive!)

(To clarify--if you are about to install Windows, you can just make a new partition table, you don't actually have to create any partitions first. This is also the case when you're about to install Ubuntu. The OS's installer will create the partitions. In the Windows case, if the issue with the USN journal entries persists, then it certainly has nothing to do with Ubuntu, so then you can post in a Windows forum to get answers.)

Hi Eliah, quick question sorry. My PC has crashed a couple times and I'm trying to use scrub to low-level format it.

But I just couldn't get anything to work. I noticed this filesystem on my installation USB trying to install Linux after Windows exploded again. I've done research on this, found lots of threads where smarter people than I don't know what it's about, kind of sick of doing that actually (just frustrated, that you're the only guy with a clue IN THE WORLD lol). I just make this point so that you know I'm not being lazy, it's just the same old pattern of a problem, research for an hour, end up with 50 more questions. I realise a large element of it is my ignorance, but the endless running around after headless chickens is wearing me down.
http://ubuntuforums.org/showthread.php?t=1615428
http://ubuntuforums.org/showpost.php?p=10715286&postcount=29

I don't know if this filesystem is legit but whenever something has "loop" or "0" in it, and it's causing hassles, I find the coincidences a bit much to ignore...

//filesystem.squashfs
/dev/loop0

--------------

Device: /dev/loop0
Mount Point: Mounted at /rofs
Connection: Unknown
SMART Status: Not Supported
Capacity: 702 MB
Partitioning: Not Partitioned

Unable to Format Drive
Unable to Unmount Volume
Unable to Format Volume
Unable to Check Filesystem

ubuntu@ubuntu:~$ sudo umount /dev/loop0
umount: /rofs: device is busy.
       (In some cases useful info about processes that use
        the device is found by lsof(8) or fuser(1))
ubuntu@ubuntu:~$ sudo fuser /dev/loop0
Cannot stat file /proc/3193/fd/35: Stale NFS file handle
Cannot stat file /proc/3193/fd/36: Stale NFS file handle
Cannot stat file /proc/3193/fd/40: Stale NFS file handle
Cannot stat file /proc/3193/fd/41: Stale NFS file handle
Cannot stat file /proc/3193/fd/42: Stale NFS file handle
Cannot stat file /proc/3193/fd/43: Stale NFS file handle
Cannot stat file /proc/3456/fd/35: Stale NFS file handle
Cannot stat file /proc/5388/fd/23: Stale NFS file handle
Cannot stat file /proc/5388/fd/24: Stale NFS file handle
ubuntu@ubuntu:~$ sudo lsof
lsof: WARNING: can't stat() tmpfs file system /cow
     Output information may be incomplete.
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ubuntu/.gvfs
     Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
init 1 root cwd DIR 0,17 340 2 /

**then about 50 pages (no joke) of output, could only copy a bit for some reason, which is here:
https://docs.google.com/document/pub?id=1idhhNjbmYLhaWHd2OvJDzquoUpB3sXLZJGPm1woP3_c

**and then ubuntu hanged, everything faded to dark...

------------------------------------

A few minutes later, I saw a "Drive Critical" message flash, something about the drive being full, then kaput. PC goes to black screen post BIOS.

I'm just..I think it's an issue to do with DNS in my modem settings, I was in the middle of something that looked promising on OpenDNS.com instruction page, when my friend's laptop crashed. Format / reinstall number 54 or something.

Sorry if this makes no sense. I'm freaking exhausted. Thanks champ!

The amount of coincidences is just...mind-blowing (if it's somehow unrelated to the fact my systems implode endlessly). On Wikipedia:

-----------------
http://en.wikipedia.org/wiki/Loop_device

In Unix-like operating systems, a loop device, vnd (vnode disk), or lofi (loopback file interface) is a pseudo-device that makes a file accessible as a block device.

Before use, a loop device must be connected to an existing file in the filesystem. The association provides the user with an API that allows the file to be used in place of a block special file (cf. device file system). Thus, if the file contains an entire file system, the file may then be mounted as if it were a disk device.

Files of this kind are often used for CD ISO images and floppy disc images. Mounting a file containing a filesystem via such a loop mount makes the files within that filesystem accessible. They appear in the mount point directory.

A loop device may allow some kind of data elaboration during this redirection. For example, the device may be the unencrypted version of an encrypted file. In such a case, the file associated with a loop device may be another pseudo-device. This is mostly useful when this device contains an encrypted file system.....

Some confusion exists about the naming of the loop device under various operating systems. Various Unix-like operating systems provide the loop device functionality under different names.

In Linux, device names are encoded in the symbol table entries of their corresponding device drivers. The device is called "loop" device and device nodes are usually named /dev/loop0, /dev/loop1, etc. They can be created by the makedev script for the static device directory, or dynamically by the facilities of the device filesystem (udev). The management user interface for the loop device is losetup and is part of the util-linux package.

Sometimes, the loop device is erroneously referred to as 'loopback' device, but this term is reserved for a networking device in the Linux kernel. The concept of the 'loop' device is distinct from that of 'loopback', although similar in name.

In BSD-derived systems, such as NetBSD and OpenBSD, the loop device is called "virtual node device" or "vnd", and generally located at /dev/vnd0, /dev/rvnd0 or /dev/svnd0, etc., in the file system. The vnconfig program is used for configuration.

Loop mounting is not natively available on Microsoft Windows operating systems (until version Windows 7, where this functionality is natively implemented, and available through the diskpart utility....

The device can then be unmounted with the following command:

umount /dev/loop<N>

**Jonny: no. no it cannot, at least in my case.**

At a lower level application programming interface (API), the association and disassociation of a file with a loop device is performed with the ioctl system call on a loop device.

See also

    Device file system
    Virtual drive
    Network block device used when the file to associate with the device is on a remote computer
    With similar name, but different concept, a loopback interface, or loopback device is network facility in UNIX-like operating systems

--------------

Apologies for cut/pasting that as I'm sure you're fully aware of what a basic Wiki page summary has on it. But the sheer number of times everything seems connected to this .local domain which appears destined to be the death of me....

And what I cannot understand, is why I even had a loop device on my USB installation boot flash drive. Unless I'm missing something, I went to some effort to create that flash drive checking the MD5 hashes and whatnot, so that I didn't have to have virtual mounted ISO images...?

"Just one super quick question, does a Linux format ignore NTFS USN Journal records?"
---------------------

***Yes, so if they survived, that's strange! How did you format the partition? By the way, this has nothing to do with USN journals, but if you want to wipe everything out (which seems to be the attitude you were taking, what with re-flashing the BIOS and all), rather than formatting existing partitions it makes more sense to do a "low-level format", creating a new, empty partition table. In Unix-style slang, the partition table is often called a disklabel. To do this in GParted, you would use Device > Create Partition Table...

***(To clarify--if you are about to install Windows, you can just make a new partition table, you don't actually have to create any partitions first. This is also the case when you're about to install Ubuntu. The OS's installer will create the partitions. In the Windows case, if the issue with the USN journal entries persists, then it certainly has nothing to do with Ubuntu, so then you can post in a Windows forum to get answers.)
----------------------

Just whilst I'm waiting for Canonical, and for the record, all my formats have been low level formats. But simply creating a new, empty partition table isn't low-level formatting correct? When I say I've been low-level formatting every time, I mean zero'ing out the entire drive with DBAN or KillDisk.

Then I have to use utilities on Ultimate boot CD to create the MBR code, and enumerate the hardware so that an installation CD or USB will be recognised. At which point, I then of course format the drive again into a single partition, and install.

I do this every time. And I have 700,000 lines of USN Journal data from a BRAND new Genuine Advantage Win7 installation. And USN Journals I can't delete, even using the BUILTIN Administrator from the command line.

I don't think I'm the Administrator of my home computer, which is what I've been telling IDIOTS on Windows forums for oh 9 weeks now.

***if the issue with the USN journal entries persists, then it certainly has nothing to do with Ubuntu, so then you can post in a Windows forum to get answers.

I appreciate that, trust me I do. But that's some sense of dry wit you have going there, telling me to look for the answers on a Windows forum hahah.

But is it not a Linux issue also, in that 3 distributions (ubuntu, Mint and JoliCloud - not sure if Joli counts) haven't been able to touch the USN Journal code either?

There seem to be two separate issues here.

One issue is that you are still seeing strange results when you inspect the USN journal on the drive that you erased. If I knew how to help you with that, I would--I suggested you use a Windows forum because I don't know how. While the online community is one of the strong points of Ubuntu, especially compared to other operating systems, and especially compared to Windows, I am taken to understand that there are nonetheless some good support forums for Windows. Unfortunately, I don't know enough to refer you to one. (The only Windows support forum I'm really familiar with is social.msdn.microsoft.come which is for software development, so this issue would not be on-topic there.)

I do have one idea with regard to this, though. Have you investigated whether these USN journal entries are real entries, as opposed to totally random data from the disk scrubbing process that your utility is recognizing as entries? Have you examined them and gotten information that has proven to document actual disk writes that have occurred?

By the way, the term "low-level format" typically refers to the creation of a new partition table, and not to scrubbing a disk. I tend to avoid that term, since it produces a lot of confusion. If you do scrub a disk completely, then the information that is replaced in a low-level format is eradicated and a low-level format is necessary to again use the disk. Therefore, if you have a bad partition table and you need to get rid of it, and a low-level format is necessary, scrubbing the disk will do the trick too. (These days, operating systems will perform a low-level format as an early installation step, if there is no partition table.)

I'll post about the other issue shortly.

The other issue is that you tried booting from the Ubuntu install CD and got the messages at https://docs.google.com/document/pub?id=1idhhNjbmYLhaWHd2OvJDzquoUpB3sXLZJGPm1woP3_c&pli=1. I am not sure when, during the installation process (or during the process of perform other, non-installation tasks with the live CD/DVD or live USB), you saw these messages. If you create a new question about this issue (I'll get to the matter of whether or not you should do that near the end of this post), then please make sure to explain exactly when those errors appeared.

You have diligently looked into the issue of loop devices on Linux-based operating systems. Unfortunately, while those errors *do* pertain to loop devices, knowing about loop devices is unlikely to help you fix the problem. This is because any error you see while attempting to boot an Ubuntu install CD/DVD or live USB, or while installing, which says anything about squashfs or loop (or tmpfs or /tmp or about how it cannot access files) is a strong indication that the problem is due to one of the following related conditions:

(1) The downloaded .iso image is corrupted, either due to a bad download or (much less likely) due to becoming corrupted after it was downloaded.

(2) The downloaded .iso image was burned to CD/DVD incorrectly, or written to the USB flash drive incorrectly, either due to an incorrect technique, or due to corruption during the process of writing (both these causes commonly occur). The likelihood of the latter can be reduced (but not to zero) by burning the CD/DVD at the slowest possible speed (that advice doesn't apply to writing .iso images to USB flash drives, though).

(3) The data on the burned CD/DVD became corrupted or otherwise rendered inaccessible between when it was burned/written and when it was attached/inserted for installing on the target machine. This is not as uncommon as you might think. For a CD/DVD (especially a DVD), there is some risk of this every time the disc is taken out or put into a drive.

(4) The CD/DVD cannot be read by the drive on the target machine, because there is something wrong with the drive, or (these days much less likely, except with some of the later PPC macs that some people still have) because the drive does not support the specific type of CD/DVD.

Now comes the part where I am going to give advice that you have probably seen (but you haven't said if you followed it). And maybe you haven't seen it. Just because this is the advice that should first be given whenever the problem you've experienced comes up doesn't mean it necessarily is.

To check for [1], an MD5 test of the .iso image should be performed (https://help.ubuntu.com/community/HowToMD5SUM). You should do that now if you haven't already. If that doesn't check out, you'll have to redownload the .iso image, MD5 test the new image, and (assuming the new one checks out) burn it to the CD/DVD or write it to the USB flash drive again.

To check definitively for [2], [3], and [4] (so that after the check you can be pretty darn sure none of those conditions apply--figuring out which one applied is a bit more complicated), boot from the CD/DVD or USB flash drive and immediately when you see the person and keyboard icons at the bottom center of the screen, press Spacebar, select your language, and select "Check disc for defects". If that reports that any files don't check out, you'll have to re-write the .iso image to the USB flash drive (and run this test on it again). This should be done on the *same* machine that you're trying to install on, because (a) it's sort of a waste to reboot another machine besides the one you want to install Ubuntu on, (b) if it tests out but then gets damaged, or the data otherwise corrupted, during the process of being moved to the new machine, then the sort of problem you were checking for would have been introduced *after* the check, and (c) if you test it on another machine and it checks out, there could still be a problem with--or limitation inherent in--the optical drive in the target machine that you haven't discovered (or, for a USB flash drive, the machine could be incapable of booting from a USB device, or there could be problems with the USB controller).

As you have probably guessed, doing "Check disc for defects" might not be possible. If you never see the keyboard and person icons at the bottom of the screen, or you get errors when you attempt to check the disc for defects, then this could also be the result of [2], [3], or [4]. (Or of [1], if you didn't rule that out by doing the MD5 test.) If that happens, you should try burning the CD/DVD image (or writing the USB flash drive) again, and make sure you are doing so correctly. Perhaps use a different method. If that doesn't fix the problem, or "Check disc for errors" completed successfully and didn't discover any problems, then you should post a separate question about this issue.

If you wish, you can post a link to the new question in this question--if you do that, I'll make sure to visit and subscribe to the new question, and I'll try to help out with it if my assistance would be helpful (though it's likely that someone else may get to it first, including people more knowledgeable in and experienced with installation problems, such as actionparsnip, delance, marcobra, Colin Watson, bcbc, and a couple others whose names I'm just not thinking of right now).

If you create a new question, you should include all the information you've posted here about this specific installation problem (not about the previous or concurrent issues that seem unrelated, like the Avahi issue and the USN journal issue), and you should make sure to describe in detail what you have tried and what has happened (otherwise people will probably ask you if you've done all the things that I've said to do in this post). As I mentioned near the top of this post, you should also clarify *when* the errors you posted at https://docs.google.com/document/pub?id=1idhhNjbmYLhaWHd2OvJDzquoUpB3sXLZJGPm1woP3_c&pli=1 occurred, and if this is a problem *booting* the CD/DVD, or a problem starting the installation, or a problem that occurs *during* the installation. Furthermore, if this is a problem that occurs when you boot from the CD (rather than something that happens once the installation has already started), then if possible, you should try booting the CD/DVD or USB flash drive on a different machine, see what happens, and include a report of your results in the new question. If it works fine on another machine, that's not necessarily an indication that anything is wrong with the machine you're using, but whether or not there turns out to be something wrong with it, information about what happens when you try to use the same boot medium on another machine will likely still be useful.

Eliah, I continue to be almost teary-eyed grateful and overwhelmed by your assistance and the quality of it. But to be fair, I'm almost teary-eyed of late, non-stop ;) This whole mess is quite literally destroying my will to live, or at least, I just want to throw computers into walls and various other solid objects (both into and at). *deep breaths*

I 100% appreciate your (quite admirably comprehensive) approach to all my ad-hoc and no-doubt poorly explained or inadequately presented questions - and I know you'll understand (as you're the only one who has so far) that, from where I sit, my education will need to be completed post-resolution. I can't afford to try and learn anything else, and that includes posting questions that no doubt have value in being asked and answered - but I just need to get through this or things are going to get ugly (more ugly) too fast for me to cope with. ie. I realise that a corrupted ISO image is a problem, and that perhaps the nature of how and where it got corrupted is the only way to solve it, but if there's a way to just skip all that and install a non-corrupted OS -ANY OS lol - that would be my preference.

I'm having an UNFATHOMABLY hard time trying to employ expert assistance for what simply has to be such simple requirements. And every expert I do hire turns out to be a complete fraud (no doubt I'm looking in the wrong places, and no I haven't tried Canonical just yet because it's not a Linux issue - I'm 99% sure that it's a networking issue now). Is there some way I could employ your brilliance for real-time support from Step 0 to SECURE ? You could literally name your price, I'm so desperate lol, I having trouble keeping it together.

I was checking MD5 hashes but only the downloaded ISOs. My DVD-R's are all brand new, but if I'm burning them using a corrupted ISO burner or USB bootable utility tool...ie. your points are well made, but the information overload is crushing me.

At the moment I'm staring at the gPXE option configuration console after low-level formatting my HDD again (sorry, zero-filled). I've spent 30 min trying to just get some defaults templates to work with, I mean...I don't know if I'm just unlucky or what but omg, this stuff cannot be so time-consuming and so complex at every stage. The variable must be me. I need expert help, and OF COURSE willing to pay, but where and who?

Please say here and you. ;) ?

Hi Eliah, I was hecka relieved to see you were still subscribed. I had hoped to return long before now and in much better circumstances.

Unfortunately, things have gone from terrible to an impossible worse. Pretty bleak stuff happening - the Avahi .local domain was merely a tiny side-effect I think. I got pretty big problems; and I think they are a lot more to do with the Andrew File System I was trying to query because it was on my system and I didn't put it there so I didn't like it. I didn't even know what it was really, but there are Atheros controller drivers being silently installed on brand new systems which have all networking functionality hard / soft turned off. And a lot of other stuff happening which experts would say is impossible.

In response to my submission of evidence, proving they are clueless about what is possible and what is not. https://answers.launchpad.net/ubuntu/+question/159797

I'm still reeling from the discovery today that Linux Ext4 journals hard disks. Journals. They're like, never a good idea if you're incapable of ensuring they remain secure.