Search Results for 'boot from iso'

Snapshots made with ‘iso-snapshot-antix_0.2.15_amd64’ do not boot, neither from USB-stick nor as iso in VirtualBox.
Versions 0.2.14 and 0.2.12 do not work either. The bug happens in sid and in Stretch as well.

Downgrade to ‘iso-snapshot-antix_0.2.10_amd64’ solves the problem.

• This topic was modified 4 years, 2 months ago by Xaver.

[Moderator BobC]

I got it onto a 3rd machine, completely different than the other two, this one an Alienware fast I7 laptop which I boosted with a very fast 250 gb Samsung EVO 850 SSD to make it really, really screaming fast.

So my method of saving and deploying did work, and I installed frugal_all to a 2nd partition, and added the grub.entry to my 40_custom on the main partition, as well as a live ISO loopback with persist_all also, and now have grub able to boot any of the three…

Thanks for everyone’s help 🙂 All is well!

40_custom

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "antiX 17.3.1 (Helen Keller) Frugal Install with persist_all" {
    search --no-floppy --set=root --fs-uuid 3c26982a-b823-44c1-8c02-3df3dd1fa51f
    linux /antiX-Frugal-4.9.146-antix.1-amd64-smp/vmlinuz bdir=antiX-Frugal-4.9.146-antix.1-amd64-smp hostname=alien buuid=3c26982a-b823-44c1-8c02-3df3dd1fa51f nowicd vga=791 persist_all tz=America/Chicago quiet splash=v disable=lx
    initrd /antiX-Frugal-4.9.146-antix.1-amd64-smp/initrd.gz
}

menuentry "antiX 17.3.1 ISO Loopback with persist_all" {
    set isofile='/antiX-17.3.1_x64-full/antiX-17.3.1_x64-full.iso'
    loopback loop (hd0,3)$isofile
    linux (loop)/antiX/vmlinuz hostname=alien fromiso=$isofile bootdev=/dev/sda3 persist_all pdev=/dev/sda3 tz=America/Chicago nowicd vga=791
    initrd (loop)/antiX/initrd.gz
}

[Moderator BobC]

I erased the HD on the old Dell D620 and started fresh with a 9 gb antiX boot, 4 gb swap, 30 gb for isofiles, and 100 gb for persistence.
I loaded and installed antiX-17.3.1_x64-full, then used my packagecomp and added all my packages, and installed aptik and aptik-gtk.

Note that I didn’t restore my home stuff or my changes yet, so the system is pretty clean at this point.

Next I will restore my /home and then make another snapshot, and then create a live USB of it, do a frugal install of it with persist_all, and then I will try to overlay my changes…

[Moderator BobC]

AMAZING!!!

It all worked on pretty much the first try.

I used my pkgcomp scripts on the old HP DV9917 system and new Dell M2400. Ran aptik-gtk backup for users, groups, and home, put all that into the live-usb/home/demo folder on the flashdrive. Installed on the new pc, ran apt-get update, ran the 2nd half of the pkgcomp, edited the list for what i wanted of the missing ones, installed that with apt-get install line generated, installled aptik and aptik-gtk with apt, ran aptik-gtk as root, did the restore of the same things, did a reboot from terminal, and all is well. just need to reimplement the few program and config changes outside of /home, and i’ll be done.

That was much, much better than last time.

I even got s2both working for hybrid suspend and hibernate.

I got all the program changes an such migrated. I think the key is to change as little as possible outside of /home, and not to install anything outside the normal packages from that repo unless its really worth the ongoing effort. I removed about half of my changes as a result, and hopefully that will make the process easier in future. I really liked the Tilde command line editor, but the effort to tweak and install it was just too much.

PS: I went back to LXTerminal as my default terminal, and now have Midnight Commander working with Geany as its external editor, and have it making automatic backup copies of everything I edit. I don’t think I could ask for a better setup than that, and that cut my number of modifications to the default system dramatically.

My next task is to reverse the process, and reload the other 1/2 of the HP Laptop’s SSD the same way from the new machine and see if it isn’t both reliable and easy by comparison, and once I’m happy with the way it runs, I’ll clear the original side of the SSD to load Buster onto.

