Best Desktop Computer for Linux Mint

[Johnny]

I have always used HP computers, then I got one with UEFI settings
instead of a legacy BIOS. I didn't think I would ever get Linux Mint
installed on it. I finally did get it installed, but it was a pain.

I would like to try another brand of computer, like Asus, Lenovo, Acer
or some other brand.

Anyone know which brand is more compatible with a Linux operating
system?

[Bobbie Sellers]

I prefer Dell Latitudes, lightly used or refurbished.
Most computers will have UEFI these days but you can go into
the BIOS, see the manual for your model, and change to Legacy
or simply turn off Secure Boot, a Microsoft addition to the
problems of the world. The machines with Ryzen are not yet
too visible in the used/refurbished marketplace but even
a new one can have the pesky MS parts turned off. On
one model I installed to for a friend the disk was locked
which required at the time entering the Windows install and
using the Windows tool to alter the disk to make room for
Linux nearly 2 years ago now. Dell has at least one model
that comes with Ubuntu and you just have to go to their
site if that is of interest to order a new Linux computer.

bliss - “Nearly any fool can use a Linux computer. Many do.” After all
here I am...

--
bliss dash SF 4 ever at dslextreme dot com

[Johnny]

It seems like a Dell Latitude is a laptop. I would rather have a
desktop tower, or small form factor computer. They are easier to work
on.

You are right about Microsoft, they are creating the problems for Linux
users.

With that HP I had, changing to legacy and turning off secure boot
wasn't enough. I found I had to also turn off Microsoft Certification
Authority, and I couldn't do it with one visit to the UEFI settings. I
had to turn legacy and secure boot first and save it, then go back to
the UEFI settings again and disable Microsoft Certification Authority.

I usually shop Newegg for refurbished computers.

[Andrew]

