Re: Automatically installing GRUB on multiple drives
Hi Nicolas, On Fri, Jan 26, 2024 at 08:49:06AM +0100, Nicolas George wrote: > Tim Woodall (12024-01-26): > > Until your UEFI bios writes to the disk before the system has booted. > > Hi. Have you ever observed an UEFI firmware doing that? Without explicit > admin instructions? Going back to my question from 2020 about what people do to provide redundancy for EFI System Partition, do I take it then that you have had no issues with just putting ESP in MD RAID-1? The "firmware may write to it" thing was raised as a concern by a few people,but always a theoretical one from what I could see. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Automatically installing GRUB on multiple drives
Andy Smith (12024-01-26): > Going back to my question from 2020 about what people do to provide > redundancy for EFI System Partition, do I take it then that you > have had no issues with just putting ESP in MD RAID-1? I have not had the occasion to test since two days ago when Thomas's remarks made me realize it was possible. > The "firmware may write to it" thing was raised as a concern by a > few people,but always a theoretical one from what I could see. Now that I think a little more, this concern is not only unconfirmed, it is rather absurd. The firmware would never write in parts of the drive that might contain data. At worst, it is possible to cover the RAID header with a dummy partition: label: gpt unit: sectors table-length: 24 sector-size: 512 first-lba: 8 1 : start=8, size=2040, type=---- 2 : start=2048, size=30712, type=lvm Regards, -- Nicolas George
Re: Automatically installing GRUB on multiple drives
Thomas Schmitt (12024-01-24): > The Debian installation and live ISOs have MBR partitions with only a > flimsy echo of GPT. There is a GPT header block and an entries array. > But it does not get announced by a Protective MBR. Rather they have two > partitions of which one is meant to be invisible to EFI ("Empty") and > one is advertised as EFI partition: > > $ /sbin/fdisk -l debian-12.2.0-amd64-netinst.iso > ... > Disklabel type: dos > ... > Device Boot Start End Sectors Size Id Type > debian-12.2.0-amd64-netinst.iso1 *0 1286143 1286144 628M 0 Empty > debian-12.2.0-amd64-netinst.iso2 4476 23451 18976 9.3M ef EFI > (FAT-12 > > So any system which boots this ISO from USB stick does not rely on > the presence of a valid GPT. You seem to be assuming that the system will first check sector 0 to parse the MBR and then, if the MBR declares a GPT sector try to use the GPT. I think it is the other way around on modern systems: it will first check sector 1 for a GPT header, and only if it fails check sector 0. Or not check sector 0 at all if legacy mode has been removed. > This layout was invented by Matthew J. Garrett for Fedora and is still > the most bootable of all possible weird ways to present boot stuff for > legacy BIOS and EFI on USB stick in the same image. I think I invented independently something similar. https://nsup.org/~george/comp/live_iso_usb/grub_hybrid.html Regards, -- Nicolas George
Re: Automatically installing GRUB on multiple drives
Hi, i hate to put in question the benefit of my proposal, but: Nicolas George wrote: > The firmware would never write in parts of the > drive that might contain data. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998 "cdrom: Installation media changes after booting it" Two occasions were shown in this bug where the EFI system partition of a Debian installation ISO on USB stick changed. One was caused by a Microsoft operating system, writing a file named WPSettings.dat. But the other was from Lenovo firmware writing /efi/Lenovo/BIOS/SelfHealing.fd . One may doubt that the success of these operations is desirable at all. The ISO was also tested with a not-anymore-writable DVD. In that case the Lenovo firmware did not raise protest over the fact that it was not possible to write to the EFI partition. Have a nice day :) Thomas
Re: Automatically installing GRUB on multiple drives
Hello, On Fri, Jan 26, 2024 at 10:09:53AM +0100, Nicolas George wrote: > Andy Smith (12024-01-26): > > The "firmware may write to it" thing was raised as a concern by a > > few people,but always a theoretical one from what I could see. > > Now that I think a little more, this concern is not only unconfirmed, > it is rather absurd. The firmware would never write in parts of the > drive that might contain data. I suppose my concern with that is that a firmware developer might feel justified in poking about in the ESP, which they might consider is there "for them". I have seen quite a few first hand reports of motherboard firmware that writes empty GPT when it sees a drive with no GPT, which I had previously considered unthinkable, so I do worry about trusting in the firmware developers. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Automatically installing GRUB on multiple drives
Hi, Nicolas George wrote: > You seem to be assuming that the system will first check sector 0 to > parse the MBR and then, if the MBR declares a GPT sector try to use the > GPT. That's what the UEFI specs prescribe. GPT is defined by UEFI-2.8 in chapter 5 "GUID Partition Table (GPT) Disk Layout". Especially: 5.2.3 Protective MBR For a bootable disk, a Protective MBR must be located at LBA 0 (i.e., the first logical block) of the disk if it is using the GPT disk layout. The Protective MBR precedes the GUID Partition Table Header to maintain compatibility with existing tools that do not understand GPT partition structures. > I think it is the other way around on modern systems: it will first > check sector 1 for a GPT header, and only if it fails check sector 0. Given the creativity of firmware programmers, this is not impossible. At least the programmers of older versions of OVMF took the presence of a GPT header as reason to boot, whereas without it did not boot. Meanwhile this demand for GPT debris has vanished and OVMF boots from media with only MBR partitions, too. I wrote: > > This layout [used by Debian installation ISOs] was invented by Matthew > > J. Garrett for Fedora > I think I invented independently something similar. > https://www.normalesup.org/~george/comp/live_iso_usb/grub_hybrid.html Not to forget Vladimir Serbinenko who specified how a grub-mkrescue ISO shall present its lures for BIOS and EFI on optical media and USB stick. The ISO has a pure GPT partition table, where the ISO filesystem is not mountable as partition but only by the base device (like /dev/sdc) or possibly by its HFS+ directory tree via the Apple Partition Map, if present. (To create such an ISO, install grub-common, grub-efi-amd64, grub-efi-ia32, and grub-pc. Then run grub-mkrescue with some dummy directory as payload. The ISO will boot to a GRUB prompt.) Have a nice day :) Thomas
Re: smartctl cannot access my storage, need syntax help
"Roy J. Tellason, Sr." writes: > On Thursday 25 January 2024 09:03:36 am Anssi Saari wrote: >> Western Digital at least claims to have solved the leaking >> problem with helium and since they've been making those drives for over >> a decade, I think it's solved. > > Your source for this? The internet, of course. WDs blog, Backblaze, a bunch of news sites, basically whatever Qwant coughed up. Why?
Re: Resizing LVM partitions
On 1/24/24 11:27 PM, Greg Wooledge wrote: On Wed, Jan 24, 2024 at 10:43:51PM +0100, Miroslav Skoric wrote: I do not have root account. Sure you do. You might not have a root *password* set. (I use sudo from my user account.) I think I already tried rescue mode in the past but was not prompted for root password. You can set a root password: sudo passwd root That should allow you to enter single-user mode, or to login directly as root on a text console, both of which are things that you may need to do as a system administrator. Especially if you're trying to unmount /home. Of course, sorry for my mixing terms. In fact I have never logged in directly as root so I thought the account was disabled or unusable. In any case, after setting a root password I did this: 1. Log-out as user (in GUI) 2. Ctrl-Alt-F2 3. Log-in as root (in CLI) 4. # lvreduce --size -50G --resizefs /dev/mapper/localhost-home Do you want to unmount "/home" ? [Y|n] y ... ... Size of logical volume localhost/home changed from 261.00 GiB (66816 extents) to 211.00 GiB (54016 extents). Logical volume localhost/home successfully resized. ... after reboot ... # df -h Filesystem Size Used Avail Use% Mounted on udev1.5G 0 1.5G 0% /dev tmpfs 297M 8.9M 288M 3% /run /dev/mapper/localhost-root 6.2G 4.7G 1.2G 81% / /dev/mapper/localhost-usr15G 11G 2.7G 80% /usr tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup /dev/sda1 228M 142M 74M 66% /boot /dev/mapper/localhost-home 208G 60G 138G 31% /home /dev/mapper/localhost-var 3.7G 2.0G 1.6G 57% /var /dev/mapper/localhost-tmp 2.3G 57K 2.2G 1% /tmp tmpfs 297M 32K 297M 1% /run/user/1000 # vgdisplay --- Volume group --- VG Name localhost System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 21 VG Access read/write VG Status resizable MAX LV0 Cur LV6 Open LV 6 Max PV0 Cur PV1 Act PV1 VG Size <297.85 GiB PE Size 4.00 MiB Total PE 76249 Alloc PE / Size 62346 / <243.54 GiB Free PE / Size 13903 / <54.31 GiB VG UUID fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM ... and then I extended /, /usr, and /var for 1GB each. Seems all ok. Thank you!
Re: Changing The PSI Definition
Greg Wooledge wrote: > On Thu, Jan 25, 2024 at 07:32:38PM -0500, Thomas George wrote: > > The current PSI works perfectly but I don't like the pale green prompt. > > > > Tried editing .bashrd , /ext/fprofile and /ext/bash.bashrc but no changes to > > the PSI definition had any effect > > You appear to be asking about the shell prompt. > > In bash, the shell prompt is defined in the PS1 variable, which stands > for "Prompt String One (1)". The last character is the numeral 1, not > the capital letter I. Might be time for a new font. I like Inconsolata, but l1I! should never look similar, nor O0@ or S$. In the kernel, PSI is pressure stall information, a way of looking at performance under load. -dsr-
Re: Changing The PSI Definition
On Fri, Jan 26, 2024 at 07:25:13AM -0500, Dan Ritter wrote: > Might be time for a new font. I like Inconsolata, but l1I! > should never look similar, nor O0@ or S$. Indeed. Also, ({[ and )}] are character groups that must be visibly different, or else any terminal or programming work you do is going to be a massive pain.
Re: Automatically installing GRUB on multiple drives
On Fri, 26 Jan 2024, Nicolas George wrote: Now that I think a little more, this concern is not only unconfirmed, it is rather absurd. The firmware would never write in parts of the drive that might contain data. UEFI understands the EFI system filesystem so it can "safely" write new files there. The danger then is that a write via mdadm corrupts the filesystem. I'm not sure if mdadm will detect the inconsistent data or assume both sources are the same. Hardware raid that the bios cannot subvert is obviously one solution.
Re: Automatically installing GRUB on multiple drives
On Fri, 26 Jan 2024, Tim Woodall wrote: On Fri, 26 Jan 2024, Nicolas George wrote: Now that I think a little more, this concern is not only unconfirmed, it is rather absurd. The firmware would never write in parts of the drive that might contain data. UEFI understands the EFI system filesystem so it can "safely" write new files there. The danger then is that a write via mdadm corrupts the filesystem. I'm not sure if mdadm will detect the inconsistent data or assume both sources are the same. Hardware raid that the bios cannot subvert is obviously one solution. https://stackoverflow.com/questions/32324109/can-i-write-on-my-local-filesystem-using-efi
Re: Automatically installing GRUB on multiple drives
On 1/26/24 08:19, Tim Woodall wrote: On Fri, 26 Jan 2024, Nicolas George wrote: Now that I think a little more, this concern is not only unconfirmed, it is rather absurd. The firmware would never write in parts of the drive that might contain data. UEFI understands the EFI system filesystem so it can "safely" write new files there. The danger then is that a write via mdadm corrupts the filesystem. I'm not sure if mdadm will detect the inconsistent data or assume both sources are the same. Hardware raid that the bios cannot subvert is obviously one solution. Is nearly the only solution, but it needs to have a hard specified format that guarantees 100% compatibility across all makers or they cannot use the word raid in their advertising. I am sick of proprietary makers doing a job that subverts the method with full intentions of locking the customer to only their product. Let there be competition based on the quality of their product. . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: in an object oriented world
John Hasler wrote: > songbird writes: >> every thing running on a computer should be able to say: > >> "I am [x version ...], these are my parents [y, z, 1, ...], i was >> compiled by program [...] from source code [...], here are my >> credentials [blah, blah]" > >> when sent a signal from GOD. > > Why should she believe it? because it only comes from GOD. no other process can send this signal. >> any process which does not respond should be thus cast into the outer >> darkness of the bits and never to return (aka a virus or unauthorized >> program). > > Malware can lie. A virus can infect an authorized program and use its > credentials. objects are only created by authorized calls to other objects so there is no pathway to infect if done correctly. if you do not allow random objects to be created that are not verified and vetted then there are no viruses. note, i'm just kicking this around and wondering if it really would be possible. songbird
Re: in an object oriented world
Songbird writes: > because it only comes from GOD. no other process can send this > signal. I meant why should GOD believe the reply? > objects are only created by authorized calls to other > objects so there is no pathway to infect if done correctly. > if you do not allow random objects to be created that > are not verified and vetted then there are no viruses. Then there is no need for your verification process. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: Automatically installing GRUB on multiple drives
Hello, On Fri, Jan 26, 2024 at 01:18:53PM +, Tim Woodall wrote: > Hardware raid that the bios cannot subvert is obviously one solution. These days the different trade-offs for HW RAID are IMHO worse. I left it behind in 2014 and don't intend to go back. 😀 Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: in an object oriented world
On Fri, Jan 26, 2024 at 07:56:35AM -0600, John Hasler wrote: > Songbird writes: > > because it only comes from GOD. no other process can send this > > signal. > > I meant why should GOD believe the reply? GOD doesn't believe. He KNOWS. Even without having to "send a signal". And now let's discuss whether Objects have any freedom, if GOD knows all in advance. I dimly remember that wars have been waged over that kind of question. But my memory is fuzzy... Cheers -- t signature.asc Description: PGP signature
Re: standardize uid:gid?
On Thu, Jan 18, 2024 at 07:31:05AM -0500, Greg Wooledge wrote: This is one of those "the boat has already left the dock" situations. If this were going to happen, it would have to have happened in the early 1990s. There is no feasible way to make it happen now. It's also a pointless endeavor, which is why it isn't a priority. In fact the trend is more toward ephemeral runtime allocation rather than hardcoding persistent IDs as more services/subsystems are designed to run in isolation. The motivation in this thread seems to simply be "I want to copy /etc/passwd around". Why? What is the actual goal, and what better (existing) mechanisms could achieve that goal?
Re: Automatically installing GRUB on multiple drives
Hello, On Fri, Jan 26, 2024 at 08:40:42AM -0500, gene heskett wrote: > On 1/26/24 08:19, Tim Woodall wrote: > > Hardware raid that the bios cannot subvert is obviously one solution. > > > Is nearly the only solution, If the problem to be solved is defined as redundancy for the ESP, there are a bunch of solutions as already discussed. All of them come with upsides and downsides. The downsides of hardware RAID for this, for me, are too big. > [hardware RAID] needs to have a hard specified format that > guarantees 100% compatibility across all makers If that happened, mdadm could support it, and then I would continue to use mdadm. In fact it already has happened, in that Intel came up with a standard for its "fake RAID" data layout and mdadm does support it already. But of course, none of the other vendors of hardware RAID took that on. https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/rst-linux-paper.pdf It has also been pointed out that there is no technical reason why EFI firmware can't support MD RAID, since MD is open source. But on the whole, we can't wait around for any of that to happen. > full intentions of locking the customer to only their product. There was a time when hardware RAID was really the only game in town, and the ability it gave to lock in the customer was just the cost of doing business. That time has passed, but I don't think the UEFI firmware developers are interested in helping out. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: rsync --delete vs rsync --delete-after
On Thu, 2024-01-18 at 13:26 +0100, Ralph Aichinger wrote: > Hello fellow Debian users, > > On Thu, 2024-01-18 at 12:18 +0100, hw wrote: > > > Always use an UPS. > > > Here I have a somewhat contrarian view, I hope not to offend too much: It's not offending, you merely have a different opinion. > For countries with stable electricity supplies (like Austria where I > live) having a small UPS might actually lead to more problems instead > of less, unless you are putting a lot of effort into it. Very often > have I had problems with UPSes, e.g. batteries dying, the UPS going > into some self test mode and inadvertedly shutting down, etc. I've never had issues with any UPS due to self tests. The batteries need to be replaced when they are worn out. How often that is required depends on the UPS and the conditions it is working in, usually every 3--5 years. I rather spend the money on new batteries (EUR 40 last time after 5 years) every couple years rather than spending thousands on replacing the hardware when a power surge damages it which could have been prevented by the UPS, and it's better to have the machines shut down properly rather taking risks with potential data loss, regardless of file systems and RAID setups in use. The hardware is usually extremely difficult --- and may be impossible --- to replace. On top of that, noone pays for the time and effort lost, and even someone did, I'd rather keep my hardware instead of going to all the lengths required to replace it. Loosing hours of work due to power outages can also be an issue, and nobody pays for that, either. > I've had no external power outage in the last 5 or 10 years, but a UPS > often needs at least one battery replacement during that time. Outages are (still) rare here, but it suffices to trigger a fuse or the main switch when some device shorts out, or someone working on the solar power systems some of the neighbours have, causing crazy voltage fluctuations, or a lightning strike somewhere in the vinicity or whatever reason for an UPS to be required. Way too many times than I could count my UPSs saved me and the hardware from power supply problems, so I can't recommend to go without one. It doesn't matter how stable you think the power grid in your country is. > [...] > Here I also doubt if this is a wise suggestion for the typical home > or small office user. RAID leads to lots and lots of complexity, that > is often not needed in a home setup. RAID isn't as complicated as you think. Hardware RAID is most simple, followed by btrfs, followed by mdadm. With hardware RAID I can instruct someone who has no idea what they're doing to replace a failed disk remotely. Same goes for btrfs and mdadm, though it better be someone who isn't entirely clueless. More importantly, the hassle involved in trying to recover from a failed disk is ridiculously enormous without RAID and can get expensive when hours of work were lost. With RAID, you don't even notice unless you keep an eye on it, and when a disk has failed, you simply order a replacement and plug it in. It's not like you could go to a hardware store around the corner and get a new disk same or next day. Even if you have a store around, they will need to order the disk, and that can, these days, take weeks or months or longer if it's a small store. The only way to get a replacement is ordering online, which requires that your computer still works and that you have access to your passwords. > I'd rather have a working backup setup with many independent copies > before I even start thinking about RAID. Yes, disks can fail, but > data loss often is due to user error and malware. That is simply wrong. RAID doesn't protect you from malware, and nothing protects you from user error. If you have data losses from malware and/or user error more often than from failed disks, you're doing something majorly wrong. > RAID helps very little with the latter two causes of data loss. And > all too often have I seen people mess up their complicated RAID > setups, because they pulled the wrong disk when another one broke, > or because they misinterpreted complicated error messages, creating > unnecessary data loss out of user error by themselves. This shows that you have no experience with RAID and is not an argument. Making backups is way more complicated than RAID. You can way more easily overwrite the wrong backup or misinterpret error messages of your backup solution than you can pull the wrong disk from a RAID or misinterpret error messages from your RAID. How exactly would you pull the wrong disk from a RAID and thus cause data loss? Before you pull one, you make a backup. When the disk has been pulled, its contents remain unchanged and when you put it back in, your data is still there --- plus you have the backup. Sure it can sometimes be difficult to tell which disk you need to replace, and it's not an issue because you can always figure out which one you need to replace.
Playing a sound when initrd wants a password
Hi. Yet another strange question. Is there a supported¹ way to have cryptsetup play a specific sound when it asks the password for the root partition from the initrd? I think brttty (braille) is already running at this point (no occasion to test yet), but a recognizable sound would be something nice to propose I think. Thanks. 1: No need to suggest I can hack the initrd to replace askpass by a script that plays the sound before running the real askpass, I already thought of it. I would like something robust, avoid hacks. -- Nicolas George
Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)
Hi, On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote: > I've never had issues with any UPS due to self tests. The batteries > need to be replaced when they are worn out. How often that is > required depends on the UPS and the conditions it is working in, > usually every 3--5 years. Out of interest what brand of UPS do you recommend for home use that has easily-replaceable batteries every 3–5 years? For a load of about 300W. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: standardize uid:gid?
On 26 Jan 2024 09:21 -0500, from mst...@debian.org (Michael Stone): > In fact > the trend is more toward ephemeral runtime allocation rather than hardcoding > persistent IDs as more services/subsystems are designed to run in isolation. Not only that, but also without persisting data to disk themselves. They might not be entirely stateless (for some, that's not even a reasonable aim; a completely stateless MTA would be of little use in practice, for example), but state persistence - and to some extent also configuration - is more and more often offloaded to, concentrated within and/or funneled through _another_ service. When there is nothing to persist to stable storage, persistent values for uid/gid becomes largely irrelevant precisely because everything can be (and often is) rebuilt from various images, whether binary executable or source code. All that remains is process isolation within the running operating system instance. I agree that this is a "solution in search of a problem" or x-y type of question. If you tell us about the _ultimate_ goal and maybe what software is involved, there's a good chance that someone can suggest an actual solution which works well in today's software ecosystem. Some reasonable suggestions have already been mentioned. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)
On Fri, 26 Jan 2024, Andy Smith wrote: > Hi, > > On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote: >> I've never had issues with any UPS due to self tests. The batteries >> need to be replaced when they are worn out. How often that is >> required depends on the UPS and the conditions it is working in, >> usually every 3--5 years. > > Out of interest what brand of UPS do you recommend for home use that > has easily-replaceable batteries every 3–5 years? For a load of > about 300W. just my experience i have 2 apc 740's that date from the mid 90's when the internal battery gave out i added a 50 amp anderson connector i connect to a 35ah sla you can change battteries while it's running
Re: Home UPS recommendations
On 26 Jan 2024 15:17 +, from a...@strugglers.net (Andy Smith): > Out of interest what brand of UPS do you recommend for home use that > has easily-replaceable batteries every 3–5 years? For a load of > about 300W. I would suggest to look at the free-standing floor-/tower-model APC _Back-UPS Pro_ series. They come in a variety of sizes, the battery is easily replacable (not sure if you can do it online, though; I've never had reason to look that up or try it) and they aren't horribly expensive to purchase (though in fairness not the cheapest). I have several and they have been very reliable. Battery replacement is basically flip it onto its side, remove a lid, slide the old battery out, put the new battery in, put the lid back, and done. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: rsync --delete vs rsync --delete-after
On Thu, 2024-01-18 at 13:09 +, Michael Kjörling wrote: > On 18 Jan 2024 13:26 +0100, from r...@h5.or.at (Ralph Aichinger): > > As a home/SOHO user, I'd rather have a working backup every few hours > > or every day than some RAID10 wonder > > Definitely agree that a solid backup regimen (including regular > automated backups; at least one off-site copy _at least_ of critical, > hot data; and planning for the contingency that you need to restore > that backup onto a brand new system without access to anything on your > current system -- think "home burns down at night" or "burglar" > scenario) is the _first_ step, and one that a great deal of people > still fail at. > > RAID is for uptime. It's also for saving you from the hassle involved with loosing data when a disk fails. > If a week-long outage (to get replacement hardware and restore the > most recent backup) and a day's worth of data loss is largely > inconsequential, as quite frankly it likely is for most home users > save for the cost of replacement hardware, that's a very different > scenario from if that same outage costs $$€€¥¥ and could destroy > your livelihood; and consequently the choices made _should_ likely > be different. That's assuming your time isn't worth anything and ignores whatever the loss of data may cost you. If that isn't relevant to you, you don't backups, either. > _Mirrored backups_ makes very little sense to me. If a storage device > used for storage of backups fails prematurely, just toss it and get a > new one and make a new backup. If the backup software goes haywire and > starts overwriting everything with random garbage, having the garbage > mirrored isn't going to help you. It's much better to have two > independent backup targets and switching between them, and figuring > the switching interval into your RPO. The only time when something > like mirrored backups will help you is when you have only one backup > set, the backup itself works fine, but a backup drive fails, _and_ the > source fails before you've been able to make a new backup. That's a > _very_ narrow scenario and easily solved by having two backup sets. Having multiple generations of backups already increases the needed storage space by a bit more than half. That makes it already arguable if it's better to make (multiple generations of) backups on a single RAID or on N single disks. Any of the disks can fail at any time. If you go with N == 2, a RAID (with multiple generations of backups on it) can be better because when a disk fails, the RAID will very likely survive and the non-RAID may not. So for daily use, I'd ideally make multiple generations on RAID and copy the latest generation to somewhere off-site, using either single disks, or another RAID. Having no hassle and no downtime at the production system and instead having hassle and downtime off-site may be much more desirable than having it the other way round. Trying to make things appear easier by pointing out that failed disks can be replaced is not helpful. Replacing a disk in a RAID isn't any more difficult (and can be much easier) than replacing a disk that isn't in a RAID.
Re: Automatically installing GRUB on multiple drives
On Wed, 2024-01-24 at 21:05 +0100, Nicolas George wrote: > [...] > GPT > ├─EFI > └─RAID > └─LVM (of course) > > Now, thanks to you, I know I can do: > > GPT > ┊ RAID > └───┤ > ├─EFI > └─LVM > > It is rather ugly to have the same device be both a RAID with its > superblock in the hole between GPT and first partition and the GPT in > the hole before the RAID superblock, but it serves its purpose: the EFI > partition is kept in sync over all devices. > > It still requires setting the non-volatile variables, though. How do you make the BIOS read the EFI partition when it's on mdadm RAID? It seems you have to have an EFI partition directly, outside sofware RAID, on each storage device, and that indeed raises the question how you keep them up to date so you can still boot when a disk has failed. It's a nasty problem. I use hardware RAID to avoid this problem ...
Re: Automatically installing GRUB on multiple drives
Hello, On Fri, Jan 26, 2024 at 04:50:00PM +0100, hw wrote: > How do you make the BIOS read the EFI partition when it's on mdadm > RAID? If MD superblock is at a part of device not used by filesystem (e.g. the end) and it is a RAID-1, each member device is indistinguishable from FAT filesystem without RAID for naive software in read-only mode. This is also how grub boots MD RAID-1 before Grub understood MD RAID. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Data and hardware protection measures; was: rsync --delete vs rsync --delete-after
On 26 Jan 2024 16:11 +0100, from h...@adminart.net (hw): > I rather spend the money on new batteries (EUR 40 last time after 5 > years) every couple years [...] > > The hardware is usually extremely difficult --- and may be impossible > --- to replace. And let's not forget that you can _plan_ to perform the battery replacement for whenever that is convenient. Which is quite the contrast to a lightning strike blowing out even _just_ the PSU and it needing replacement before you can even use the computer again (and you _hope_ that nothing more took a hit, which it probably did even if the computer _seems_ to be working fine). >> I've had no external power outage in the last 5 or 10 years, but a UPS >> often needs at least one battery replacement during that time. > > Outages are (still) rare here, but it suffices to trigger a fuse or > the main switch when some device shorts out, or someone working on the > solar power systems some of the neighbours have, causing crazy voltage > fluctuations, or a lightning strike somewhere in the vinicity or > whatever reason for an UPS to be required. It's also worth talking to your local electrician about installing an incoming-mains overvoltage protection for lightning protection. I won't quote prices because I had mine installed a good while ago and also did it together with some other electrical work, but I was surprised at how low the cost for that was, and I _know_ that it has saved me on at least one occasion. It won't do power conditioning or power loss protection of course, but it _does_ greatly increase the odds that your home wiring survives a lightning-related voltage surge. (Nothing will realistically protect you against a _direct_ lightning strike; in that case the very best you can hope for is damage containment.) > More importantly, the hassle involved in trying to recover from a > failed disk is ridiculously enormous without RAID and can get > expensive when hours of work were lost. With RAID, you don't even > notice unless you keep an eye on it, and when a disk has failed, you > simply order a replacement and plug it in. Indeed; the point of RAID is uptime. > You can always tell with a good hardware RAID because it > will indicate on the trays which disk has failed and the controller > tells you. Or you can label the physical disks. Whenever I replace a disk, I print a label with the WWN of the new disk and place it so that it is readable without removing any disks or cabling; then I use the WWN to identify the disk in software; in both cases because the WWN is a stable identifier that I can fully expect will never change throughout the disk's lifetime. So when the system tells me that wwn-0x123456789abcdef0 is having issues, I can quickly and accurately identify the exact physical device that needs replacement once I have a replacement on hand. And if the kernel logs are telling me that, say, sdg is having issues, I can map that back to whatever WWN happens to map to that identifier at that particular time. (In practice, I'm more likely to get useful error details through ZFS status monitoring tools, where I already use the WWN, so I likely won't need to go that somewhat circuitous route.) > Yes, my setup is far from ideal when it comes to backups in that I > should make backups more frequently. That doesn't mean I shouldn't > have good backups and that UPSs and RAID were not required. Or that, again, they solve different problems. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Automatically installing GRUB on multiple drives
hw (12024-01-26): > How do you make the BIOS read the EFI partition when it's on mdadm > RAID? I have not yet tested but my working hypothesis is that the firmware will just ignore the RAID and read the EFI partition: with the scheme I described, the GPT points to the EFI partition and the EFI partition just contains the data. Of course, it only works with RAID1, where the data on disk is the data in RAID. Regards, -- Nicolas George
Re: Home UPS recommendations
On Fri, 2024-01-26 at 15:37 +, Michael Kjörling wrote: > On 26 Jan 2024 15:17 +, from a...@strugglers.net (Andy Smith): > > Out of interest what brand of UPS do you recommend for home use that > > has easily-replaceable batteries every 3–5 years? For a load of > > about 300W. > > I would suggest to look at the free-standing floor-/tower-model APC > _Back-UPS Pro_ series. I have had a couple of those, never had any problems with them. Though replacement batteries cost more than half the price of a new UPS so I ended up just buying a a second UPS when the original batteries got rather feeble. (After 7 years). I've now stopped using it though because of the cost of the electricity it uses. It uses 18W when just sitting there ready for action, which worked out at 40GBP a year! -- Tixy
Re: Home UPS recommendations
I, too, have always used APC. I've heard people swear by APC, and I've heard people swear *at* APC. I've had reason to do both, myself (and I won't elaborate on either). -- James H. H. Lampert
Re: in an object oriented world
Hi, On Fri, Jan 26, 2024 at 8:46 AM songbird wrote: > > John Hasler wrote: > > songbird writes: > >> any process which does not respond should be thus cast into the outer > >> darkness of the bits and never to return (aka a virus or unauthorized > >> program). Q: is javascript sourced from who knows where on the Internet considered an unauthorized program? if no, have you heard of "malvertising"? > > Malware can lie. A virus can infect an authorized program and use its > > credentials. > > objects are only created by authorized calls to other > objects so there is no pathway to infect if done correctly. I hate it when someone blithely tosses off that "if done correctly" nonsense - ignoring the last 60+ years of computer history that shows people more often than not CANNOT actually "do it correctly." I came across this recently https://thephd.dev/c-undefined-behavior-and-the-sledgehammer-guideline TL,DR: undefined behavior yields incorrect behavior if (i >= 0 && i < sizeof(tab)) { printf("tab[%d] looks safe because %d is between [0:%d]\n", i, i, (int)sizeof(tab)); return tab[i]; } doesn't actually verify that i is always within limits. $ cat bad-behavior.c #include #include #include #include uint8_t tab[0x1ff + 1]; int safe = 0; uint8_t f(int32_t x) { if (x < 0) return 0; if ( safe ) { /* do a valid overflow check */ if ((INT32_MAX / 0x1ff) <= x) { printf("overflow prevented!\n"); return 0; } } int32_t i = x * 0x1ff / 0x; /* signed integer overflow yields undefined behavior */ if (i >= 0 && i < sizeof(tab)) { printf("tab[%d] looks safe because %d is between [0:%d]\n", i, i, (int)sizeof(tab)); return tab[i]; } return 1; } int main(int argc, char **argv) { (void)argc; memset(tab, 0, sizeof(tab)); if ( strcmp(argv[1], "safe") == 0 ) safe = 1; return f(atoi(argv[2])); } /* * https://thephd.dev/c-undefined-behavior-and-the-sledgehammer-guideline * * gcc -O2 -o bad.exe bad-behavior.c * ./bad unsafe 5000 * tab[62183] looks safe because 62183 is between [0;512] */ $ gcc -O2 -o bad.exe bad-behavior.c $ ./bad unsafe 5000 tab[62183] looks safe because 62183 is between [0:512] $ ./bad safe 5000 overflow prevented! > if you do not allow random objects to be created that > are not verified and vetted then there are no viruses. That sounds so very easy. Not so easy to do in practice, but it sure _sounds_ easy enough. > note, i'm just kicking this around and wondering if it > really would be possible. I'd vote for possible but improbable. Regards, Lee
Re: rsync --delete vs rsync --delete-after
On 26 Jan 2024 16:39 +0100, from h...@adminart.net (hw): >> RAID is for uptime. > > It's also for saving you from the hassle involved with loosing data > when a disk fails. Which translates to more quickly fully recovering from the loss of a storage device. When used for redundancy and staying within the redundancy threshold of your setup, _done right_, RAID reduces unplanned downtime to zero in case of loss of a storage device. Depending on your setup, the replacement can either be made online or planned for, and once complete, (hopefully) no data whatsoever has been lost and everything has happened at minimal time cost. I'm assuming that _the physical act_ of replacing the storage device is similar regardless of how it is configured in software: the same number of screws, clamps or similar need removing and reinstalling; the same amount of time is required to physically move the old and the new storage device; etc. >> If a week-long outage (to get replacement hardware and restore the >> most recent backup) and a day's worth of data loss is largely >> inconsequential, as quite frankly it likely is for most home users >> save for the cost of replacement hardware, that's a very different >> scenario from if that same outage costs $$€€¥¥ and could destroy >> your livelihood; and consequently the choices made _should_ likely >> be different. > > That's assuming your time isn't worth anything and ignores whatever > the loss of data may cost you. If that isn't relevant to you, you > don't backups, either. Sure, you can tune the RPO (recovery point objective) for your backup solution as needed. If you need a RPO of five minutes after catastrophic storage failure (meaning that you lose no more than five minutes of data regardless of when failure happens), then you're going to make different choices than if a 24-48 hour RPO is fine. But I'm willing to say that _most_ home users can recover from a loss of a day's worth of changes to their data without that being a major blow to whatever they are doing; and if the user does something important, nothing prevents running an extra backup to capture those changes. (I've done that myself on occasion.) Similarly, you are going to make different choices based on your RTO (recovery time objective). RAID gives you essentially zero RTO as long as you retain sufficient redundancy, but _not_ past that. Once your storage drops below whatever level of redundancy you have, you're looking at rebuilding from backups, at which point backup frequency and backup restoration time are the minimums which will dictate your RPO and RTO respectively. So even if you have RAID, you need to know what your target RPO and RTO are, respectively, because again those values are going to be a major factor in the design of your backup regimen. >> _Mirrored backups_ makes very little sense to me. [...] > > Having multiple generations of backups already increases the needed > storage space by a bit more than half. That makes it already arguable > if it's better to make (multiple generations of) backups on a single > RAID or on N single disks. Any of the disks can fail at any time. If > you go with N == 2, a RAID (with multiple generations of backups on > it) can be better because when a disk fails, the RAID will very likely > survive and the non-RAID may not. I'm not sure how you figure that. To survive the loss of N > 0 storage devices within a set, a storage solution needs to have a raw capacity greater than the usable capacity. An illustrative case would be a three-way mirror: it can survive the loss of two out of three storage devices, but only has the usable storage capacity of a single (typically the smallest) of the devices. It's not really any different from that a commodity HDD or SSD probably won't survive the failure of one of its platters or flash chips respectively, even ignoring cascade effects of either the failure or the cause of failure. How much extra storage space you need to keep multiple generations of backups is going to depend a lot on the rate of churn of your dataset. Again as an illustrative example only, suppose you have 1 TB of data and modify 1 MB per day, and make backups daily; with two devices each capable of storing 2 TB you can have two full copies plus 1M days' worth of history on each. This is irrespective of how those storage devices themselves are furnished. > Trying to make things appear easier by pointing out that failed disks > can be replaced is not helpful. It's a _backup_. _By definition_, a backup is only critical once the primary copy becomes inaccessible for some reason. Hence: >> The only time when something >> like mirrored backups will help you is when you have only one backup >> set, the backup itself works fine, but a backup drive fails, _and_ the >> source fails before you've been able to make a new backup. For a primary copy, _of course_ the calculus is different. -- Michael Kjörling 🔗 https://michael.kjorli
Re: Playing a sound when initrd wants a password
On 2024-01-26, Nicolas George wrote: > Hi. > > Yet another strange question. Is there a supported¹ way to have > cryptsetup play a specific sound when it asks the password for the root > partition from the initrd? > > I think brttty (braille) is already running at this point (no occasion > to test yet), but a recognizable sound would be something nice to > propose I think. > > Thanks. > > 1: No need to suggest I can hack the initrd to replace askpass by a > script that plays the sound before running the real askpass, I already > thought of it. I would like something robust, avoid hacks. > I guess a systemd timer unit constitutes a hack.
Re: Playing a sound when initrd wants a password
Curt (12024-01-26): > I guess a systemd timer unit constitutes a hack. A systemd timer in the initrd? Can you elaborate? -- Nicolas George
AW: AW: su su- sudo dont work
Sorry it was my mistake It is su - su or sudo. Sorry. Is su - the best for install? Regards Sophie Von: Hans Gesendet: Dienstag, 23. Januar 2024 18:29 An: debian-user@lists.debian.org Betreff: Re: AW: su su- sudo dont work Am Dienstag, 23. Januar 2024, 13:54:25 CET schrieb Schwibinger Michael: For gvetting root as normal user, best is use "su -". Note: It is not "su-", but "su -", with a space between su and the minus sign. Good luck! Hans > Thank You. > > 2 questions > 1 > Is the best to use su- > for ding install? > 2 > All 4 dont work. > What do I do wrong? > Regards > Sophie > >
Re: Playing a sound when initrd wants a password
On 2024-01-26, Nicolas George wrote: > Curt (12024-01-26): >> I guess a systemd timer unit constitutes a hack. > > A systemd timer in the initrd? Can you elaborate? > A play-sound.timer unit file in /usr/lib/systemd/system-generators/initrd directory. A play-sound.service file in the same directory (that plays the sound). Build and update the initrd image. Enable and start timer. Untried and untested and possibly erroneous.
Re: AW: AW: su su- sudo dont work
On Fri, Jan 26, 2024 at 04:23:07PM +, Schwibinger Michael wrote: > su - > su > or sudo. > > Is su - > the best for install? Whatever works best for *you* is best. "su -" is quite popular. If it does what you need, and is convenient for you, then there's your answer.
Re: Playing a sound when initrd wants a password
Curt (12024-01-26): > A play-sound.timer unit file in /usr/lib/systemd/system-generators/initrd > directory. I see no mention of this directory on the web. Where did yo find the idea of using it, I want to check the doc. And what should I put in the timer file to express “when a password is asked”? In fact, what relation do you see between a timer and cryptsetup asking for a password? -- Nicolas George
Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)
On Fri, 26 Jan 2024, Andy Smith wrote: Out of interest what brand of UPS do you recommend for home use that has easily-replaceable batteries every 3–5 years? For a load of about 300W. I currently have two Eaton Ellipse ECO 1600's. I change the batteries every 4-5 years, but this is not as easy as it should be. It is not evident that only one of the four back panel screws needs to be removed. I took me a while to learn this. The four screws are deeply recessed and difficult to see. They have different heads: some are Torx 10, others are a star. Keep trying different screwdrivers until you feel something turning. The battery compartment is too tight. I took me 4 attempts to get the batteries back in, with the cables still connected and positioned such that the rear panel can be put back. If you re-assemble and the UPS doesn't respond to pressing the ON/OFF button, then the battery leads have detached. Start all over again. Good luck! It could have been a lot easier. Roger
Re: AW: AW: su su- sudo dont work
Am Freitag, 26. Januar 2024, 17:23:07 CET schrieben Sie: Yes, if you want to install soemthing for example by using the apt command, best way is becoming root with the command "su -" and then install the rquired package. Example: su - then enter the password of the user root If installing for example firefox, first read the repository: apt update then install the package apt install firefox-esr - Hint: If you want a graphical method and you have no X and Wndow-Manager running (like KDE, Gnome, XFCE whatever), I suggest using aptitude. You have to install aptitude first: apt install aptitude Then you can start the gui with the command "aptitude" as root. Hint 2: aptitude is controlled by keypresses without any enter-key. For example, when started aptitude, just press the "u" key and it reads the update, "U" (Shift + u) marks all newer packages automatically to be updated, then press "g" and you will shwo, what it will do. Press "g" again, and it will do the update. Please note: If you want to upgrade the whole sytem, then using apt or apt-get will be the better choice! But aptitude is very well for installing single packages or weekly upgrades, where not much packages will be renewed. If you are not much experienced, and you have a window-manager running like KDE, Gnome, XFCE, LXDE or another one, then look at synaptic. Synaptic is a graphical tool for installing packages, it is a GUI for apt. Synaptic MUST run as root. Hope this helps. By the way: I believe, you are not very experienced in English language, so I suggest to suscribe in the fine German forum, which is debian-user-ger...@lists.debioan.org. Here is the link: https://lists.debian.org/debian-user-german/[1] Good luck! Hans > Sorry > it was my mistake > > It is > > su - > su > or sudo. > > Sorry. > > Is su - > the best for install? > > Regards > > Sophie > > > > [1] https://lists.debian.org/debian-user-german/
Re: Home UPS recommendations
Andy Smith composed on 2024-01-26 10:17 (UTC-0500): > On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote: >> I've never had issues with any UPS due to self tests. The batteries >> need to be replaced when they are worn out. How often that is >> required depends on the UPS and the conditions it is working in, >> usually every 3--5 years. > Out of interest what brand of UPS do you recommend for home use that > has easily-replaceable batteries every 3–5 years? For a load of > about 300W. Ambient temps have a huge effect on UPS battery life. Temps here are purposely above average, between 76F (winter) and 82F (summer), saving much electricity in cooling season, which here in Florida is long, among other reasons. Before I moved, I had 7 UPSes online at all times due to unconscionable frequency and length of power outages from the monopoly power provider. Since moving I'm down to 4. It was uncommon for replacement batteries to last more than 30 months, and common that they lasted less than 24 to as little as 18 or 20. OEM batteries usually managed up to 60. Those with plastic instead of metal cases have the advantage that swollen old batteries can usually be extracted successfully, while metal could necessitate such heroics as drill and saw to extricate. My favorite brands are Tripp-Lite and Eaton. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: Home UPS recommendations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Take a look at Tripp Lite: https://en.wikipedia.org/wiki/Tripp_Lite I used them for years to back up a small domain -- they make sine-wave electricity. -- Glenn English -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAnBYJltAY/CZCf14YxgqyMMhYhBCyicw9CUnAlY0ANl5/XhjGC rIwyAADRkQf9F15abScn8QtbHzaldounIDL5Enn70DWfqHynWyrwj2qx6dLb KjpGOHpwMa7DFrgxnQkYRT0LSQBjGggAtRHOvMxr+yc2azCDY8Btg/YUI21j U9uqM062bocANEl++AEuIWvIxE1u4TET8GbFMWOXYREJna3zZcSZjp7mCWQ3 auzRNW8VXVolBgj0BH0OApLRga3cIMt8nZ7C6PjYRAtjlzO4K0nUgPijcOp/ fHoSyFk+xN8GAFCZyQNJ6tYup/NkDehOfxdhDAUHijGoRsf+sbW9ixHeIuU3 0GfyxjPjuz/QqzSbGk73PVpss+6sSLye+nIltTZG9xOAdcwVs32fGA== =qBp5 -END PGP SIGNATURE-
Re: Playing a sound when initrd wants a password
On Fri 26 Jan 2024 at 16:13:26 (+0100), Nicolas George wrote: > Hi. > > Yet another strange question. Is there a supported¹ way to have > cryptsetup play a specific sound when it asks the password for the root > partition from the initrd? > > I think brttty (braille) is already running at this point (no occasion > to test yet), but a recognizable sound would be something nice to > propose I think. It looks as if the root directory is decrypted by /usr/share/initramfs-tools/scripts/local-top/cryptroot and, from its prereqs, that this script makes sure it is the last to run from scripts/local-top, by actually being run from scripts/local-block/cryptroot. (Correct me if I'm wrong: I'm a tyro in here.) I notice that there is a slew of empty directories in /etc/initramfs-tools/scripts/, and I can only assume that anything you drop into these gets merged with those in /usr/share/initramfs-tools/scripts/ when the initramfs is built. There is no scripts/local-block/ directory under /etc/, possibly because it's not intended that you interfere with the "ordering trick" mentioned above. So I would try dropping a logging/printing script into /etc/initramfs-tools/scripts/local-top/ in order to see whether it runs, and at the right time. The script could also look and see what support is already available for making noises. Cheers, David.
Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)
On Fri 26 Jan 2024 at 19:03:33 (+0100), Roger Price wrote: > I currently have two Eaton Ellipse ECO 1600's. I change the batteries > every 4-5 years, but this is not as easy as it should be. It is not > evident that only one of the four back panel screws needs to be > removed. I took me a while to learn this. The four screws are deeply > recessed and difficult to see. They have different heads: some are > Torx 10, others are a star. Keep trying different screwdrivers until > you feel something turning. 20/20 hindsight might suggest that you were only intended to remove the star, if by that you mean Philips/Pozidrive. Cheers, David.
Monospace fonts, Re: Changing The PSI Definition
On Fri 26 Jan 2024 at 07:25:13 (-0500), Dan Ritter wrote: > Greg Wooledge wrote: > > On Thu, Jan 25, 2024 at 07:32:38PM -0500, Thomas George wrote: > > > The current PSI works perfectly but I don't like the pale green prompt. > > > > > > Tried editing .bashrd , /ext/fprofile and /ext/bash.bashrc but no changes > > > to > > > the PSI definition had any effect > > > > You appear to be asking about the shell prompt. > > > > In bash, the shell prompt is defined in the PS1 variable, which stands > > for "Prompt String One (1)". The last character is the numeral 1, not > > the capital letter I. > > Might be time for a new font. I like Inconsolata, but l1I! > should never look similar, nor O0@ or S$. I'll give a shout-out for Hack,¹ which I can't fault for use in xterms. Comparingxterm -geometry 80x25+0+0 -fa hack -fs 16 with xterm -geometry 80x25+0+0 -fa inconsolata -fs 18 (to make the sizes roughly the same), I find the inconsolata stroke width on the basic Roman alphabet is a little spindly. Other criticisms are that the stroke widths (and even the size) later in the table (eg 0x256–1312) are thicker or larger, and many single-width characters are slightly oversize and get truncated at the top & right (eg Ŵ at 0x372, Lj 456). Mixing fractions is ugly, too: ½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞. The ‘’ quotes are pretty, though. Of course, these criticisms only apply to the implementation from fonts-inconsolata, rendered on xterms, as compared with fonts-hack. I don't know whether they arise because the font is a work in progress, and the implementation hasn't yet caught up: eg, the capitals with diacriticals look fine in the sample off the web at: https://levien.com/type/myfonts/textest.pdf ¹ I first saw Hack mentioned by Gene in May 2016, thanks. Cheers, David.
Re: Home UPS recommendations
ghe2001 wrote: > Take a look at Tripp Lite: > > https://en.wikipedia.org/wiki/Tripp_Lite > > I used them for years to back up a small domain -- they make > sine-wave electricity. One of the references in the wikipedia article looked interesting: https://www.computerworld.com/article/2472189/a-surge-protector-that-doesn-t-protect.html