• This reply was modified 4 years, 3 months ago by BobC.
• This reply was modified 4 years, 3 months ago by BobC.

[Member tradonal]

filochard wrote:

Bonjour,
Pouvez vous corriger mon fichier grub.cfg pour lancer l’iso antix depuis mon disque dur avec grub2 ?
==============================================================================
menuentry ‘antiXLoopback_antiX-17.2_386-full.iso’ {
set root=(hd0,msdos7)
set iso=antiX-17.2_386-full.iso
loopback loop /$iso
linux (loop)/antiX/vmlinuz quiet splash=v disable=lx
initrd (loop)/antiX/initrd.gz
}
====================================================================================
Mon pc pentium 2 512Mo et carte graphique agp.
Merci.

Hello,
Pour le fichier /boot/grub/grub.cfg normalement on ne le modifie pas…..
http://www.linuxpedia.fr/doku.php/expert/grub2
Sans avoir plus de renseignements sur votre configuration….
Je dirais juste ceci:
Sans entrer dans le détail, je pense que comme ceci https://forum.mxlinux.org/viewtopic.php?p=476981#p476981 vous devriez y arriver….

[Forum Admin anticapitalista]

This is what I use, though it may be overly complicated. My iso is on /

menuentry "antiX-18 ISO boot" {
     echo Boot disk address is: $root

     set iso='/antiX-18.a1_x64-full.iso'
     set bootparms='from=all quiet persist nocheckfs'

     search -f $iso --set=root

     echo ISO root is:          $root
     echo ISO is:               $iso
     echo Boot parms are:       $bootparms
     echo
     loopback loop $iso
     linux (loop)/antiX/vmlinuz fromiso=$iso $bootparms
     initrd (loop)/antiX/initrd.gz
     echo Booting $iso} 

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Forum Admin anticapitalista]

I’m not seeing this at all.

I booted latest 17.3.1 (live usb) and can see my installed antiX in rox-filer and spacefm under /media.
Same with running same iso live in virtualbox; it sees my antiX-17.3 vbox install in both rox and spacefm.

O/P cannot see his/her Lubuntu partition, caprea are you saying running antiX live cannot see your installed antiX?

Added: OK, caprea beat me to the post 🙂

Added2: Zee, are you running antiX live off the usb device or installed? If the latter, then I suggest you run it live for your purposes.

• This reply was modified 4 years, 3 months ago by anticapitalista.
• This reply was modified 4 years, 3 months ago by anticapitalista.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member calinb]

I did a couple of unnecessary things in the above so I decided to try again without any redundant steps.

Last time, I rebooted after installing the RT kernel package with Synaptic and then again after remastering (and before running live-kernel-updater). At least that’s what I remember doing. I had also run the initrd installer redundantly (not realizing it had already been done).

Thus, I decided to try again with a different approach.

I used a pre-RT kernel Synaptic installation snapshot .iso to make a new bootable USB (so I wouldn’t need to configure my desktop and network with my preferences again).

I booted without persistence and then did the following:

1. apt-get update and dist-upgrade.
2. Synaptic installation of the new RT kernel.
3. remastered
4. ran live-kernel-updater
5. rebooted

I obtained the screen in the attached file. 🙁 / 🙂 (at least the new kernel is installed).

LinuxCNC forum members often have trouble getting the RT kernel to boot. Can this be fixed with some boot options?

I might need to build an RT kernel from source using “make oldconfig” from antiX kernel source. I haven’t done that in many years (back in my Gentoo days). Arrghh!

Thanks for any advice, as always.

-Cal

• This reply was modified 4 years, 3 months ago by calinb.
• This reply was modified 4 years, 3 months ago by calinb.
• This reply was modified 4 years, 3 months ago by calinb.

Attachments:

1. 

   antiX_live_RT_kernel_update.jpg
   

I think I might need BitJam’s help again. I’m doing some investigative groundwork to build a CNC system using LinuxCNC. I’ll need a preempt-RT kernel for my CNC hardware. Over at LinuxCNC, the devs are working on a Debian Stretch live boot .iso with an RT kernel and it might even be getting close to release, but the stable release is still on Wheezy. I’m not expecting much in the way of persistence features from the live LinuxCNC .iso so why not try antiX?

