MX-14 beta 2

[dolphin_oracle]

there is one advantage to running a 32 bit kernel on a 64bit system, at least if you have more than 4gb of ram and support the PAE .

Debian multi-arch is an evolving beast, and a lot of popular apps (brother printer drivers, netflix-desktop, steam, I'm looking at you) are 32 bit only. You can install them on a 64bit system, but you run into having to have multiple libraries installed. and with MX's extensive use of wheezy-backports, I'm not so sure that a 64 bit system will not have problems, particularly with ia32-libs (a perennial source of pain for me).

[namida12]

Trying beta2 on another system with a Biostar Motherboard :


demo@mx1:~/Desktop
$ 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: Mobo: N/A model: nForce Bios: Phoenix version: 6.00 PG date: 08/26/2005
CPU: Single core AMD Athlon 64 3400+ (-UP-) cache: 512 KB flags: (lm nx pae sse sse2 sse3) clocked at 2411.705 MHz
Graphics: Card: NVIDIA G73 [GeForce 7300 GT]
X.Org: 1.12.4 drivers: nouveau (unloaded: fbdev,vesa) Resolution: 1920x1080@60.0hz
GLX Renderer: Gallium 0.4 on NV4B GLX Version: 2.1 Mesa 8.0.5
Audio: Card: NVIDIA nForce3 250Gb AC'97 Audio Controller driver: snd_intel8x0 Sound: ALSA ver: k3.12-0.bpo.1-686-pae
Network: Card: NVIDIA CK8S Ethernet Controller driver: forcedeth
IF: eth0 state: up speed: 100 Mbps duplex: full mac: 00:16:ec:77:4f:22
Drives: HDD Total Size: 163.9GB (-) 1: id: /dev/sda model: Maxtor_6Y160P0 size: 163.9GB
Partition: ID: / size: 793M used: 4.3M (1%) fs: rootfs
Sensors: System Temperatures: cpu: 40.0C mobo: N/A gpu: 58.0
Fan Speeds (in rpm): cpu: N/A
Info: Processes: 106 Uptime: 4 min Memory: 174.2/1008.2MB Client: Shell (bash) inxi: 1.9.16
demo@mx1:~/Desktop
$

[Silent Observer]

Wow, this looks like it could be a good candidate to replace antiX on my second desktop machine, maybe even in place of MEPIS on my quad-core -- but I have a question: the mention of a PAE kernel seems to imply MX is 32-bit (if 64-bit, it wouldn't need PAE to access large RAM installation). Is there a 64-bit version, or some advantage to running a 32-bit kernel on 64-bit capable systems?

There's a few more computers out there that can use a 32-bit OS. Most of those will run a PAE kernel. (For instance my Atom NetBook is 32-bit only, but will use a PAE kernel.) Super old hardware will need antiX. It's i486 version will run on almost anything. Including the latest and greatest.
If you need 64-bit then Mepis is ready and waiting.

Yep, I've got two machines in the house that can only run 32-bit (both currently on antiX 13.2). I was checking whether MX might replace MEPIS for me (having a more current kernel and other parts might, for instance, allow installing Pepper Flash, which won't go on MEPIS 11).

[kmathern]

Yep, I've got two machines in the house that can only run 32-bit (both currently on antiX 13.2). I was checking whether MX might replace MEPIS for me (having a more current kernel and other parts might, for instance, allow installing Pepper Flash, which won't go on MEPIS 11).

There's a pepperflashplugin-nonfree in wheezy-backports. so yes you'll be able to install it.

The pepperflashplugin has the same sse2 requirement that the other flashplugin has, so you still might not be able to use it with old 32bit machines.

[tascoast]

No problems downloading via the Sourceforge source nor installing under VirtualBox (PAE already checked/anticipated by VB this time around), and I now have both betas running this way with no drama.

I'm going to explore the USB approach next I think and making ISOs after that, two things that perhaps make MX-14 (antiX etc too I think) particularly interesting if I understand the implications ie. a 'portable' OS (within reason, hardware being similar to initial setup) and burning a current MX-14 setup to disc as an ISO for easy reinstall (unlike others, with updates and personal settings, updates and modifications included). These features will make me learn a bit more but seem to fly under the radar as far as beginners go and might deserve a bit of emphasis.

I can't comment on wireless support as such, using VB (it passes to the machine fine as expected), although this would be a nice bit of icing and make me figure out how to go from XP/M 11 dual boot to adding MX-14 as a third boot option, although it is something I'd probably want to set up anyway over time after working of a USB.

kindly
Mick

[BitJam]

I'm going to explore the USB approach next I think and making ISOs after that, two things that perhaps make MX-14 (antiX etc too I think) particularly interesting if I understand the implications ie. a 'portable' OS (within reason, hardware being similar to initial setup) ...

