Re: Home UPS recommendations (Was Re: rsync --delete vs rsync--delete-after)
On 1/28/24 13:55, Andy Smith wrote: Hi, Thanks, this is very useful. On Sun, Jan 28, 2024 at 06:58:08PM +0100, hw wrote: However, stay away from their cheap models as seen on this[1] picture (Back UPS). They work and you can replace the batteries yourself even though you're not supposed to. It's a minimum basic device. It may be on ok option if you're on a budget. Their batteries last about 3 years. So, I must admit, I am quite tempted by BX1600MI which would cost me about £183. The equivalent spec in the Pro range is more than twice this price. Although the battery is not strictly user-replaceable, I watched some videos on the task and it seems pretty easily doable. Something for me to think on. Thanks, Andy I'm a fan of APC, but the consumer versions. and I don't worry about batteries until they won't last the 6 or 7 seconds it takes to spin up the 20kw kohler in the back yard. My now deceased wife was on an oxy concentrator the last 15 years of her life, and a power failure of 20 minutes might have finished her, so I bought a standby just a few months before the direcho that took power down for 3 days in June 2010. Very handy since. I have an APC-1600 that been begging for a battery for a couple years, Still works fine for those few seconds. Take care, stay well, Andy. Cheers, Gene Heskett, CET -- "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: File has unexpected size (x != y). Mirror sync in progress? [IP: ...] ...
On Sat 27 Jan 2024 at 14:50:25 (+), Albretch Mueller wrote: > On 1/19/24, David Wright wrote: > > On Fri 19 Jan 2024 at 22:19:21 (+), Albretch Mueller wrote: > >> Package dependencies to me are just DAGs, > > Are they? No circular dependencies? > > The way I see them, "circular dependencies" are "cultural". > "organizational" issues not essentially technical ones. circular > dependencies happen in packages which should be part of the same node. > Show me examples in which it is not the case. To save time, I just used the list's search, and found a reference to presumably the wheezy Packages file: Package: openjdk-6-jre-headless Version: 6b38-1.13.10-1~deb7u1 Depends: openjdk-6-jre-lib (= 6b38-1.13.10-1~deb7u1), [ … ] Package: openjdk-6-jre-lib Version: 6b38-1.13.10-1~deb7u1 Depends: openjdk-6-jre-headless (>= 6b27) I guess that example gives you something cultural or organisational to chew on? > >> [ … ] I haven’t found a book yet, explaining it all. > >> At times I have found great explanations about single aspects. > > What sales figures would you expect to see with such a book? > > ... and since that sounds to me like ransom money aren't you the one > who would determine the amount yourself? I haven't a clue what you're rambling on about. Ransom money? You originally wrote: > >> [ … ] So, to start I would > >> like to study the Debian packages and how dpkg establishes and keeps > >> those dependencies. What happens on the hire and on the repositories > >> with certificates ... I haven’t found a book yet, explaining it all. > >> At times I have found great explanations about single aspects. For there to be a book on the subject, someone has to invest the time and effort to write it, and persuade others to proofread and publish it. But who's this book for—a whole book … on Debian's APT and dpkg? Perhaps after you've studied your issues long enough, though, you might write one. Cheers, David.
Re: smartctl cannot access my storage, need syntax help
On Thu 25 Jan 2024 at 12:24:21 (-0500), Roy J. Tellason, Sr. wrote: > On Thursday 25 January 2024 09:03:36 am Anssi Saari wrote: > > On Tue 23 Jan 2024 at 06:32:54 (-0500), gene heskett wrote: > > > On 1/23/24 06:12, Gremlin wrote: > > > > On 1/23/24 06:04, gene heskett wrote: > > > > > On 1/23/24 00:30, Karl Vogel wrote: > > > > > > > > On 1/22/24 11:31, gene heskett wrote: > > > > > > > > > > > > G> How does an 8T backup server sound for another $200 in hdwe? > > > > > > Very > > > > > > G> enticing and I do have the sheckel's. > > > > > > > > > > > > https://www.amazon.com/dp/B07CQJBSQL > > > > > > Seagate Desktop 8TB external Hard Drive, 3.5 Inch, USB 3.0 > > > > > > STGY8000400 > > > > > > $168.18 > > > > > > > > > > > > What if you buy two, use one for a complete backup and the other for > > > > > > incrementals or differentials? (I know, more than $200...) > > > > > > > > > > > My disastrous experience with the last pair of seagates > > > > > preclude exploring that path, ever again. I bought a couple > > > > > 2T's to replace 2 1T's I had outgrown and had close to 70,000 > > > > > spining hours on the. They lasted a bit less than 30 days, > > > > > dropping off the sata cables connecting then, never to be > > > > > found again. Then I find they were shingled tech, and helium > > > > > filled so the heads flew lower. So the helium made the disks "drop off" the SATA cables? How does that work? > > > > https://www.howtogeek.com/803276/cmr-vs.-smr-hard-drives-whats-the-difference/ > > > > > > I carefully note, the use of Helium and its problems is very carefully > > > ignored. What's the connection between shingled disks and helium? > > 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. When were these leakage incidents? I haven't heard about them; only Gene's wartime anecdotes about helium passing through inch-thick walls of Monel with impunity. > Your source for this? Indeed, for any of this. As for facts from the internet, I read this on one page selected at random — well, a top google hit: https://recoverysquad.com.au/what-are-the-advantages-of-helium-sealed-hard-drives/ "Helium HDDs as compared to standard HDDs Helium HDDs offer several advantages over traditional hard drives, including: [ … ] · Their lower power consumption translates into longer battery life for portable devices. ↑↑↑ · And lastly, they generate less heat, which can be an issue with traditional HDDs. ↑↑ [ … ] What are the challenges with Helium Hard Drives? The challenges with helium hard drives are that they are expensive to produce and they have a limited lifespan. The drives tend to run a bit hotter than traditional hard drives, and they also use more power." ↑↑ WTF? Cheers, David.
Re: Stop packagekitd from downloading updates
On 29/01/2024 04:24, Greg Wooledge wrote: On Sun, Jan 28, 2024 at 03:57:30PM -0500, Stefan Monnier wrote: systemctl mask packagekit I don't think you're looking at the right thing. "packagekit" seems to be an interface to dbus. By itself, it doesn't do what you think it does. Perhaps there are other hacks like "equivs" to formally satisfy dependencies. In my point of view, dbus-daemon has no flexible ways to override configuration like ones available in systemd (/lib, /etc, /run). Maybe I did something wrong, but an attempt to hide an installed service failed. I tried to put a /dev/null symlink in /usr/local/share/dbus-1/services. So "systemctl mask" may be the only way to prevent D-Bus activated service start. The disadvantage is noise in logs.
Re: Playing a sound when initrd wants a password
On 28/01/2024 00:07, Curt wrote: (Anyway, this is what my personal robot explained to me and may be subject to imperfection and error.) I find it over-sophisticated and, being put after the recipe, extremely unfriendly to those who get it in search engine results. Unfortunately bootup(7) is really complicated. Anyway, the world has changed.
Re: Stop packagekitd from downloading updates
Hello, On Sun, Jan 28, 2024 at 04:42:18PM -0500, Greg Wooledge wrote: > On Sun, Jan 28, 2024 at 04:31:02PM -0500, Stefan Monnier wrote: > > I self-inflicted this by installing [unattended-upgrades] so many years ago? > > It's a dependency of some/most(?) desktop environments, I think. I > doubt you installed it by name and forgot. I do not have it installed on my recently-install Debian 12 / GNOME desktop. I do have packagekit though, which includes this config file: $ cat /etc/apt/apt.conf.d/20packagekit // THIS FILE IS USED TO INFORM PACKAGEKIT THAT THE UPDATE-INFO MIGHT HAVE CHANGED // Whenever dpkg is called we might have different updates // i.e. if an user removes a package that had an update DPkg::Post-Invoke { "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; }; // When APT's cache is updated (i.e. apt-cache update) APT::Update::Post-Invoke-Success { "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; }; So I think probably that unattended-upgrades is downloading Stefan's packages and then poking packagekit over DBUS to make the GNOME tell Stefan about it. Which also explains the warning when packagekit is disabled. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Automatically installing GRUB on multiple drives
Hello, On Sun, Jan 28, 2024 at 09:09:17PM +0100, hw wrote: > On Sun, 2024-01-28 at 17:32 +, Andy Smith wrote: > > If someone DOES want a script option that solves that problem, a > > couple of actual working scripts were supplied in the link I gave to > > the earlier thread: > > > > https://lists.debian.org/debian-user/2020/11/msg00455.html > > https://lists.debian.org/debian-user/2020/11/msg00458.html > > Huh? Isn't it simpler to use mdraid RAID1 to keep the UEFI partitions > in sync without extra scripts needed? Could you read the first link above. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Automatically installing GRUB on multiple drives
Hello, On Sun, Jan 28, 2024 at 09:03:50PM +0100, hw wrote: > Show me any installer for Linux distributions that handles this > sufficently without further ado. That was the question I posed several posts back: what do people do for redundant ESP. > When you don't use btrfs, you have either hardware RAID or > mdraid. …or zfs or bcachefs or no redundancy at all… > With mdadm RAID, it isn't much better than with btrfs since > without further ado, you still don't have redundant UEFI > partitions. As mentioned, people do try it, and we don't yet have any reports of catastrophe. I'm not sure I am brave enough though. > With btrfs and mdadm RAID, it's basically worse because you have > to deploy another variant of software RAID in addition to the > software built into btrfs. I see, so this is basically a philosophical objection. You already have software that provides redundancy (btrfs), but since UEFI firmware can't read it and insists that ESP be vfat, it would mean providing redundancy another way. This need to have two means of redundancy is an affront to you. In practical terms, having md driver just for a small ESP array is not going to be a big deal, but just the idea of configuring this extra form of redundancy, having that extra driver loaded etc., is unpleasant. > So at least for boot disks, I'll go for hardware RAID whenever > possible, especially with btrfs, until this problem is fixed. Or do > you have a better option? Right, so your answer is hardware RAID. If you're happy with that, that's great, but I've left hardware RAID behind nearly ten years ago and this issue isn't enough for me to welcome it back. Though it leaves a bad taste, I still would rather go with either syncing ESPs by script or putting ESP in MD RAID and hoping firmware never write to it. I just wondered if there were more options (yet). Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Stop packagekitd from downloading updates
Am So, Jan 28, 2024 at 16:31:02 -0500 schrieb Stefan Monnier: the thing you don't want done. Is "unattended-upgrades" installed by any chance? Hmm yep, it is! So that's it? Well, you can look in /var/log/unattended-upgrades/ for the log files. „dpkg-reconfigure unattended-upgrades” will tell you if the package is configured to do its jobs. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Stop packagekitd from downloading updates
On Sun, Jan 28, 2024 at 04:31:02PM -0500, Stefan Monnier wrote: > > There is probably some other package that's *using* packagekit to do > > the thing you don't want done. Is "unattended-upgrades" installed by > > any chance? > > Hmm yep, it is! > So that's it? > I self-inflicted this by installing this package so many years ago? It's a dependency of some/most(?) desktop environments, I think. I doubt you installed it by name and forgot.
Re: Stop packagekitd from downloading updates
> I don't think you're looking at the right thing. "packagekit" seems > to be an interface to dbus. By itself, it doesn't do what you think > it does. Aha! > There is probably some other package that's *using* packagekit to do > the thing you don't want done. Is "unattended-upgrades" installed by > any chance? Hmm yep, it is! So that's it? I self-inflicted this by installing this package so many years ago? Thanks, Stefan
Re: Stop packagekitd from downloading updates
On Sun, Jan 28, 2024 at 03:57:30PM -0500, Stefan Monnier wrote: > >> How can I stop those downloads? > >> > >> Currently, I did > >> > >> systemctl mask packagekit I don't think you're looking at the right thing. "packagekit" seems to be an interface to dbus. By itself, it doesn't do what you think it does. There is probably some other package that's *using* packagekit to do the thing you don't want done. Is "unattended-upgrades" installed by any chance?
Re: Stop packagekitd from downloading updates
>> How can I stop those downloads? >> >> Currently, I did >> >> systemctl mask packagekit > > Well, you might just get rid of the package. > > apt purge packagekit > > should do it. Of course, but that also gets rid of packages I do want to keep (such as the `gnome` metapackage). > To prevent it from starting on the next boot: > > systemctl disable packagekit > > You may have to unmask it first. This doesn't work: # systemctl disable packagekit The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=, Also=, or Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled or disabled using systemctl. Possible reasons for having these kinds of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/, .requires/, or .upholds/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified. # which is why I masked it instead. In any case, I'd rather find a way to say precisely what I mean (i.e. "don't download updates in the background") than to have to chase down the daemon of the day used to perform those automatic downloads (I remember going through the same charade a few years back, before `packagekit` existed). Especially since I don't know what else `packagekit` might be doing (some of it might be things I do appreciate). Also, maybe the downloads are not initiated by `packagekit` but by some other system (which just happens to delegate the task to `packagekit`), and that other system may end up deciding to do the same downloads some other way if `packagekit` isn't available. Stefan
Re: Data and hardware protection measures
Michael Kjörling composed on 2024-01-28 19:23 (UTC): > On 28 Jan 2024 19:19 +0100, from h...@adminart.net (hw): >> On Fri, 2024-01-26 at 15:56 +, Michael Kjörling wrote: >>> It's also worth talking to your local electrician about installing an >>> incoming-mains overvoltage protection for lightning protection. >> Hm I thought it's expensive. > So did I until I actually asked someone who could give me a quote for > actually installing it. Old construction used meter "boxes" that don't support accessories like those. My utility won't touch mine unless I pay an electrician for an expensive full service upgrade. -- 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: mv bug - cannot move to subdirecctory of itself.
On 1/28/24 03:44, Brett Sutton wrote: So I'm not certain if I'm in the right spot but I had to start somewhere. I have a docker container that was working but has suddenly stopped working. I believe the possible cause was when I added a second drive to my zfs rpool - the timing was a little too coincidental. Please post: # zpool status rpool The docker command sequence I'm running is: RUN wget https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-1.3.2-linux-x86-64.tar.gz -O /tmp/webp/webp.tar.gz RUN tar -xvf /tmp/webp/webp.tar.gz --directory /tmp/webp/unzipped RUN mv /tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp /usr/bin/cwebp ``` which results in the error: ``` mv: cannot move '/tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp' to a subdirectory of itself, '/usr/bin/cwebp' The command '/bin/sh -c mv /tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp /usr/bin/cwebp' returned a non-zero code: 1 What happens if you run the mv(1) command by hand? # mv /tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp /usr/bin/cwebp The reason I'm here is because of this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923420 Have you implemented and run a test case to determine if your ZFS supports "renameat2 RENAME_NOREPLACE flag"? David
Re: Automatically installing GRUB on multiple drives
On Sun, 2024-01-28 at 17:32 +, Andy Smith wrote: > Hi, > > Keeping all this context because I don't actually see how the > response matches the context and so I might have missed something… > > On Sun, Jan 28, 2024 at 11:54:05AM -0500, Dan Ritter wrote: > > hw wrote: > > > How is btrfs going to deal with this problem when using RAID? Require > > > hardware RAID? > > > > > > Having to add mdadm RAID to a setup that uses btrfs just to keep efi > > > partitions in sync would suck. > > > > You can add hooks to update-initramfs or update-grub. > > > > To a first approximation: > > > > firstbootpart = wwn-0x5006942feedbee1-part1 > > extrabootparts = wwn-0x5004269deafbead-part1\ > > wwn-0x5001234adefabe-part1 \ > > wwn-0x5005432faebeeda-part1 > > > > for eachpart in $extrabootparts ; \ > > do cp /dev/disk/by-id/$firstbootpart /dev/disk/by-id/$eachpart; done > > I realise that the above is pseudocode, but I have some issues with > it, namely: > > a) I don't see what this has to do with btrfs, the subject of the >message you are replying to. Then again, I also did not see what >btrfs had to do with the thing that IT was replying to, so >possibly I am very confused. > > b) My best interpretation of your message is that it solves the "how >to keep ESPs in sync" question, but if it is intended to do that >then you may as well have just said "just keep the ESPs in sync", >because what you wrote is literally something like: > >cp /dev/disk/by-id/wwn-0x5002538d425560a4-part1 > /dev/disk/by-id/wwn-0x5002538d425560b5-part1 > >which …is rather like a "now draw the rest of the owl" sort of >response given that it doesn't literally work and most of the job >is in reworking that line of pseudocode into something that will >actually work. > > If someone DOES want a script option that solves that problem, a > couple of actual working scripts were supplied in the link I gave to > the earlier thread: > > https://lists.debian.org/debian-user/2020/11/msg00455.html > https://lists.debian.org/debian-user/2020/11/msg00458.html Huh? Isn't it simpler to use mdraid RAID1 to keep the UEFI partitions in sync without extra scripts needed? (I don't like that option, but it seems like an option when you have no hardware RAID.)
Re: Stop packagekitd from downloading updates
On Sun, 28 Jan 2024 14:10:46 -0500 Stefan Monnier wrote: > How can I stop those downloads? > > Currently, I did > > systemctl mask packagekit Well, you might just get rid of the package. apt purge packagekit should do it. Less drastic, to simply shut down the current daemon, systemctl stop packagekit To prevent it from starting on the next boot: systemctl disable packagekit You may have to unmask it first. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Automatically installing GRUB on multiple drives
On Sun, 2024-01-28 at 16:46 +, Andy Smith wrote: > Hi, > > On Sun, Jan 28, 2024 at 05:17:14PM +0100, hw wrote: > > Ok if Andy and you are right, you could reasonably boot machines with > > an UEFI BIOS when using mdadm RAID :) > > I've been doing it for more than two decades, though not with UEFI. > > > How is btrfs going to deal with this problem when using RAID? Require > > hardware RAID? > > > > Having to add mdadm RAID to a setup that uses btrfs just to keep efi > > partitions in sync would suck. > > ESP have to be vfat so why are you bringing up btrfs? > > If you want to use btrfs, use btrfs. UEFI firmware isn't going to > care as long as your ESP is not inside that. It's easy to boot from btrfs software RAID without further ado. These nasty and annoying UEFI partitions get in the way of that since they are not kept in sync with each other when you have several without further ado. That easily leads to situations in which you can't boot after a disk has failed despite you have RAID. That is something that must not happen; it defeats the RAID. It's bad enough when you have access to the machine and it's a total nightmare when not because you'll have to somehow go there to fix this. If the disk having the UEFI partition has failed and there's no redundance that's at least sufficently in sync, it's even worse. Show me any installer for Linux distributions that handles this sufficently without further ado. When you don't use btrfs, you have either hardware RAID or mdraid. With harware RAID, the problem doesn't come up. With mdadm RAID, it isn't much better than with btrfs since without further ado, you still don't have redundant UEFI partitions. With btrfs and mdadm RAID, it's basically worse because you have to deploy another variant of software RAID in addition to the software built into btrfs. So at least for boot disks, I'll go for hardware RAID whenever possible, especially with btrfs, until this problem is fixed. Or do you have a better option?
Re: Data and hardware protection measures; was: rsync --delete vs rsync --delete-after
On Sun, 28 Jan 2024 19:19:55 +0100 hw wrote: Hello hw, >How do you know in advance when the battery will have failed? Even my very basic UPS (APC Backup 1400) has a light on the front labelled "Replace Battery". That, combined with a very annoying high pitch scream, are pretty good motivators to do the job. I know the Backup 1400 was mentioned in this thread as "probably avoid" (or something similar), but it's served me well thus far. Had to replace the battery pack only once. That was after ten years, not the three to five that people have been talking about. APC no longer sell that model, but battery packs are still available. Just as an FYI, the battery packs are sealed Lead-Acid. Where I live (UK), it's possible to sell lead-acid batteries to scrap merchants. Amount paid is variable and subject to massive market forces that are best described as 'volatile'. Like others have mentioned with some of the more basic APC devices, this particular model isn't designed with user replaceable batteries in mind, but it's not an overly difficult task. It can't easily (if at all) be done leaving connected devices powered up, though. -- Regards _ "Valid sig separator is {dash}{dash}{space}" / ) "The blindingly obvious is never immediately apparent" / _)rad "Is it only me that has a working delete key?" They take away our freedom in the name of liberty Suspect Device - Stiff Little Fingers pgpqAXSSxvoLF.pgp Description: OpenPGP digital signature
Re: Data and hardware protection measures
On 28 Jan 2024 19:19 +0100, from h...@adminart.net (hw): > On Fri, 2024-01-26 at 15:56 +, Michael Kjörling wrote: >> 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 [...] > > To comment myself, I think was 3 years, not 5, sorry. > >>> 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. > > How do you know in advance when the battery will have failed? You replace the battery before it fails completely. Most batteries don't go from perfectly fine to completely dead within one charge cycle. If the battery drains completely during a power outage before the UPS has a chance to respond to the battery's loss of capacity, that becomes a (hopefully clean) power cut, which _still_ is _a lot_ better than equipment which isn't designed to deal with a significant overvoltage condition taking the brunt of a lightning strike. I'm assuming, of course, that you replace the battery with one of the same chemistry. The UPS will probably assume some discharge characteristic depending on what battery type the OEM uses (lead acid, NiCd, NiMH, LiIon, ...); of course if you give the UPS a battery using some other chemistry, that'll immediately wreak havoc with lots of things. >> 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). > > It would also hit the display(s), the switches and through that > everything that's connected to the network, the server(s) ... That > adds up to a lot of money. Which is why I said "even _just_ the PSU", emphasis original. >> It's also worth talking to your local electrician about installing an >> incoming-mains overvoltage protection for lightning protection. > > Hm I thought it's expensive. So did I until I actually asked someone who could give me a quote for actually installing it. > That doesn't exactly help when the failed disk has disappeared > altogether, as if it had been removed ;) If that happens, I'd get output along the lines of: # zpool status pool: tank state: DEGRADED scan: scrub repaired B in with errors on config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2-0ONLINE 0 0 0 wwn-0x0001-crypt ONLINE 0 0 0 8446744073709551616 UNAVAIL 0 0 0 was /dev/mapper/wwn-0x1113-crypt wwn-0x2225-crypt ONLINE 0 0 0 wwn-0x3337-crypt ONLINE 0 0 0 wwn-0x4449-crypt ONLINE 0 0 0 wwn-0x555b-crypt ONLINE 0 0 0 clearly identifying the problem. And also most likely a lot of event notifications telling me that wwn-0x1113-crypt is having issues within the "tank" pool, plus any applicable kernel logs for the device disconnection and perhaps lower-level I/O errors. Similarly, if a storage device suddenly starts returning garbage, that will show up likely as CKSUM errors and the device will eventually get kicked out of the pool, showing as state FAILED with large error counter values. (zpool status would also provide some more explanatory details, in the example above including that "applications are unaffected" because sufficient redundancy would still exist; but I'm eliding those here because I don't have them handy and don't feel like creating such a situation just to get example output. The important part is that the disk that dropped off the bus will show as likely UNAVAIL with its internal identifier and a reference to its WWN because of my naming scheme, instead of as completely missing. Solution is to get a replacement disk, plug it in, execute "sudo zpool replace tank $numeric_id $new_device_path", and wait a while, all the while I can still use the system normally.) No matter what kind of storage solution you're using - hardware RAID, software RAID, no redundancy, whichever - or how you're doing backups (assuming that you are, for some value of "you"), you can't just ignore issues with it. That way lies data loss. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Stop packagekitd from downloading updates
Apparently, there's now a thing called `packagekit` whose daemon seems to like to download updates "in the background" for me. Thanks, but no, thanks. This tends to occur at inopportune times for me and it's not far enough "in the background", so it gets in the way (furthermore, I like to download my packages with `debdelta` and `packagekitd` doesn't know how to do that, AFAICT). How can I stop those downloads? Currently, I did systemctl mask packagekit which might get the job done, but I don't really know what other impact it might have, and I see that APT complains about it (tho it still works fine, as far as I can tell): # LANG=C apt update Hit:1 http://deb.debian.org/debian stable InRelease Hit:2 http://security.debian.org stable-security InRelease Hit:3 http://security.debian.org testing-security InRelease Hit:4 http://deb.debian.org/debian testing InRelease Hit:5 http://deb.debian.org/debian unstable InRelease Error: GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit packagekit.service is masked. Reading package lists... Done Building dependency tree... Done Reading state information... Done All packages are up to date. # Where can I say specifically that I don't want automatic background download of updates? Stefan
Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)
Hi, Thanks, this is very useful. On Sun, Jan 28, 2024 at 06:58:08PM +0100, hw wrote: > However, stay away from their cheap models as seen on this[1] picture > (Back UPS). They work and you can replace the batteries yourself even > though you're not supposed to. It's a minimum basic device. It may > be on ok option if you're on a budget. Their batteries last about 3 > years. So, I must admit, I am quite tempted by BX1600MI which would cost me about £183. The equivalent spec in the Pro range is more than twice this price. Although the battery is not strictly user-replaceable, I watched some videos on the task and it seems pretty easily doable. Something for me to think on. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Playing a sound when initrd wants a password
[ Sorry, didn't read the actual post, just answering the Subject: ] What makes you think initrd will be satisfied with a sound? Stefan 🙂
Re: Data and hardware protection measures; was: rsync --delete vs rsync --delete-after
On Fri, 2024-01-26 at 15:56 +, Michael Kjörling wrote: > 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 [...] To comment myself, I think was 3 years, not 5, sorry. > > 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. How do you know in advance when the battery will have failed? > 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). It would also hit the display(s), the switches and through that everything that's connected to the network, the server(s) ... That adds up to a lot of money. > [...] > 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. Hm I thought it's expensive. I'll ask when I get a chance. > [...] > > 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; That doesn't exactly help when the failed disk has disappeared altogether, as if it had been removed ;) But then, you can go by the numbers of the disks you can still see. And beware of SSDs; when they fail, they're usually entirely inaccessible whereas you may be still able to resuce (some) data from a spinning disk after it failed. It's probably really bad with mainbaords that use M2 storage since apparently, they seem to support only one (of the some type at least) rather than two. So you can't use those at all. What's the point of that? ZFS cache maybe?
Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)
On Fri, 2024-01-26 at 15:17 +, 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. Generally I recommend APC because they work well (which is something to be expected and shouldn't need to be pointed out), they can easily be monitored with apcupsd and, very importantly, their batteries are usually easily available so you can replace them without difficulty. However, stay away from their cheap models as seen on this[1] picture (Back UPS). They work and you can replace the batteries yourself even though you're not supposed to. It's a minimum basic device. It may be on ok option if you're on a budget. Their batteries last about 3 years. I like the better models way better, like as on that[2] picture (Back UPS pro). I bought one a bit over 10 years ago (it even came with a 120k or so warranty for when a device protected by it would get damaged) and replaced the batteries twice so far. It's been working without any issues ever since, and it'll probably work as long as new batteries remain available. So that's about 3 years battery life as well. Then it depends on a lot of things, primarily on the availability of replacement batteries, then on how much you're willing to spend --- since you can buy used ones because the only thing that goes bad is the batteries, and you can find new old stock --- how much power you need, if you want one that features a network card and if you want a 19" rack version or a standalone version. Of course, their models change over time. The 900VA smart UPS pro delivers up to 540W, IIRC, and when it's overloaded it very annoyingly beeps, but it continues to provide power. I guess it shuts down when it's overloaded and the main power fails, but I've never had that happen yet. For only 300W you go for this one: https://www.apc.com/us/en/product/BR700G/apc-backups-pro-700va-420w-tower-120v-6x-nema-515r-outlets-avr-lcd-user-replaceable-battery/ Just keep in mind that you usually end up needing a UPS with higher capacity than you planned for. So it makes sense to check what the batterie(s) cost and what the price difference between models with lower and higher capacity is. Some models take two or more batteries while the version with lower capacity may take the same battery but only one, making it overall so much cheaper that the model with more capacity that requires two (or more) batteries may get too expensive. But there may be a model with slightly more capacity that still takes only one battery and you may be glad later that you spent a little more money for more capacity. Definitely stay away from UPSs from HP. If you can reach someone from HP at all, they will charge you before they would tell you what the price of the batteries might be :( Eaton probably makes good ones, too, but they're not common here, same as another manufacturer the name of which I can't remember. So I have no experience with them. Of course, you don't want to buy one from an unknown manufacturer with no reputation, especially when it's a chinese one. The batteries are pretty generic, but for all you know, the manufacturer may have not understood that pretty high currents can flow in an UPS and probably has skimped on the wiring and/or other components to keep it cheap, and it'll set your house on fire. APC has understood that even in their basic models (at least for the wiring; I can't tell for the other components since I don't have enough knowledge about those). After having said all the above, it's pretty simple because it comes down to that, unless anything APC is difficult to come by where you life, you can't go wrong with APC. [1]: https://cdn-reichelt.de/bilder/web/xxl_ws/E910/APC_BX1400U_01.png [2]: https://oaziscomputer.hu/images/products/6934_apc-back-ups-pro-900-br900g-gr_1527776643.jpg
Re: Automatically installing GRUB on multiple drives
Hi, Keeping all this context because I don't actually see how the response matches the context and so I might have missed something… On Sun, Jan 28, 2024 at 11:54:05AM -0500, Dan Ritter wrote: > hw wrote: > > How is btrfs going to deal with this problem when using RAID? Require > > hardware RAID? > > > > Having to add mdadm RAID to a setup that uses btrfs just to keep efi > > partitions in sync would suck. > > You can add hooks to update-initramfs or update-grub. > > To a first approximation: > > firstbootpart = wwn-0x5006942feedbee1-part1 > extrabootparts = wwn-0x5004269deafbead-part1\ > wwn-0x5001234adefabe-part1 \ > wwn-0x5005432faebeeda-part1 > > for eachpart in $extrabootparts ; \ > do cp /dev/disk/by-id/$firstbootpart /dev/disk/by-id/$eachpart; done I realise that the above is pseudocode, but I have some issues with it, namely: a) I don't see what this has to do with btrfs, the subject of the message you are replying to. Then again, I also did not see what btrfs had to do with the thing that IT was replying to, so possibly I am very confused. b) My best interpretation of your message is that it solves the "how to keep ESPs in sync" question, but if it is intended to do that then you may as well have just said "just keep the ESPs in sync", because what you wrote is literally something like: cp /dev/disk/by-id/wwn-0x5002538d425560a4-part1 /dev/disk/by-id/wwn-0x5002538d425560b5-part1 which …is rather like a "now draw the rest of the owl" sort of response given that it doesn't literally work and most of the job is in reworking that line of pseudocode into something that will actually work. If someone DOES want a script option that solves that problem, a couple of actual working scripts were supplied in the link I gave to the earlier thread: https://lists.debian.org/debian-user/2020/11/msg00455.html https://lists.debian.org/debian-user/2020/11/msg00458.html Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Automatically installing GRUB on multiple drives
hw wrote: > How is btrfs going to deal with this problem when using RAID? Require > hardware RAID? > > Having to add mdadm RAID to a setup that uses btrfs just to keep efi > partitions in sync would suck. You can add hooks to update-initramfs or update-grub. To a first approximation: firstbootpart = wwn-0x5006942feedbee1-part1 extrabootparts = wwn-0x5004269deafbead-part1\ wwn-0x5001234adefabe-part1 \ wwn-0x5005432faebeeda-part1 for eachpart in $extrabootparts ; \ do cp /dev/disk/by-id/$firstbootpart /dev/disk/by-id/$eachpart; done You'll need to provide suitable values for the partitions, and remember to fix this when you change disks for any reason. And test it, because I have not even run it once. -dsr-
Re: rsync --delete vs rsync --delete-after
On Fri, 2024-01-26 at 16:27 +, Michael Kjörling wrote: > On 26 Jan 2024 16:39 +0100, from h...@adminart.net (hw): > [...] > > 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. It's simple: when using RAID1 with 2 disks, you double the physical storage capacity needed. When using 2 independent disks, you also double the capacity. In either case, when a disk fails, the RAID has a chance to survive the failure while the single disks don't (ignoring that you may be able to recover data from a failed disk). So either you don't loose a backup or you do loose one backup. If you're lucky, you loose the outdated backup rather than the most recent one. If you made the backup on RAID, you don't loose the most recent backup. I like it better not to loose the most recent backup. That's assuming that you have storage capacity for a single backup, i. e. one backup on RAID vs. one most recent backup on one disk and on older backup on the other disk. Of course, when you have multiple generations of backups on each set of disks, things get more complicated. It also gets more complicated when the volume you're making backups of doesn't fit on a single disk ... > [...] > > 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: I have to disagree here. The backup is always critical before you have eliminated the possibility that the data can get lost. Only when you have done that, then you don't need a backup at all.
Re: Automatically installing GRUB on multiple drives
Hi, On Sun, Jan 28, 2024 at 05:17:14PM +0100, hw wrote: > Ok if Andy and you are right, you could reasonably boot machines with > an UEFI BIOS when using mdadm RAID :) I've been doing it for more than two decades, though not with UEFI. > How is btrfs going to deal with this problem when using RAID? Require > hardware RAID? > > Having to add mdadm RAID to a setup that uses btrfs just to keep efi > partitions in sync would suck. ESP have to be vfat so why are you bringing up btrfs? If you want to use btrfs, use btrfs. UEFI firmware isn't going to care as long as your ESP is not inside that. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Automatically installing GRUB on multiple drives
On Fri, 2024-01-26 at 16:57 +0100, Nicolas George wrote: > 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. Ok if Andy and you are right, you could reasonably boot machines with an UEFI BIOS when using mdadm RAID :) How is btrfs going to deal with this problem when using RAID? Require hardware RAID? Having to add mdadm RAID to a setup that uses btrfs just to keep efi partitions in sync would suck.
mv bug - cannot move to subdirecctory of itself.
So I'm not certain if I'm in the right spot but I had to start somewhere. I have a docker container that was working but has suddenly stopped working. I believe the possible cause was when I added a second drive to my zfs rpool - the timing was a little too coincidental. The docker command sequence I'm running is: RUN wget https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-1.3.2-linux-x86-64.tar.gz -O /tmp/webp/webp.tar.gz RUN tar -xvf /tmp/webp/webp.tar.gz --directory /tmp/webp/unzipped RUN mv /tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp /usr/bin/cwebp ``` which results in the error: ``` mv: cannot move '/tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp' to a subdirectory of itself, '/usr/bin/cwebp' The command '/bin/sh -c mv /tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp /usr/bin/cwebp' returned a non-zero code: 1 ``` So clearly /usr/bin isn't a subdirectory of /tmp/webp so the error must be wrong. There are no symlinks involved. zfs list reports: ``` rpool 402G 493G 96K / rpool/ROOT 141G 493G 96K none rpool/ROOT/ubuntu_c520d1 141G 493G 18.8G / rpool/ROOT/ubuntu_c520d1/srv 208K 493G 96K /srv *rpool/ROOT/ubuntu_c520d1/usr 522M 493G 96K /usr* rpool/ROOT/ubuntu_c520d1/usr/local 522M 493G 515M /usr/local rpool/ROOT/ubuntu_c520d1/var 36.2G 493G 96K /var rpool/ROOT/ubuntu_c520d1/var/games 208K 493G 96K /var/games rpool/ROOT/ubuntu_c520d1/var/lib 23.3G 493G 16.8G /var/lib rpool/ROOT/ubuntu_c520d1/var/lib/AccountsService 744K 493G 100K /var/lib/AccountsService rpool/ROOT/ubuntu_c520d1/var/lib/NetworkManager 2.64M 493G 236K /var/lib/NetworkManager rpool/ROOT/ubuntu_c520d1/var/lib/apt 232M 493G 98.8M /var/lib/apt rpool/ROOT/ubuntu_c520d1/var/lib/dpkg 327M 493G 74.1M /var/lib/dpkg rpool/ROOT/ubuntu_c520d1/var/log 2.23G 493G 1002M /var/log rpool/ROOT/ubuntu_c520d1/var/mail 208K 493G 96K /var/mail rpool/ROOT/ubuntu_c520d1/var/snap 10.7G 493G 12.8M /var/snap rpool/ROOT/ubuntu_c520d1/var/spool8.26M 493G 2.36M /var/spool rpool/ROOT/ubuntu_c520d1/var/www 300K 493G 108K /var/www *rpool/USERDATA 251G 493G 96K /* rpool/USERDATA/bsutton_b4334o 250G 493G 68.9G /home/bsutton rpool/USERDATA/root_b4334o 854M 493G 845M /root rpool/var 9.39G 493G 96K /var rpool/var/lib 9.39G 493G 96K /var/lib *rpool/var/lib/docker 9.39G 493G 9.39G /var/lib/docker* ``` Of course these paths shouldn't be relevant as all of the paths in the docker container should be inside a docker volume all mounted under /var/lib/docker. The reason I'm here is because of this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923420 When I run 'info coreutils' it reports : ``` This manual documents version 8.32 of the GNU core utilities, including ``` >From my reading of the bug 8.32 should have a fix for the mv bug. Now this could well be a bug in docker as it has a somewhat dubious history of working with zfs but the symptom I'm encountering seemed to match the above bug so here I am. Any help or suggestions where to go would be appreciated. Brett ``` Step 6/30 : RUN lsb_release -a ---> Running in c5120a6be61b No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Release: 22.04 Codename: jammy ``
Re: Request about Boot Repair Disk
Am 27.01.2024 um 19:03 schrieb fran...@libero.it: > (it is a long report) This is interesting ... BUT i lack the required experience: Neither do i use Windows nor a notebook, but i would guess, that the last paragraph from your report contains the root cause of your problem: > Please do not forget to make your UEFI firmware boot on the Debian GNU/Linux > 12 (bookworm) entry (sda1/efi//shim.efi ( will be updated in the > final message) file) ! > If your computer reboots directly into Windows, try to change the boot order > in your UEFI firmware. > > If your UEFI firmware does not allow to change the boot order, change the > default boot entry of the Windows bootloader. > For example you can boot into Windows, then type the following command in an > admin command prompt: > bcdedit /set {bootmgr} path \EFI\\shim.efi ( will be updated in > the final message) > As you already found by yourself, both systems are setup to be bootable in uefi mode, and uefi by default has some way of making a choice (either at boot time of through changing the boot order permanently) GRUB is not strictly necessary for this to happen, but it can be used in the mix. What would be very good to know, is, how is your firmware manufactured and what does it allow? How does it cooperate? If you want to get a better understanding of the UEFI boot process (with or without grub), i recommend reading the documentation at https://www.rodsbooks.com/linux-uefi/ good luck