I’m running antiX 17.3.1 frugal persist on my old Samsung Netbook (Atom) that still runs MX-16 from its hard disk. I found “Linux for modern PCs (meta-package), PREEMPT_RT” using Synaptic and it installed linux-image-4.9.0-8-rt-686-pae with the RT patch set. Next I downloaded BitJam’s cli tools and live-kernel-updater zip archives from GitHub (“sudo apt-get install” git didn’t work for git and I don’t know where to find it).

Sadly, uname -r reveals that the new RT kernel is not running, even though live-kernel-updater reports that the RT kernel is the default. Here’s what I get from live-kernel-updater:

Starting live-kernel-updater
===============================================================================
Current running kernel is 4.9.146-antix.1-486-smp
                                                                                        
Please select the system to update                                                      
= The current Live System on sda1                                                       
> sdb   59.5G Mass Storage Device                                                       
Press <Enter> to select the highlighted entry                                           
Use 'h' for help, 'r' to redraw, 'q' to quit                                            
Will use running live system                                                            
Found linuxfs file linuxfs in directory /antiX-Frugal-4.9.146-antix.1-486-smp
Found:
  2 total live kernels 
  1 default live kernel      (4.9.0-8-rt-686-pae)
  1 old live kernel          (4.9.146-antix.1-486-smp)

  2 total installed kernels 
  0 new installed kernels 
                                                                                        
Please select an action to perform                                                      
> Rollback vmlinuz to 4.9.146-antix.1-486-smp (2019-01-29)                              
> Update initrd using file /usr/lib/iso-template/initrd.gz                              
> Quit                                                                                  
Press <Enter> to select the highlighted entry                                           
Use 'h' for help, 'r' to redraw, 'q' to quit                                            
Press 'q' again to quit  

=====================================================================
/usr/local/bin/live-kernel-updater
        program: live-kernel-updater
        started: Wed Jan 30 01:34:28 EST 2019
        version: 2.00.11 (Mon Jan 15 08:26:50 MST 2018)
         kernel: 4.9.146-antix.1-486-smp
             OS: antiX 17.3.1 (Helen Keller)
      found lib: /usr/local/lib/cli-shell-utils/cli-shell-utils.bash
    lib version: 2.20.01 (Mon Jan  7 20:46:14 MST 2019)
---------------------------------------------------------------------

Found man page: live-kernel-updater.1
Current running kernel is 4.9.146-antix.1-486-smp
Will use running live system
Found linuxfs file linuxfs in directory /antiX-Frugal-4.9.146-antix.1-486-smp
 > wait_for_file /live/boot-dev/antiX-Frugal-4.9.146-antix.1-486-smp/linuxfs
 > mkdir -p /run/live-kernel-updater/linux
 > mount -t squashfs -o loop,ro /live/boot-dev/antiX-Frugal-4.9.146-antix.1-486-smp/linuxfs /run/live-kernel-updater/linux
Found:
  2 total live kernels
  1 default live kernel      (4.9.0-8-rt-686-pae)
  1 old live kernel          (4.9.146-antix.1-486-smp)

  2 total installed kernels
  0 new installed kernels

"/var/log/live-kernel-updater.log" [readonly] 182 lines, 7616 characters

Thanks much!
-Cal

[Forum Admin BitJam]

@geo3geo, fehlix thinks he has a solution in the works. Unfortunately, you will need to download a new iso. We could also provide an xdelta3 patch. Xdelta3 does work on Windows.

What is the name of the iso file you are using? We can try to get that one updated first.

The problem seems to be that some newer systems refuse to boot with the version of Grub we are using. This might be related to secure boot but turning off secure boot does not fix it.

Context is worth 80 IQ points -- Alan Kay

[Anonymous]

Although the OP may have encountered an edge case, we’ve seen multiple reports of “Rufus successfully created MX18 liveUSB”, right?
.

what_do_bootable_usb_makers_like_rufus_actually_do
a Jan 2019 reply posted reddit by the author of Rufus