Are you looking to set up dual boot or do you just want to run Linux on
it? I got my "main machine" new, three years ago from a local shop. It
is an AMD.
An SSD for the OS stuff (although I don't keep /var on it) and a
rotating disk for stuff like /home. It came without an OS installed and
I set it up with UEFI. The advantage of a decent "Generic PC" is that
the manufacturer won't have added anything weird and generic which could
cause Linux problems. Ryzens are old enough now that a current
distribution can handle them.
I have had problems with Nvidia graphics and tend to go for AMD.
The problem at the moment is that it is not a good time to be buying a
PC - they are pretty scarce on the ground and correspondingly expensive.

[Johnny]

Newegg has plenty of inexpensive refurbished computers.

I'll just be running Linux Mint. If the computer comes with Windows, I
will just tell the Linux Mint installer to erase the whole disk and
install Linux Mint. I have never had any problems with Intel graphics.

[Zebee Johnstone]

In comp.os.linux.hardware on Mon, 22 Mar 2021 15:46:37 -0500

Johnny <joh...@invalid.net> wrote:
>
> It seems like a Dell Latitude is a laptop. I would rather have a
> desktop tower, or small form factor computer. They are easier to work
> on.

Any dell desktop will do in my experience. I picked up a dell
optiplex with 4k intel graphics and 16gb ram for not very much on
fleabay.

Zebee

[David Brown]

Almost any computer is fine with Mint - UEFI or not. If you are using
UEFI and starting with a blank disk, you need to make you have the small
UEFI partition at the start of the disk, but that's all there is to it.

[David Brown]

On 22/03/2021 22:08, Andrew wrote:
> Johnny wrote:
>>
>>
>> I have always used HP computers, then I got one with UEFI settings
>> instead of a legacy BIOS.  I didn't think I would ever get Linux Mint
>> installed on it.  I finally did get it installed, but it was a pain.
>>
>> I would like to try another brand of computer, like Asus, Lenovo, Acer
>> or some other brand.
>>
>> Anyone know which brand is more compatible with a Linux operating
>> system?
>>
>
> Are you looking to set up dual boot or do you just want to run Linux on
> it?  I got my "main machine" new, three years ago from a local shop.  It
> is an AMD.
> An SSD for the OS stuff (although I don't keep /var on it) and a
> rotating disk for stuff like /home.

That's good advice - /if/ you are using a very small and cheapo SSD from
at least 10 years ago.

Otherwise, you need to be malicious or have a very specialised use-case
to have any hope of causing wear problems on your SSD. If it is a
particularly cheapo device, you could conceivably have measurable
slowdown when it is nearing full. The solution there is to leave a
small partition (5 GB, for example) unallocated when you partition the
blank disk - that gives you extra flash overprovisioning on the disk,
and ensures there is always free space for efficient writing and garbage
collection.

(Of course, if you have a big /home and need to be cost-effective, then
spinning rust gives you more space for your dollar, and you pick your
tradeoffs. But it is badly outdated, if it was ever right at all, to
think that SSD's are unsuitable for files that are written often.)

>  It came without an OS installed and
> I set it up with UEFI.  The advantage of a decent "Generic PC" is that
> the manufacturer won't have added anything weird and generic which could
> cause Linux problems.  Ryzens are old enough now that a current
> distribution can handle them.

Once you have the basics right - the choice of 32-bit or 64-bit, x86 or
ARM, etc. - then any distribution will work fine with any cpu. There
may be details in the power saving modes and that kind of thing.

> I have had problems with Nvidia graphics and tend to go for AMD.

If you are happy with non-free drivers and a modern Linux (like the
latest Mint), then Nvidia is usually a better choice than AMD. If you
prefer open source drivers, then you might want AMD. If you are not
into 3D gaming, heavy graphics programs or GPU-accelerated code, then
either will be absolutely fine, including the integrated GPU on some
modern Intel or AMD cpus.

[Marc Haber]

Any decent and current Linux will run fine on UEFI.

I'd rather go with a more mainstream distribution such as Fedora,
Ubuntu or Debian than get a new computer for that. UEFI is the
sensible way to go since we desperately need to let go of the BIOS
emulation after its 40th birthday.

That being said, I am a honorable member of the "church of thinkpad"
and would buy a used T- or X-Thinkpad in my targeted budget range. I
have always assembled my desktop machines myself and cannot comment on
the quality of Lenovo in that segment.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[David Brown]

On 23/03/2021 09:50, Marc Haber wrote:
> Johnny <joh...@invalid.net> wrote:
>> I have always used HP computers, then I got one with UEFI settings
>> instead of a legacy BIOS. I didn't think I would ever get Linux Mint
>> installed on it. I finally did get it installed, but it was a pain.
>>
>> I would like to try another brand of computer, like Asus, Lenovo, Acer
>> or some other brand.
>>
>> Anyone know which brand is more compatible with a Linux operating
>> system?
>
> Any decent and current Linux will run fine on UEFI.
>
> I'd rather go with a more mainstream distribution such as Fedora,
> Ubuntu or Debian than get a new computer for that.

Mint is mainstream, and builds on Ubuntu but - in my subjective opinion,
of course - is nicer to use, avoids unpleasant hidden commercial deals,
and is more convenient for things like graphics drivers. If Ubuntu
works on a machine, Mint will work too.

> UEFI is the
> sensible way to go since we desperately need to let go of the BIOS
> emulation after its 40th birthday.
>

UEFI is a complete waste of time and effort. It added nothing useful
that you couldn't do with traditional BIOSes, but made everything more
complicated. In theory, it allowed for extensibility of different
pre-boot programs - in practice, there are a total of zero use-cases for
this. There is nothing that a UEFI BIOS can do that a traditional BIOS
cannot, and there is nothing that could not be done better with a simple
BIOS and a flash disk with a dedicated Linux system for when you want
something more complex (like settings with a more advanced gui).

[Aragorn]

On 23.03.2021 at 11:13, David Brown scribbled:

> UEFI is a complete waste of time and effort. It added nothing useful
> that you couldn't do with traditional BIOSes, but made everything more
> complicated. In theory, it allowed for extensibility of different
> pre-boot programs - in practice, there are a total of zero use-cases
> for this. There is nothing that a UEFI BIOS can do that a
> traditional BIOS cannot, and there is nothing that could not be done
> better with a simple BIOS and a flash disk with a dedicated Linux
> system for when you want something more complex (like settings with a
> more advanced gui).

I'm not sure I agree with your assessment, David. For one, the legacy
BIOS is the main reason why x86-64 processors still have (and need to
power up in) a "real mode", i.e. the 16-bit mode that the 8086/8088
processors ran in, with only 1 MiB of addressable memory (of which part
is reserved for hardware access), no privilege separation, no memory
management unit, and all software having full access to all of the
hardware.

RISC machines — which do not have a real mode, and which were never
designed to work with real-mode operating systems like CP/M or MS-DOS —
have already long used an EFI. So while UEFI does have its flaws and
its corporately controlled committee overseeing the UEFI specification,
the legacy BIOS was an anachronism and really needed to go.

Now, that said, while I really see no use for a 32-bit UEFI on 64-bit
hardware — what genius ever came up with that idea anyway? — a 64-bit
UEFI running a 64-bit OS does offer things that a legacy BIOS cannot.

For one, it saves the boot loader and the kernel bootstrapping code from
having to pull all kinds of tricks for storing information about the
hardware in a memory location that won't get zapped when the kernel
bootstrap code switches the processor from real mode to protected mode,
PAE mode and then long mode (in that order). If on the other hand the
system boots in UEFI mode, then the kernel can obtain all information
about the hardware directly from the firmware, because the UEFI runs in
the same 64-bit address space.

Another advantage — one that I personally have no use for, but many
other people do — is that a UEFI allows for booting multiple operating
systems installed on the same drive, even if those operating systems
don't have a boot loader that can do this. The legacy BIOS cannot do
that, because it requires one partition to be marked with the boot
flag, and then loads that partition's boot sector into memory, and then
passes control of the machine onto whatever code was in that boot
sector. The only caveat is that all operating systems on the same
drive have to be installed in either UEFI mode or in BIOS mode, but not
as a mix of both — such is possible if the operating systems are
installed on different drives, but not when they're on the same drive.

Of course, additions to the UEFI specification such as Secure Boot —
which should rather be called Restricted Boot, because that's what it
was really included for — are deplorable, as are hardware optimizations
like Fast Boot for making Microsoft Windows perform better at
boot-up. If Microsoft Windows needs to be able to boot faster, then
that's on the Microsoft developers, and then that should not require any
special modifications of how the hardware works. That's turning the
world upside down — which Microsoft has a long history of doing.

That all said, this computer here is a shop-built machine — the shop's
own "brand" if you will, and they're all sold without an OS installed —
and I've set it up to boot in UEFI mode, with both Secure Boot and Fast
Boot disabled. It runs Manjaro Stable, installed on a GPT-partitioned
SSD, and I've also added an older and slightly smaller HDD — also
partitioned as GPT — for storing my backups. No proprietary stuff either
— it's an MSI motherboard with onboard Intel 630 UHD graphics. And it
works like a charm. ;)

--
With respect,
= Aragorn =

[Marc Haber]

David Brown <david...@hesbynett.no> wrote:
>UEFI is a complete waste of time and effort. It added nothing useful
>that you couldn't do with traditional BIOSes, but made everything more
>complicated.

It has also removed a truckload of cruft that has been useless since
the mid-1980ies. Complicated is only your perception because you have
to adapt to some things being different, while you know the BIOS
atrocities by heart.

[David Brown]

On 23/03/2021 11:59, Aragorn wrote:
> On 23.03.2021 at 11:13, David Brown scribbled:
>
>> UEFI is a complete waste of time and effort. It added nothing useful
>> that you couldn't do with traditional BIOSes, but made everything more
>> complicated. In theory, it allowed for extensibility of different
>> pre-boot programs - in practice, there are a total of zero use-cases
>> for this. There is nothing that a UEFI BIOS can do that a
>> traditional BIOS cannot, and there is nothing that could not be done
>> better with a simple BIOS and a flash disk with a dedicated Linux
>> system for when you want something more complex (like settings with a
>> more advanced gui).
>
> I'm not sure I agree with your assessment, David. For one, the legacy
> BIOS is the main reason why x86-64 processors still have (and need to
> power up in) a "real mode", i.e. the 16-bit mode that the 8086/8088
> processors ran in, with only 1 MiB of addressable memory (of which part
> is reserved for hardware access), no privilege separation, no memory
> management unit, and all software having full access to all of the
> hardware.
>

There is no need to make UEFI to solve that - just scrap the badly
outdated "real mode" and start code running in "sane mode" (I've
forgotten what that is called in modern x86 parlance - enhanced long
mode, or something). The only thing that is needed to make this work is
a very simple default setup in the memory management unit. Coreboot has
perhaps three or four instructions in "ancient mode" before jumping
straight to "sane mode" for everything else. There is no early reason
why BIOSes should do anything else. And there is certainly no need for
shells, hidden partitions, "extensible" firmware that is never extended,
"trusted encryption", or any of the other complicating twaddle of UEFI.

UEFI was created for one purpose, and one purpose only - it was invented
by Microsoft in order to make life difficult for anyone who wanted to
put something other than Windows on a computer. Everything else is just
an excuse with no real benefit to anyone.

Look at it this way - how often have you ever used your computer's UEFI
BIOS in a way that is different from a "traditional BIOS" ? Apart from
the inconvenience of having to waste a little disk space on a pointless
UEFI partition, what difference does it make? The answer is /none/.

> RISC machines — which do not have a real mode, and which were never
> designed to work with real-mode operating systems like CP/M or MS-DOS —
> have already long used an EFI. So while UEFI does have its flaws and
> its corporately controlled committee overseeing the UEFI specification,
> the legacy BIOS was an anachronism and really needed to go.
>
> Now, that said, while I really see no use for a 32-bit UEFI on 64-bit
> hardware — what genius ever came up with that idea anyway? — a 64-bit
> UEFI running a 64-bit OS does offer things that a legacy BIOS cannot.
>

I think we should be clear here on the terms, and what we mean by them -
then it will be easier to see what I mean here.

The original PC BIOS had three functions. It would do the initial setup
of the system (ram initialisation, chipset configuration, etc.). It
would find and start the bootloader from the beginning of the disk. And
it provided services (such as INT 13, if my memory serves me) for the OS
to access hardware.

After a while, this third function was effectively useless as OS's
handled the hardware themselves.

BIOS's continued to be developed in an idiotic manner - often in
assembly, and invariably in real mode. That was the choice / fault of
the BIOS designers - there was no requirement to do so, and no purpose
in doing so. (They'd still need some real mode and assembly code to
support INT 13 and the rest, as long as they wanted to support DOS.)

Intel tried to change this by starting the EFI project. It petered out
from lack of support. Intel, Microsoft and some manufacturers got
together to make the UEFI specifications. These were full of a range of
ideas, features and complications which have never been used in
practice. Much of the point - for Microsoft - was to make sure Linux
would not work. Intel hoped it would let them scrap the silly old
compatibility modes on their cpus. Manufacturers hoped it would mean
the BIOS writers would use tools from this century and make BIOSes that
didn't look like DOS programs.

None of the complications of UEFI add anything of use. Almost none of
the new features are used. (There are a couple of things that OS's read
from it about motherboard and cpu setup, which could have been handled
in other ways.) None of the claimed benefits of UEFI, such as support
for sane cpu modes, big disks and C programming are in any way a feature
of UEFI - they could all have been part of any kind of BIOS.

The only things that are particular to UEFI are the signed firmware
stuff, and the ability to run different programs from a specific
dedicated partition. Those are the bits designed to be inconvenient,
and the provide no benefit.

> For one, it saves the boot loader and the kernel bootstrapping code from
> having to pull all kinds of tricks for storing information about the
> hardware in a memory location that won't get zapped when the kernel
> bootstrap code switches the processor from real mode to protected mode,
> PAE mode and then long mode (in that order). If on the other hand the
> system boots in UEFI mode, then the kernel can obtain all information
> about the hardware directly from the firmware, because the UEFI runs in
> the same 64-bit address space.

That doesn't need UEFI - it needs a simple default "all memory mapped
directly and fully accessible" default to the memory management unit in
the x86 cpu, as is done on sensible processors, and then all the other
silly old compatibility modes can be scrapped (other processors never
had them).

>
> Another advantage — one that I personally have no use for, but many
> other people do — is that a UEFI allows for booting multiple operating
> systems installed on the same drive, even if those operating systems
> don't have a boot loader that can do this. The legacy BIOS cannot do
> that, because it requires one partition to be marked with the boot
> flag, and then loads that partition's boot sector into memory, and then
> passes control of the machine onto whatever code was in that boot
> sector. The only caveat is that all operating systems on the same
> drive have to be installed in either UEFI mode or in BIOS mode, but not
> as a mix of both — such is possible if the operating systems are
> installed on different drives, but not when they're on the same drive.
>

That doesn't need UEFI. People were using bootloaders to handle
multiple operating systems long before UEFI was conceived.

> Of course, additions to the UEFI specification such as Secure Boot —
> which should rather be called Restricted Boot, because that's what it
> was really included for — are deplorable, as are hardware optimizations
> like Fast Boot for making Microsoft Windows perform better at
> boot-up. If Microsoft Windows needs to be able to boot faster, then
> that's on the Microsoft developers, and then that should not require any
> special modifications of how the hardware works. That's turning the
> world upside down — which Microsoft has a long history of doing.
>
> That all said, this computer here is a shop-built machine — the shop's
> own "brand" if you will, and they're all sold without an OS installed —
> and I've set it up to boot in UEFI mode, with both Secure Boot and Fast
> Boot disabled. It runs Manjaro Stable, installed on a GPT-partitioned
> SSD, and I've also added an older and slightly smaller HDD — also
> partitioned as GPT — for storing my backups. No proprietary stuff either
> — it's an MSI motherboard with onboard Intel 630 UHD graphics. And it
> works like a charm. ;)
>

UEFI is no longer a problem (it was, when it was introduced). You make
sure you have your pointless little partition, then install your OS of
choice like normal. But that does not stop it being a useless waste of
effort.

[David Brown]

On 23/03/2021 13:46, Marc Haber wrote:
> David Brown <david...@hesbynett.no> wrote:
>> UEFI is a complete waste of time and effort. It added nothing useful
>> that you couldn't do with traditional BIOSes, but made everything more
>> complicated.
>
> It has also removed a truckload of cruft that has been useless since
> the mid-1980ies.

Cruft that was once useful, but could later have been removed /without/
adding a trainload of new UEFI cruft that has never been not used.

[Marc Haber]

Right. But the Industry did do it differently. Love it, change it,
leave it.

[David W. Hodgins]

On Tue, 23 Mar 2021 10:07:10 -0400, David Brown <david...@hesbynett.no> wrote:
> UEFI was created for one purpose, and one purpose only - it was invented
> by Microsoft in order to make life difficult for anyone who wanted to
> put something other than Windows on a computer. Everything else is just
> an excuse with no real benefit to anyone.

That's overlooking another key advantage of uefi. It is basically a mini os that
the user has no control over that allows various government agencies to install
root kits that the user's os can not detect.

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[Henrik Carlqvist]

On Tue, 23 Mar 2021 11:13:48 +0100, David Brown wrote:
> There is nothing that a UEFI BIOS can do that a traditional BIOS
> cannot,

Yes it is. An UEFI BIOS is able to understand and modify contents on file
systems on the computer. This in combination with the feature to be able
to update the BIOS from software running in the computers operating
system makes things interesting in a bad way. This is the kind of
features that gives us persistent malware surviving reformatted and even
repaced disks. The features are not only used by malware makers but has
also been used by vendors like Lenovo for bloatware:

https://www.techdirt.com/articles/20150812/11395231925/lenovo-busted-
stealthily-installing-crapware-via-bios-fresh-windows-installs.shtml

What did they call this? Secure boot?

regards Henrik

[David Brown]

On 23/03/2021 18:19, David W. Hodgins wrote:
> On Tue, 23 Mar 2021 10:07:10 -0400, David Brown
> <david...@hesbynett.no> wrote:
>> UEFI was created for one purpose, and one purpose only - it was invented
>> by Microsoft in order to make life difficult for anyone who wanted to
>> put something other than Windows on a computer.  Everything else is just
>> an excuse with no real benefit to anyone.
>
> That's overlooking another key advantage of uefi. It is basically a mini
> os that
> the user has no control over that allows various government agencies to
> install
> root kits that the user's os can not detect.
>

That is not something I see as particularly realistic. (There are other
ways to do that better, such as the Intel Management Engine.)

[David Brown]

On 23/03/2021 20:40, Henrik Carlqvist wrote:
> On Tue, 23 Mar 2021 11:13:48 +0100, David Brown wrote:
>> There is nothing that a UEFI BIOS can do that a traditional BIOS
>> cannot,
>
> Yes it is. An UEFI BIOS is able to understand and modify contents on file
> systems on the computer.

First, let me repeat - there is nothing that the UEFI BIOS can do that
another BIOS cannot. There is nothing hindering a non-UEFI BIOS being
able to access files. A Coreboot BIOS, for example, has as much of a
Linux system as you choose to compile into it. It is not UEFI - it does
not provide the UEFI-specified services, or need the UEFI partition.

Secondly, a UEFI BIOS cannot access files except on a very simplistic
and limited filesystem (fat32). It can't work with files on NTFS, ext4,
btrfs, raid, or anything else.

> This in combination with the feature to be able
> to update the BIOS from software running in the computers operating
> system makes things interesting in a bad way. This is the kind of
> features that gives us persistent malware surviving reformatted and even
> repaced disks. The features are not only used by malware makers but has
> also been used by vendors like Lenovo for bloatware:
>
> https://www.techdirt.com/articles/20150812/11395231925/lenovo-busted-
> stealthily-installing-crapware-via-bios-fresh-windows-installs.shtml
>
> What did they call this? Secure boot?
>

Traditional BIOSes have been able to block writes to boot sectors
(previous to that, boot sector viruses were "popular". The only virus I
have ever had on a computer was a boot sector virus). And updates to
BIOS were protected by "security by obscurity" - updates were so
inconvenient that you didn't do it by mistake or malware.

When you have unnecessarily features that are not used (and therefore
people don't get familiar with them and spot flaws), and an overly
complex design, then security failures are almost inevitable.

[David W. Hodgins]

True. Lojax only being detected 3 years ago means it's not widespread yet.
https://www.fudzilla.com/news/47311-uefi-hack-is-finally-with-us

[Andrew]

If you're worried about horrible things happening on your /boot/efi
filesystem, may I suggest
https://linuxconfig.org/intrusion-detection-systems-using-tripwire-on-linux
I have used this in the distant past when in a corporate network where a
sysadmin was known to have dubious morals and can say that you need to
be very careful which filesystems you use this on - a "differences"
report of half a million lines is useless for practical purposes, even
/boot/efi is updated quite frequently with the distribution I use.

[Johnny]

Thanks. I won't be buying a Lenovo.

[Adrian Caspersz]

On 24/03/2021 12:49, Johnny wrote:

>> What did they call this? Secure boot?
>>
>> regards Henrik
>
> Thanks. I won't be buying a Lenovo.
>

That was 2015, and Lenovo got rightly scolded.

In 2021, crapware is free with Windows 10. You won't be running that.


No, don't rule out Lenovo. They probably have the most Linux friendly
kit out there, laptops and desktops, particularly in the second-hand
ex-business (not consumer line) business.

https://itsfoss.com/lenovo-linux-certified/

Whatever you are looking at (Dell/HP/Lenovo), try and find a
hardware-maintenance manual for the product, an online community of
upgraders for the product (maybe also linux users), youtube channels,
and availability of spares and goodies on eBay.

However, if you are into playing computer games, then go elsewhere.
ex-Business line products won't have either the graphics or power supply
support unless you bastardize a server or workstation machine.

--
Adrian C

[Johnny]

I haven't decided yet which computer I will buy. I just want a newer
one, I think this old HP came out in 2013.

I've picked out one so far, it's a little over 3 years old.

It only has 8GB of DDR4 memory, but I have 16 GB of DDR4 memory I can
install.

https://www.newegg.com/dell-optiplex-5050-business-desktops-workstations/p/1VK-0001-5JU87?Description=dell%20optiplex%205050&cm_re=dell_optiplex%205050-_-9SIAAJ2DBA8261-_-Product&quicklink=true

I don't play computer games other than Freecell, and the old HP is fine
for that.

[David W. Hodgins]

On Wed, 24 Mar 2021 06:31:25 -0400, Andrew <Do...@hyperspace.vogon.gov> wrote:
> If you're worried about horrible things happening on your /boot/efi
> filesystem, may I suggest
> https://linuxconfig.org/intrusion-detection-systems-using-tripwire-on-linux

This isn't a discussion about the files on disk being changed. It's a discussion
about the firmware being hacked, which would then make things like tripwire
useless. The firmware runs before the os even starts. While uefi normally only
includes code for working with vfat file systems, a hack of it could add code
that works with other file systems too.

Like the Intel Management engine, or the AMD Platform Security Processor, the
uefi firmware has control before the os starts up so it can in theory include
a remote access tool.

Unlike the Intel Management engine, or the AMD Platform Security Processor, which
are only found in server systems targeted at corporate or government users, the
uefi firmware is also in all newer consumer devices.

Tools like tripwire are helpful to identify changes made that the os can detect.
It doesn't help with stealth root kits that get started before the os or tripwire
starts.

[Scott Alfter]

In article <20210322145810.4efb70c6@jspc>, Johnny <joh...@invalid.net> wrote:
>I have always used HP computers, then I got one with UEFI settings
>instead of a legacy BIOS. I didn't think I would ever get Linux Mint
>installed on it. I finally did get it installed, but it was a pain.
>
>I would like to try another brand of computer, like Asus, Lenovo, Acer
>or some other brand.

What's wrong with EFI? It is different from working with an older
BIOS-based system, but once you're only slightly familiar with it, it seems
easier to deal with. I've installed Gentoo Linux on EFI systems ranging
from a Dell PowerEdge R7515 on down to a Rock Pi X without any trouble to
speak of.

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

[Scott Alfter]

In article <s3c50g$96h$1...@dont-email.me>,

David Brown <david...@hesbynett.no> wrote:
>Almost any computer is fine with Mint - UEFI or not. If you are using
>UEFI and starting with a blank disk, you need to make you have the small
>UEFI partition at the start of the disk, but that's all there is to it.

On most systems, I usually keep /boot separate from the rest of the
filesystem. It's a perfect candidate for merging with the EFI system
partition. Kernel images will go in its root, while the bootloader will go
in its EFI directory. Make it a 100-200MB FAT32 partition, but set the
appropriate type (EF00) instead of the usual value for FAT (0700). (This
assumes you're using GPT partitioning. Numbers for MBR would be different,
but why would you use MBR partitioning with EFI?) I usually set the noauto
and noatime flags on it in /etc/fstab.

[Bobbie Sellers]

Nothing at all wrong with EFI and it provides better partioning choices
for users who need it. It is also capable of handling modern
equipment much easier than when 80 GB IDE hard drives were the norm.
When you have special needs for security then such a facility gives
you the chance to have multiple encrypted partions and systems such
as Split Linux which hids the actual OS from possibly interested
parties. On my Amiga I had 9 partitions and one was the backup
of the system and that was on a 4.3 GB hard drive. On my
Dell 6520 I had multiple OSes and partitions with my base
system having uefi, /boot, /, /var, /usr, /home and then for
the rest of the systems maybe 2 partions each and up to at
least 4 installs of various systems. That does not run like
a charm but shows up the problems of that method especially
with GRUB which each new install modifies. In addition those
extra partitions may be filled with the data for various uses.

For a lot of uses LiLo is adequate but no longer maintained
as far as I know. But for modern and future systems EFI is far
superior.

bliss - “Nearly any fool can use a Linux computer. Many do.” After all
here I am...

--
bliss dash SF 4 ever at dslextreme dot com

[Henrik Carlqvist]

On Wed, 24 Mar 2021 16:24:25 +0000, Scott Alfter wrote:

> On most systems, I usually keep /boot separate from the rest of the
> filesystem. It's a perfect candidate for merging with the EFI system
> partition. Kernel images will go in its root, while the bootloader will
> go in its EFI directory.

Some bootloaders like syslinux will require that also the kernel is
placed in the EFI system partition.

regards Henrik

[Henrik Carlqvist]

On Wed, 24 Mar 2021 10:12:10 +0100, David Brown wrote:

> On 23/03/2021 20:40, Henrik Carlqvist wrote:
>> On Tue, 23 Mar 2021 11:13:48 +0100, David Brown wrote:
>>> There is nothing that a UEFI BIOS can do that a traditional BIOS
>>> cannot,
>>
>> Yes it is. An UEFI BIOS is able to understand and modify contents on
>> file systems on the computer.
>
> First, let me repeat - there is nothing that the UEFI BIOS can do that
> another BIOS cannot. There is nothing hindering a non-UEFI BIOS being
> able to access files.

In theory no, but in practice a traditional BIOS has size limits. With
UEFI the BIOS got bloated and with this bloat came both problems from
complexity and insecurity by design.

> A Coreboot BIOS, for example, has as much of a
> Linux system as you choose to compile into it. It is not UEFI - it does
> not provide the UEFI-specified services, or need the UEFI partition.

Yes, I do not claim that UEFI is the only bloated BIOS. My intention was
to compare UEFI with traditional (legacy) BIOS made to boot a DOS
partition table with MBR.

> Secondly, a UEFI BIOS cannot access files except on a very simplistic
> and limited filesystem (fat32). It can't work with files on NTFS, ext4,
> btrfs, raid, or anything else.

This is true, but some operating systems will look for files on that
partition and run them.

> Traditional BIOSes have been able to block writes to boot sectors
> (previous to that, boot sector viruses were "popular". The only virus I
> have ever had on a computer was a boot sector virus).

Yes, but a boot sector virus could be removed by replacing the drive or
by simply overwriting the MBR. Malware which has gotten into your BIOS is
a lot harder to get rid of.

regards Henrik