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

Wild Penquin

  • Content Count

  • Joined

  • Last visited

Everything posted by Wild Penquin

  1. There are ways to do what the OP wants (conversely to what some replies here claim). I've done this before, way back when I had a computer with no internet-connection (actually, the computer had a slow modem connection but it was not used for upgrading, since it would not have been feasible), and wanted to upgrade it's Debian-based distribution. Though, I must admit I'm not 100% sure what the OP wants and if this way is the right tool for the job, but if the goal is to be able to upgrade a Debian-based distribution without an internet connection (or a non-usable, for example, too slow one), it
  2. Well, I agree with mahyar and others in this thread - it really depends on what you are doing on the computer, your priorities, and also heavily on what games you play. Depending on the titles and your luck, experiences may vary =). As someone gaming on Linux since the early 2000s (!), things have improved a lot since then. I'm also someone who can easily do and doesn't mind doing a few tweaks here and there. However, some games work just fine out-of-the-box without any tweaks (with Proton and/or Wine,), some games have native ports and those numbers have been steadily albeit slowl
  3. First, post the complete output of the apt install command. Copy and paste it her (in code tags), including the command you've typed. One possibility is that you have not synced the apt database (with apt update) before running apt install. Another alternative is that your apt mirror sources are misconfigured for some reason. A third possible reason is wrongly configured network (or some network error anywhere from your computer to the mirror). Or, possibly, those packages with those names just don't exist (I didn't check). Apt should give reasonably sensible error messages which
  4. Ok, that tells us the VGA cable is at least working. There should be some kind of boot manager installed (grub or something) but depending on how it is configured, the delay for it automatically selecting Linux could be so short you can never see it (especially if the Linux installation is the only choice). What about the VTs?
  5. VGA input is intelligent enough that it can communicate with the GPU (and OS) so that a resolution / refresh rate can not be set outside what the display can handle. Unless someone has specifically told / forced X.org to use that high display rate, it should not set it that high (well, more modern revisions were - but you have a flat panel, so...). There is the possibility that your VGA cable is very old or broken and can not communicate with the display (if the data pin is broken, the OS can not "sense" the display, and can do whatever it wants with the signal... actually, old CRT VGA monitor
  6. Some distributions install grub into the EFI partition, along with it's configuration files. Not all do, but that is one valid way to install grub. What this means, is that even after deleting all partitions of the said Linux installation, it's grub might still linger on and have it's configuration in the EFI partition. You can even have many grub installation in the EFI partition. If for whatever reason the default UEFI entry is the old grub UEFI entry, updating grub settings from the current Linux OS will not fix things - unless the said command also ensures the grub instance it
  7. This is true, which is why I prefer amd GPUs. Not only did the NVidia Linux drivers have a bit less-than-Window performance, their overall quality and stability is worse (also, no support whatsoever from NVidia; but for AMGPU drivers: if you know how to gather information from crashes, logs etc. - even better if you can run a debugger - it is actually possible to get help and bugs fixed with amdgpu by posting useful bug reports in trackers). As for OPs question: indeed Linux is not any magic wand, it does not make your PC magically perform better. In some corner cases it may be pos
  8. Your point is right in principle, but none of the examples you've given are native Linux games. They are using Vulkan but they are using the Windows implementation of it. Which means they still need to run trough Wine implementation of the Windows API (Windos Vulkan -> Linux Vulkan will include it's own computation costs, which might not be at all faster than, say, dxvk). Games which have a real Native Linux port run very well (X-COM series, Tomb Raider series for example).
  9. Also, look at your BIOS settings. It is likely your fans are controlled by the BIOS and fan curve settings are setting in a suboptimal way (considering acoustics etc). It does not make much sense to enable software fan control unless the BIOS settings are very limited and you really need it (always consider the scenario of a system hang when the processor is at a 100% usage loop - and if the fan control software doesn't work, fans will not ramp up).
  10. Also, I believe one can boot from GRUB to any correctly installed Legacy-bootable OS. I.e. if GRUB has been booted in UEFI mode, it can boot any (correctly installed) OS. If it has been booted in Legacy mode, it can not boot UEFI-enabled OSes, generally (emphasis because I'm not sure on the UEFI Grub -> Legacy boot chain, but there is no reason it should not work). But indeed as long as OP (or anyone who is asking any question) does not provide information about their setup, it is really difficult to give advice / instructions on any matter. As a general tip: learn h
  11. (sigh) this is still an issue with current Windowses? I though people haven't needed to deal with this kind of S**** since the UEFI booting came along. I only thought windowses overwrote MBRs (and in the very early days of UEFI though they were the only OS in the EFI, but that could have also been buggy/half-***ed UEFI implementations). Anyways, in this kind of situation grub has booted properly but it can not find it's configuration file. There are (at least) two places where it can reside in: in grub's dedicated folder "grub" in the root of EFI (I believe this is a bit no
  12. This has nothing to do with the problem, grub can load an OS from any disk and partition (if it is a sensible one; it might not do something like booting a DOS-based OS from an extended partition etc.). Post the output of "sudo lsblk" and "sudo blkid" here, that way we can help. The page can be daunting as it has loads of information out of which not all is relevant to you. To summarize the process is roughly: install os-prober (it is not installed per default in Arch), mount your windows partition and then run grub-mkconfig (as outlined earlier on that
  13. Well, it is not the only way - it is one way. I do agree on the insanity part. FOSS is not indeed a magic wand which will solve every problem, but it is one way to help facilitate this goal. Also, previously I was not referring to the end-user software (although it also does play a role - a closed source software can only be ported by the source rights holder, but with a more free license many other parties can facilitate a port). To re-iterate what I was trying to say: Currently, we have competing, closed source APIs and Libraries for every major OS (Windows, O
  14. Hi GCandy77, I'll try to answer your questions as you've numbered them. 1. dynamic mount via systemd units: First question: why do you need to do this? Wouldn't listing the partitions in fstab suffice? This is also in the grey box right in the beginning of the Manjaro forum post you've linked. (The OP there says the manual in in contradiction; I disagree with that, it's just a wrong interpretation the OP is making. I argue it makes sense to configure system so that the configuration is easy to read and change for humans. Systemd can have it's own
  15. @maplepants, I agree. Coming from a non-programmer, Java has been marketed as something it was never meant to be (or so I've been told), and it is not the only one of that kind of cases (well, it happens everywhere, in every field... reality doesn't often match with marketing - ever played a videogame which didn't live up to it's hype? Marketing is shady! ). It still has it's uses (despite misleading marketing) but the bytecode can not be as efficient as something compiled from a more efficiency-oriented language, say, C. There might still be some development possible here with i
  16. I think you are touching an important problem here. I'll start with an analogy from the history: way back in the emerging home-computer segment in the 70s and 80s, there were loads of different computers. They all had their own software, and a piece of software made for, say Commodore Amiga would not work on an Atari ST. The reason was they had different kind of hardware. At some point IBM PC became the standard as we know it today, kind of by half-accident (it was supposed to be a proprietary system, but then clones emerged, and I'm not sure IBM sued anybody, but in any case, then
  17. Also, after re-reading your post I noticed you are planning to use chroot. That is usually not necessary in case your bootloder is working. You can pass kernel parameters so that it will not start any X.org session. The official way would be to add: systemd.unit=rescue.target on these modern, systemd days but "single", "1" or "s" should also work as an alias coming from sysvinit days. How you do this depends on your boot loader. See: https://wiki.archlinux.org/index.php/Systemd#Change_default_target_to_boot_into This a bit less error prone than chroot (though tha
  18. Unless something is really screwed up (such as: stuff in /etc, out-of-tree files everywhere etc.) then there is no reason to reinstall. I would go as follows: Remove all packages installed from AUR (pacman -Rns ...) Re-install the graphics drivers as per the wiki Based on what you've told, this is all there is to fix. In case you have indeed used packages outside Arch repositories (which it does sound like - you mention an uninstallation script!), things might get a bit more hairy. The same page I've linked above has tips on how to list files not owned by any pa
  19. What are you specifically worried about? If your system works fine now, no damage was done. Overall IMHO the dangers of running sensors-detect is a bit exaggerated sometimes. That being said, it can cause lock-ups, or at least in theory even data corruption or some similar problems. But these issues are somewhat theoretical, yes still there is some real risk. The more obscure, and more locked-in like the H/W you are using, the greater the risk - but I don't know about all the details. Blame manufacturers who don't adhere to standards or open up their H/W sensors to software, for t
  20. I want to chime in with some personal experiences. In general, amdgpu drivers are of better quality than NVidias drivers (on Linux!). Examples on which they are better: tearing (or lack of it on amdgpu), minor stability issues, suspend support. That being said, NVidia drivers are not bad. I used them still in 2019 and they were certainly usable. There were some minor problems, but there was always some workaround, but for example, I was not able to completely eliminate tearing. Suspend didn't work. There were occasional driver related problems with NVidia and KDE Plasm
  21. The most important question which is needed to be asked, is: what is the actual problem you are facing? It seems you have an idea about what the problem is and are trying to solve the problem that way, but it also seems this idea is way off track. This is a really common mistake people make: assume you know what you are doing (when you don't). Hence: we need the answer to the question above! EDIT: In essence, the problem is similar to this. Also, this part on the same guide seems relevant. I think I've seen better examples of a similar, badly formed question, in other h
  22. Yes, I can see that. I should have been more specific, it was the sentence before them which I did not understand.
  23. One thing with dual booting several OSes (the number of distributions is not a factor here, really) is that one OS should manage (traditionally) the boot manager, and one OS only (i.e. only one Linux distribution chosen by you!). Previous Windows versions used to overwrite BIOS/MBR bootloaders at upgrade time, and on UEFI computers, at least OS X has the bad habit to remove another boot manager, such as rEFInd, forcing the user to re-install the boot manager. Now I'm not sure about current Windowses (10), but previous Windowses even in the UEFI era might just remove non-Windows OS
  24. There are many GUI backup utilities for Linux distributions, which can be found via Google or other search engines (more correctly: frontends to the underlying GNU utilities, most probably rsync for vast majority of them, but they could use other mechanisms too). The fact there are many is also a problem; because of that it is difficult to give recommendations, as user experiences are more sparse for any single utility (and I personally have none). For (example) OS X Users, things are simpler and quite different: there's Time Machine, everyone uses it and everyone can recommend it.