Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Wild Penquin

  • Content Count

  • Joined

  • Last visited


This user doesn't have any awards

1 Follower

About Wild Penquin

  • Title

Profile Information

  • Gender
  • Location


  • CPU
  • Motherboard
    Asus Maximus VII Gene
  • RAM
  • GPU
    EVGA GTX 970 (04G-P4-3975-KR)
  • Case
    Lian Li DX-04
  • Storage
  • PSU
    Works and is silent
  • Display(s)
    Samsung LC34F791
  • Cooling
  • Keyboard
    Corsair K95RGB Platinum
  • Mouse
    Logitech G703
  • Sound
    Jazz, Progressive Rock, electronic music!
  • Operating System
    Arch Linux

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. For question 1): I meant which image, where did you download it? What software did you use to create it? Did the software and/or image state if it it UEFI, Legacy or hybrid bootable? With this information, you do not need to guess / blindly test the boot method. As for Legacy setting, it should be quite straightforward. If this is the manual of your MB, the instructions seems to be on page 80 (3-22). EDIT: it seems, according to the manual, that on this particular MB Legacy boot can not be disabled altogether; but this might change according to BIOS revisions etc. EDIT: Question 2) is meant do diagnose if the USB media is UEFI bootable. Without the USB inserted, you should not get a boot entry in BIOS where you are supposed to choose which UEFI entry to boot from (obviously). If you insert the USB media before booting into BIOS, you should get an entry. Also, at least in some modern BIOSes, it should populate the entry even if you insert the USB media after booting into BIOS (you might need to reload the BIOS boot menu by exitting and re-entering). Anyways, if inserting the USB stick doesn't add any UEFI entries, the USB image is not UEFI bootable (or at least not detected us such by your BIOS).
  2. In short: there are two ways of booting (PCs). The old, legacy way (dating back to 80s) and UEFI (which has become common during the last decade or so). Bootable USB media (and other removable media) can be either Legacy, UEFI or hybrid (both ways) bootable. Modern desktops can boot in both ways, but usually Legacy boot is disabled per default. UEFI bootable removable media needs to be booted trough some BIOS menu manually. Three questions: how was the media made in the first place? Do you get additional boot entries in BIOS if you insert the media? Have you tried enabling Legacy boot in BIOS?
  3. I think your output for 'apt-get update' is not for that command (it should not try to install any packages). Are you sure you typed "update", not "upgrade"? For reference: https://linux.die.net/man/8/apt-get You can get (more or less) the same manual on your installation by typing "man apt-get" in terminal and other means, too. In short, "update" will sync source repositories db (and should not install any packages on itself) and should be run before any other operations. Obviously, if your db is not in sync (way out of it), you might run into errors if apt-get upgrade tries to download something that does not exist anymore. In general, it makes sense to learn what commands mean instead of blindly typing them, since it makes it easier to figure out what fails and why; if apt-get update fails, fix it first. None of the subsequent steps can not possibly work otherwise (checking config, as already suggested, is a good step since that could be the culprit).
  4. @wasab Agreed, that's why I mentioned encryption @Shoe_Eater Now that you put it that way .... I don't think it is that far fetched that implementing secure boot could not have some motivations aiming at some kind of monopoly on the OS market. Granted, it can be easily disabled currently on most computers. But, that does not necessarily need to be so in the future! "Embrace, Extend, Extinquish" as someone said at M$; and in this case they are at Embrace or Extend -stage, slowly moving to Extinquish (I certainly hope that is not the future)....
  5. I think secure boot has it's uses in situation where a potentially malicious user (schools students?) has access to a computer, or if the computer is on the go and it can not be guaranteed it is under the eyes of the owner all the time (and a malicious user might have time to boot some other OS). Granted, if a user has physical access, he can do whatever with the computer provided he/she has enough time. But secure boot makes it more difficult, and often non-feasible to boot another OS. But if it is the data that needs (malicious read) protection, encryption is a way better protection (and a separate thing from secure boot). But then again, on computers without secure boot, you could lock down BIOS with a password, and set it to boot only from a single source / hard disk (which is good enough for schools etc.). I guess secure boot could allow booting from some other media which has boot entries signed with trusted keys? TL;DR: it certainly has some uses, but a home user usually has little. Some conspiracy theorists say it was invented by Microsoft to prevent booting Linux, but I think that is mostly baloney
  6. Well, this is only partially correct. There are standards for hardware, among controlling fan speed, but these are not always followed. It is not just the fan speed that has standards. Linux as an OS, will need someone to write drivers for non-standard hardware. This can be really difficult if the manufacturers either don't do it themself or release the specification for someone else to do it (=volunteers!). Unfortunately, laptops (or, their manufacturers) are notorious for making their devices non-standard, and only releasing closed-source drivers for their (not users) choice of OS. Sometimes reverse-engineering is needed to get even basic stuff working. Luckily, sometimes they release closed-source drivers for Linux, sometimes even Open Source some part(s) of their drivers. Macbook Pros are not especially well supported on the manufacturers part. That being said, distributions could make life easier for users and automate installation for setting up Laptops and possibly some other more exotic hardware. Often the case is, there is some small third-party (open sourced or closed source) utility to add missing functionality which is not there OOTB. Generally, they don't, since there are limited volunteers and diminishing returns for the needed work to support every piece of hardware out there... so some manual work from the user is needed. Think of Linux (or OpenBSD or any Open Source, free OS) as if you were building a house from stuff you get from the HW store; you will need to do some work yourself. There will always be some manual work for Open Source OSes (unless someone makes some kind of paid distribution / service, which will give enough incentive for someone else to polish the experience for the end user!). p.s.: on my Macbook Pro, in addition to fan speed control, I also needed to 1) find the right Wireless driver - and the closed source driver just stopped working after a recent update, 2) add SysRq support (re-map key configuration on Kernel level), 3) install ReFind (there could have been other solutions but this was easiest) and 4) tweak the Touchpad to my liking. With default drivers it's just way too buggy for two-finger scroll, which is a must for my workflow, and 5) tweak the way screen brightness was set, sine aalthough it was working, it was not working 100% well (not all of the range was in use). Possibly something else I forgot.
  7. Well, on my old MBP from 2009, IIRC on OS X it way way more quiet than on Linux (and while CPU was quite hot, it didn't throttle), but in Linux without fan control, the fan would spin at 100% no matter the load (problem: this is unbearably loud). So I needed fan control in Linux just to get a reasonable noise level from the Macbook. So in my case, it is converse to OPs situation (but different model MacBook Pro). So I agree, fan control is needed. In any case, it should not be a surprise you need fan control (and other tweaks) on an OS not supported by the manufacturer...
  8. Another good read is this: http://write.flossmanuals.net/command-line/introduction/
  9. It should work with or without quotes. So either: MAKEFLAGS="-j6" or MAKEFLAGS=-j6 Should be fine (quotes are necessary if you have spaces, say adding several MAKEFLAGS; and with that rationale the quotes are more clean or correct, because it will be easier to add flags later if needed). Some programs might compile / parallelize worse than others, some might have some weird (non-standard) way to call make or compiling the source and drop the MAKEFLAGS variable set in /etc/makepkg.conf. In that case you could try to fix the PKGBUILD. IMO it is a bad habit to set MAKEFLAGS in the PKGBUILD (unless there are specific reasons to do so); Usually they are system specific and should be set on the host system.
  10. In that case, ITheSpazI already linked the instructions.
  11. Nice that you got it working! Just a few things (for future and people eavesdropping): Partition entries (numbers) have nothing to do with the actual order they are on the disk (has been like this on MSDOS type partition tables IIRC and still is on GPT). The number which will be assigned, will be the first free number (but I suppose a partition utility could assign any free number, but this is what they will usually do). If you delete and add partitions, you might end up with any kind of partition numbers and their orders. But it is nothing to worry about, as it irrelevant what numbers the partitions are given; generally, it is not recommended to rely on them (or even disk device nodes) in any case, but use partition or FS UUIDs. Moreover, GUI partition utilities might not give all relevant information. For example, the listing in OP does not state where a partition starts and ends - it only gives their sizes. They could be in order (they are on the disk), but this is only an assumption, and not a safe one (say, you want to resize a partition - it might be more difficult than anticipated). Best to use command line (since those are DE agnostic and same for all, and even work for example if your DE fails) or figure out how to get more information out of that GUI thing, whatever it is (perhaps there is an option to display more columns with more information?). To answer your original question: the approach is to make sure GRUB does not have anything on the previous Linux installation. It is possible it is installed that way, in case the installation was left over from your previous Linux installation. Most Linux distributions will install their bootloader, unless specified otherwise - so usually the one which was installed last will be "in charge". Lukyp outlined what is needed. You can do this from the already booted Linux installation (no need to bind mount nor chroot).
  12. Any live Linux, chroot and then passwd (please ask if you don't know what this means). Unless the hard disk is encrypted, there is no (real) protection on any computer, if a user has physical access to it. A re-install is a good (better!) option, too. You won't have any cruft left from the previous owner. Who knows, there might be rootkits already installed (either on purpose or by accident from the previous owner). EDIT: Also, you might want to free Linus Sebastian from that laptop. Otherwise, we will get no new videos from LTT anymore! EDIT2: If the laptop has a bootloader, such as grub, with some way to access Kernel boot parameters (and it is not disabled on purpose), it is quite easy to boot into a single-user =root session without the password being ever aked.
  13. Yes, clamav will do the trick and is probably what the OP needs. I'm not aware of any alternatives (probably because clamav does it's job good enough, is free and open source - and in such a case, it makes little sense to divide development efforts into separate projects). About viruses in general: There have been little viruses for Linux. The most probable reason is that Linux (or OS X) is a less popular OS. It makes sense for virus writers to target popular OSes of the time (such as DOS and Windows). Also, Linux is/has been protected by more computer-literate users, who are less likely to fall into "stupid mistakes", say dialog boxes on web sites etc.; and are more likely to be able to spot viruses and be prepared for them. Also, Linux as an OS (at least pre-Windows XP) was much better protected against virus infections (although, it can not be stressed enough: it was never immune. The protection comes only from more clearer the separation of Kernel | user-space | permission system of the OS FS). But: the protection from rarity and more-computer-literate user space might diminish, as a OS becomes more popular (and possibly the average user is not that computer literate as before). Usually (at least historically) Viruses have not (usually!) migrated from an OS to another. But this is not a "safe" assumption; it has been like this only because it has been convenient from the viruses point of view (or their developers). It is certainly possible to write a OS-agnostic virus (even across architectures, I'd assume it is more easier though if the CPU architecture is the same - which used to protect OS X users). There more and more common factors between OSes, such as web browsers, and common scripted languages (Javascript and the like) which might run OS-agnostic viruses. Also there are file formats, which are borderline (or actual) programming languages in their own right, and could (at least in theory) contain a virus. One good example is MS Word macro viruses, and these are OS agnostic at least to a certain degree. Also, it is possible a Windows virus will run in Wine (in OS X or a Linux desktop environment). It will still see a Windows machine, but it doesn't mean it can not corrupt the users files (depends on how Wine is/was configured, but 99% of the time it has full R/W support to the users home dir who is running Wine). There's one important point, though: just because a Virus could not run on your OS, doesn't mean it is desirable to share viruses from files you got elsewhere for your peers (who might run another OS). That's why it is a bit naïve to claim there are no scanners targeting viruses made for another OS than on which they are running. There is a clear need, and there have (pratically) always been virus scanners for "other" OSes, especially on non-Desktop-only oriented OSes (clamav runs on many OSes, btw).
  14. This probably boils down into Laptop manufacturers not giving information about their devices (or better yet, actually supporting Linux). In worst case, the touchpad is non-standard. There is no way for the drivers to know what to expect from such a touchpad... Anyways, run in (a terminal) 'xinput list'. Is your touchpad listed there? If yes, then try 'xinput list-props X' (just the number should be enough) and try to figure out how to use xinput to make the touchpad behave. I can't give specific instructions from the top of my head, but perhaps this will point you in the right direction :-) I needed to do some tweaks with xinput for my MBP (though, it was nowhere near as bad as what you describe), but for multi-touch, the default Synaptics was just unacceptable. I got better results with libinput. If xinput does not help, you might try to look for instructions to how to switch to libinput instead (of Synaptics ... it get's a bit hairy, xinput is a tool to configure either under X.org). It might work better (or not) with libinput (worth a shot). There are some google hits with "linux touchpad sensitivity" which might be relevant.
  15. I did a Google search I think you could do this with xbindkeys and xte. See: https://askubuntu.com/questions/624756/how-can-i-map-keyboard-buttons-to-my-mouse-buttons You can bind any mouse key (or key+mouse combination) to trigger pretty much anything (command, script, keystrokes). With xte you can even fake any keystroke. Long answer and some thoughts (about the lack of a GUI options and other stuff): If you want someone to implement a GUI option for this (from your wording I'm not sure are you asking for help or someone to make this option into the GUI, which you already know doesn't exist), then I think you are on the wrong forum. Better place is the official forum for the DE or Distro you want the feature implemented on, or better yet, a feature request on the appropriate bugzilla. You need to invest some time in making a good feature request, and rationalize why the features you want to implement are needed and/or are a priority, if you ever wish them to come into fruition (i.e. give good examples of use cases and problems that a proposed feature would fix). A tool to do what you want does (possibly?) not exist just because it makes no sense to most people. You are probably trying the wrong approach to some other problem; can you be more specific, why do you want to do this; what is your use case? What you are trying to achieve? The behavior of mouse keys should be (ideally) defined higher on the software stack (software should react to the mouse key events the way the user wants). But, sometimes software does not have the features you need ... so I can see that what you need might come usefull. But it is a corner case! After all, they are a different (physical) keys, and even separate devices. Conclusion: as this is a corner case, it it should not be a GUI option in the first place, at least not in the core GUI of the DE; that should be left to more common use cases, since if every users (special) needs would be covered, options will grow exponentially, which will make the GUI quite a mess eventually. So this seems like a job for a user script or for third party tools (such as xbindkeys/xte and others; someone could of course write a frontend GUI for a certain use case!). But scripts and command line utilities will always be more versatile than a feasible GUI can be - for this kind of task! This is a classic example of "right tool for right job". [/long answer]