Seams like .net Framework version (until) 4.5 is already installed as listed here.
Also on this page, under the 'Instruction', there is a Note specified which says:
Windows 8 and Windows Server 2012 include the .NET Framework 4.5. Therefore, you don't have to install this software on those oper...
I actually watched him copy the list from the other answer/edit it in letter for letter
Note the typo'd lower case t on one of the .NEts -____-
@Sathya: creating a shortcut to "C:\Program Files\Nightly\firefox.exe" -metrodesktop opens up the metro version of firefox for me... in the normal desktop
Mozilla mentions
Elm is the experimental repository where most of our Metro development work has been happening.
Now, I grabbed the latest nightly from the Elm repo, installed it & then despite starting it from the start screen, I was still provided the desktop version.
Is there a way ...
Question... I am currently running an NFS mounted home filesystem which is reporting 100% full even though a df shows otherwise (~25%). How can one correct this?
@LordStryker What is reporting 100% full? Since NFS is client and server, you're going to have to specify which box you are reading the values from in both cases.
None that I am aware of. Our user directories in /home are nowhere close to the size of the HDD on which our /home directory is mounted (when running du -sh)
This has happened in the past where we had some runaway .nfsXXXXXX files being created and .xsession-errors files filling up but this time around it is no the case
I have not. We have a lot of clients linked in right now at the moment and I was hoping to avoid bringing down nfs
The server has not been restarted in about a year.
okay, so if the server itself is reporting that the reiser partition is 100% full, and that reading has nothing to do with nfs (as df shouldn't, on the server, at least), then at least we know that the fact that it's NFS isn't responsible for the problem
the question should be rather, why is NFS only reporting that it's 25% full to the clients :P
since you said it is only 25% full, I'm assuming you're getting that reading from a client
I'd trust df on the server (which comes directly from the filesystem on the HDD, which is what you care about) over anything NFS says
the sum of du doesn't necessarily equal df... there are things like filesystem metadata, which consume disk blocks, but are not accounted for as actual files
is the NFS mounted /home directory the only thing on the partition, or are there other things (system files, etc) on the same partition? (note: partition, not disk. don't care about the rest of the disk, really)
reiserfsck --check <partition device node> -- but before you do it, run reiserfsck --help and get a feel for the command line options
i.e. don't take my word for it; read the manpage and/or --help entries
also the functionality might depend on the version of reiserfsprogs that is installed
judging from the fact it's a production box that's been up for over a year, it's probably quite old, but i don't know when the --check option was introduced or when it gained online support
I believe the problem is stemming from two of our clients who probably clock in the most usage/time on their machines relative to everyone else. I told them a periodic logging out could help stem this problem but I'm unsure if that is the case.
A peer of mine believes that disk usage is 100% due to memory being reserved for open processes and it never gets released.
To be honest I don't know enough about unix to even know/guess as to what is really happening.
I ran resiserfsck --check on a local partition just to test it and it cannot read the superblock
@LordStryker disk usage wouldn't be related to memory; furthermore, I can't think of any release of Linux in the past 5-6 years that has had issues with not releasing userspace resources after a process exits
even if a process was taking up its full allocation of file descriptors, that still couldn't impact system-wide
@LordStryker ah, it probably only works on partitions that aren't mounted
it'd be nice to know a bit more about what we're working with as far as versions of packages (yes, it matters a whole lot to those of us with experience) -- Linux kernel version, distro version, list of any packages that have been compiled from source to a different version than the distro, etc.
also the hardware -- is it RAID? hardware RAID? software?
were this not a production box, my first kneejerk reaction would be to apply any distro updates to the system and reboot it... it's a fairly interesting problem space to try and fix an issue like this without bringing the service down (in your case NFS), but depending on the amount of money projected to be lost due to downtime, you could just wait until after hours, low activity period, etc and try it
also... I really can't bring myself to being comfortable with reiserfs as a production FS, particularly when you throw NFS into the mix and the lack of RAID
@JourneymanGeek the thing is, there's time pressure... so while it might be an interesting question for education purposes, such as "what can be done to attempt to troubleshoot an online reiserfs volume?" it's unlikely to help him now
I like more dynamic filesystems like btrfs... that thing... is so amazingly flexible... I wouldn't be surprised if it can shrink itself, online, simultaneously with checking and repairing the inode table, while changing the compression type on files from lzo to lzma, while defragging :D
@LordStryker filesystem wars is something better left for SF, but I can say that the consensus seems to be somewhere between ZFS (for crazies and Sunnites/Oraclites); ext4 (for Ted T'so fans); XFS (for SGI/RedHat fans or people who are sold by the "big and lots" mantra); or btrfs (for people who like experimental, dynamic stuff that's going to be awesome Real Soon Now (tm))
basically, anything but reiserfs or jfs
also depends on volume size, number of files vs. size of files, etc
for absolutely enormous, eye-popping sizes of volumes and/or the files themselves, xfs pretty much wins; even the crazies agree on that
btrfs has good data integrity and almost anything you want to do with it can be done "online" (without unmounting)
ext4 has great performance and good scalability but is somewhat lacking on online features compared to btrfs, as well as data integrity
ZFS supports software RAID5 better than any other filesystem but it's not running at full steam / feature support on Linux quite yet; its home domain is Solaris or BSD
The thing I'm worried about is this will just happen again in a few weeks time...
This really is the 3rd time its happened (usually over the course of a couple days usage rises up to 100%...) but this time around .nfsXXXX files and the .xsession-errors files are not the culprits
du won't be able to report size for anything that it doesn't have execute permission on, although as root, all discretionary access controls are ignored
so unless you have mandatory access control and somehow lock out root with an integrity level or something
oh, another possibility
you could have a situation where a directory branch is removed from the dirent table but it still contains inodes within it that occupy space
think like a tree's branch breaking off... the filesystem still knows about the "leaves" on the tree but it can't list them because it's not connected to the tree trunk, it's on the floor
you might want to be carefully diplomatic when broaching the topic, but since this sounds like a production system, I probably wouldn't go with a limited support release like OpenSUSE 11.3, and I probably wouldn't go with a filesystem without online repair and CRC verification support.
if it were me and I could start over, I'd put RHEL6 on it (or one of its free-as-in-beer binary rebuilds, e.g. CentOS or Scientific), or an officially long term supported build of SUSE (note, not OpenSUSE), or Ubuntu 12.04 LTS. Then I'd put xfs or btrfs on it.
@TomWijsman I think there's a certain element of tacticalness. I am intentionally trying to answer or ask just enough questions to fill the bottom level of things (that is to say, those 3 rep ones)
@LordStryker I would consider btrfs to be fairly stable on enterprise distros. on vanilla upstream kernels or Fedora or something it's not that stable because of all the flux
but OpenSuse, RHEL and Ubuntu LTS try to close off the bugs and corner cases to make a good build of it
almost anything that makes it into RHEL is going to be rock solid
it "has" it, but it's called "not a production filesystem"
thing is, the only FS I'm aware of that does online check/repair is btrfs... and there does not exist a filesystem that will never encounter FS corruption during runtime, it's just not possible, especially in the face of bad sectors, etc
XFS does not do online check/repair; they say that their check tool (which is read only) reports "spurious errors" (incorrect information, essentially) unless the FS is unmounted or marked read only during the check
ext4 is no better
I think with RHEL 7 (whenever that comes) btrfs will be the no-brainer solution, as it should be production quality by then
OH!
I found an enterprise Linux vendor that's willing to support btrfs in true production configurations
SUSE also. so if you are an enterprise running a server and you want a production quality FS that your vendor will stand behind (including for support calls, etc), you can use SUSE (not OpenSUSE) or Oracle Linux
I imagine it's production quality in Oracle but not in RHEL because Oracle ships a newer kernel and they also house the upstream maintainers for btrfs, so they probably are better at testing it and integrating the latest code without breaking it
@LordStryker also if you don't know about ksplice, you and your boss need to be tarred, feathered and used as an organic fuel source in an exothermic chemical reaction with oxygen
ksplice + btrfs + oracle UEK2 = win
don't be afraid to pay a little... that way, if it DOES break, you call up Oracle on the phone instead of talking to lowlifes like me and say "HEY ORACLE, YOUR BTRFS BROKE MY SERVER!!!" and they'll give you instructions to fix it :p
I think I'm in a wrong place. Thanks for the barrage of -ve votes. I quit this place because something is wrong here. I'm blacklisting this site in my company, and I won't encourage my employees to use it. Thanks again — akula5 mins ago
ksplice isn't expensive but i'd consider it high priority if you're going to do a rebuild / re-image
with the existing opensuse 11.3 / reiser thing i don't think it's important at all because your FS and OS version are already pretty silly for a production box
anyway I have a server that's been running a ksplice-patched kernel and it has several public IPv4 and IPv6 addresses and minimal firewalling, and it's never been hacked
@LordStryker short term fix: (1) reboot box into single user mode; (2) make sure home directory is not mounted; (3) reiserfsck --check /dev/whatever; (4) init 3 (or reboot if you're paranoid)
I think I'm in a wrong place. Thanks for the barrage of -ve votes. I quit this place because something is wrong here. I'm blacklisting this site in my company, and I won't encourage my employees to use it. Thanks again — akula13 mins ago
long-term fix: backup the /home directory, wipe the system, buy a hardware RAID controller, install RAID10 disk array, put Oracle Linux on it with UEK2 and Ksplice and btrfs, and forget it exists until dust clogs up the CPU fan and overheats the box (this event will happen before the system goes down to due FS issues)
@allquixotic: The only problem I would see with this kind of technique is that some former bug can introduce something different in memory (the data part, not the code part) which will propagate itself. But the chance is small, and requires like a time span of some years.
Well, someone needs to write something like this in an open-source way; that will yield some more defensive programming as they know it can be used more mainstream.
also, kernel warnings and bugs really suck in production systems, but they do happen
sometimes if they're severe enough they can cause a character device or block device to become unresponsive if the kernel freezes or kills the kernel task that bugged
@allquixotic Yeah, but to be clear, but was talking about something "introduced" by a former kernel version that bugs something in a later kernel version. So ECC won't help here...
Anyhow, I'd suppose the patch would be widely tested on similar ksplice systems so it might not make it onto your production system if such bug would happen.
a reminder for all you non-mods: there's a lot of... sub-par content coming in with the contest. so it goes. please make good use of the review queue, and your votes! we'll be staying on top of the flags and close queues as well as we can, but we need some help with all the extra attention we're getting