Rufus developer here. Glad you asked, because a lot of people seem to think an utility like Rufus doesn’t do much (“Why use Rufus when you can just use diskpart?”), and fail to realize that there is usually a lot more happening behind the scenes because of all the many quirks that are inherent to what can mostly be described as trying to fit a round peg (an ISO image) into a smaller square hole (a USB drive).

So, what does Rufus do. Well, that varies a lot depending on the type of source image you have and type of computer you are trying to boot.

If the source is a DD (pure disk image) or ISOHybrid image (mixed ISO and disk image), then this is the simplest case: Rufus does write it, bit for bit, without any conversion, onto the USB drive… except (quirk #1) it also first needs makes sure that there doesn’t exist another process that is currently trying to access the drive in write mode, since, to reliably write to the drive, you really don’t want to leave the door open for something else to also have kept some write access opened, as there is no telling how they might arbitrarily change the data you just wrote behind your back, and screw up the boot. Also, you may have to work around some Windows own quirks (quirk #2, mostly seen with Windows 10), where Windows will prevent you to write whatever you want unless you first cleared the drive properly (and by properly, Microsoft means using one of the 3 methods that are supposed to clear the partition tables and whatnot, but that are temperamental enough so that only one tends to work as expected). Now, once you managed to clear the drive, write the data, and made sure that nothing should have been able to modify it behind your back, then you “should” be able to rely on the makers of the image to have sorted the USB boot, so your job is done (or at least, if it doesn’t work, it’s not your issue).

However, not all ISOs are ISOHybrids. Especially the Windows ISOs aren’t, so the method above, which we call “DD Mode”, cannot be applied all the time. Besides, DD writing presents major drawbacks for Windows users in that the image may be written using a file system that Windows does not support, in which case many people are going to be confused as to why they are no longer able to see or access the content of their USB in File Explorer, or, in case the image contains an EFI System Partition, why they suddenly only see a super small FAT32 partition with next to no content, from what used to be a large USB… And even if the image does use a file system / partition mapping (remember, Windows version prior to Win10 1703 could not mount more than one partition from a drive with the “removable” attribute, which most USB Flash Drives will have) that lets users access the data from Windows, by writing in DD Mode, you are only ever going to be able to use your drive up to the maximum size of the original image. In other words, this means that if the people who created a DD/ISOHybrid image used a 4GB image, then, if it gets copied on a 32GB drive, there’s going to be 28GB of data that you can’t use at all, until you repartition and reformat your drive, which of course isn’t ideal… And I’m not even going to comment on how ISOHybrid is a major hack in the first place, by trying to combine two completely different file systems do stuff they were never designed to do, with all the problems that can ensue (which is why it’s very unlikely you’re ever going to see ISOHybrid versions of Windows ISOs. But then again, who knows…). For the record, this is the reason you can’t use Etcher to write a Windows ISO to an USB drive because Etcher can only cope with DD or ISOHybrid images. Despite what many people seem to believe, because it has become the norm to use it on recent popular Linux distros, ISOHybrid is the exception rather than the norm, so if you only support “DD Mode”, you’re going to be stuck at some stage…

So, what do you do when you don’t have a DD or ISOHybrid image. Well, that is where things start to get a lot more “interesting”.

A lot of people seem to think that, if that ISO is UEFI compatible, then it’s about as easy as writing a DD image, in that you simply need to copy the content of the ISO onto a FAT32 formatted partition, and you’re good to go… Except you may have a file on that ISO that is larger than 4 GB (For instance ALL of the recent retail versions of the Windows 10 1809 are like that), in which case you can’t use FAT32 (file system design limits the maximum size of a single file to 4GB or less), and you need to apply some workaround to boot from NTFS. So Rufus does detect that and applies the relevant quirk appropriately (quirk #3). Also, and it turns out that some Linux distros, such as Mandriva (which I’m calling out, because I have opened a bug with them on this for more than 6 months now, and despite repeated requests for updates, they have yet to acknowledge it), have drunk a bit too much of the ISOHybrid Kool-aid, and decided to remove the FAT32 file system driver from their custom GRUB bootloader, which of course wrecks havoc for the boot process of unsuspecting users… And that’s not even mentioning some of the Debian derivatives’ ISOHybrids that don’t bother having the UEFI bootloaders present on the ISO file system, so that they will get copied automatically if you duplicate the ISO content, but instead cram them into a virtual efi.img FAT image. So (quirk #4), Rufus must also extract the efi.img content so that, if you use ISO Mode and not DD Mode, the resulting drive should still boot. Oh, and then there’s Windows 7, which is UEFI compatible (at least for the x64 version), but only after you rename/copy the relevant EFI loader in the right place (quirk #5). Still, converting an UEFI bootable ISO to UEFI bootable USB is actually pretty straight forward (provided the people who created the ISO made sure their content could be booted in Hard Disk mode from a FAT32 or NTFS file system)…

Things however get A LOT more complicated when you need to convert your ISO not for UEFI USB boot, but for BIOS USB boot, because that’s where you get submerged by the quirks. And there are still a lot of BIOS based machines out there. Your first problem being that, when you boot an ISO on a BIOS computer, you will be using a completely different method than when you boot an USB Flash Drive. In the first case, you don’t need to care about bootable attributes, partitions, boot records (such as the Master Boot Record, or “MBR” which you might have heard of) and whatnot. In the second, you very much do. So, when you are converting a BIOS bootable ISO image to a BIOS bootable USB image, there’s A LOT that needs to happen behind the scenes. First of all, because everybody can create their own custom way of booting an ISO from a CD/DVD drive, an application like Rufus must be able to provide the USB/HDD equivalent of whatever binary was used by the ISO. Thankfully, in the case of Linux distros, there only seems to exist 2 types of BIOS bootloaders being used: Syslinux or GRUB. So, what Rufus does is, detect whether the ISO version of GRUB or Syslinux is being used by the image and then write a HDD version of the same bootloader (because, once again, the ISO version of GRUB of Syslinux is absolutely hopeless at booting a USB or HDD, so you can’t even patch the existing binary to do so). So that’s why you may have to download some files from a remote server during the conversion process. And it gets even more “interesting” because (quirk #6) the Syslinux people have somehow managed to make their versions of Syslinux incompatible with one another, especially when it comes to modules (which thankfully, though not always — but this is a quirk that I’m not going to count, you can reuse from ISO to USB/HDD). For instance, you can’t use modules built for Syslinux 5.01 with Syslinux 5.02… or even between some pre-releases of the same version!), so you need to detect and handle that, rather than blindly copy whatever Syslinux binary you may have tried to include in Rufus. Oh, and some distros (Manjaro… why is it always them?) may decide to use custom build options for GRUB so (quirk #7) you need to sort that out as well. Oh and then there’s the whole issue of GRUB or Syslinux config files that may be looking for a media installation partition with a specific label… that can’t be converted to a FAT32 one, because FAT32 volumes are limited to 11 uppercase characters, so (quirk #8) you may want to fix that as well. Should I mention that that last quirk also applies to UEFI? But that’s still just for GRUB or Syslinux and as I said, everybody can write their custom ISO bootloader, for which Rufus will need to provide a USB equivalent, so having a conversion process for GRUB or Syslinux will only get you so far. And that is why we also have bootloaders for ReactOS or KolibriOS. Apart from that, we also had to write out own MBR (quirk #9), to emulate the Windows BIOS ISO bootloader, that asks the user to press for a key, so that the multi-reboot process of Windows installation in BIOS mode could be conducted unattended, as it can be from optical drive.

[..]

So, to answer your question, what Rufus is actually doing is a very straightforward bootable ISO → bootable USB conversion… while also trying not to bring too much attention to all the corner cases that need to be accounted for and that require extensive quirks to be applied, in order to make people wonder if there’s really that much happening behind the scenes…

[Forum Admin BitJam]

geo3geo wrote:

Under Win10 I burned the latest Iso to a USB memory using Rufus and I can boot off the USB no problem. This has an Aptio 2008 bios. When I try it on another laptop (the one I want it to run on of course) it freezes with a message
Could not open “\EFI\BOOT\fallback.efi”
This second machine has an Aptio 2018 BIOS and is a GeoBook.

Any pointers?

Do you have a 2nd usb stick you can use? If so, I suggest that you boot the existing usb stick on the computer where it works and then plug in the 2nd stick and run “sudo live-usb-maker”. This will offer to clone your system to the new stick. The new stick might work better on the UEFI computer.

Too many notes
I imagine Rufus makes what is called a dd live-usb (or what I would call a dd-live-iso because the stick has the read-only iso filesystem copied to it) and some tricks are played (using hybridiso) to add a fat-32 file system so UEFI can read it and boot from it. But UEFI is generally pretty buggy and does strange things. If it boots Windows then it is assumed to be problem free. The cloned live-usb will be a “real” live-usb with read-write file system which might work better.

That error message shows up when you boot our dd-live-iso with UEFI. Normally the system will continue to boot and after that message flashes by you will get to the Grub menu. Our “real” live-usb boots slightly differently so maybe the problem that you had with the dd-live-iso will not occur with the real live-usb you cloned.

If you tell me the iso file you used, I will test here to make sure a dd-live-usb made from it boots via UEFI. Edit: The exact make and model of the computer that is not booting might help us see if other people are reporting similar problems on it.

The live-usb-maker clone mode is part of our strategy to get people to use live-usbs made with our software. We believe this is the best live-usb you can get. The Most Extensive Live-usb on the Planet! We have no control over other software that makes live-usbs and the whole “hybridiso” plus “dd” thing is a kludge. UEFI is a messy, buggy kludge as well with lots of system specific crazy bugs. If UEFI is not working right, you always want to test it on another, different machine. I’ve got 4 machines here I test on. The most expensive one has the wackiest UEFI bugs.

I also suggest that when you boot your existing live-usb you select the “checkmd5” option. This will verify that most of the bits written were written correctly. If an error is detected then it is possible there was also an error in the “dd” UEFI bootloader. You can do the same check on the cloned live-usb.

PS: our live-usb works with secure boot even though our installed systems do not (yet). You could try disabling secure boot anyway and see if that helps.

PS-2: Ninja’ed by christophe! Sorry christophe, I should have read your post more carefully before chiming in.

• This reply was modified 4 years, 3 months ago by BitJam.
• This reply was modified 4 years, 3 months ago by BitJam.

Context is worth 80 IQ points -- Alan Kay

Under Win10 I burned the latest Iso to a USB memory using Rufus and I can boot off the USB no problem. This has an Aptio 2008 bios. When I try it on another laptop (the one I want it to run on of course) it freezes with a message
Could not open “\EFI\BOOT\fallback.efi”
This second machine has an Aptio 2018 BIOS and is a GeoBook.

Any pointers?

• This topic was modified 4 years, 3 months ago by geo3geo.

[Anonymous]

it thinks I manually installed all these

“manually (explicitly) installed”

When you (or your scripted operation) perform an apt-get install _____ packagename operation, explicitly naming a given package, its status will be marked “manually installed”. Similarly, on Day1 when booting the stock distribution, most of the pre-installed packages bear that same status (manually installed) b/c they were explicitly listed during the scripted build-iso operation.

I have an Antix 16 server, that runs Cups, Samba, MySQL and Bacula. I want to upgrade this to Antix 17, but the server is too critical to simply install the new version, so I thouight I would take a snapshot, install the snapshot on a Qemu/KVM vm and could test the upgrade process, update the repos and dist-upgrade. I upgraded my laptop from 16 to 17 using this method, so it seems succesfull. My first attempt with antixsnapshot failed, when booting the iso, it couldn’t locate linuxfs. The only change I had made to antixsnapshot.conf was to change the file locations from the default. I discovered I had not update the “exclude” correctly and had failed to include a 900G filesystem, not sure why that made a difference but it seemed to. My second attempt with antixsnapshot generated a snapshot with linuxfs, but now I get a message about missing /live/aufs. isosnapshot is not an option, there is no X on the server. Any ideas?

david235

inxi for the system.
System: Host: server-1 Kernel: 4.10.1-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc v: 4.9.2 Console: N/A
dm: N/A Distro: antiX-15-V_x64-core-libre Killah P 30 June 2015
Machine: Type: Desktop System: HP product: ProLiant ML110 G6 v: N/A serial: MX202901BL Chassis: type: 7
serial: MX202901BL
Mobo: Wistron model: ProLiant ML110 G6 serial: 0123456789 BIOS: HP v: O27 date: 01/26/2010
Memory: Array-1: capacity: 16 GiB slots: 4 EC: Multi-bit ECC max module size: 4 GiB note: est.
Device-1: DIMM 2 size: 4 GiB speed: 1332 MHz type: DDR3 manufacturer: N/A part-no: Not Specified
Device-2: DIMM 1 size: 4 GiB speed: 1332 MHz type: DDR3 manufacturer: N/A part-no: Not Specified
Device-3: DIMM 4 size: 4 GiB speed: 1332 MHz type: DDR3 manufacturer: N/A part-no: Not Specified
Device-4: DIMM 3 size: 4 GiB speed: 1332 MHz type: DDR3 manufacturer: N/A part-no: Not Specified
CPU: Topology: Dual Core model: Intel Core i3 530 bits: 64 type: MT MCP arch: Nehalem rev: 2
L2 cache: 4096 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 23419
Speed: 2926 MHz min/max: 1197/2926 MHz Core speeds (MHz): 1: 2926 2: 2926 3: 2926 4: 2926
Graphics: Card-1: Matrox Systems MGA G200e [Pilot] ServerEngines driver: mgag200 v: kernel bus ID: 1c:00.0
chip ID: 102b:0522
Display: server: No display server data found. Headless server? tty: 160×49
Message: Advanced graphics data unavailable in console. Try -G –display
Audio: Message: No PCI card data found.
Network: Card-1: Broadcom NetXtreme BCM5723 Gigabit Ethernet PCIe driver: tg3 v: 3.137 port: N/A
bus ID: 1e:00.0 chip ID: 14e4:165b
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: f4:ce:46:0f:f5:6a
IF-ID-1: virbr0 state: down mac: 8a:38:17:87:95:d7
Drives: HDD Total Size: 2.87 TiB used: 1.31 TiB (45.6%)
ID-1: /dev/sda model: VB0160EAVEQ size: 149.05 GiB speed: 3.0 Gb/s serial: 9VY8CDBN temp: 27 C
ID-2: /dev/sdb vendor: Western Digital model: WD10EALS-00Z8A0 size: 931.51 GiB speed: 3.0 Gb/s
serial: WD-WCATR5084841 temp: 30 C
ID-3: /dev/sdc type: USB vendor: Seagate model: ST1000LM035-1RK172 size: 931.51 GiB serial: W932HE1G
ID-4: /dev/sde type: USB vendor: Seagate model: ST1000LM035-1RK172 size: 931.51 GiB serial: WL14VVXL
Partition: ID-1: / size: 144.59 GiB used: 102.95 GiB (71.2%) fs: ext4 dev: /dev/sda1
ID-2: swap-1 size: 2.02 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda2
Sensors: System Temperatures: cpu: 49.0 C mobo: N/A
Fan Speeds (RPM): N/A
Repos: Active apt repos in: /etc/apt/sources.list.d/antix.list
1: deb http://repo.antixlinux.com/jessie jessie main nosystemd
Active apt repos in: /etc/apt/sources.list.d/debian.list
1: deb http://ftp.gr.debian.org/debian/ jessie main contrib non-free
2: deb http://security.debian.org/ jessie/updates main contrib non-free
No active apt repos in: /etc/apt/sources.list.d/mx.list
Active apt repos in: /etc/apt/sources.list.d/openvpn.list
1: deb http://build.openvpn.net/debian/openvpn/stable jessie main
No active apt repos in: /etc/apt/sources.list.d/siduction.list
No active apt repos in: /etc/apt/sources.list.d/various.list
Info: Processes: 186 Uptime: 24d 1h 09m Memory: 15.60 GiB used: 1.64 GiB (10.5%) Init: SysVinit v: 2.88
runlevel: 5 default: 5 Compilers: gcc: 4.9.2 alt: 4.9 Shell: bash v: 4.3.30 inxi: 3.0.10