If you develop on a LiveUSB (or a frugal install) then the situation is actually a little better than this because you drop the requirement for similar hardware. The whole Live hardware detection system stays intact. If you have plenty of RAM on your development system then add and remove packages to suit your taste and when you are done (before you reboot) run remaster-live via the RemasterCC (CC= Control Centre). If you want to save system changes across reboots without having to remaster each time then enable root persistence via the same RemasterCC. If you don't have much RAM on your development system then you need to either remaster-live frequently (to move fs changes from RAM to squashfs on disk) or enable Root Persistence and choose Static Root Persistence in the bootloader menu (which always saves fs changes on disk). You are free to switch between Static and Dynamic Persistence (or to go back to no persistence) every time you boot (unless all your file system changes are too big to fit into RAM in which case you can't use Dynamic Persistence).

If you want to create a family of respins and make both 64-bit and 32-bit versions then the build-antiX-iso system might be a better fit. IIRC, it is currently being used to make all six versions of antiX as well as MX and an antiX music respin. Until the final MX-14 gets out the door there might not be a lot of help available to get your started using the system.

NOTE: the one step that is not yet automated in the LiveUSB is the creation of a .iso file from the LiveUSB. It involves just two commands: genisoimage and isohybrid.

[namida12]

Using live Media to run MX-14:

Machine: Mobo: Biostar Motherboard: nForce Bios: Phoenix version: 6.00 PG date: 08/26/2005
CPU: Single core AMD Athlon 64 3400+ (-UP-) cache: 512 KB flags: (lm nx pae sse sse2 sse3) clocked at 2411.705 MHz
Graphics: Card: NVIDIA G73 [GeForce 7300 GT]

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 is the first problem I have had with the live media. Earlier today I moved 50 gigs without any problems occurring. But have tried several times without success to move more files, and just ended up with a (.fuse hidden 000000x00) file that could not be deleted. Confused not understanding this slowdown. I only have about 1 gig more to save to external drive, and then i can format the drive...

Edit: have managed to move the remaining files, and now tumbler is active keeping the volume busy, and it tells me I should not disconnect the drive. This is the bug, that tumbler has? since i am on a demo, believe this should not create a problem, but not certain...

Funny, I recently realized when you drag a file from one drive to another drive it does not give you the choice to "copy" or "move", is there a setting i need to change to have this choice again, seem to remember Mepis 11.9.92 giving me that option.

[BitJam]

@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.

[Silent Observer]

Yep, I've got two machines in the house that can only run 32-bit (both currently on antiX 13.2). I was checking whether MX might replace MEPIS for me (having a more current kernel and other parts might, for instance, allow installing Pepper Flash, which won't go on MEPIS 11).

There's a pepperflashplugin-nonfree in wheezy-backports. so yes you'll be able to install it.

The pepperflashplugin has the same sse2 requirement that the other flashplugin has, so you still might not be able to use it with old 32bit machines.

I've got one system currently running 32-bit MEPIS on which I had to add an antiX install to allow a user to play Flash based games that require a Pepper generation Flash plugin -- converting that system entirely to MX would resolve that (though users would still have to use Chrome/Chromium to have Pepper). The 32-bit CPU systems won't be helped on that front; one is the last processor AMD made that didn't support SSE2, the other is a Pentium II 300 MHz.

[golinuxgo]

I just pulled out an old HP Celeron computer that hadn't been booted in over 500 days. It had an old squeeze install that I was using to play with window managers etc. MX-14 live loaded but there were problems. QupZilla crashed every time it tried to pull up a web page. The page would appear for a few seconds and then . . . poof. Then I thought I would try installing. It failed with this message and I had to push the button:

minstall
Sorry, failed to create a user directory.

In all fairness I was not very focused - cooking and working on another 'puter at the same time. I'll try again later maybe with AntiX. At least I was able to get the system specs onto a flash drive. Maybe you gurus will see something in there that could be a problem:

$ 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: No /sys/class/dmi, using dmidecode: you must be root to run dmidecode

CPU: Single core Celeron (Coppermine) (-UP-) cache: 128 KB flags: (pae sse) clocked at 664.621 MHz

Graphics: Card: Intel 82810 (CGC) Graphics Controller
X.Org: 1.12.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1280x1024@60.0hz
GLX Renderer: Gallium 0.4 on softpipe GLX Version: 2.1 Mesa 8.0.5

Audio: Card: Intel 82801AA AC'97 Audio Controller driver: snd_intel8x0 Sound: ALSA ver: k3.12-0.bpo.1-686-pae

Network: Card: Broadcom NetXtreme BCM5705 Gigabit Ethernet driver: tg3
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 00:10:18:0c:5f:7c

Drives: HDD Total Size: 30.0GB (-) 1: id: /dev/sda model: QUANTUM_FIREBALL size: 30.0GB

Partition: ID: / size: 388M used: 3.8M (1%) fs: rootfs ID: swap-1 size: 1.03GB used: 0.00GB (0%) fs: swap

Sensors: None detected - is lm-sensors installed and configured?

Info: Processes: 100 Uptime: 5 min Memory: 140.0/499.6MB Client: Shell (bash) inxi: 1.9.16