MX-14 beta 2

[BitJam]

@golinuxgo, my first thought was not enough memory but james c says his 512 Meg machine worked fine.

I suggest you try launching "qupzilla" from the command line in a terminal window. Perhaps there will be some more useful output when it crashes. If the kernel is having problems then there might be useful information in the output of "dmesg".

It is also possible that you need to do a command-line install on this machine. Unfortunately, this bootloader option is broken on beta-2. You can kill off the GUI with the command (as root):

Code: Select all

/etc/init.d/lightdm stop

You can use <ctrl><alt><Fn> to get to a virtual console where "n" is in 1 -- 6. Once there you can move between virtual consoles with <alt><left-arrow> and <alt><right-arrow>. Use <shift><pgup> and <shift><pgdn> for limited scrolling.

You might want to mount your flash drive in XFCE before you kill it although I'm not certain it will stay mounted.

[Jerry3904]

And, again, just a reminder that MX-14 is not designed for low-end machines--where antiX rules.

This is a "midweight" distro.

[uncle mark]

And, again, just a reminder that MX-14 is not designed for low-end machines--where antiX rules.

This is a "midweight" distro.

While not disagreeing, I will tell you it works well on my 750MHz PIII with 512MB. Surprisingly so. I was quite taken aback at how well, actually.

[golinuxgo]

And, again, just a reminder that MX-14 is not designed for low-end machines--where antiX rules.

This is a "midweight" distro.

I previously had squeeze with gnome2 and xfce desktops installed on this machine so I thought MX-14 might work OK. Unfortunately I don't have free space on my other testing machine to install MX-14 right now.

[Jerry3904]

And, again, just a reminder that MX-14 is not designed for low-end machines--where antiX rules.

This is a "midweight" distro.

While not disagreeing, I will tell you it works well on my 750MHz PIII with 512MB. Surprisingly so. I was quite taken aback at how well, actually.

Good to know. I only keep mentioning this b/c I want to avoid the use of the word "lightweight": everybody uses it, and some (like antiX) actually make it work extremely well. Just from a marketing perspective (--> my job), the "lightweight" field is saturated.

[uncle mark]

And, again, just a reminder that MX-14 is not designed for low-end machines--where antiX rules.

This is a "midweight" distro.

While not disagreeing, I will tell you it works well on my 750MHz PIII with 512MB. Surprisingly so. I was quite taken aback at how well, actually.

Good to know. I only keep mentioning this b/c I want to avoid the use of the word "lightweight": everybody uses it, and some (like antiX) actually make it work extremely well. Just from a marketing perspective (--> my job), the "lightweight" field is saturated.

I gotchya. Me and anti had a brief bit of fun with this earlier. Some people think Linux is supposed to run on a toaster, and if you call something "lightweight", they'll try and install it on one.

[megatotoro]

And, again, just a reminder that MX-14 is not designed for low-end machines--where antiX rules.

This is a "midweight" distro.

While not disagreeing, I will tell you it works well on my 750MHz PIII with 512MB. Surprisingly so. I was quite taken aback at how well, actually.

Good to know. I only keep mentioning this b/c I want to avoid the use of the word "lightweight": everybody uses it, and some (like antiX) actually make it work extremely well. Just from a marketing perspective (--> my job), the "lightweight" field is saturated.

I'd add "ideal for netbooks" to it. My Toshiba NB-100 agrees!

[Jerry3904]

Totally agree! I have two, both running extremely well with MX-14.

[namida12]

@namida12, the hidden .fuse file is a copy of a file you deleted/moved while another process still had it open. This will happen with file systems mounted via fuse (filesystem in userspace), most likely NTFS. I imagine the other process that had the file open was tumbler. For more about this problem with tumber see this thread.

I am trying to move files from sda1 to /media/backup-2013 (a USB 2.0 external drive), and it has continued to lock up/freeze with 400 Gigs free on the external drive.

This symptom would occur if you were mistakenly moving a lot of data to the LiveCD/USB root file system. All changes to that file system are stored in RAM so when you copy too much information into it, you run out of RAM and the system freezes up. When you reboot then all signs of this are gone. I'm not sure that is what happened but it is a simple explanation. This could also happen if you copied a bunch of files to a file system that is mounted as tmpfs (which stores the entire filesystem in RAM).

In the future you can run the following in a terminal window:

Code: Select all

df -h $DIRECTORY

where $DIRECTORY is where you plan to copy files. This will tell you what the underlying file system is for that directory. If it tells you the underlying filesystem is "/live/aufs" then you don't want to fill it with files.

Also, you can monitor how much RAM is being used for the root file system with either one of these commands:

Code: Select all

$ df -h /live/aufs-ram
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           1.2G  1.7M  1.2G   1% /live/aufs-ram

This shows you how much RAM is being used by the file system and how much is theoretically available although you may run out of RAM before that limit is reached.

The other command is simply

Code: Select all

$ free -m
             total       used       free     shared    buffers     cached
Mem:          1516        144       1371          0          0         47
-/+ buffers/cache:         96       1419
Swap:            0          0          0

With the -m flag all sizes are in megabytes. The number you are interested is in the "cached" column. Among other things, this number includes all of the RAM used by the LiveCD/USB root file system and all tmpfs file systems. Most programs that monitor memory usages *ignore* the RAM that is used as cache assuming the system can reclaim that memory when it is needed. On a LiveCD/USB (or any system that stores a significant amount of data on tmpfs) this is a very bad assumption. So if you copy a bunch of files to the root file system of a LiveCD/USB you may end up running out of memory with little warning. The 47 meg in the "free" command output is larger than the 1.7M in the "df" output because the "free" output includes all other forms of cached data.

Quote: "This symptom would occur if you were mistakenly moving a lot of data to the LiveCD/USB root file system."

Code: Select all

df -h $DIRECTORY

Would this be correct?

Code: Select all

df -h $/media/backup-2013

I was trying to copy files from a hard drive 130 gig sda1 formatted as ext3, and only holding data to a 1 Gig external hard drive " /media/backup-2013 formatted as ect4" not to a usb flash drive. Not a NTFS formatted hard drive.

All the problems started when the .fuse file appeared. I could not delete, copy or move the .fuse hidden file, but after renaming the file, I then copied it to the external drive and once there I was able to delete it easily in both drives. But could not shut down the system, I ended up shutting down the computer holding the power button for 5 seconds, walked away for a few minutes with system powered down. Later restarted the live media, and then was able to continue copying the files, to the external hard drive, once the hidden fuse file was deleted on both hard drives.

Maybe this was another instance of the tumber bug. But i do not have a record of what happened, and do not want to try and recreate the problem. The 120 Gig hard drive was recycled using dban to make certain it was not easily read, and that drive is powering another AntiX operating system as a replacement for a malware infected WinXP owner, that has been converted to Linux. She is delighted, and she was playing a Facebook game when i left her on her own.

One machine at a time, as WinXP get closer to its end of life... I was hesitant to use MX-14, and decided on AntiX, but really think MX-14 is going to be a good O/S for winXP users.

JR

[james c]

Another old machine.....MX latest live. 512 mb of ram again w/swap but a much slower P3 compared to the 1.7 Ghz Athlon XP box.

Qupzilla seems ok for basic browsing but sites like Youtube lead to an immediate and sudden crash.Problem didn't seem to appear with the faster cpu.

Code: Select all

-demo@mx1:~
$ inxi -F
System:    Host: mx1 Kernel: 3.12-0.bpo.1-686-pae i686 (32 bit) 
           Desktop: Xfce 4.10.2 Distro: MX-14_13.98_386-xfce beta2 30 January 2014
Machine:   System: Micro-Star product: MS-6215 version: 0000000
           Mobo: Micro-Star model: MS-6351 version: 1.0 Bios: American Megatrends version: 62710 date: 03/30/01
CPU:       Single core Pentium III (Coppermine) (-UP-) cache: 256 KB flags: (pae sse) clocked at 863.754 MHz 
Graphics:  Card: Intel 82815 Graphics Controller (CGC) 
           X.Org: 1.12.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1024x768@85.0hz 
           GLX Renderer: Gallium 0.4 on softpipe GLX Version: 2.1 Mesa 8.0.5
Audio:     Card: Intel 82801BA/BAM AC'97 Audio Controller driver: snd_intel8x0 Sound: ALSA ver: k3.12-0.bpo.1-686-pae
Network:   Card: Intel 82801BA/BAM/CA/CAM Ethernet Controller driver: e100 
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 00:10:dc:a8:50:d9
Drives:    HDD Total Size: 40.0GB (-) 1: id: /dev/sda model: WDC_WD400EB size: 40.0GB 
Partition: ID: / size: 388M used: 13M (4%) fs: rootfs ID: swap-1 size: 1.15GB used: 0.00GB (0%) fs: swap 
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 99 Uptime: 9 min Memory: 179.6/499.5MB Client: Shell (bash) inxi: 1.9.16 
demo@mx1:~

Code: Select all

$ free
             total       used       free     shared    buffers     cached
Mem:        511536     490988      20548          0      96924     211732
-/+ buffers/cache:     182332     329204
Swap:      1126396        240    1126156